Módulo 01 - BI Aula Pratica

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
Nesta aula
 Histórico.
 Definição.
 Arquitetura básica.
Histórico
 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.
Definição
O que é
Inteligência
de Negócios?
Definição
 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.
Arquitetura básica
 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
Conclusão
 Histórico.
 O que é?
 Arquitetura resumida.
Próxima aula
 Data Warehouse.
Aula 1.2. Data Warehouse
Nesta aula
 Características do Data Warehouse.
 Data Marts.
 Estrutura do Data Warehouse.

Introdução
 Um Data Warehouse (DW, DWH ou armazém de dados) é um conjunto

de dados produzido para oferecer suporte à tomada de decisões; é
também um repositório de dados atuais e históricos, disponível para
os responsáveis pelas empresas ou instituições.
Características do Data Warehouse
 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 à decisão.
 Integrado. A integração está bastante ligada à 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 à 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 atualizá-los.
Data Marts
 Um Data Warehouse une bancos de dados de toda uma empresa; já um Data

Mart normalmente é menor e se concentra em um assunto ou departamento
especifico. Um Data Mart é um subconjunto de um Data Warehouse, que
normalmente consiste em uma única área temática (p. ex., marketing,
operações).
Estrutura de um Data Warehouse
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.
Conclusão
 Data Warehouse.
 Data Marts.
 Estrutura resumida.
Próxima aula
 Maturidade para BI.

Capítulo 2. Maturidade para BI

Aula 2.1. Maturidade para BI
Nesta aula
 Maturidade para BI.
 Estágios de maturidade.
Introdução
 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.
Modelo TDWI
Estágio 1 – Inexistente
 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.
O Golfo
 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.

Estágio 2 – Preliminar
 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 3 – Repetido
 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ão e 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.
O Abismo
 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.
Estágio 4 – Gerenciado
 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 5 – Otimizado
 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.
Conclusão
 Empresas encontram-se em estágios específicos dependendo de sua

maturidade.
 Obstáculos a serem enfrentados para avançar estágios.

Próxima aula
 Dimensões do modelo de maturidade.

Aula 2.2. Dimensões do modelo de maturidade
Nesta aula
 As dimensões do modelo de maturidade.
 Forma de avaliação da maturidade.

Introdução
 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.
Escopo
 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.
Patrocinador
 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.
Apoio financeiro
 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.
Retorno
 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.
Arquitetura
 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.
Dados
 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.
Desenvolvimento
 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.
Entrega
 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.

Instruções de valor para cada dimensão
Conclusão
 Dimensões analisadas para definir a maturidade.

Próxima aula
 Etapas de um projeto de BI.

Capítulo 3. Etapas de um projeto de BI

Aula 3.1.1. Etapas de um projeto de BI (Parte 1)
Nesta aula

Introdução
Justificativa
 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 dos custos.
– 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.
Planejamento
 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.
Análise
 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.
Conclusão
 Como justificar um projeto de BI.
 Necessidade de um planejamento.
 Análise em um projeto de BI.

Próxima aula
 Continuação: etapas de um projeto de BI.

Aula 3.1.2. Etapas de um projeto de BI (Parte 2)
Nesta aula

Introdução
Design
 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.
Construção
 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.

Implantaçã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.
Etapas
 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.
Conclusão
 Etapas do projeto de BI.
 O fim de uma etapa é o início de outra.
 Aprender com projetos anteriores.

Próxima aula
 Equipe de um projeto de BI.

Capítulo 4. Equipe de um projeto de BI

Aula 4.1. Equipe de um projeto de BI
Nesta aula
 Equipe de um projeto de BI.
 Equipe principal e estendida.

Introdução
 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.
Equipe principal
 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).

Outros membros da 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.
 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.
 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.
Equipe estendida
 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.

Conclusão
 Equipe do projeto.
 Equipe engajada.
Próxima aula
 Planejamento de um projeto de BI.

Capítulo 5. Planejamento de um projeto de BI

Aula 5.1. Planejamento de um projeto de BI
Nesta aula
 Planejamento de um projeto de BI.

Introdução
 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.
Envolvimento do negócio
 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?
Escopo do projeto
 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?
Análise de custo-benefício
 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?

A infraestrutura
 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?

Pessoal e habilidades
 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?
Conclusão
 Aspectos a serem analisados para planejar um projeto de BI.

Próxima aula
 Gerenciamento do projeto.
 Definição do projeto.
Aula 5.2. Gerenciamento e definição de um projeto de BI
Nesta aula
 Gerenciamento de um projeto de BI.
 Definição de um projeto de BI.

Introdução
 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.

Gerenciamento de projetos
 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.
Definição do Projeto de BI
 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.
Metas e objetivos
 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.
Escopo do projeto
 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).
Riscos de 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.
Restrições
 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
 Sequência não desejada, mas frequentemente é adotada.

Restrições
 Sequência desejada e que felizmente várias empresas adotam.

Premissas
 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.
Procedimentos de controle de mudança
 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ável no 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.
Conclusão
 Aspectos a serem analisados para planejar um projeto de BI.
 Gerenciar riscos.
 Tomar decisões que menos afetarão o projeto.

Próxima aula
 Planejamento do projeto de BI.

Aula 5.3. Dependências e tarefas do projeto de BI
Nesta aula
 Tarefas e atividades a serem desenvolvidas.
 Dependências entre tarefas.
 Estimativas.
Introdução
 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.

Atividades e tarefas
 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.
Técnicas de estimativa
 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.
Atribuição de recursos
 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.
Dependências de tarefas
 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 recursos
 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.
Método do caminho crítico
 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.
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
Conclusão
 Listagem de atividades e tarefas.
 Dependências entre as tarefas.
 Criação do cronograma.
Próxima aula
 Sequência de atividades do planejamento.

Aula 5.4. Atividades para o planejamento de um projeto
de BI
Nesta aula
 Lista de atividades para planejar um bom projeto de BI.

Introdução
 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.
Atividades do planejamento
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).
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.
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.
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”.
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.
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.
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.
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.
Conclusão
 Atividades básicas para elaborar e iniciar um projeto de BI.

Próxima aula
 Ciclo analítico da inteligência de negócios.

Capítulo 6. Ciclo analítico do BI

Aula 6.1. Ciclo analítico do BI
Nesta aula
 O processo iterativo para análise de negócios.

Introdução
 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
Monitoramento de atividades
 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.
Identificação das exceções
 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.
Determinação dos fatores causais
 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.
Modelagem de alternativas
 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.
Atuação e acompanhamento dos resultados
 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.
Conclusão
 Análise de exceções e tratamento.

Próxima aula
 Tipos de soluções de BI.

Capítulo 7. Tipos de soluções de BI

Aula 7.1. Tipos de soluções de BI
Nesta aula
 Possibilidades de soluções empregadas em projetos de BI.

Introdução
 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
BI Estratégico BI Tático BI Operacional
Desenvolver e avaliar os Gerenciar iniciativas táticas Monitorar e otimizar

Objetivos de negócio objetivos de negócio de para alcançar objetivos processos operacionais de
longo prazo estratégicos negócio
Domínio de negócio
Escopo Organizacional Processos de negócio
específico.
Gerentes de negócio,
Executivos, analistas de Analistas de negócio, usuários operacionais
Usuários
negócio gerentes de negócio (internos e externos),
processos operacionais
Introdução
BI Estratégico BI Tático BI Operacional
Dentro de um mesmo dia

Tempo Meses e anos Diário, semanas, meses
a diário
Tempo real, quase em

Dados Históricos Históricos tempo real, de baixa
latência e históricos
Centrados em processos,
Centrados em dados, Centrados em dados,
Modo de Operação direcionados a usuários e
direcionado a usuários direcionado a usuários
processos
Consultas de acesso direto
 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.

Relatórios padrão
 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
BI Operacional
 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.

Conclusão
 Tipos de soluções de BI.
 Estratégicas, táticas e operacionais.
 Todas são importantes.

Próxima aula
 Aplicativos analíticos, gestão do conhecimento, inteligência competitiva.

Aula 7.2. Aplicativos analíticos, gestão do conhecimento,
inteligência competitiva
Nesta aula
 Aplicativos analíticos.
 Importância da gestão do conhecimento e inteligência competitiva nas

empresas.
Aplicativos analíticos
 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.
Gestão do conhecimento
 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.
Captar Reter Desenvolver Compartilhar
 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.
Inteligência competitiva
 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.

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

Conclusão
 Aplicações analíticas.
 Importância e frutos da gestão do conhecimento e da inteligência

competitiva.
Próxima aula
 Mineração de dados.
Aula 7.3. Mineração de dados
Nesta aula
 Mineração de dados.
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
Mineração de dados
 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.
 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.
 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.
Conclusão
 O apoio do Data Mining na tomada de decisões.
 Descoberta de informações para geração de conhecimento.

Próxima aula
 Dashboards e scorecards.
Aula 7.4. Dashboards e scorecards
Nesta aula
 Camada de apresentação por dashboards e scorecards.

Introdução
 Interfaces de alto nível com forte apelo visual.
 Imagens de leitura e interpretação rápida.
 Indicadores facilitadores de compreensão.

Dashboards
 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?

Scorecards
 De um ponto de vista de alto nível, balanced scorecard (BSC) é 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 – Perspectivas estratégicas
Scorecards
 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
Conclusão
 Visualização a partir de dashboards.
 Formulação e utilização de scorecards.

Próxima aula
 Modelagem dimensional, tabelas fato e dimensão.

Capítulo 8. Modelagem multidimensional

Aula 8.1. Modelagem multidimensional
Nesta aula
 Visão multidimensional de dados.
 Tabelas fato e dimensão.

Introdução
 Imagem global da realidade do negócio.
 Informações em níveis apropriados de detalhes.
 Otimização das consultas.
 Mais intuitiva.
Dimensional x Relacional
 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).

loja lojaDepto depto
cidade bairro
ProdDepto
tipoVenda itemVendido
produto
hora
marca categoria
dia
mês fornecedor subCategoria

Cidade
tipoVenda Bairro
Loja
depto
itemVendido
Produto
Ano Marca
Mês Fornecedor
Dia subcategoria
Hora Categoria
depto
Modelagem dimensional
Modelagem dimensional
Componentes do modelo dimensional
Tabela fato
 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
 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)

Tabelas fato x dimensão
 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.

Modelos estrela e floco de neve
 Modelo estrela
– Dimensões desnormalizadas.
 Modelo snowflake
– Dimensões normalizadas.
Modelos estrela e floco de neve
Conclusão
 Diferenças e vantagens do modelo dimensional para BI.
 Características das tabelas fato e dimensão.

Próxima aula
 Hierarquia das dimensões.

Aula 8.2. Hierarquia das dimensões
Nesta aula
 Hierarquia das dimensões.
 Pontos importantes da modelagem dimensional.

Introdução
 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.

Hierarquia de dimensões
Hierarquia de dimensões
 As hierarquias não devem ser divididas em tabelas dimensões

diferentes.
 Dimensões correlacionadas devem ser combinadas.

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.
Pontos a destacar
 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.
Conclusão
 Hierarquia de dimensões.
 Medidas aditivas e não aditivas.
 Dimensões temporais.
 Dicas e mitos.
Próxima aula
 Enterprise Data Warehouse.
 Bus Matrix.
Aula 8.3. Enterprise Data Warehouse Bus Matrix
(EDWBM) e projeto dimensional
Nesta aula
 Enterprise Data Warehouse Bus Matrix (EDWBM).
 Projeto dimensional.
Introdução
 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.
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.

Bus Matrix
 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.
Projeto dimensional
 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.

Pontos a destacar
 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.
Conclusão
 A arquitetura EDWBM.
 Projetando um modelo dimensional.

Próxima aula
 Operadores.
Aula 8.4. Operadores
Nesta aula
 Operadores em modelos dimensionais.
 OLAP.
Introdução
 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.
Cubo OLAP
Analisando o cubo OLAP
Drill down e roll up
 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.
Roll up
Drill down
Drill across e drill through
 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
Slice and dice
 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
Pivot
 É 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
Outros possíveis operadores
 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.

Conclusão
 Operações possíveis de serem realizadas em cubos OLAP.

Próxima aula
 Dados informacionais x operacionais.
 Data Warehouses.
 Data Marts.
 Documentação.
Aula 8.5. Dados informacionais x operacionais, Data
Warehouses, Data Marts e documentação
Nesta aula
 Dados informacionais x operacionais.
 Data Warehouses.
 Data Marts.
 Documentação.
Introdução
 Fixação de conceitos.
 OLTP X OLAP.
 DW X DM.
 Importância da documentaçã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 Estruturado em fatos e
tabelas, processamento dimensões, com processamento
repetitivo analítico/preditivo
Tempo de resposta Otimizado para faixas abaixo de 1 Análises mais complexas, com
segundo tempos de resposta maiores
Data Warehouse e Data Mart
 Revisão dos conceitos.
 Aplicações do DW e DM.
 Formas de construção.
 Aplicações.
Data Warehouse e Data Mart
Data
Warehouse
Data Mart Data Mart

vendas inventário
Data Mart Data Mart

marketing atendimento
Data Warehouse
 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 – Benefícios
 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 Mart
 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 – Benefícios
 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 Warehouse x Data Mart
 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.
Construção Top-Down
 Construção do DW e especialização dos DMs.

Construção Bottom-Up
 Construção dos DMs e expansão para o DW.

Documentação
 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.

Conclusão
 Dados OLTP e OLAP.
 Revisão de conceitos fundamentais.
 DW e DM.
 Documentação.
Próxima aula
 Abordagens para modelagem de aplicações BI.

Capítulo 9. Abordagens de Bill Inmon e Kimball

Aula 9.1. Abordagem de Bill Inmon
Nesta aula
 Modelagem de DW.
 Inmon x Kimball.
 Características.
Introdução
 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
kimball
Inmon
Abordagem Inmon
 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 – Vantagens
 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 – Desvantagens
 Abordagem Top-Down centrada nos 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.

Conclusão
 Abordagens Inmon e Kimball.
 Características da abordagem Bill Inmon.

Próxima aula
 Abordagem Kimball.
Aula 9.2. Abordagem de Kimball
Nesta aula
 Características da Abordagem de Kimball.

Introdução
 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)
Inmon
kimball
Abordagem Kimball – Vantagens
 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 – Desvantagens
 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.
Conclusão
 Abordagem Kimball.
 Abordagem mais indicada.

Próxima aula
 Ciclo Kimball.
Aula 9.3. Ciclo Kimball
Nesta aula
 Processo para o desenvolvimento de um DW.

Introdução
 Diagrama do ciclo de vida de um projeto de BI por Kimball.

Ciclo Kimball – Modelagem
 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.

Seleção do processo de negócio
 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.
Definição do grão
 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.
Escolha das dimensões
 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.
Métricas das tabelas de fatos
 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.
Conclusão
 O ciclo Kimball.
 Detalhamento da fase de análise e modelagem.

Próxima aula
 Quadrante mágico.
Capítulo 10. Aplicativos de BI

Aula 10.1. Quadrante mágico dos aplicativos de BI
Nesta aula
 O quadrante mágico da Gartner.

Introdução
 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.
Quadrante mágico
 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 determinadas características de um mercado. Basta imaginar
uma empresa automobilística focada apenas em carros 4×4 para
trilheiros. Ela se diferencia de uma fabricante de carro comum.
Quadrante mágico
Conclusão
 Apoio do quadrante na escolha de ferramentas.

Próxima aula
 Apresentação de aplicativos de BI.

Aula 10.2. Apresentação de aplicativos de BI
Nesta aula
 Apresentar alguns populares e bons aplicativos de BI.
 Pentaho PDI.
 Microsoft Power BI.
 Tableau.
Pentaho PDI
Pentaho PDI
 O Pentaho Data Integration é o componente da suite Pentaho usado para criar processos
de ETL. Trata-se da ferramenta mais popular e madura da suite inteira, com seus mais de
15 anos de existência.
 Com o Pentaho Data Integration é possível fazer inúmeras operações de integração de

dados, como por exemplo:
– Migração de dados;
– Movimentação de grandes volumes de dados;
– Transformação de dados;
– Limpeza de dados;
– Conformidade de dados.
Pentaho PDI - Spoon
Pentaho PDI
 O Pentaho Data Integration é formado por duas categorias de

artefatos: jobs e transformações.
 O Pan é o programa que executa transformações.
 O Kitchen executa os jobs.

Pentaho PDI – Transformações
 É a operação sobre os dados.
 Opera as etapas simultaneamente sobre as linhas que chegam.
 Exemplo de operações:
– Leitura de dados de uma tabela, de um banco de dados;
– Seleção de campos específicos de uma tabela;
– Concatenação de valores de dois campos distintos de uma tabela;
– Divisão de valores contidos em um único campo gerando dois ou mais novos campos ou linhas;
– Merge de dados de tabelas contidas em bancos de dados diferentes;
– Merge de dados originados em tabelas, arquivos XML, TXT ou CSV, entre outras fontes de dados;
– Aplicação de expressões regulares em texto para limpeza.

Pentaho PDI – Jobs
 Um job sequencia operações.
 Ao contrário de uma transformação, que opera sobre as linhas de

dados em paralelo, um job realiza operações completas, uma por uma.
 Ele permite, por exemplo, combinar transformações em uma

sequência específica e, com isso, automatizar uma dada tarefa. Por sua
natureza, ele não fornece muitos recursos técnicos para manusear os
dados em si, deixando isso a cargo das transformações.
Power BI
Power BI
Power BI
Power BI
 Facilidade de uso.
 Tutoriais e vídeos no site oficial.
 Grande comunidade.
 Utilização fácil mesmo para profissionais que não são da área de TI.
 Linguagem natural.
 Baixo custo.
 Ricas e abundantes funcionalidades da área de apresentação.

Tableau
Tableau
Tableau
 Aprendizagem em minutos.
 Vídeos e tutoriais no site que facilitam o aprendizado.
 Diversas versões: Mobile, public, server, etc.
 Diversas funcionalidades de visualização.
 Facilidade e eficiência em integrar dispositivos móveis.

Conclusão
 Aplicativos para apoio no projeto de BI.

Módulo 01 - BI Aula Pratica

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Módulo 01 - BI Aula Pratica

Título original:

Enviado por

Direitos autorais:

Fundamentos em Inteligência de Negócio

Capítulo 1. Definição e fundamentos de BI

Prof. Daniel Capanema

 1865: O primeiro uso conhecido do termo “business intelligence”. Richard

 1958: IBM, Hans Peter Luhn: “A capacidade de apreender as inter-relações

 Anos 70 e 80: Crescimento da popularidade dos sistemas de apoio à

 Década de 1990: Ferramentas de Business Intelligence. O termo e as técnicas se tornam

 2000: Análise preditiva. Aprendizado de máquinas para prever mudanças no futuro do

 BARBIERE: Business Intelligence representa a habilidade de se estruturar, acessar e

 KIMBALL e ROSS: Business Intelligence é um termo genérico para descrever o

 MOSS e ATRE: O BI não é um produto, nem um sistema. É uma arquitetura e uma

 Gartner Group: Business Intelligence é definido como a aplicação de

 As aplicações de BI podem auxiliar em vários segmentos das

– Alterações no comportamento de clientes e padrões de consumo;

– Recursos das empresas;

 De maneira mais ampla, pode-se dividir a arquitetura de BI em três

– Repositório de dados analíticos;

 Características do Data Warehouse.

 Estrutura do Data Warehouse.

 Um Data Warehouse (DW, DWH ou armazém de dados) é um conjunto

 Integrado. A integração está bastante ligada à orientação por assunto. Os Data

 Um Data Warehouse une bancos de dados de toda uma empresa; já um Data

 Data Sources: É de onde estaremos buscando, extraindo os dados que serão

 Data Staging Area: Parte do Data Warehouse responsável pelo

 Data Presentation Area: É onde os dados estão organizados, armazenados e

 Maturidade para BI.

Prof. Daniel Capanema

 Maturidade para BI.

 Métodos de gestão e visão voltados para o passado podem acarretar o

 As ferramentas são apenas uma parte do processo, e é preciso o

 A maioria dos projetos de BI não obtém sucesso por não ter a

 Moore (2003) define modelo de maturidade como sendo uma

 As empresas necessitam, portanto, medir qual seu nível de maturidade

 Existem vários modelos para analisar o nível de maturidade de uma

 Este estágio é formado por duas fases que estão interligadas:

– Spreadmarts: Os próprios usuários usam aplicativos, geralmente planilhas

 O golfo é o primeiro obstáculo enfrentado. Desafios:

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

 Inserção em um ambiente de BI e DW.

 Primeiras ferramentas de BI, principalmente de consultas, relatórios e

 Alguns usuários começam a usar as ferramentas para analisar

 Busca de insights. Como o negócio foi executado no passado?

 Iniciativa de âmbito departamental.

 Utilização de modelo padrão de projeto e desenvolvimento de metodologias que

 Cresce o uso do BI entre usuários casuais, que utilizam informações em conjuntos

 Obstáculo mais amplo e mais profundo do que o golfo. Desafios:

– Padronização: Conciliar termos, definições e regras em diversos Data Marts e DW é

– Transição para TI corporativa: Dificuldade dos departamentos entregarem suas

– Caos de relatórios: Muitos relatórios. Repetidos e desencontrados.

– Evitar inflexibilidade de arquitetura: as soluções de BI têm de se adaptar

 Arquitetura unificada: Arquitetura de DW que define o conjunto comum de regras, termos e

 Totalmente carregado: DW totalmente carregado com todos dados necessários para os

 Flexível: Os desenvolvedores isolam a arquitetura permitindo fazer mudanças em um

 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

 Retorno para as unidades de negócio através de centros de excelência.

– Empresa ampliada: Organizações utilizam BI e DW para oferecer aos

 Empresas encontram-se em estágios específicos dependendo de sua

 Obstáculos a serem enfrentados para avançar estágios.

 Dimensões do modelo de maturidade.