Plataformas de BI Na Prática

Plataforma de BI na Prática
Autor
Allan Herison Ferreira
Autora revisora
Elisamara de Oliveira
Apresentação
Olá, estudante! Iniciamos aqui um percurso que tem como objetivo oferecer conhecimento e
informações necessárias para o desenvolvimento de competências que permitam a você auxiliar
organizações de todo tipo a melhorarem o modo como utilizam dados e informações no
processo de tomada de decisão.
O uso científico dos dados é cada vez mais valorizado por todo tipo de instituições: sociais,
privadas, governamentais, acadêmicas, do terceiro setor... e um dos pilares para o bom uso de
dados, de modo científico, ou por que não dizer, da Ciência de Dados, é partir de premissas e
pressupostos bem fundamentados, basear-se em modelos bem estruturados (de dados, de
tecnologias e de processos) e pautar-se por dados validados que correspondam à realidade
objetiva, à fatualidade dos eventos relevantes a serem descritos, mensurados e analisados.
Nesta disciplina, nossa jornada passa por três etapas fundamentais para o processo de tomada
de decisão e para a Ciência de Dados ou Data Science, sendo elas: do histórico, do contexto e da
análise (do passado, do presente ou do futuro).
Enfatizamos a importância dos dados históricos para processos de tomada de decisão.

Compreender o modo como as organizações funcionam, se organizam e como ocorre o processo
de tomada de decisão de seus gestores e dirigentes é condição indispensável para quem é
responsável por propor soluções de problemas na área de Inteligência de Negócios, bem como
para quem se propõe a entregar soluções de Ciências de Dados. Desse modo, compreender os
tipos de problemas que cada nível organizacional procura resolver é também essencial.
Esperamos que você aproveite ao máximo este percurso e que o torne ainda mais proveitoso
relacionando os pontos que apresentamos aqui com situações e experiências que você já viveu,
seja no ambiente corporativo, seja em situações domésticas e familiares. Pois, quanto mais você
puder encontrar exemplos significativos, mais profundamente e de modo mais intenso assimilará
os pontos aqui apresentados. Muito sucesso!
Prof. Allan H. Ferreira

Videoaula - Introdução ao Business Intelligence - Plataforma de BI
na Prática
Escaneie a imagem ao lado com um app QR code para assistir o vídeo ou clique aqui
[https://player.vimeo.com/video/490773848] .
1 Business Intelligence
1.1 Histórico deiBusiness Intelligencei
Ao tratarmos das soluções de Inteligência de Negócios, que é mais conhecida pelo termo
Business Intelligence, ou simplesmente pela sigla BI, é muito importante considerarmos que este
tipo de solução reúne não somente ferramentas (softwares ou sistemas), mas também
metodologias específicas e problemas bem definidos que visa resolver.
Além disso, as soluções de BI desenvolveram-se de modo orgânico por diferentes organizações

ao longo do tempo. Isso significa que as soluções de BI não surgiram “da noite para o dia” - ao
contrário! Tal como observado por Howard Dresner nos anos 1990, muitas empresas vieram
desde a década anterior (anos 1980) buscando maneiras de resolver problemas críticos ligados
ao uso de dados históricos para dar suporte ao processo de tomada de decisão. Dresner (Figura
1) observou que as soluções que as empresas vinham desenvolvendo apresentavam pontos
comuns importantes (que detalharemos adiante) e que posteriormente passaram a ser
classificadas como “soluções de inteligência de negócios” ou Business Intelligence Solutions
(CONNELLY; MACNEILL; MOSIMANN, 1996).
Figura 1 – Howard Dresner
Fonte: cdnl.tblsft.com
[https://cdnl.tblsft.com/sites/default/files/
blog/2011-09-09_1312.png]
Ou seja, a necessidade de resolver problemas, as tecnologias que estavam disponíveis e a

criatividade de pessoas que estavam determinadas a buscar soluções para tais problemas
surgiram antes do nome dado a este tipo de solução. Só então, depois que foi possível observar
um padrão comum entre tais práticas, é que surgiu o rótulo “BI” que se consagrou por meio de
Dresner e pelo Gartner Group (instituição que acompanha e avalia soluções em diversas áreas,
inclusive na área de sistemas de informação) cujo logotipo pode ser visto na Figura 2.
Figura 2 – Logotipo do Gartner Group
Fonte: wikimedia.org
[https://commons.wikimedia.org/wiki/File:
Gartner_logo.svg]
Caro estudante, utilizamos aqui referências, definições e citações do glossário do Gartner (2020)
por três motivos principais:
pelo fato de ser uma das instituições mais reconhecidas em termos de pesquisa e produção de
conhecimento em BI;
por utilizarem um método de revisão ponto a ponto que reúne a visão de especialistas com grande
atividade no mercado e na academia;
por constantemente atualizarem suas bases de conhecimento para atender às demandas do
mercado.
Começamos aqui com a definição do termo Serviços de BI ou Business Intelligence Services,

como segue:
Ofertas para projetar, desenvolver e implantar processos corporativos, bem como para integrar,
suportar e gerenciar as aplicações e plataformas tecnológicas relacionadas. Estas [ofertas] incluem
aplicações de negócios e infraestrutura para plataformas de BI, necessidades analíticas e
infraestrutura de data warehousing. As soluções incluem áreas como Corporate Performance
Management (CPM) e área analítica, além da tradicional plataforma de BI, da infraestrutura de Data
Warehouse e da área de qualidade de dados. (GARTNER, 2020)
Na virada dos anos 1980 para os anos 1990 dois autores desenharam aquelas que viriam a ser
as bases fundamentais de desenvolvimento de estruturas de dados para dar suporte às soluções
de BI: William “Bill” Inmon e Ralph Kimball (INMON, 2005; KIMBALL, 2006).
Cada um desses autores apresentou metodologias que traziam aspectos comuns e diferenças
em suas propostas para bases de dados gerenciais, Data Warehouses ou Data Marts. Embora
discordassem em relação a diversos aspectos sobre a implementação de estruturas de dados
para suporte ao ambiente de BI, ambos concordavam que o projeto de criação da base de dados
gerencial que oferece suporte ao ambiente de BI deve atender aos objetivos da organização, ser
realizável por meio de entregas moduladas, justificar o investimento aportado e ser escalável em
termos de desenvolvimento (INMON, 2005; KIMBALL, 2006).
Para que o processo de entendimento das soluções de BI seja mais eficaz, inclusive para quem
tem aqui o primeiro contato com esse tipo de solução, vamos dividir este conteúdo em dois
grandes blocos – somente para efeito de facilitação do aprendizado – são eles:
1. o bloco de arquitetura e processos

2. o bloco de ferramentas e componentes.
Assim sendo, em nossa disciplina, falaremos da relação entre estes dois blocos e observaremos
quais tipos de problemas estes visam inicialmente resolver. Então apresentaremos detalhes
sobre cada um deles e os cuidados que devemos ter ao desenvolvê-los antes de começarmos a
construir exemplos práticos relativos a ambos. Depois disso, integraremos os dois blocos e
analisaremos de modo prático os problemas, os processos, as dificuldades enfrentadas e as
soluções propostas pelas soluções de BI tendo em perspectiva o modo como contribuem para o
desenvolvimento de soluções de gestão de desempenho e, em última análise, para o universo da
Ciência de Dados.
As soluções de BI são propostas por profissionais que reúnem conhecimentos de

diferentes disciplinas e atuam na interseção entre os saberes tecnológicos, de negócios
e das análises quantitativas e qualitativas de dados e informações.
1.2 Histórico do desenvolvimento de soluções de BI
Nos anos 1980 e 1990, antes da consolidação das soluções de BI no mercado, os problemas
originais ou “anteriores” que as organizações ou empresas tiveram que enfrentar podem ser
assim resumidos:
Informatização dos processos operacionais: criação dos primeiros sistemas que atendiam
necessidades específicas das empresas.
Integração dos processos operacionais: junção de tarefas comuns entre diferentes sistemas
formando um sistema único como o ERP- Enterprise Resource Planning,ou seja, um sistema integrado
de gestão empresarial.
Divisão do ambiente gerencial/operacional: construção de bancos de dados gerenciais dedicados a
suprir as áreas de negócio para tomada de decisão.
Ao conhecermos esse histórico podemos observar que as soluções de BI surgiram, em grande

parte, para resolver problemas relativos ao próprio modo de como as empresas e organizações
utilizavam as tecnologias disponíveis para atingir seus próprios objetivos.
As organizações que nos anos 1980 e 1990 foram pioneiras em iniciativas do que viria a ser
chamado de BI percebiam a necessidade de entregar aos seus gestores informações do histórico
de dados de modo consolidado – mas com possibilidade de detalhamento dessas informações
– sem que isso gerasse impacto no processamento das informações operacionais que
garantiam o funcionamento da empresa (CONNELLY; MACNEILL; MOSIMANN, 1996)
Estudante, pergunte a si mesmo:
Por que uma organização visa implementar soluções de BI (ou de qualquer outro tipo)?
Que tipo de problemas a empresa visa resolver ao buscar uma solução?
Qual o histórico de tentativas de resolução desse problema, sucessos e fracassos que teve até então?
Buscar conhecer respostas a perguntas simples como essas pode ser o diferencial determinante
entre quem sabe e quem não sabe o que está fazendo em projetos que visam proporcionar
soluções reais.
Videoaula - Problemas e soluções em BI - um breve histórico
1.2.1 Dos ambientes transacionais para os gerenciais
Os bancos de dados transacionais, que utilizam modelagem relacional, são desenhados para
atender usuários operacionais e visam garantir que seja preservada a integridade e a otimização
do armazenamento dos dados em tabelas normalizadas – priorizando o controle da entrada dos
dados no sistema. Por outro lado, os bancos de dados gerenciais, que utilizam modelagem
multidimensional, são desenvolvidos para garantir a otimização da extração ou da “saída” dos
dados para os usuários gerenciais. Os ambientes gerenciais de dados ou bancos de dados, com
propósito de servir de base para o processo de tomada de decisões de equipes gerenciais, visam
atender a um perfil específico de usuários (CONNELLY, 2001).
Se, por um lado, o ambiente transacional é caracterizado por operações de curtíssimo prazo, por
outro lado, o ambiente gerencial de dados é marcado pela compreensão de prazos maiores, pela
consideração de dados mais resumidos e agregados.
Um usuário operacional que está fazendo o registro de uma venda no sistema está preocupado
em inserir cada dado daquela única operação com o máximo de qualidade, atenção e precisão.
Um usuário gerencial, seja ele um gerente, um coordenador ou um analista, está (de modo geral)
preocupado em analisar um conjunto maior de dados já agregados. Por exemplo, essa pessoa
pode desejar saber qual o volume de vendas feito ao final do dia, ao longo da semana, no último
mês ou ano. Em lugar de observar cada um dos pedidos em detalhe, venda a venda, essa pessoa
pode querer analisar primeiro os “grandes números” do dia, da semana ou do mês, demandando
assim, relatórios mais resumidos.
A Figura 3 traz uma pirâmide que resume as diferenças entre os ambientes transacionais e
operacionais.
Figura 3 – Ambiente Transacional x Ambiente Operacional
Fonte: Autoria própria
Já faz algumas décadas que gestores, coordenadores e analistas que não são especialistas na
área de TI se utilizam de ferramentas que apoiam a análise e visualização de dados, sem terem
que se tornar necessariamente programadores ou desenvolvedores de consultas a bancos de
dados. Isso ocorreu porque desde os anos 1980 veio ocorrendo um intenso processo de
simplificação da interface dos sistemas para melhor atender aos usuários “das áreas de
negócio” ou para melhor atender aos não técnicos.
Estudante, se um gestor que não tivesse conhecimentos fundamentais de programação ou

conhecimento sobre como fazer consultas a bancos de dados, nos anos 1980 ou 1990,
precisasse de um relatório simples que apresentasse os resultados das vendas de certos tipos de
produtos nos estados ao longo do último ano ele teria como obter esta informação sem apoio da
equipe de TI ou do Centro de Processamento de Dados? Provavelmente não. Ele teria, portanto,
que fazer solicitações à equipe do CPD ou do TI para que fizessem queries no banco de dados
onde estavam armazenadas estas informações.
Os bancos de dados que haviam sido desenvolvidos até então eram quase sempre modelados em
formato relacional, normalizados e preparados para o recebimento de um volume constante de
dados.
Agora, considere que esta empresa do nosso exemplo disponha somente de um único banco de
dados que armazena as informações no modelo relacional que é responsável pelo
armazenamento, registro a registro, de cada pedido que é feito durante o dia. Esse cenário é ainda
observável em empresas da atualidade, empresas de todos os portes, ainda que disponham de
bancos de dados gerenciais para atenderem muitas de suas áreas, setores ou departamentos.
Em cenários atuais, uma empresa que neste momento está desenvolvendo aplicações
extremamente avançadas que envolvem o uso de Big Data, Machine Learning ou ferramentas de
Data Science quase que invariavelmente possui bancos de dados relacionais que não oferecem
suporte à análise de dados gerenciais, planilhas de dados dispersas e informações não
completamente digitalizadas, processadas e armazenadas.
Esse ambiente heterogêneo é uma realidade com a qual os diferentes perfis de profissionais de
TI terão que lidar durante um bom tempo na maioria das vezes, seja porque a organização irá
priorizar os sistemas que merecerão ser desenvolvidos para atender às suas estratégias
corporativas, seja porque há limitações orçamentárias, intelectuais ou de pessoal, seja por
alguma combinação variável destes e de outros fatores.
Este cenário expõe dois dos principais problemas que a maioria das organizações enfrentavam
antes do surgimento das soluções de BI:
O problema da concorrência entre usuários transacionais/operacionais e usuários gerenciais pelos

mesmos recursos computacionais (acesso ao mesmo banco de dados desenvolvido para atender aos
processos operacionais/transacionais).
O problema da disponibilização dos dados de modo facilitado, acessível, organizado e interativo para
usuários das áreas não técnicas (disponibilização de uma interface de fácil uso para gestores das
diferentes áreas da organização).
Uma empresa de médio ou grande porte tem 100 vendedores responsáveis por registrar
as vendas feitas aos clientes. Cada um destes 100 vendedores atende, em média, 20
clientes por dia. Cada um desses clientes costuma fazer 10 pedidos por dia, cada um dos
quais incluindo 10 itens. Qual o volume de registros processados a cada dia?
Neste caso teremos:
100 (vendedores) × 20 (clientes) × 10 (pedidos) × 10 (itens por pedido) = ± 200 mil registros
por dia
Se, ao longo de 1 ano, há aproximadamente 250 dias úteis, teremos aproximadamente 50

milhões de registros armazenados no banco de dados transacional por ano.
Com base no exemplo, a questão é: qual o volume de dados para o qual esse banco de dados foi
projetado para processar em um único dia? 100 mil? Um milhão? Duas, cinco, dez vezes o
volume que costuma processar em média a cada dia?
Agora tome como exemplo o relatório mostrado na Tabela 1, que traz informações de vendas em
um certo ano.
Tabela 1 – Relatório de Vendas Anual
Quantidade Vendida (em milhares) 1º Trim. 2º Trim. 3º Trim. 4º Trim. 2020
Argentina 6 5 8 10 29
Brasil 12 8 9 11 40
Chile 7 5 6 8 26
TOTAL 25 18 23 29 94
Fonte: Elaborado pelo autor.

Com base nos cálculos mostrados no primeiro exemplo, se o relatório da tabela 1 tiver que ser
processado no meio de uma tarde normal durante a rotina desta empresa, qual o volume de
dados e a quantidade de registros que teriam que ser processados de uma única vez?
O banco de dados processaria 250 vezes mais registros do que estaria preparado para processar
ao longo do dia, pois o relatório gerencial analisa dados acumulados do ano, de uma única vez,
em nível máximo de detalhes, antes de chegar aos valores agregados exibidos no relatório. Isso
equivale a dizer que o banco de dados processaria até 50 milhões de registros de uma vez (ou
em uma única query)!
O banco de dados transacional foi projetado para responder a este tipo de demanda de
processamento? A resposta a esta questão é quase sempre negativa.
Este exemplo dramático poderia ser resolvido de diversas formas, ainda no ambiente
transacional, com maior ou menor efetividade, mas ajuda a compreendermos melhor o tipo de
problema que as organizações enfrentavam antes de começarem a desenvolver suas bases de
dados gerenciais.
A concorrência entre demandas gerenciais e operacionais pelos recursos computacionais

dedicados ao ambiente transacional é um dos principais problemas a serem resolvidos ao
projetarmos soluções de BI. E este problema está especificamente relacionado à arquitetura de
dados e ao modo como serão pensados os bancos de dados, suas camadas e processos de
extração, processamento e carga entre os mesmos, ao longo do desenvolvimento da solução de
BI. Este problema está ligado, portanto, ao modo de como os dados serão organizados em bases
de dados, em tabelas, em seus respectivos relacionamentos e processos de transferência de
dados.
Assim sendo, a equipe de sistemas irá desenvolver um banco de dados (ou conjunto de bancos
de dados) com modelagem específica que facilite aos gestores alcançarem seus objetivos
informacionais: obterem informações precisas, organizadas de modo facilitado e interativo.
Essa modelagem de dados (ao contrário das bases transacionais) não visa controlar registro a
registro o modo como cada usuário está alimentando o sistema, pois, ao contrário das bases
transacionais, esse banco de dados receberá informações já testadas, validadas e processadas
pelas próprias bases transacionais, e receberá os dados em lotes diários, semanais ou mesmo
em tempo real, mas de forma automatizada por meio de um processo que visa controlar a
extração, o processamento ou a transformação dos dados e sua alimentação ou carga na base
de dados gerencial. Esse processo, que você possivelmente conhece, é o ETL - Extract,
Transform and Load e faz parte da integração de dados.
O desenvolvimento da base de dados gerencial resolve os dois problemas que destacamos?
Você observará que o primeiro deles (concorrência entre usuários gerenciais e operacionais pelo
uso do banco de dados transacional) acaba por ser enfrentado por meio da construção de bases
de dados gerenciais modeladas e mais preparadas para receber demandas de consultas de
grandes volumes de dados. Por outro lado, um banco de dados gerencial continua sendo um
banco de dados que para ser consultado precisará de alguém que saiba programá-lo ou fazer
queries nele. É aí que surgem as ferramentas de BI, pois servem exatamente como interface para
a facilitação do acesso e uso das informações contidas nos bancos de dados gerenciais pelos
usuários das áreas de negócio ou pelos usuários não técnicos.
Certamente as ferramentas de BI demandarão algum nível de treinamento para seu uso, mas, de
modo geral, exigirão conhecimento técnico muito menor do que aquele necessário para fazer
programação em linguagem de consulta diretamente às bases de dados.
Os bancos de dados gerenciais visam disponibilizar as informações aos usuários não técnicos,
ou usuários das áreas de negócio, de modo simplificado e com alta capacidade de
processamento, sem gerar concorrência de processamento com bancos de dados transacionais.
Para isso, segundo Kimball (2006), quanto mais simplificado for o modelo de dados, melhor, e,
para Inmon (2005), quanto melhor integrado e validado o ambiente, melhor.
Videoaula - Ambientes transacionais e gerenciais- um breve

histórico
1.3 Projeto multidimensional:iData Marts ieiData Warehousesi
A modelagem multidimensional é uma técnica de criação, projeto e desenvolvimento de um

modelo de dados para um banco de dados gerencial. Seu objetivo principal é permitir a
sumarização e estruturação dos dados, de forma a apresentá-los em visões que permitam a
análise desses dados, visando o suporte às decisões estratégicas de uma organização
empresarial.
É utilizada especialmente quando uma empresa precisa obter diversas visões a respeito de um
mesmo acontecimento ou fato relevante para os negócios.
A modelagem multidimensional é utilizada no projeto de um Data Warehouse (DW). Este projeto

pode ser implementado usando uma arquitetura de Data Marts (DMs) independentes ou
integrados:
Na arquitetura independente, os DMs fornecem suporte à decisão para os grupos de usuários ou

departamentos, desempenhando o papel de um DW departamental, sem foco corporativo.
Na arquitetura integrada, os DMs, apesar de serem implementados separadamente por grupos de
usuários ou departamentos, são integrados ou interconectados, permitindo uma visão corporativa
dos dados.
A criação de um Data Mart (DM) pode ser tratada como um projeto-piloto para que uma empresa
conheça os benefícios da tecnologia antes de decidir pela implementação de um projeto de DW.
Um Data Mart pode ser definido como um subconjunto de dados do DW.
Quando o projeto de um banco de dados gerencial é desenhado para atender a uma área ou setor
específico da organização, este inicia-se pela criação de um Data Mart, nome que faz alusão aos
termos Dados (Data) e Mercado (Mart) no sentido da proximidade com o consumidor, ou do
“varejo”. Ou seja, os Data Marts são desenvolvidos para estarem disponíveis a um grupo de
usuários de dados gerenciais de modo quase sempre circunscrito a um assunto ou área da
organização.
Quando o projeto de um banco de dados gerencial é desenhado para atender ao conjunto das
áreas de modo corporativo, este inicia-se pela criação do Data Warehouse, nome relacionado aos
termos Dado (Data) e Armazém (Warehouse).
Um Data Warehouse (DW) é uma arquitetura de armazenamento projetada para armazenar dados
extraídos de sistemas transacionais e de outras fontes externas. O DW combina esses dados
(após processos de limpeza e transformação) para fomentar a análise de dados e para dar
suporte à geração de relatórios para toda a organização a fim de atender necessidades de
negócios predefinidas.
Os cinco componentes que formam a arquitetura de uma solução de BI baseada em Data

Warehouse, segundo o Gartner (2020) são:
as fontes de dados transacionais;

o processo de extração e conversão de dados;
os sistemas de gerenciamento de banco de dados multidimensional (DW);
a administração do servidor de DW;
as ferramentas de BI.
A Figura 4 mostra os principais componentes de uma solução de BI com DW e DMs.
Figura 4- Componentes de uma arquitetura de DW com DMs
Fonte: Adaptado de senior.com.br [https://www.senior.com.br/noticias/agilidade-e-confiabilidade-na-

tomada-de-decisao-impulsiona-companhias-a-adesao-de-ferramentas-de-business-intelligence]
Já dissemos que nos anos de 1990 houve um intenso debate entre os dois principais autores
relacionados à temática dos bancos de dados gerenciais. Vejamos as suas propostas com mais
detalhes a seguir.
Videoaula - Compreendendo demandas históricas
1.3.1 Ralph Kimball versus Bill Inmon
A Figura 5 traz a imagem de Ralph Kimball.
Figura 5- Ralph Kimball
Fonte: alchetron.com
[https://alchetron.com/Ralph-Kimball]
De acordo com a proposta de Ralph Kimball (2006), podemos destacar:
Os Data Marts (DMs) e Data Warehouses (DWs) deveriam funcionar como uma unidade integrada com
o máximo de detalhe, ou menor granularidade de dados, em modelo Estrela.
O banco de dados multidimensional deveria ter camadas anteriores que permitissem um melhor
tratamento ou armazenamento de dados em formato não dimensional, tal como os Operational Data
Stores. Porém, era no banco de dados multidimensional que os aspectos críticos como a garantia da
conformidade dos dados, a tradução para a linguagem de negócios, a possibilidade de realização de
análises agregadas e detalhadas (drill down, drill up, e drill through ou across) e a troca interativa de
dimensões (slice and dice) eram garantidos em termos de arquitetura e modelagem de dados em
Estrela.
A integridade dos dados deveria ser previamente garantida pelos sistemas transacionais, restando à
equipe responsável pelos bancos de dados gerenciais garantir essa integridade por meio de um
cuidadoso processo de ETL que alimentaria os DMs/DW em modelo Estrela.
Um conjunto de Data Marts, cada um deles formado por um ou mais conjuntos de tabelas em modelo
estrela (ou snowflake), ao ser integrado, comporia um DW.
Em um ambiente que visa atender a complexidade das mais diversas corporações ou

organizações, é muito comum observar grandes conjuntos e subconjuntos de modelos Estrela
integrados que formam o que pode ser chamado de “constelação” formada por diversos modelos
estrela (ou snowflake) integrados em um DW. Este tipo de modelagem é mais aproximado ao
conceito de DW proposto por Kimball.
Assista ao vídeo “Business Intelligence / Data Warehouse Lifecycle in Depth” em que o Professor
Ralph Kimball expõe sua proposta de DW. Acione as legendas em inglês.
Link: youtube.com [https://www.youtube.com/watch?v=fQp7HL_gSW4] Acesso em 11 Ago. 2020
A Figura 6 traz a imagem de Bill Inmon.
Figura 6 - Bill Inmon
Fonte: biready.com.au
[http://www.biready.com.au/news.htm#.Xw
HiW21KiUk]
De acordo com a proposta de Bill Inmon (2005), podemos destacar:
As camadas intermediárias de dados proporcionada por Operational Data Stores (ODSs) e pelos
Enterprise Data Warehouses (EDWs) eram essenciais para a garantia de um ambiente integrado em
modelagem relacional que deveria garantir o mínimo de redundância e o máximo de integridade dos
dados (por meio dos processos de ETL, mas também por meio de modelos de dados relacionais).
O banco de dados gerencial relacional serviria de base para a distribuição de subconjuntos de dados
de acordo com as demandas das diferentes áreas e de acordo com as tecnologias disponíveis.
Haveria um investimento considerável nas camadas intermediárias que, se por um lado tenderia a
garantir um ambiente mais estruturado de dados, por outro poderia elevar substancialmente o
volume de investimento devido à alta complexidade dos modelos relacionais e da manutenção do
processo de ETL.
Por outra perspectiva, ao tratar da entrega dos dados para a comunidade de usuários, a proposta
previa a flexibilização da modelagem nas etapas posteriores de modo a disponibilizar os dados de
acordo com os objetivos das áreas e dos fornecedores de tecnologia e ferramentas de BI.
Se, de um lado, a proposta de Inmon (veja a Figura 7) oferecia um maior controle das regras de
negócio, um acompanhamento mais detalhado das mudanças que o modelo de dados pode
sofrer ao longo do tempo, bem como um ambiente mais estruturado de dados, por outro lado,
esse tipo de modelo poderia tornar-se bastante oneroso para ser implementado, em especial nos
casos de empresas com modelos de negócios complexos.
Figura 7 – Modelo aproximado de Bill Inmon
Fonte: stitchdata.com [https://www.stitchdata.com/resources/operational-data-store/]
A proposta de Kimball (2006) oferecia uma modelagem mais simplificada que assumia que o
controle de integridade seria realizado pelas equipes responsáveis pelo gerenciamento das
bases transacionais (que serviam de origem para as bases de dados dimensionais). Embora a
implementação seja de alavancagem mais rápida, por ser menos exigente em termos de controle
relacional dos dados e por aceitar bem o nível de redundância típico da modelagem estrela, ainda
assim era um modelo estruturado de dados que demandaria investimento e acompanhamento
intenso – em especial para tratar anomalias causadas pela atualização de dados qualitativos –
que ocorreriam quando as dimensões do modelo estrela precisassem ser atualizadas para
refletir a realidade do negócio.
Em comum, os dois autores consideram que existem etapas, ou camadas, essenciais para o
desenvolvimento das bases de dados gerenciais, sendo elas a camada das origens de dados
transacionais, a camada de stage, a camada de tratamento e integração de dados que pode ser
baseada em um Operational Data Storage, ou em um Enterprise Data Warehouse, a camada
dimensional em modelagem Estrela ou Snowflake e finalmente a camada de interface com os
usuários proporcionada pelas ferramentas de BI.
Assista ao vídeo “Taxonomies/Ontologies - Bill Inmon” em que Bill Inmon fala sobre seu modelo
de DW e termos associados. Ative as legendas em inglês.
Link: youtube.com [https://www.youtube.com/watch?v=qVWbPEg9-dU] Acesso em 11 ago. 2020.
Se de um lado os modelos relacionais utilizados em ambientes transacionais são complexos

devido ao processo de normalização a que são submetidos, de outro lado os modelos
multidimensionais de dados gerenciais visam ao máximo atingir a simplicidade – sem que, no
entanto, se tornem inviáveis, seja por se tornarem redundantes, seja por se tornarem pouco
manejáveis do ponto de vista técnico. Para Inmon (2005), os benefícios dos modelos relacionais
podem e devem ser aplicados nas camadas de dados que dão suporte às ferramentas de BI.
O Quadro 1 traz uma comparação entre as abordagens de arquitetura das camadas de dados
propostas por Ralph Kimball e Bill Inmon.
Quadro 1 - Comparativo entre visões de Ralph Kimball e Bill Inmon
Kimball Inmon
Necessidade Imediata Escala de tempo mais ampla
Orientado a Áreas de negócios Corporativo
Orçamento Orçamento reduzido Orçamento maior
Requisitos Voláteis Mais estáveis e escaláveis
Cliente Base de usuários Corporativo
Origens de dados Estáveis Modificáveis
Investimento inicial Mais baixo Superior

Kimball Inmon
Projetos Mais complexos Menos complexos
Mas, há outros aspectos a considerar: os DBAs (Database Administrators) responsáveis pela

gestão da escalabilidade dos bancos de dados tendem a manter regras específicas para
diferentes modelos de dados, e faz parte de suas preocupações a garantia da manutenção de um
ambiente minimamente previsível e controlável das tabelas e instâncias dos bancos de dados
que estão sob sua supervisão.
Considerados estes fatores, qual seria então o “modelo de dados” ideal, caro(a) estudante?
O mais simples possível de se modelar?

O que garanta melhor rastreabilidade e controle das regras de negócio?
Uma combinação destes aspectos?
A resposta irá variar de projeto para projeto, mas podemos partir da premissa de quanto mais
simples o modelo, melhor. Mas não se preocupe. Nossa disciplina está apenas começando e
com certeza você terá condições de responder essa pergunta a partir do conhecimento que irá
adquirir!
Mas, antes de prosseguirmos, observe a situação apresentada a seguir:
Uma empresa possui um BD modelado com tabela única ou flat table, que contém todos
os dados e seus atributos para a equipe de gestores fazer suas análises. Neste BD são
armazenados diariamente 200 mil registros de vendas feitas na América do Sul e cada
um deles registra “América do Sul” no campo Continente. Quantas vezes “América do
Sul” apareceria repetido nessa tabela única? A resposta seria: 200 mil vezes por dia ou
50 milhões de vezes por ano ou 200 milhões de vezes em 4 anos!
Pela situação mostrada, podemos ver que questões aparentemente simples como essa acabam
escapando à observação de profissionais de TI que não possuem formação adequada para
resolver problemas na área de BI. A consequência disso são omissões e negligências que
resultam em dificuldades sérias que poderiam ser evitadas.
Por isso, estudante, prepare-se bem para ser um profissional que realmente possa contribuir
para que as soluções de BI sejam úteis aos gestores e às empresas que comandam.
Videoaula - Ciclos de dados transacionais e gerenciais
Videoaula - Camadas de dados para ambientes de BI - parte 1
Exercícios de fixação
1) Os _______ são desenvolvidos para estarem disponíveis a um grupo de usuários de dados
gerenciais de modo quase sempre circunscrito a um assunto ou área da organização. Quando o
projeto de um banco de dados gerencial é desenhado para atender ao conjunto das áreas de
modo corporativo, este inicia-se pela criação do ________. As lacunas são correta e
respectivamente preenchidas com
Bancos de Dados Relacionais; Modelo de Dados Multidimensional.
Data Marts; Data Warehouse.
Modelos de Dados Relacionais; Modelo de Dados Multidimensional.
Data Warehouses; Data Mart.
2) Entre os anos 1980 e 1990, antes da consolidação das soluções de BI no mercado, os

problemas que as organizações tiveram que enfrentar incluem os seguintes, EXCETO:
integração dos processos operacionais: junção de tarefas comuns entre diferentes sistemas
formando um sistema único como o ERP- Enterprise Resource Planning, ou seja, um sistema
integrado de gestão empresarial.
informatização dos processos operacionais: criação dos primeiros sistemas que atendiam
otimização das ferramentas OLAP: inclusão de técnicas mais avançadas de ETL para melhoria
da visualização dos dados em cubos ou hipercubos.
divisão do ambiente gerencial/operacional: construção de bancos de dados gerenciais

dedicados a suprir as áreas de negócio para tomada de decisão.
Recapitulando
Nesta unidade, vimos a importância de se conhecer o histórico dos problemas e

soluções que as organizações enfrentam antes ou depois de implementarem soluções de
BI. Vimos os tipos de dificuldades enfrentadas pelos tomadores de decisão antes de
implementarem seus Data Marts, Data Warehouses ou soluções de BI.
Conhecemos o modo como organizações optaram por montar suas camadas de

arquitetura de dados inspiradas por renomados profissionais que se dedicaram ao tema,
tal como Ralph Kimball e Bill Inmon.
Vimos também como as organizações consumidoras de soluções de BI influenciaram o

próprio mercado e o modo como tais soluções vieram sendo implementadas desde os
anos 1990, com o acompanhamento de consultorias especializadas como o Gartner
Group.
Por fim, pudemos comparar as diferentes abordagens de projetos propostas por Kimball
e Inmon, identificando vantagens e desvantagens de uso em cada uma destas propostas.
Videoaula - Camadas de dados em ambientes de BI - parte 2
2 Dados no ambiente multidimensional
2.1 Ambientes transacionais como origem de dados para BI
Os ambientes transacionais de dados são aqueles responsáveis pelo processamento de

informações que garantem que as operações fundamentas da organização sejam executadas.
Esses ambientes podem ser compostos por bases de dados transacionais de ERPs, que
compartilham processos e modelos de dados, ou de sistemas legados e autônomos
desenvolvidos para áreas específicas. Estes ambientes podem possuir ODSs que dão suporte ao
ambiente transacional principal da organização e podem ser materializados em forma de
registros e tabelas em sistemas de gerenciamento de bancos de dados ou em forma de arquivos
de dados como arquivos de texto ou planilhas de cálculo (GARTNER, 2020).
A Figura 8 mostra o ambiente transacional com as camadas de dados relacionadas ao processo

de ETL.
Figura 8 – Ambiente transacional com ODS em uma arquitetura de DW
Fonte: adaptado de randygrenier.blogspot.com

[https://randygrenier.blogspot.com/2011/02/operational-data-stores-ods.html]
Estudante, para ilustrar o cenário de um ambiente transacional comum de um pequeno negócio

de livraria, observe o exemplo a seguir:
Imagine uma pequena loja de livros que nunca tenha sido informatizada. Imagine que
um primeiro sistema esteja para ser oferecido ou implementado para o negócio. Uma
das primeiras operações a ser “automatizada” ou informatizada é a de venda. Assim, a
proprietária compra um computador e a cada venda feita ela alimenta em uma planilha
o código do livro, a quantidade vendida, o preço unitário e automaticamente a planilha
calcula o valor da compra.
O cenário apresentado é um clássico exemplo do processamento de uma operação de venda.

Esse processo ocorre milhões e milhões de vezes a cada hora, nas mais diversas partes do
mundo, em empresas de todo porte, utilizando os mais variados tipos de sistemas – desde
planilhas de cálculos até avançados módulos de sistema integrados de gestão empresarial.
O objetivo dos sistemas que atuam no nível operacional ou transacional é garantir que a entrada
de dados ocorra do modo mais consistente e otimizado possível (CONSTANTINO; SURIAN, 1998).
Imagine que a proprietária da livraria queira melhorar sua planilha adicionando dados sobre os
livros. Observe que a planilha original tinha apenas algumas poucas colunas, como vemos na
Figura 9.
Figura 9 – Exemplo de planilha original de uma pequena livraria
Conforme mostra a planilha (Figura 9), podemos observar que a livreira controla algumas poucas
informações como o código do livro (que ela mesma pode ter atribuído ou que pode ser um
padrão geral utilizado pelas editoras), o valor unitário (U), a quantidade que o cliente está
comprando (Q) e o valor calculado (U * Q).
Observe que esta planilha trabalha somente com valores detalhados, ou não agregados. Isso
significa que não há ainda um cálculo que apresente o valor total dessa compra. Além disso, a
livreira não controla os diferentes pedidos que são feitos pelo cliente, nem a data em que o
pedido ocorreu. Essas informações certamente farão falta em algum momento. Veja na Figura 10
uma pequena livraria como a de nosso exemplo.
Figura 10 – Uma pequena livraria
Fonte: intrinseca.com.br [https://www.intrinseca.com.br/blog/2014/07/livrarias-

de-paraty/]
Estudante, quando falamos de problemas a serem resolvidos no nível operacional, de modo geral,
estamos tratando de questões de curtíssimo prazo. Ou seja, a livreira quer neste momento
resolver o problema do cálculo do valor da venda que é feita naquele momento. Ela não está
preocupada ainda com outras operações como emitir um recibo de venda, em fazer o
fechamento do caixa, ou em controlar seu estoque de livros, e não está preocupada ainda com
questões de nível tático/gerencial ou com questões estratégicas. Note que ela poderá
incrementar seu “sistema” adicionando mais controles, ou mais colunas, à sua planilha tanto
para melhorar suas operações, quanto para melhorar sua base de informações para decisões no
nível tático e estratégico.
Em uma grande corporação ao invés de uma planilha com poucas colunas, as operações são
controladas por sistemas ou por módulos de sistemas que utilizam bancos de dados com grande
número de colunas ou campos em tabelas organizadas de acordo com critérios muito
específicos de modelagem de dados.
Entretanto, mesmo as empresas mais poderosas que existiam na primeira metade do século XX
acabaram por processar os seus dados operacionais de modo muito similar ao modo como a
livreira do nosso exemplo o faz.
Os primeiros bancos de dados não eram organizados em tabelas que visavam garantir a
integridade dos dados, a redução de redundância e a organização dos diferentes “assuntos” ou
entidades que visavam armazenar. De início os bancos de dados eram compostos por uma única
tabela que dispunha de várias colunas para armazenar os registros de interesse da organização.
Vejamos como exemplo uma melhoria feita pela livreira em sua planilha. Imagine que ela deseje
agora controlar a data da venda, a editora do livro e o tipo de livro. Sua planilha passa a ter
adicionalmente as colunas mostradas na Figura 11.
Figura 11 – Exemplo de planilha melhorada de uma pequena livraria
Na planilha da Figura 11, que pode parecer trivial para um profissional da área de TI, podemos
observar que a empreendedora agora controla também dados como o número do pedido (P), a
data da venda, o nome e a categoria do produto (livro), a editora, a quantidade, valor unitário e o
total da venda agregado por pedido.
Vamos fazer a diferenciação dos dados de modo a melhor compreendermos os mesmos no

ambiente de BI. Primeiro diferenciamos os dados quantitativos (colunas de valores – últimas três
colunas) dos dados qualitativos (primeiras colunas) e a coluna de datas. Em cinza estão as
colunas que existiam na primeira versão da planilha. Além disso podemos diferenciar os dados
de acordo com o seu nível de detalhe e tipo de origem.
Videoaula - Componentes do ambiente CPM (Query & Report)
2.2 Dados qualitativos e quantitativos
Dados qualitativos são dados descritivos do ambiente de negócio, por exemplo, dados de perfis
de clientes, descritivos de produtos etc., e dados quantitativos são aqueles que servem para
medir/quantificar o negócio, e que se relacionam com os dados qualitativos, como por exemplo,
quantidade de produtos (quantitativo) da marca X (qualitativo) em estoque; total de compras
(quantitativo) feitas por consumidores com perfil Y (qualitativo).
Estudante, como falaremos aqui de dimensões, fatos e medidas, vamos recordar a que estes
termos se referem?
O modelo multidimensional, que caracteriza os bancos de dados gerenciais, é formado por 3

elementos básicos:
Fatos, que são uma coleção de itens. Cada fato representa um item, uma transação ou um evento de
negócio. Os fatos são representados por valores numéricos e implementados em tabelas de fatos.
Exemplos de fatos seriam vendas, produtos, clientes etc.
Dimensões, que definem o contexto de um assunto de negócios e participam de um fato, como ano,
país, vendedor, fornecedor etc.
Medidas (variáveis), que são atributos numéricos que representam um fato. As medidas podem ser
preço unitário de um produto, número de unidades de produtos vendidos etc.
Videoaula - Componentes do ambiente CPM (OLAP)
2.2.1 Dados quantitativos e tipos de medidas em tabelas de fato
Tomemos por exemplo os dados com os valores mostrados na planilha da Figura 11 e vamos
analisá-los:
O Valor Unitário(U) e a Quantidade(Q) são dados não calculados ou medidas originais que foram
inseridas tal como estão na planilha.
A coluna Valor(U*Q) é uma coluna calculada ou uma medida derivada, pois seu valor pode ser
calculado registro a registro sem depender da leitura de mais de uma linha da planilha.
Se lermos somente a segunda linha da coluna de Valor Unitário (R$15,00) e a segunda linha da coluna
de Quantidade (2), e multiplicarmos esses dois valores, poderemos chegar ao resultado apresentado
na segunda linha da coluna Valor (R$ 30,00).
Os valores apresentados na coluna Total(P) não necessariamente são calculados com base na leitura
de apenas uma linha (embora por vezes uma linha seja suficiente – como ocorre com a quarta linha
da tabela). Nesse caso temos uma coluna calculada agregada que depende da leitura de um conjunto
de linhas (ou da totalidade da lista/tabela) para que seja possível chegar ao cálculo agregado. No caso
específico o cálculo utilizado é a soma.
Os sistemas transacionais podem armazenar dados quantitativos ou dados agregados. No

entanto, nos sistemas mais antigos, quase sempre eram armazenados apenas os dados não
calculados, cabendo aos aplicativos e interfaces do sistema apresentarem os dados calculados
e/ou agregados.
Com base na análise de dados que fizemos, podemos notar que há três tipos de medidas:
1. Medida aditiva: Quando uma medida ou dado quantitativo pode ser utilizado nos diversos cruzamentos de
dimensões em seu nível máximo de detalhe. Esta medida é considerada uma medida aditiva (por
exemplo, podemos analisar a soma da quantidade de produtos vendidos por cliente, por produto e por
vendedor).
2. Medida não aditiva: As medidas ou métricas que não permitem agregações para as dimensões com as
quais estão relacionadas são consideradas não aditivas, ou seja, se uma métrica somente fizer sentido em
seu estado máximo de detalhe, demandando tratamento especial nas ferramentas de BI por meio de
operações de rollup
3. Medida semiaditiva: se uma medida trata da quantidade de horas trabalhadas por um vendedor (ainda que
seja possível criar um indicador derivado que possa ser atribuído ou comparado com produtos ou clientes)
essa medida será considerada semiaditiva.
Nos bancos de dados gerenciais que utilizam modelagem multidimensional, os dados

quantitativos, ou as medidas, são campos das tabelas de fato.
Diferenciar cálculos derivados de cálculos agregados é uma atividade importante na análise de

bases de dados transacionais e gerenciais. Os cálculos derivados podem ser realizados
considerando somente um registro de cada vez, mas os cálculos de agregação dependem da
leitura de toda a série de dados para que se possa chegar ao resultado.
2.2.2 Dados qualitativos e atualização gradual de dimensões

Agora vamos a outro cenário.
Imagine-se no lugar da livreira, tendo que fazer o registro de uma nova venda. Imagine também
que você queira adicionar outras colunas que ache relevante controlar no seu negócio, como
exemplo, o nome do cliente, seu endereço e telefone. Agora imagine que a cliente Ana fez a
compra de 10 livros quaisquer e que você tenha que alimentar essa planilha de tabela única.
Quantas vezes você terá que digitar (ou copiar e colar) o endereço e o telefone dela? Além da
primeira vez, terá que replicar nove vezes, certo? Isso lhe parece razoável?
Diante de situações similares a essa temos dois problemas clássicos que devem ser resolvidos
pelos especialistas em bancos de dados: a integridade e a redundância dos dados. De acordo
com Constantino e Surian (1998), a solução envolve os seguintes aspectos:
Deve haver meios para garantir que o processo de inserção ou input de dados seja o mais íntegro e
otimizado possível, pois se a pessoa tiver que digitar 10 vezes o endereço do cliente, eventualmente
ela poderá errar em uma das digitações. Se o cliente fez a última compra há alguns dias, a pessoa
responsável pela inserção dos dados pode não se recordar do formato digitado da última vez ou pode
simplesmente errar a digitação, além de perder tempo repetindo a operação de digitação dos dados.
Para melhor lidar com esse problema de integridade de dados, inicialmente os sistemas de
informação, através de interfaces programadas, procuravam fazer esse controle.
Gradualmente a integridade dos dados passou a ser uma tarefa dos SGBDs (Sistemas de
Gerenciamento de Banco de Dados), com base na modelagem relacional.
O uso de modelos relacionais para os bancos de dados garantiu um melhor controle da redundância
de dados, bem como da integridade das informações.
Quando são criadas tabelas separadas para clientes, livros, venda, pedidos etc., pode-se garantir
que para cada cliente seja possível adicionar somente um registro específico para o endereço,
telefone e outras informações. Isso serve para a tabela de livros, onde armazenamos para cada
registro os dados relativos àquele item. Neste cenário, um BD de um sistema para controle de
vendas da livraria poderia ter tabelas como as mostradas na Figura 12.
Figura 12 – Tabelas separadas para o BD de uma livraria
Desta forma, é possível transformar uma tabela única de dados com muitas redundâncias em um
conjunto de tabelas otimizadas (normalizadas) que garanta a integridade e o mínimo de
redundância de dados.
Como você sabe, para que um modelo relacional de dados funcione, o SGBD deve permitir que as
tabelas possam se comunicar por meio de relacionamentos ou joins.
Assim sendo, saímos de um modelo em que havia uma única tabela (flat table) com diversas
colunas, para um modelo relacional com o mínimo de redundância e com o máximo controle de
integridade dos dados. Mas, por outro lado, este novo modelo torna-se bem mais complexo. Isso
ocorre porque o principal objetivo dos ambientes transacionais é garantir que as transações
ocorram de modo mais preciso e controlado possível – operação por operação, registro por
registro. A Figura 13 permite observarmos a diferença entre um modelo de tabela única para um
modelo relacional.
Figura 13 – Tabela única x Tabelas no Modelo Relacional
É possível observar do lado esquerdo da Figura 13 uma representação da tabela não normalizada
e os registros redundantes (com mesma cor) dentro dela. Do lado direito é possível observar uma
representação do conjunto de tabelas normalizadas e como este modelo se torna mais complexo
(ao mesmo tempo em que se torna mais efetivo no controle de integridade e redundância de
dados).
Considere um modelo que controle dados de Clientes e dos Produtos que este cliente compra na
livraria de nosso exemplo, e ainda possua as características:
Relacionado ao Cliente: sejam indicados a cidade, a UF e o país.

Relacionado ao Produto: sejam cadastrados o tipo de produto (livros, revistas ou artigos de papelaria,
por exemplo) e a família do produto (romance, poesia, revista semanal, caderno etc.).
Relacionado à Venda: sejam indicados a data da venda, o valor unitário de cada produto, a quantidade
de produtos que o cliente está comprando, o valor total da venda.
Neste modelo, quando uma atendente vai inserir o pedido, precisará:
indicar o código do cliente (que se já estiver cadastrado irá recuperar os dados de cidade, UF,
país e tipo de cliente) → registrar cada produto (que se já estiver cadastrado, irá recuperar os
dados de tipo e família de produto e eventualmente o preço unitário) → indicar para cada item
vendido (produto) a quantidade que o cliente está comprando.
Agora, imagine-se como a pessoa que coordena ou gerencia a livraria. Imagine que você deseja
saber, ao final do dia, a quantidade e o valor vendido de diferentes tipos de produtos para
diferentes unidades da federação. Tal como observamos, de modo simplificado, no relatório da
Figura 14.
Figura 14 – Exemplo de relatório de Vendas de uma livraria

Como você sabe, para fazer essa consulta ou query em SQLserá necessário indicar o
relacionamento entre tabelas.
Nesta consulta, será necessário envolver quantas tabelas para que seja possível responder tal
questão gerencial?
Isso vai depender da modelagem, mas uma resposta seria a mostrada na Figura 15. Assim, para
este exemplo, devem ser incluídas as tabelas: Cidade, UF, Cliente, Pedido, Detalhe do Pedido,
Produto e Tipo de Produto ainda que sejam exibidos somente resultados diretamente
relacionados aos campos UF, Tipo de Produto e Quantidade Vendida (agregada).
Figura 15 – Tabelas envolvidas na consulta que resulta no relatório da

livraria
Os bancos de dados desenvolvidos para dar suporte ao ambiente transacional são modelados de
modo diferente daqueles que são desenvolvidos para dar suporte ao processo gerencial de
tomada de decisões.
Quando tratamos dos dados qualitativos, estamos basicamente tratando das dimensões de um
banco de dados gerencial que utiliza modelagem multidimensional.
Um dos problemas que as organizações enfrentam ao processarem e armazenarem dados
descritivos ou qualitativos implica no controle de alterações na “hierarquia” de dados destas
dimensões.
Trataremos adiante dos elementos qualitativos, que compõem as dimensões do cubo que
suporta operações OLAP (Online Analytical Problem). Por ora, observemos que as dimensões
podem sofrer alterações ao longo do tempo, ainda que estas alterações sejam menos frequentes
que as atualizações que ocorrem nas tabelas de fato (associadas às medidas ou dados
quantitativos). Essas alterações são de extrema importância e devem ser cuidadosamente
tratadas.
Videoaula - Componentes do ambiente CPM (Mining)
Tratamento de dados no ambiente iSlowly Changing

2.3 multidimensional: Dimensioni
Slowly Changing Dimension se refere à atualização gradual das alterações nas dimensões (e em
tabelas de fato). Vejamos do que se trata.
Imagine que um vendedor que trabalhou nos 2 anos anteriores na cidade do Rio de
Janeiro tenha sido transferido no início do ano para a filial de Belo Horizonte de uma
empresa.
Neste caso, como um relatório que apresenta as vendas consolidadas por UF (RJ e MG) deverá
tratar das vendas desse profissional?
Se, por exemplo, no banco de dados transacional simplesmente for feita a alteração do código de
cidade do vendedor, isso resultará na transferência de todo o histórico de vendas desse vendedor
da cidade do Rio de Janeiro para a cidade de Belo Horizonte... isso implicaria na distorção do
resultado das vendas das duas cidades, das UFs que abrigam estas cidades, das regiões de
venda, das equipes de vendas e dos seus respectivos gerentes.
Trazendo este caso para o ambiente multidimensional de um Data Warehouse, esta mesma
distorção poderia ser evitada, ou minimizada, no caso de haver atualizações incrementais ao
banco de dados que faz o controle de atualização das dimensões.
Diversas alternativas surgiram ao longo do tempo para controlar estas alterações graduais das
tabelas de dimensão, que incluíam optar pelo “não controle da alteração”, ou seja, aceitar
distorções como a descrita, bem como a criação de colunas de swap para atualização, ou seja,
havendo uma coluna que indica a cidade atual do vendedor e outra que indica a cidade anterior.
Nestes casos, no entanto, o controle do histórico de atualizações da dimensão acaba sendo

parcial.
O controle das atualizações graduais das dimensões, denominado Slowly Changing Dimensions
– SCD, por meio do uso de chaves artificiais ou Surrogate Keys, proporcionam um controle mais
efetivo dessas alterações.
Observemos a Figura 16 e consideremos o que ocorreria se o vendedor Pedro deixasse o Rio de

Janeiro e passasse a atuar pela cidade de Belo Horizonte. Considere nas colunas separadas à
direita as dimensões relativas aos totais de vendas por vendedor (Vendas em Milhões) e por
estado (UF/Total UF).
Figura 16 – Exemplo de tabela de Vendas no ano atual e dimensões associadas
No caso da Figura 16, para cada vendedor (e seu respectivo ID) é possível identificar as vendas
que realizaram em determinado ano (ano atual). Podemos ver nas últimas colunas os totais de
vendas por vendedor (Vendas em Milhões) e o total de vendas agregada por estado (UF/Total
UF).
O que ocorreria se cada vendedor, no ano seguinte, vendesse mais 1 milhão, mas um deles, o
Pedro do RJ, tivesse sido transferido para MG?
Se não for feito o controle da alteração das dimensões (SCD) e se a atualização do banco de
dados gerencial não for incremental, o resultado seria como o exibido na Figura 17 (pelo fato de
os valores estarem associados à chave ID Vendedor).
Figura 17 – Tabela de Vendas no ano seguinte, com a transferência de Pedro e dimensões associadas
Observe que as vendas de Belo Horizonte/MG foram substancialmente aumentadas (pois herdou
as vendas do RJ) enquanto o Rio de Janeiro aparece sem resultados acumulados de vendas.
Assim observamos que o histórico dos dados foi atualizado em relação ao acompanhamento do
histórico de cada vendedor, mas, não é mais possível acompanhar o histórico de vendas das
cidades e estados nos quais atuavam.
Uma forma de tratar essa situação de atualização de dados é utilizando uma chave especial
artificial que pode ser automaticamente gerada/incrementada pela ferramenta de ETL ou que
pode ser baseada em uma chave composta que considere a chave do vendedor e a chave dos
demais atributos de dimensão da tabela fato que precisam ser controlados. Assim sendo,
podemos ter a disposição de atributos e registros mostrada na tabela 18.
Figura 18 – Tabela fato Vendas com a coluna SK Vendedor adicionada e dimensões associadas
A tabela de fato Vendas (da esquerda), que representa o caso do exemplo aqui utilizado,
armazena as medidas que desejamos controlar, bem como a chave estrangeira artificial (SK
Vendedor) que foi criada para garantir o controle de atualização gradual da dimensão. Já as
tabelas de dimensão armazenam os dados tal como vemos do lado direito da tabela de fato
Vendas.
Quando o vendedor Pedro foi transferido do RJ para MG, seus dados históricos foram mantidos
em seu estado e cidade de origem (R$ 4 milhões de vendas pelo RJ) e um novo registro foi
adicionado para armazenar as suas vendas por Belo Horizonte/MG. Desta forma, observamos
(nas colunas do lado direito) que os dados do histórico agregado por estado se mantiveram
coerentes com as atividades da empresa.
Ferramentas de integração de dados/de ETL permitem que sejam criados dispositivos que fazem
relações de “procura”, de “de para”, de “lookup” tal como pode ser feito em planilhas de cálculo
com funções como “proxv” ou “vlookup” que leem as chaves primárias (como ID Vendedor) e
criam o mecanismo de incremento ou composição da Surrogate Key antes de armazená-la como
chave estrangeira na tabela de fato.
As chaves compostas podem também ajudar a resolver problemas como o da garantia de

unicidade dos dados. Observe que há mais de um vendedor chamado João na tabela de fato
Vendas de nosso exemplo. Resolvemos o problema da coluna Vendedor utilizando a combinação
do ID do vendedor com o seu nome, o que tornou o vendedor unicamente identificado.
Os modelos relacionais, normalizados, são extremamente efetivos e eficientes para atender

demandas operacionais. O processo de normalização de tabelas reduz a redundância de dados
ao mínimo e permite um melhor controle da integridade dos dados. Por outro lado, eles podem se
tornar pouco eficientes e efetivos para realização de consultas de dados (execução de queries) e,
consequentemente, para a geração de relatórios gerenciais e para a visualização de dados.
Videoaula - Componentes do ambiente CPM (Resumo)
1) Ao tratarmos dos dados qualitativos estamos basicamente tratando _______ de um banco de
dados gerencial, que utiliza modelagem multidimensional. A lacuna é corretamente preenchida
com:
das tabelas fato
das medidas não aditivas
das operações transacionais
das dimensões
2) Considere as afirmativas e assinale a INCORRETA:
é desejável transformar uma flat table com poucas redundâncias em um conjunto de tabelas
normalizadas que garanta a integridade e o máximo de redundância de dados.
quando falamos de problemas a serem resolvidos no nível operacional, de modo geral,

estamos tratando de questões de curtíssimo prazo.
quando uma medida ou dado quantitativo pode ser utilizado nos diversos cruzamentos de
dimensões em seu nível máximo de detalhe, esta medida é considerada uma medida aditiva.
uma coluna calculada agregada depende da leitura de um conjunto de linhas para que seja
possível chegar ao cálculo agregado.
Recapitulando
Nesta unidade, pudemos observar como os dados dos ambientes transacional e

gerencial/multidimensional são organizados e tratados de modos distintos devido às
suas finalidades, objetivo de uso, armazenamento e recuperação.
Vimos que os dados transacionais têm por objetivo dar suporte às atividades
operacionais da organização. Já os dados gerenciais podem ser organizados em
modelos de dados multidimensionais e disponibilizados para os tomadores de decisão
em um ambiente de fácil uso por meio de ferramentas de BI.
Vimos que as informações (transacionais e gerenciais) podem ser organizadas também

pelo tipo de dados dos quais são compostas, podendo ser utilizadas para descrever o
negócio (dados qualitativos) ou para medir o negócio (dados quantitativos).
Observamos alguns dos problemas e soluções que as organizações enfrentam ao buscar

atender gestores e tomadores de decisão (ao criarem bancos de dados gerenciais), e as
diferentes formas de atender aos seus objetivos.
3 Estruturas de dados e ferramentas de BI e CPM
3.1 BI e informações em nível tático-estratégico
Estudante, vimos que os ambientes transacionais de dados são caracterizados principalmente

pelo seu papel de garantir a entrada de dados de modo mais organizado e íntegro possível
respeitando as lógicas transacionais dos processos que um modelo relacional visa controlar.
Vimos também que os ambientes gerenciais de dados são caracterizados por armazenarem os
dados em uma lógica que torne mais ágil e fácil extrair ou garantir a saída dos dados que irão dar
suporte à tomada de decisão de tais gestores.
Ainda fazendo um retrospecto, estudamos que as decisões de curtíssimo prazo como decidir
qual o valor de desconto a ser dado em um único pedido ou se um produto pode ou não ser
vendido naquele momento de acordo com a disponibilidade do estoque, são exemplos de
decisões geralmente relacionadas ao nível operacional.
As decisões de nível gerencial tendem a reger prazos maiores e aspectos mais gerais da
organização. Há, ainda, decisões de longo prazo que determinam em linhas muito amplas o
sentido ou a direção que a organização irá tomar. São decisões que tratam de indicadores de
desempenho que têm impacto geral sobre a organização, mesmo que estejam sob a
responsabilidade de uma área ou departamento específico. Este nível de atuação é o nível
estratégico da organização.
Um dos objetivos de quem proporciona soluções de BI é compreender o fluxo dos diferentes

tipos de informações: desde a camada transacional ou operacional, apoiada por sistemas OLTP e
bases de dados transacionais, até o nível estratégico, passando, é claro, pelo nível tático ou
gerencial, apoiado por ferramentas de BI.
No processo de tomada de decisões é muito importante saber a quantidade e a qualidade de

dados e informações à disposição do gestor. Para ajudar o executivo neste processo crucial, é
necessário utilizar as ferramentas de apoio à decisão em uma hierarquia capaz de diferenciar as
necessidades dentro das diversas situações na organização, o que reforça a importância da
informação.
Cada nível de gestão, seja estratégico, tático ou operacional, possui diferentes necessidades de
informação. Isto tem implicações importantes para a escolha das ferramentas de apoio à
decisão que a empresa deva adquirir ou desenvolver.
A Figura 19 ilustra os tipos de informação de acordo com o nível de tomada de decisão, com
destaque ao ambiente de Business Intelligence, que atua no nível tático-estratégico.
Figura 19 – Informações nos níveis decisórios
Um exercício interessante a ser feito é o de rastrear um dado desde a sua inserção no banco de
dados transacional até a chegada dele em um gráfico apresentado para a alta direção de uma
organização.
Você poderá observar que um pedido que estava previsto para ser efetivado pelo maior cliente da
empresa ao final do mês poderá resultar na necessidade do gestor daquela conta comercial ter
que justificar ao corpo de diretores o porquê de não terem atingido o resultado do trimestre.
Ao analisarmos este exemplo fictício podemos identificar que, além de observarmos e

acompanharmos os dados históricos que se acumulam ao longo das operações ou transações
da organização, nós também consideramos dados de previsão ou de planejamento da
organização. Façamos, então, as perguntas pertinentes:
Como estes planejamentos ocorrem?

Com base em quê o gerente comercial mantinha a expectativa de um certo volume de vendas para
aquele mês ou trimestre?
Como essa expectativa de venda mensal impacta nas decisões de nível estratégico?
Se tivermos em mente que os profissionais de BI e de Gestão de Desempenho são responsáveis

por oferecer as melhores condições possíveis para que os gestores e dirigentes (mas não só
eles) tomem as melhores decisões para suas organizações, então constataremos que buscar
respostas às questões mencionadas é algo essencial. Estas respostas certamente são obtidas
com o apoio de soluções de BI.
3.2 Contexto histórico de soluções de BI e CPM
Se um Data Mart (DM) ou um Data Warehouse (DW) integrado a uma ferramenta de BIoferecer
somente informações sobre o histórico das operações em diversos níveis de agregação para os
tomadores de decisão formularem suas hipóteses e proporem ações para atingir os objetivos da
organização, então haverá um risco muito alto de que estes tomadores de decisão tenham que,
eles mesmos, encontrarem formas de cruzar os dados históricos com suas metas e
planejamentos sobre o negócio.
Este tipo de problema foi muito frequente nos anos 1990 e 2000. Modelos de dados gerenciais,
DMs ou DWs que mantinham informações históricas com grande confiabilidade e acessibilidade,
mas que, no entanto, não alcançavam as principais demandas de informação dos tomadores de
decisão, pois, não raramente, parte dos processos críticos de nível tático e estratégico não
estavam completamente integrados aos sistemas transacionais que serviam de origem para os
ambientes de dados gerenciais.
Muitas vezes esses processos críticos eram (e ainda são) realizados por meio de planilhas de
cálculo – inclusive em organizações multinacionais e de grande porte.
Diante deste cenário, muitos fabricantes de soluções de BI optaram por integrar os processos de
análise de dados (Data Analysis & Reporting) com os processos de planejamento estratégico
(Planning & Consolidation) e de monitoramento de indicadores críticos (Monitoring, KPI e
Scorecards).
O conjunto destas soluções integradas passou a ser chamado de Gestão de Desempenho

Corporativo ou Corporate Performance Management – CPM ou Gestão de Desempenho
Empresarial (Enterprise Performance Management) a depender do fornecedor das soluções.
CPM é um termo guarda-chuva que descreve as metodologias, métricas, processos e

sistemas usados para monitorar e gerenciar o desempenho dos negócios de uma
empresa. Aplicações de CPM traduzem estrategicamente informações para planos
operacionais, e agregam resultados. Essas aplicações são também integradas em
diversos elementos de planejamento e controle ou endereçam BAM - Business Activity
Monitoring. CPM deve ser suportado por uma suíte de aplicações analíticas que
fornecem funcionalidades para dar apoio a estes processos, metodologias e métricas.
(GARTNER, 2020)
Empresas líderes de mercado à época como a Cognos (que se tornou IBM Cognos em finais dos
anos 2000), que adquiriu e desenvolveu diversas ferramentas para viabilizar sua plataforma CPM,
ou a Oracle, que desenvolveu sua plataforma de EPM ainda naquela década.
Figura 20 – Logotipo IBM Cognos
Fonte: medium.com
[https://medium.com/@existbi321/propel-
your-enterprise-forward-with-ibm-
cognos-training-9bb75c399232]
Já nos anos 2010 passou a ocorrer a intensificação de um processo de redução de escopo (ou
downsizing) similar ao que a computação transacional experimentou nos anos 1980 em termos
de hardware.
A busca por soluções rápidas de apoio ao processo de tomada de decisão e o desenvolvimento

de estratégias de gestão de projeto que reduzissem o escopo e o risco da implementação de
projetos de grande complexidade propiciou o surgimento e o estabelecimento de um mercado de
ferramentas de rápida implementação.
Fabricantes como a Qlik, Tableau e Microsoft desenvolveram soluções de BI mais leves ou de

visualização de dados que passaram a concorrer com fabricantes que propunham ambientes
mais tradicionais e estruturados ao mercado.
Figura 21 – Logotipo Tableau software
Fonte: tableau.com
[https://www.tableau.com/pt-br]
Podemos afirmar que continua a haver espaço para as diferentes abordagens de implementação
de BI e CPM, das mais estruturadas àquelas completamente voltadas para atender demandas ad
hoc ou de rápida implementação.
Agora que você conhece de modo mais geral alguns dos problemas enfrentados pelas
organizações antes e depois de implementarem soluções de BI, bem como os tipos de problemas
que enfrentam mesmo após desenvolverem seus bancos de dados gerenciais e disponibilizarem
informações por meio de ferramentas de BI, você poderá refletir de modo mais aprofundado
sobre os problemas que os tomadores de decisão enfrentam em seu dia a dia.
3.3 Componentes de soluções de BI e CPM
Agora que conhecemos o histórico e o contexto das soluções de BI e CPM poderemos analisar,
ou entender, melhor os componentes que integram estas soluções.
As soluções de BI, dependendo dos fornecedores, costumam oferecer ferramentas de Reporting,

Analysis e Data Mining.
Como característica principal, estas soluções ou ferramentas têm em comum o uso de dados
históricos para dar suporte ao processo de tomada de decisão.
Em outro eixo, se encontram ferramentas de Planning, Budgeting e Forecasting. Vamos ver essas
ferramentas nas seções que se seguem.
3.3.1 Ferramentas de iReportingi
As ferramentas de Reporting ou do tipo Query-Report fazem parte do grupo de ferramentas de

Information Delivery (ou de disponibilização de informações). São caraterizadas por oferecerem
um ambiente de fácil utilização pela comunidade de usuários, que podem elaborar ou executar
relatórios a partir de ferramentas de BI (GARTNER, 2020).
Podemos dividir os perfis de usuários entre autores, consumidores e visualizadores de relatórios:
Usuários autores: podem criar relatórios ou conjuntos de relatórios com diferentes níveis de
interatividade e recursos para suas comunidades de usuários e visualizadores.
Usuários consumidores: podem realizar algum nível de interação com os relatórios desenvolvidos
pelos autores, podem por exemplo modificar critérios de filtros dinâmicos, modificar as colunas e
linhas de relatórios, detalhar ou resumir até certo ponto as informações.
Usuários visualizadores: podem acessar relatórios previamente elaborados em formato pouco
interativo, em geral em PDF.
As ferramentas de Information Delivery baseiam-se geralmente em catálogos de dados. Os

catálogos de dados são interfaces que traduzem os dados que estão armazenados com nomes
técnicos no banco de dados em uma interface de fácil compreensão e interação.
Se em um ambiente de banco de dados uma pessoa quiser fazer uma consulta sobre o Tipo de
Cliente, o Tipo de Produto e a Quantidade Vendida, terá que fazer uma query para obter tal
resultado, em uma ferramenta de Reporting, Query-Report ou Ad Hoc Query.
Esta pessoa poderá selecionar, em uma interface gráfica, os campos que interessam para a
consulta (clicando e arrastando) de modo a montar seu relatório sem ter que necessariamente
programar uma query. Veja a Figura 22, que traz a tela de um sistema deste tipo.
Figura 22 – Tela de ferramenta Query-Report com informações de vendas (sales)
Fonte: informatec.com [https://www.informatec.com/en/technologies/qlik/qlikview]
Os catálogos de dados que servem de base para as ferramentas de Reporting ou Query-Report

podem ser montados em bases relacionais, dimensionais ou em tabelas simples, mas
geralmente são montados para traduzir a linguagem de banco de dados multidimensionais (DMs
e DWs) para a linguagem de negócios através de uma interface gráfica (GARTNER, 2020).
3.3.2 Ferramentas dei Analysisi
Para melhor compreendermos as ferramentas do tipo Analysis vale a pena revermos alguns
pontos tratados anteriormente quando descrevemos as bases de dados transacionais. Os
bancos de dados transacionais são normalmente relacionados com bases de processamento
online ou Online Transaction Processing (OLTP), já as bases analíticas são organizadas por
dimensões, priorizando as tarefas de consulta de dados, usando solução Online Analytical
Processing (OLAP).
De acordo com o glossário do Gartner (2020), as ferramentas OLAP podem ser desenvolvidas
sobre bancos de dados relacionais ou dimensionais, podem funcionar com base em servidores
de dados ou servidores de arquivos. Podem, portanto, fazer consultas em bancos de dados de
fabricantes diversos, podem ler somente arquivos nativos que já armazenam os dados gerenciais
em formatos multidimensionais previamente processados ou podem fazer algum nível de
combinação entre estes cenários.
3.3.3 Ferramentas dei Data Miningi

Há também um universo bastante amplo que tende a ser ora integrado, ora separado, das
ferramentas de BI, que são as ferramentas de Data Mining.
As ferramentas de Data Mining podem utilizar qualquer tipo de origem de dados previamente
tratados para que os algoritmos de identificação de padrões qualitativos ou quantitativos sejam
aplicados.
Este tipo de solução beneficiou-se imensamente dos ambientes de DW e DM desenvolvidos para

atender os ambientes de BI tradicionais e, portanto, passaram a ser vistos por muitas
organizações tanto como parte do ambiente de BI quanto de CPM.
Com a consolidação das soluções de Big Data, o “Mining” passou a ser visto cada vez mais
como parte integrante deste escopo mais amplo de soluções.
3.3.4 Ferramentas dei Planning, Budgeting ie iForecastingi
As ferramentas de Planning, Budgeting e Forecasting formam outro eixo de soluções do

ambiente CPM (ou CPM Suites) (GARTNER, 2020).
Estas ferramentas dão suporte ao processo de geração de informações de planejamento,

orçamentação e previsão para as organizações e podem ser desenvolvidas de modo integrado
ou independente das demais ferramentas que compõem o conjunto de soluções CPM.
Uma organização pode utilizar diferentes fluxos para definição de seu planejamento estratégico
ou orçamentário, dentre os quais encontram-se as estratégias top down e bottom up.
Top down: a presidência da empresa e cada diretoria determina, a título de exemplo, um valor de
orçamento que será destinado à sua área, à sua equipe. Neste caso, cada gerente terá que definir
como empregará os valores de orçamento e as metas a serem alcançadas de acordo com os recursos
humanos, de infraestrutura, intelectuais e financeiros de que dispõe. Este processo chama-se “de
cima para baixo” pelo fato de que as limitações foram definidas do alto da cadeia hierárquica e
passam a reger os limites dos níveis inferiores.
Bottom up: a diretoria pede aos seus gerentes, que por sua vez pedem aos seus subordinados,
coordenadores e analistas, que detalhem quais as necessidades que têm para realizarem bem seus
trabalhos (para atingirem as metas gerais da organização). Cada analista elabora, então, sua parte do
plano orçamentário que é submetido ao coordenador acima dele, que por sua vez contribui com
informações adicionais e faz os ajustes necessários antes de submeter aos gerentes, que repetem
essa ação antes de submeterem à diretoria. O processo é chamado de “de baixo para cima”, pois o
fluxo de alimentação de informações veio do nível operacional para o estratégico.
Normalmente o que observamos nas organizações mais bem estruturadas é uma combinação
destes fluxos top down e bottom up em diferentes níveis e fases, com certa flexibilidade, de
acordo com cada área ou departamento.
Esse processo de orçamentação, de elaboração de previsões ou de planejamento baseia-se nos
dados históricos disponíveis ou, quando é uma organização completamente nova, em
informações de benchmarking baseadas em dados de pesquisa, de empresas similares ou de
concorrentes no mercado.
O processo de consolidação do orçamento permite que os dirigentes, gestores, coordenadores e

analistas acompanhem o fluxo de contribuição, correção e submissão do orçamento em suas
diferentes etapas ao longo da cadeia hierárquica tanto no sentido top down quanto no sentido
bottom up.
Assista ao vídeo “Monthly Budgeting & Forecasting Model”. Ative as legendas em inglês.
Link: youtube.com [https://www.youtube.com/watch?v=Awm_LxHbHHE] Acesso em 11 ago. 2020.
3.4 Ferramentas de monitoramento (iScorecardis)
As Ferramentas de Monitoramento incluem dashboards e scorecards, que fornecem uma visão

dos indicadores de desempenho corporativo, gráficos e planilhas e podem incluir sistemas mais
sofisticados como cubos tridimensionais e até ferramentas de Realidade Virtual.
Caro(a) estudante, para entendermos a aplicabilidade destas ferramentas, vamos voltar ao

exemplo daquela livraria.
Imagine que a livraria cresceu, mantém diversas filiais pelo país e recebeu um investimento
muito grande, tornando possível à sua proprietária escolher o melhor modo de aportar esses
valores.
Ela deve abrir outras filiais?

Deve melhorar o processo de logística e entrega dos produtos aos clientes?
Deve investir em TI?
Deve melhorar suas ferramentas e equipes de venda?
Como decidir o que fazer com esse dinheiro?
Expandindo este exemplo aos casos que realmente ocorrem, estamos falando de um tipo de
decisão que tem impacto nos níveis operacional, tático e estratégico, mas que, no entanto,
dependerá de uma decisão de nível estratégico, que provavelmente procurará se amparar ao
máximo nas informações fornecidas pela sua equipe tática/gerencial.
Esta decisão quase sempre irá se pautar por informações históricas da própria organização. A
diretoria da empresa irá analisar os resultados dos últimos anos e trimestres, irá identificar os
pontos fortes e fracos do negócio, avaliará ameaças e oportunidades antes de definir como usar
o dinheiro.
Poderá definir, a depender dos últimos resultados, do contexto econômico, político e social e dos
objetivos da organização, se a melhor estratégia será, por exemplo, a de realização dos lucros, a
de crescimento, a de sobrevivência, a de redução de escopo e assim por diante.
Definidos os objetivos estratégicos, os dirigentes examinam quais são os indicadores a serem

acompanhados ou monitorados de acordo com o orçamento previsto. Se os dados de
planejamento, de orçamentação e previsão (Budget & Forecast) do próximo ano já estiverem
alimentando o DM ou o DW, então os diretores e gerentes poderão montar consultas e relatórios:
gráficos, tabelas ou cockpits que permitam comparar o desempenho planejado com o
desempenho realizado até aquele momento.
Essa análise do planejado versus o realizado é a base do monitoramento estratégico.
Este trabalho poderia ser feito por meio de um conjunto ou uma combinação de relatórios
gerenciais, mas muitas organizações preferem utilizar uma plataforma de monitoramento
integrada baseada em dashboards ou em ferramentas de acompanhamento de Indicadores de
Performance ou de Mensuração (KPI Tools & Metrics Tools) que podem ser integradas em
ferramentas ou plataformas Scorecard (de monitoramento). Veja a Figura 23, que apresenta um
dashboard que se parece com um cockpit de carro.
Figura 23 – Dashboard
Fonte: dashboardmentor.com [https://www.dashboardmentor.com/autotask-performance-dashboards-3-0/]
Essas ferramentas de monitoramento estratégico oferecem a combinação de recursos

tecnológicos (como uma interface gráfica de fácil utilização) com recursos metodológicos (como
o uso de metodologias como o Balanced Scorecads ou o uso de narrativas de dados, os Story
Tellings).
Balanced Scorecard (BSc) é uma abordagem de medição e gestão de desempenho que reconhece
que os indicadores financeiros por si só não são suficientes para a análise e processo de tomada
de decisão e que uma empresa precisa de um conjunto mais abrangente e equilibrado de medidas
que reflitam os diferentes drivers que contribuem para um desempenho superior e para o alcance
dos objetivos estratégicos da empresa. O BSc é impulsionado pela premissa de que existe uma
relação de causa e efeito entre aprendizado, eficiência interna e processos de negócios, clientes e
resultados financeiros (GARTNER, 2020).
O principal objetivo deste tipo de solução é garantir que os principais indicadores de

desempenho da organização sejam facilmente compreendidos, monitorados, acompanhados e
atribuídos aos respectivos responsáveis, garantindo que todos “falem a mesma língua” e
“estejam na mesma página”. Geralmente estas soluções oferecem recursos como a possibilidade
de que os gestores façam perguntas e comentários uns aos outros relativos aos diferentes
indicadores e dimensões que são acompanhados. Um dos aspectos mais relevantes deste tipo
de solução é a rastreabilidade do impacto que os indicadores de desempenho têm uns sobre os
outros.
Assista aos vídeos:
1) “Dashboards and Scorecards”. Ative as legendas em inglês.
Link: youtube.com [https://www.youtube.com/watch?v=pomZE_mDe5w] . Acesso em 11 ago.

2020.
2) “Scorecards Versus Dashboards”. Ative as legendas em inglês.
Link: youtube.com [https://www.youtube.com/watch?v=7fJ_gJR4RkE] . Acesso em 11 ago. 2020.

Videoaula - Modelo relacional como origem de ambiente de BI -
parte 1
1) Associe a função com o nível administrativo e marque a resposta correta.
1- Estratégico 2- Tático 3-Operacional
A - Os gerentes de nível médio desenvolvem planos de curto e médio prazo e orçamentos, e

especificam as políticas, procedimentos e objetivos para as unidades da organização.
B- Os gerentes da supervisão desenvolvem recursos de planos de curto prazo como os

programas de produção.
C- Os principais executivos desenvolvem as metas globais, estratégias, políticas e objetivos da

organização por meio de um planejamento estratégico de longo alcance.
1B; 2C; 3A
1A; 2B; 3C
1C; 2B; 3A
1C; 2A; 3B
2) Dentre as afirmativas, está INCORRETO afirmar:
tratados para que os algoritmos de identificação de padrões qualitativos ou quantitativos
sejam aplicados.
Nos anos 2010 passou a ocorrer a intensificação de um processo de ampliação do escopo

(downsizing) similar ao que a computação transacional experimentou nos anos 1990 em
termos de hardware.

sistemas usados para monitorar e gerenciar o desempenho dos negócios de uma empresa.
Balanced Scorecard (BSC) é uma abordagem de medição e gestão de desempenho que

reconhece que os indicadores financeiros por si só não são suficientes para a análise e
Recapitulando
Nesta unidade, pudemos conhecer como as informações utilizadas para o processo de

tomada de decisão podem ser organizadas e estruturadas de diferentes formas de modo
a atender os diferentes níveis de tomada de decisão das organizações: níveis
estratégico, tático e operacional.
Vimos também como as ferramentas de BI podem ser divididas em diferentes

categorias: Query, Reporting, Analysis e Mining. Destacamos as ferramentas de Reporting
& Analysis que, na etapa prática desta disciplina, são trabalhadas por meio do ambiente
Qlik Sense de ferramentas de BI.
Vimos também que as ferramentas de BI interagem e são complementadas por outros

tipos de soluções como as de Planning & Workflow utilizadas para dar suporte a
atividades de elaboração de orçamentos, análise preditiva e testes de hipótese, bem
como pelas ferramentas de monitoramento que permitem a elaboração de mapas e
painéis estratégicos, bem como de Dashboards e Cockpits.
Vimos que o conjunto de ferramentas de análise e reporte (BI), de planejamento e

controle de fluxos de aprovação (Planning) e de monitoramento (Scorecard) compõem o
conjunto de soluções descrito pelo Gartner como ferramentas de gestão de desempenho
corporativo ou Corporate Performance Management (CPM).
4 Prática de desenvolvimento em solução de BI
4.1 Sobre o projeto
Agora que você conhece mais sobre as camadas e estruturas de dados que dão suporte às
soluções de BI e CPM é possível colocar em prática o conhecimento que você construiu até aqui
em um projeto de BI, ainda que seja em um ambiente de teste desenhado para fins educacionais.
A prática em um ambiente de teste como o que propomos aqui ajuda a ter uma visão mais
abrangente do conjunto de problemas e soluções oferecidas de exemplo, pois, por ser um
ambiente de pequena complexidade, você pode ter mais controle sobre ele e, ao mesmo tempo,
também permite apresentarmos situações que ajudam a ilustrar problemas reais que os
profissionais de BI encontram em campo.
Lembre-se que desde a antiguidade, Aristóteles indicava um excelente caminho para resolução
de problemas conhecido como o princípio da análise dedutiva, ou seja, diante de um grande e
complexo problema uma boa prática é dividi-lo em problemas menores, mais manejáveis, que
possibilitem a você e à sua equipe uma melhor forma de abordá-lo e de resolvê-lo.
Utilizaremos aqui como exemplo de ambiente estratégico de tomada de decisão um processo

que também afeta o nível gerencial, mas que ajuda a ilustrar o imenso impacto que tal processo
gerencial tem no nível estratégico e vice-versa.
Videoaula - Modelo relacional como origem de ambiente de BI -
parte 2
4.2 Construção de modelo de dados para suporte ao ambiente de BI
A pessoa responsável por desenhar modelos de dados que darão suporte a soluções de BI parte
de um cenário marcado pela complexidade das bases de dados transacionais normalizadas, ou
seja, os modelos relacionais.
Este é o ponto de partida para a abordagem do problema.
No horizonte, essa pessoa almeja a criação do modelo mais simples possível para o projeto de
BI. Se for uma empresa que realmente não processará grandes volumes de dados, que faz um
registro bastante limitado de informações, nada impediria que esse modelo de dados gerencial
fosse o de uma tabela única, uma flat table. Entretanto, quanto maior for o volume de dados, há
grande chance de que o modelo tenha muita incidência de redundância de dados, e isso
certamente irá atrapalhar sua criação ou manutenção. Então parte-se para a busca de modelos
intermediários. Este processo, segundo Kimball (2006) ocorre para que, ao mesmo tempo, os
relacionamentos ou joins entre as tabelas sejam mais simples e que o nível de redundância seja
reduzido ao mínimo.
Considere a diferença entre dois exemplos de empresas:
Empresa A) uma empresa que fabrica navios e que controla a venda de navios para seus clientes.
Qual o volume de dados gerado por essa empresa ao longo de 1 ano?
Navios são produtos caros e que demoram a ser construídos. Portanto, ainda que essa empresa
produza e venda 100 navios em 1 ano, esse volume de dados é extremamente pequeno (ainda que
essa empresa tenha um enorme banco de dados para controlar os componentes utilizados para a
fabricação do navio).
Empresa B) uma empresa que atende a centenas de clientes no país e que processa milhares de
transações feitas por estes clientes ao longo do mês.
Quantas vezes um dado como o tipo de cliente, sua cidade ou UF apareceriam de modo
repetido em um modelo de tabela única?
Vamos analisar: no caso da Empresa A, a consideração de um modelo de tabela única está longe
de ser um absurdo, mas, no caso da Empresa B, o uso de tabela única é praticamente inviável.
Como estes cenários são comuns, procuramos utilizar um tipo de modelagem específico que
busca encontrar um meio termo entre o modelo normalizado e o modelo de tabela única.
Este tipo de modelagem pode ser desenvolvido de diferentes formas e apresentamos aqui um
método simples e eficiente para elaborá-lo.
Para colocá-lo em prática precisaremos de um modelo relacional que servirá de base para o
nosso projeto. Precisaremos conhecer as tabelas, colunas e registros desse modelo de dados e,
então, aplicaremos alguns passos para transformá-lo em um modelo de dados gerencial (ou
multidimensional).
Para deixar nosso projeto mais realista, vamos criar nossa empresa e dar um nome para nosso
projeto: Empresa ForteTec e Projeto ForteBI.
Tomemos como base o modelo relacional mostrado na Figura 24 para o projeto ForteBI.
Figura 24 – Modelo relacional base para o projeto ForteBI
No modelo relacional do projeto ForteBI representado na Figura 24, podemos observar que a
empresa ForteTec visa controlar os pedidos feitos por seus clientes, os vendedores que dão
suporte a estas vendas e os produtos que são comercializados.
Vamos seguir as etapas para a estruturação do projeto ForteBI nas seções que se seguem.
4.2.1 Identificação das tabelas descritivas (qualitativas) e de mensuração

(quantitativas)
O primeiro passo para começar a desenhar um modelo gerencial para um banco de dados que irá
receber informações desse modelo relacional por meio de um processo de ETL é analisar cada
uma dessas tabelas e marcá-las.
Desse modo, olhamos para cada uma das tabelas e perguntamos a nós mesmos:
Essa tabela armazena um dado qualitativo ou quantitativo?

Essa tabela visa armazenar informações descritivas do negócio ou visa armazenar movimentações
ou dados quantitativos que ajudam a mensurar o negócio?
→ Atenção: As tabelas que você identificar como tabelas que servem para
armazenar dados descritivos ou qualitativos devem ser sinalizadas com uma elipse
azul. Já as tabelas de mensuração, de movimento ou quantitativas serão marcadas
com uma elipse vermelha.
Após fazermos a identificação das tabelas quantitativas e qualitativas chegamos ao resultado

apresentado na Figura 25. Observe que das 14 tabelas somente duas não foram marcadas como
essencialmente descritivas ou qualitativas.
Figura 25 – Modelo relacional base para o projeto ForteBI com tabelas

marcadas
As tabelas Pedido e Detalhe do Pedido não foram marcadas com elipses azuis porque servem
principalmente para armazenar dados relativos às transações que visamos controlar e aos
valores, datas ou números calculáveis que visamos mensurar, ou seja, são tabelas que não
possuem estruturas ou elementos descritivos, mas elementos de mensuração e de transações.
Estas duas tabelas, embora sirvam de suporte ao relacionamento entre tabelas qualitativas, são
tabelas quantitativas e por isso foram sinalizadas com elipses vermelhas.
Videoaula - Modelagem dimensional
4.2.2 Análise dos relacionamentos entre tabelas
Após identificarmos as tabelas descritivas (qualitativas) e de mensuração (quantitativas)

passamos então para a análise dos relacionamentos estabelecidos entre essas tabelas.
As regras de relacionamento são basicamente as mesmas estudadas em cursos de modelagem

de dados e podem ser aplicadas do mesmo modo a este tipo de análise que fazemos agora.
Nesta etapa, para a elaboração do modelo gerencial da empresa ForteTec a partir do modelo
relacional, vamos identificar as tabelas qualitativas (com elipses azuis) que se relacionam
diretamente, sem se relacionar com tabelas quantitativas.
Ao fazer isso, podemos notar que algumas das tabelas com elipses azuis ou qualitativas formam
grupos específicos. Se olharmos, do ponto de vista do negócio, o tipo de dados que cada grupo
carrega, observaremos que tratam invariavelmente de um mesmo assunto.
Também vamos aplicar a mesma regra às tabelas com elipses vermelhas ou quantitativas, ou
seja, identificar grupos de tabelas que se relacionam diretamente sem passar por tabelas
qualitativas.
Feito isso, chegamos ao esquema de agrupamento (sinalizado por cores diferentes) da Figura 26
(a partir do modelo da Figura 25).
Figura 26 – Modelo relacional base para o projeto ForteBI com grupos de

tabelas marcadas
4.2.3 Criação do modelo multidimensional: Estrela e iSnowflakei
Após a definição dos relacionamentos, vamos criar o modelo multidimensional do projeto ForteBI
de nossa empresa.
Para nos ajudar, vamos criar o cenário de movimentação de negócios da empresa ForteTec:
A base de dados relacional recebe anualmente 50 milhões de registros.

Há uma equipe de aproximadamente 100 vendedores.
Até o momento foram atendidos aproximadamente 2 mil clientes que compram 1 ou mais dos cerca
de 500 produtos que a empresa comercializa.
Com base neste cenário, a pergunta é:
Quais destas tabelas contêm os maiores volumes destes registros?

Você provavelmente indicou corretamente que são as tabelas Detalhe do Pedido e Pedido, pois
estas tabelas são as responsáveis pelo armazenamento das transações da empresa, que tem
grande volume de transações ocorrendo diariamente.
As tabelas qualitativas ou de descrição (com elipses azuis) que tratam de um mesmo assunto e
que foram agrupadas, formarão as respectivas dimensões do modelo de dados gerencial.
Já as tabelas quantitativas ou de movimento (com elipses vermelhas) que tratam de um mesmo

assunto e que foram agrupadas formarão as tabelas de fato do modelo de dados gerencial.
Deste modo, chegamos ao modelo de dados multidimensional apresentado na Figura 27.
Figura 27 – Modelo multidimensional Estrela para o projeto ForteBI
Observe que este modelo é caracterizado por uma tabela central (tabela de fato Vendas) que se
relaciona com tabelas periféricas (tabelas de dimensão Produto, Vendedor e Cliente).
Este tipo de modelo é denominado Modelo Estrela, pois a tabela de fato ocupa a posição central
e as tabelas de dimensão se espraiam como se fossem pontas de uma estrela.
Ralph Kimbal (2006) tornou este tipo de modelagem popular nos anos 1990 ao empregá-lo
largamente em recomendações para projetos de Data Warehouses e Data Marts.
O modelo Estrela permite ao mesmo tempo certo nível de redução da redundância de dados sem
tornar o modelo multidimensional demasiadamente complexo (quando comparado com o
modelo relacional).
Suponha que só tenham ocorrido vendas para um único estado (SP) e que tenha sido vendido um
único tipo de produto (X). Neste caso, a pergunta é:
Quantas vezes a unidade federativa SP apareceria repetidamente na tabela dimensional de Cliente

(considerando que esta tabela armazene dados de 2000 clientes)?
A resposta seria: igual ao total de clientes presentes na tabela de dimensão, ou seja, 2.000 vezes.
Embora o modelo Estrela admita redundâncias, o volume de redundância tende a ser muito
inferior ao que haveria no caso de um modelo de tabela única. Além disso, o modelo Estrela
proporciona um ambiente bem menos complexo que o dos modelos relacionais.
Eventualmente, quando uma tabela de dimensão contém volume muito grande de dados, pode
ser necessário desmembrar tal tabela de dimensão em duas ou mais.
Imagine que o modelo multidimensional da empresa ForteTec armazenasse transações de 20

milhões de clientes de uma operadora de telefonia. Neste cenário, a dimensão Cliente poderia
armazenar os 20 milhões de clientes e seus atributos como: as cidades onde vivem, as UFs e o
país das cidades, o tipo de cliente etc. Todos estes atributos poderiam repetir-se milhares ou
milhões de vezes nesta tabela dimensional.
Como resolver esse problema de extrema redundância de dados?
A saída tende a ser o desmembramento ou hierarquização da tabela de dimensão (da ponta da

estrela) em mais de uma tabela. Ou seja, seria feita uma estruturação de hierarquia da dimensão.
A título de exemplo, a tabela Cliente passaria a ter tabelas para a localidade do cliente e para
outros atributos de cliente.
A Figura 28 apresenta como ficaria o modelo com a hierarquização da dimensão Cliente.

Figura 28 – Modelo multidimensional Snowflake para o projeto ForteBI
O modelo da Figura 28, no qual uma ou mais dimensões possuem hierarquias, é denominado
modelo Snowflake.
Se você já olhou para o símbolo da temperatura fria nos aparelhos de ar condicionado, ou se já

esteve em um lugar onde há neve, você possivelmente reconhecerá esse símbolo (T). Este
símbolo pode ser descrito como uma estrela cujas pontas foram desmembradas em fractais.
Esse é o símbolo do floco de neve ou snowflake e é assim que chamamos este tipo de modelo que
parte de uma estrela, mas que tem uma ou mais de suas dimensões (ou pontas) desmembradas.
Agora vamos falar um pouco sobre as tabelas de fato (ou apenas tabelas fato), como a tabela
fato Vendas de nosso modelo multidimensional.
As tabelas fato:
Normalmente armazenam dois tipos de dados: métricas (naturais, calculadas ou agregadas) e

chaves-estrangeiras utilizadas para relacionar as tabelas de fato com as tabelas de dimensões (que
contém as chaves primárias de cada dimensão).
Podem armazenar dados com o máximo detalhamento para as transações que controlam (por
exemplo, para cada pedido e detalhe de pedido trazem os seus respectivos dados de quantidade
vendida, valor unitário e valor de venda).
Podem armazenar dados agregados (trazendo o valor agregado da soma das quantidades vendidas, a
média de preços operado e a soma dos valores).
Podem trazer valores consolidados (comparando a previsão de vendas para o dia, o valor de vendas
realizada e a diferença entre estes valores).
Podem trazer uma fotografia de um determinado período ou momento (o resultado de vendas do
último mês fechado ou do acumulado de vendas desde o início do ano até o último fechamento).
Podem ser do tipo que visa somente relacionar dimensões (mas ainda assim os registros podem ser
contados, gerando um tipo de métrica calculada para tal fato).
As tabelas fato podem ser atualizadas de duas maneiras:
Atualização incremental: o processo de ETL considera somente a diferença de transações entre o

último processamento (última carga) e os novos dados registrados no ambiente transacional.
Carga completa: carga completa dos dados toda vez que há a execução de um novo processo de ETL.
As ferramentas de integração de dados, de ETL, oferecem vasta gama de recursos para controlar
a atualização dos DMs e DWs. Em alguns casos, quando há grande volatilidade ou grande
intensidade na alteração do histórico de dados transacionais, pode-se optar por fazer a
atualização incremental.
4.3 Construção de uma aplicação prática de BI
Agora que você conhece conceitos fundamentais para a implementação de solução de BI, vamos
fazer aqui o desenvolvimento de uma aplicação prática de BI voltada para a criação de relatórios,
painéis de análise e apresentação de narrativas de dados.
4.3.1 Definição do modelo multidimensional do projeto prático de BI
Caro(a) estudante, embora já tenhamos mostrado a você os modelos multidimensionais Estrela e

Snowflake do projeto ForteBI, para criarmos nossa aplicação prática, estes modelos terão que
ser modificados e simplificados. Isso porque vamos utilizar dados que já existem na base de
dados na plataforma de BI e estes dados estão todos em inglês. Além disso, a base de dados
desta plataforma é muito grande e é necessário utilizarmos apenas uma parte dos dados, de
forma simplificada, para viabilizar nosso estudo.
Então vamos apresentar os modelos Snowflake e Estrela que usaremos em nosso projeto
prático.
A Figura 29 traz o modelo Snowflake para o projeto prático ForteBI.

Figura 29 – Modelo Snowflake para o projeto prático ForteBI
No modelo Snowflake da Figura 29:
Temos no centro a tabela fato F-Sales (que corresponde à tabela fato Vendas), note que o F antes de
Sales indica que se trata de uma tabela Fato.
Temos a dimensão D-Product (que corresponde à dimensão Produto), note que o D antes de Product
indica que se trata de uma tabela Dimensão.
Temos a dimensão D-Customer (que corresponde à dimensão Cliente), note que o D antes de Customer
indica que se trata de uma tabela Dimensão. Esta dimensão é formada pelos membros:
R-Province (que corresponde a um Estado e está relacionado ao Local Cliente).
R-Region (que corresponde a uma Região e está relacionada ao R-Province).
D-Customer Segment (que corresponde a um Segmento e está relacionado ao Tipo Cliente).
Note que a dimensão (Other Dimensions) apenas ilustra que outras dimensões poderiam ser
incorporadas ao modelo.
A Figura 30 traz o modelo Estrela para o projeto prático ForteBI.

Figura 30 – Modelo Estrela para o projeto prático ForteBI
No modelo Estrela da Figura 30:
Temos no centro a tabela fato F-Sales (que corresponde à tabela fato Vendas), note que o F antes de
Sales indica que se trata de uma tabela Fato;
Temos a dimensão D-Product (que corresponde à dimensão Produto);
Temos a dimensão D-Customer (que corresponde à dimensão Cliente);
Temos a dimensão R-Province (que corresponde a um Estado e está relacionada ao Local Cliente);
Temos a dimensão R-Region (que corresponde a uma Região e está relacionada ao Local Cliente);
Temos a dimensão D-Customer Segment (que está relacionada ao Tipo Cliente).
Note que a dimensão (Other Dimensions) apenas ilustra que outras dimensões poderiam ser
incorporadas ao modelo e que o D antes do nome de cada dimensão indica que se trata de uma
tabela Dimensão.
A vantagem do modelo Estrela em relação ao Snowflake é ser mais simplificado.
Em nosso projeto prático faremos o processo de ETL usando o modelo Snowflake e depois
faremos sua conversão para o modelo Estrela para realizarmos as outras etapas.
É importante manter em mente que, em condições ideais, os modelos de bancos de dados

multidimensionais – Data Marts e Data Warehouses – devem ser os mais organizados,
simplificados e otimizados possível.
Videoaula - Introdução ao ambiente Qlik Sense
4.3.2 Definição da plataforma de BI e da base de dados
Utilizaremos o ambiente Qlik como plataforma de testes.
Figura 31 – Logotipo da plataforma Qlik
Fonte: help.qlik.com
[https://help.qlik.com/pt-BR/]
Você poderá utilizar o ambiente Qlik de testes de acordo com as políticas do fabricante.
Opcionalmente você poderá aplicar cada uma das práticas e conceitos aqui apresentados em
outras ferramentas de sua preferência.
Você também poderá testar seus conhecimentos obtidos em outras disciplinas, como de ETL, na
mesma plataforma de ambiente Qlik se desejar.
Vamos usar um conjunto de arquivos que representará as nossas origens de dados. Esses
arquivos estão organizados para representar um ambiente que traz características de bases
relacionais e multidimensionais, pois se utilizássemos uma base de dados totalmente otimizada
para o ambiente de BI, acabaríamos por deixar de ver situações importantes que você, como
profissional de BI, encontrará eventualmente ao longo de sua carreira e para as quais terá que
propor soluções. Por este motivo é que você observará essa característica híbrida e parcialmente
otimizada da base de dados de nosso projeto.
O objetivo é que você compreenda de que modo irá construir uma aplicação de BI utilizando o
ambiente Qlik Sense Cloud.
Você encontrará no arquivo compactado do nosso projeto:
os arquivos correspondentes às dimensões D-Product (Produto), D-Customer (Cliente) e a tabela fato F-

Sales (Vendas);
arquivos de suporte às tabelas de dimensões que têm por objetivo exemplificar um ambiente de
modelagem do tipo Snowflake, que no nosso projeto, são as tabelas R-Province, R-Region e D-Customer
Segment.
Caro(a) estudante, é importante ressaltar que este conjunto de arquivos foi elaborado com o
objetivo de fornecer um ambiente didático que nos permita exercitar a construção de uma
aplicação de BI considerando aspectos conceituais e práticos vistos ao longo da disciplina.
Você poderá praticar e exercitar livremente tópicos relacionados à programação de consultas a

bancos de dados, bem como processos de extração, transformação e carga – que não são focos
dessa disciplina – mas que são muito próximos e complementares.
Videoaula - Como começar a desenvolver sua aplicação de teste no

ambiente Qlik.-
4.3.3 Download e análise das fontes de dados

Vamos trabalhar com uma base de dados que servirá de suporte aos diferentes exercícios que
faremos no ambiente de BI do Qlik. Essa base de dados, criada como um subconjunto de dados
obtidos dos samples (exemplos) próprio Qlik, foi desenvolvida pelo professor para simular
situações possíveis de se encontrar no ambiente de implementação de um projeto de BI em
casos reais. Os dados se referem ao Canadá e estão todos em inglês.
Você deve seguir os seguintes passos:
1. Acesse a documentação referente ao ambiente Qlik por meio deste link: qlik.com
[https://www.qlik.com/us/trial/qlik-sense-business] (Acesso em 12 ago. 2020). Caso o link não funcione
mais, procure no Google o link atualizado.
2. Configure sua conta de novo usuário seguindo as orientações do próprio fabricante. A Figura 32 mostra a
tela inicial da versão 12.5. Caso as telas tenham mudado, siga as novas orientações do fabricante.
Figura 32 – Tela do Qlik para configuração de uma nova conta de usuário
Fonte: qlik.com [https://www.qlik.com/us/trial/qlik-sense-business]

Faça o download do arquivo que se encontra na aba Material Complementar da plataforma. Nesta aba
você encontrará um arquivo denominado “BasedeDados_ForteBI.zip”. Faça o download deste arquivo
para uma pasta de trabalho em seu computador e extraia os arquivos compactados.
A Figura 33 mostra o arquivo BasedeDados_ForteBI.zip extraído, em que os arquivos que
compõem a base de dados estão visíveis.
Figura 33 – Arquivos da base de dados para o projeto prático ForteBI
Após abrir e acessar o conteúdo destes arquivos, você verá que:
A tabela D-Product contém atributos de produtos como: nome do produto, código do produto, código de
negócio, código geral de produto e a margem do produto.
A tabela F-Sales contém diversos atributos, inclusive o código de produto (Product Code), que é a chave
estrangeira correspondente à chave Product Code na tabela D-Product. Há outros campos como
segmento do cliente, código da província, código de transporte, prioridade, data do pedido, data de
envio etc. Há também diferentes medidas: lucro obtido, preço unitário, custo de entrega do frete etc.
Esta tabela fato possui datas, chave estrangeira e uma chave primária que é o código do pedido (Order
ID).
A tabela R-Province, um arquivo .csv, contém as chaves região, província e código da província. Esta
tabela possui a chave primária de província (E-Province) e a chave estrangeira de região (E-Region). A
Figura 34 mostra o conteúdo desta tabela.
Figura 34 – Conteúdo do arquivo R-Province.csv
A tabela R-Region, que também é um arquivo .csv, no qual encontramos cada uma das regiões de
vendas e o código de região que serve como chave primária (E-Region Code). A Figura 35 mostra o
conteúdo desta tabela.
Figura 35 – Conteúdo do arquivo R-Region.csv

Videoaula - Criação de relacionamentos/associações no Qlik Sense
4.3.4 Importação dos arquivos e Extração, Transformação e Carga de dados
Estudante, é importante considerar que quanto mais cedo for feita a transformação de dados,
menor tende a ser o nível de retrabalho posterior. Portanto, considere que logo após extrair os
dados do ambiente transacional e reservá-los nas tabelas de staging, você pode começar a fazer
as transformações necessárias (de acordo com as necessidades do negócio) nas camadas de
ODS ou de DW relacional, fazendo os ajustes e eventuais agregações na camada do DW
multidimensional ou dos DMs. E por fim deixar somente as transformações estritamente
necessárias para a camada de aplicações.
A interface do Qlik Sense é dividida em três blocos (veja a Figura 36):
Preparar (Organizador de dados)

Analisar (Ideias)
Narrar (Narrativas)
Figura 36 – Interface do Qlik
Quando o ambiente de teste do Qlik é instalado, são trazidos vários exemplos do próprio
ambiente Qlik: ele pergunta se o usuário quer utilizar os dados de exemplo ou se quer utilizar
seus próprios dados. É recomendável, no início, utilizar os modelos de dados de exemplo do Qlik.
O modelo de exemplo do Qlik oferece uma série de campos e colunas e monta, automaticamente,
várias sugestões de análise a partir de seus algoritmos internos.
Vamos iniciar aprendendo como criar uma aplicação, seguindo os passos:
1. Ao clicar na guia Gerenciador de dados no alto da área de trabalho, o Qlik mostra que não há nenhum
modelo ou dado carregado ainda. Esse é o ponto de partida, como mostra a Figura 37.
Figura 37 – Tela do Qlik- ponto de partida

2. Vamos adicionar uma das bases de dados (o arquivo D-Customer) de nosso projeto clicando no símbolo de
adição (+) no centro da área de trabalho do Qlik. Será perguntado qual será a origem de dados. Embora seja
possível selecionar as mais diversas fontes de dados, trabalhamos com arquivos de dados do Excel por
uma questão didática e de facilidade de acesso aos dados, então você deve clicar na área onde está escrito
"solte um arquivo aqui ou clique para selecionar um arquivo" (veja a seta vermelha) para selecionar Excel,
conforme mostra a Figura 38.
Figura 38 – Tela do Qlik para seleção da origem de dados

3. Em seguida, vamos clicar em Arquivos de dados na parte superior esquerda da tela → você deve localizar
os arquivos no local do seu computador onde estão salvos e selecionar a tabela D-Customer. Feito isso,
vamos desabilitar o campo Customer Segment (pois depois vamos criar uma tabela separada para esse
campo, com o objetivo de reduzir a redundância através da criação de uma hierarquia de dimensão). A
Figura 39 mostra esta tela do Qlik com o campo desabilitado.
Figura 39 – Tela do Qlik com o campo Customer Segment da tabela D-Customer desabilitado

4. Em seguida, clicamos em Adicionar dados que está no canto inferior direito, conforme pode ser visto na
Figura 39. Feito isso, aparecerá a tela da Figura 40, mostrando os dados de exemplo do Qlik (SampleData) e
a nossa base de dados Customer-D.
Figura 40 – Tela do Qlik com a base de dados Customer-D do projeto de BI

5. Após a importação do arquivo de dados de origem, precisamos fazer a carga de dados para obtermos as
informações disponíveis para análise. Para isso, basta clicar em Carregar dados que está no canto
superior direito da tela. Ao fazer isso, conseguimos visualizar na parte de baixo da área de trabalho os
campos e informações da tabela, conforme pode ser visto na Figura 40.
6. Conforme dissemos no passo 3, vamos criar uma tabela separada para o campo Customer Segment, com o
objetivo de reduzir a redundância ao criar uma hierarquia de dimensão do modelo Snowflake. Você deve
clicar em Gerenciador de dados, e em seguida digitar os nomes das colunas e seus dados manualmente.
Crie a coluna Segment Code e insira os seguintes dados nas linhas desta coluna: 801, 805, 807, 809. Crie a
coluna Customer Segment e insira os seguintes dados nas linhas destas colunas: Consumer, Corporate, Home
Office, Small Business. Veja o resultado na Figura 41. Após a edição manual dos dados, clique em
Adicionar dados que está no canto inferior direito da tela.
Figura 41 – Tela do Qlik com campos e dados adicionados manualmente

7. Feita essa adição manual, na tela seguinte, clique em Carregar dados no canto superior direito.
8. Agora vamos criar os relacionamentos entre estas duas tabelas. Este processo é bastante simplificado no
Qlik, pois basta clicar e arrastar uma tabela sobre a outra. Clique no círculo referente à tabela Customer-D e
a arraste sobre D-Customer_Segment.
Observe que, ao clicar e arrastar um círculo sobre outro, seus aros mudam de cor. Estas cores
podem ser verde, amarelo ou vermelho e correspondem ao nível associativo entre elas. A cor
verde corresponde a um alto grau de afinidade (de relacionamento) entre as tabelas, a cor
amarela indica grau moderado de afinidade e a cor vermelha indica baixa afinidade ou falta de
relacionamento.
No caso mostrado na Figura 42 entre as tabelas Customer-D e sua hierarquia D-Customer_Segment,

podemos identificar que há alto grau de afinidade, em função da cor verde.
Figura 42 – Tela do Qlik com tabelas Customer-D e D-Customer_Segment associadas

9. Finalizada a inclusão da tabela D-Customer, precisamos fazer o mesmo para as tabelas restantes. Para isso
você deve repetir alguns passos, mas não será necessário desabilitar nenhum campo nem fazer adição de
colunas (tabelas dimensão) das outras tabelas. Siga o roteiro a seguir para cada uma das tabelas: F-Sales,
R-Region, R-Province e D-Product. Preste atenção, pois no caso de tabelas .csv o passo f) deve ser feito com
cuidado.
a. Clique na guia Gerenciador de dados.

b. Como fizemos no passo 2, clique no símbolo de adição (+) no canto superior esquerdo da tela → clique na
área onde está escrito “solte um arquivo aqui ou clique para selecionar um arquivo", conforme mostrado
na Figura 38.
c. Como fizemos no passo 3, clique em Arquivos de dados na parte superior esquerda da tela → localize e
selecione a tabela no local do seu computador onde está salva.
d. Como fizemos no passo 4, clique em Adicionar dados que está no canto inferior direito da tela.
e. Como fizemos no passo 5, clique em Carregar dados que está no canto superior direito da tela.
f. Atenção: No caso de tabelas do tipo .txt ou .csv, verifique com atenção se o cabeçalho da primeira coluna
foi reconhecido, clicando na opção Nomes do campo e selecionando Nomes de campos embutidos; depois,
clique logo abaixo em Tamanho do cabeçalho e selecione uma linha. A tela da Figura 43 mostra um
exemplo de cabeçalho que não foi reconhecido e você não pode correr este risco.
Figura 43 – Tela do Qlik com cabeçalho não reconhecido
Videoaula - Modelos de dados Snowflake e Estrela no Qlik
4.3.5 Criando relacionamento entre tabelas e indicando chaves: modelo

iSnowflakei
Ao clicar e arrastar uma tabela sobre a outra (como fizemos com as tabelas Customer-D e D-
Customer_Segment) você observará que um vínculo/relacionamento é criado, como mostra a
Figura 44. Se você clicar no pequeno círculo no meio da ponte do vínculo criado, você poderá
identificar os critérios automaticamente sugeridos pelo Qlik para seu relacionamento. É sempre
recomendável que você tenha o controle, ou seja, que você identifique e crie os relacionamentos
críticos do seu modelo de dados. Você pode, assim, personalizar o vínculo ou “associação” no
Qlik pressionando o botão Personalizar associação, que fica no canto inferior esquerdo da tela,
conforme mostra a Figura 44.
Figura 44 – Tela do Qlik mostrando o relacionamento criado entre 2 tabelas
Em seguida (conforme mostra a Figura 45) você poderá indicar de cada lado da associação
(correspondente a cada uma das tabelas) qual o campo que será utilizado como chave primária.
No caso da tabela D-Customer_Segment escolha o campo Segment Code como chave primária. No
caso da tabela Customer-D escolha o campo Customer Segment Code como chave estrangeira.
Figura 45 – Tela do Qlik mostrando como indicar a chave primária das tabelas
Após definir o campo de associação, indicando a chave primária e/ou estrangeira das
respectivas tabelas, você pode clicar no botão Associar que fica no canto inferior direito da tela
(veja a Figura 45). Embora você possa alterar o nome da associação criado automaticamente
pelo Qlik, no nosso projeto vamos manter o nome sugerido (como o nome Customer Segment
Code-Segment Code mostrado na Figura 45).
Note, como mostra a Figura 46, que a coloração abaixo do nome da associação indica o grau de
afinidade das tabelas.
Figura 46 – Cor indicativa da associação criada entre as tabelas
Neste primeiro momento, estamos criando um modelo de relacionamento do tipo Snowflake

entre as tabelas, conforme mostra a Figura 47.
Mas este exercício tem por objetivo somente ensinar a você como criar um modelo Snowflake.
No nosso projeto, usaremos o modelo Estrela, então depois veremos como fazer esta
modificação.
Figura 47 – Modelo Snowflake
Para criarmos o modelo da Figura 47, você deve ligar as tabelas e indicar suas chaves de acordo
com as orientações a seguir.
a. Remova a associação entre D-Customer_Segment e Customer-D arrastando uma tabela (círculo) para longe da
outra e em seguida crie um relacionamento entre D-Customer_Segment e F_Sales (indique como chave
primária da tabela D-Customer_Segment a coluna Segment Code e para a tabela F_Sales indique como chave
estrangeira a coluna Customer Segment Code). Fazemos este passo para ao mesmo tempo aprendermos
como remover uma associação já existente e criarmos um novo relacionamento.
b. Arraste a tabela Customer-D e faça sua associação com a tabela F-Sales (indique como chave primária da
tabela Customer-D a coluna Customer Code e para a tabela F-Sales indique também a coluna Customer Code
como chave estrangeira).
c. Arraste a tabela R-Region para R-Province (indique como chave primária da tabela R-Region a coluna E-
Region Code e como chave estrangeira de R-Province a coluna E-Region Code também).
d. Arraste a tabela D-Product para a F-Sales (indique como chave primária da tabela D-Product a coluna
Product Code e como chave estrangeira da tabela F-Sales também a coluna Product Code).
Videoaula - Modelos de dados Snowflake e Estrela no Qlik
4.3.6 Do modelo iSnowflakei para o modelo Estrela
Caro(a) estudante, em nosso projeto ForteBI não usaremos o modelo Snowflake mas sim o
modelo Estrela conforme recomendação do fabricante Qlik para simplificação dos modelos.
Como é importante que você saiba montar os dois tipos de modelo (Snowflake e Estrela), fizemos
primeiro o modelo Snowflake.
Portanto, vamos modificar os relacionamentos entre as tabelas do modelo Snowflake para o

modelo Estrela.
Se você clicar sobre uma tabela e arrastar afastando-a de outra com a qual estiver associada,
você poderá remover ou “quebrar” a associação entre as mesmas.
Para chegarmos ao modelo Estrela, vamos seguir os passos indicados a seguir.
1. Desassociar as tabelas R-Region e R-Province da tabela Customer-D. A Figura 48 mostra o resultado.

Figura 48 – Remoção da associação das tabelas R-Region e R-Province da tabela Customer-D

2. Recriar os relacionamentos de modo a associar as tabelas R-Province e R-Region à tabela de fato F_Sales. O
resultado deve ficar como mostra a Figura 49, que é o modelo Estrela.
Figura 49 – Modelo Estrela

Videoaula - Visualização dos dados no ambiente Qlik - parte 1
4.3.7 Visualização do script de carga de dados
Caro(a) estudante, embora não seja necessário para o nosso projeto, acho importante que você
saiba como visualizar o script de carga de dados gerado para o modelo Estrela de nosso projeto.
Para isso, clique em Gerenciador de Dados e selecione Editor de carga de dados.
O script é gerado automaticamente, mas, você também pode criar camadas de scripts que são
executados na ordem que você definir no painel (lado esquerdo da tela).
Observe na Figura 50 que cada tabela que você importou corresponde a um trecho do script
gerado. No código mostrado na figura, você pode identificar parte do script da carga da tabela D-
Customer, as cargas das tabelas D Product e R-Province.
Figura 50 – Visualização do script de carga de dados gerado pelo Qlik
A recomendação é a de que as tabelas fato do modelo (pode haver mais de uma) sejam sempre
as últimas a serem carregadas.
Você pode exportar cada uma das tabelas dimensão e fato em formato .qvd. Estes arquivos .qvd
são arquivos de dados que podem ser utilizados como origens de aplicações criadas para os
usuários finais.
A vantagem do uso de arquivos .qvd como origens de dados de aplicações está no fato de serem
previamente processadas e, portanto, muito mais rápidas para consultas a serem feitas pelas
aplicações de frontend dos usuários.
Assim, é possível, por exemplo:
Criar uma camada de aplicação Qlik para trabalho de ETL (que tem como origem conexões, tabelas
ou arquivos de dados), que é utilizada para transformar e fazer cálculos necessários do projeto, e que
tem como destino de carga os arquivos .qvd.
Criar uma camada de aplicação Qlik para apresentação de dados que é utilizada para ler os arquivos
.qvd, criar as visões de negócio dos usuários em uma camada de frontend e que tem como destino as
aplicações que serão publicadas para a comunidade de usuários.
Ao criar uma aplicação de frontend, ou seja, para atender às demandas de informações
gerenciais da comunidade de usuários do negócio, você poderá repetir os passos que
ensinamos, prescindindo da criação de relacionamentos que não forem necessários à validação
de dados. Em outras palavras, você poderá criar aplicações de ETL no Qlik Sense sem ter
necessariamente que criar associações entre tabelas, pois as utilizará somente para criar os
arquivos .qvd que serão posteriormente utilizados nas aplicações de front end.
Já nas aplicações de visualização de dados, ou de frontend você terá que criar as associações
necessárias que permitam que seus usuários criem análises baseadas nas diversas dimensões e
fatos que contêm os dados de interesse para eles. Para isso você poderá repetir os passos, mas
utilizando arquivos .qvd como origem de dados das aplicações.
Caro você queira saber mais, estudante, recomendamos que você consulte a documentação do
fabricante (Qlik).
Videoaula - Visualização dos dados no ambiente Qlik - parte 2
4.4 Criando visualizações e análises
Agora que você já sabe como criar uma aplicação no ambiente Qlik Sense com o objetivo de
transformar e modelar os dados, que já sabe como importar, transformar e associar tabelas,
passamos a conhecer como os usuários poderão visualizar os dados a partir da interface de
criação de pastas do ambiente Qlik.
Nosso objetivo será criar um exemplo de visão de negócios e conhecer alguns dos principais
componentes de visualização de dados do Qlik Sense.
Após criar uma aplicação no ambiente Qlik Sense, é natural criar a camada de visualização de
dados para os usuários.
Este trabalho é feito através da guia Analisar que fica no centro do menu da barra superior da
tela.
Você poderá criar quantas visualizações ou “pastas” desejar para atender aos usuários. Para
nosso projeto, vamos fazer isso passo a passo.
1. Para iniciar, selecione Pasta na guia Analisar. A Figura 51 mostra a tela resultante, que é uma pasta vazia.
Isso porque, no nosso caso, você não deve aceitar que o Qlik crie análises de exemplo/teste automáticas.
Figura 51 – Tela do Qlik com a pasta vazia

2. Clique na pasta para você ter o botão Editar pasta visível no canto superior direito da tela, como pode ser
visto na Figura 51.
3. Clique no botão Editar pasta. Você observará a interface de criação de visualizações do Qlik Sense. Essa
interface exibe (do lado esquerdo) quatro botões que correspondem a diferentes tipos de objetos ou
componentes que você pode utilizar para construir sua visualização (veja os botões na Figura 52). Vamos
entender para que servem estes botões:
Campos: Você pode utilizar campos que são originados a partir das tabelas importadas e carregadas
no modelo Estrela de nosso projeto. Os campos podem ser originais tal como vindos das tabelas
carregadas, ou podem ser calculados por meio de edições dos scripts ou na tela de importação de
tabelas.
Itens Mestres: Os itens mestres são objetos que você cria para reutilizar em diferentes visualizações.
Você pode, por exemplo, criar uma dimensão hierarquizada por meio de itens mestres. Pode ser
definido um caminho de detalhamento (drill down) desde informações mais resumidas para
informações mais detalhadas (por exemplo, você poderia criar um drill que iria de País para
Estado/UF e então para Cidade). Cada item mestre pode ser utilizado como um campo composto em
uma visualização.
Gráficos: A área Gráficos contém aqueles objetos de construção de visualizações mais comumente
utilizados e que fazem parte do repertório padrão de objetos de visualização do Qlik Sense. Lá você
encontra os layouts de gráficos como de colunas, de pizza etc., bem como filtros e tabelas que dão
suporte às suas análises.
Objetos personalizados: Na área de objetos personalizados você encontra outros tipos de layouts de
gráficos elaborados por terceiros que podem ser adicionados à sua solução Qlik.
Na Figura 52 você pode observar em detalhe os botões de acesso aos diferentes objetos
disponíveis no ambiente Qlik Sense.
Figura 52 – Os 4 botões para edição de pastas

4. Vamos criar uma primeira pasta/visualização. É recomendável que antes de inserir algum campo da
origem de dados você crie um “espaço” (placeholder) ou insira um componente que melhor receba a
informação que irá selecionar. Este objeto pode ser um layout gráfico ou um filtro. Vamos começar
inserindo filtros como placeholders que receberão os campos necessários para sua análise.
Para isso, clique no botão Gráficos, encontre na lista de objetos o item painel de filtro e então arraste este
objeto para a área de trabalho (área maior quadriculada) do painel de análise. Ao inserir o objeto você será
perguntado se já deseja incluir uma dimensão. Veja a Figura 53.
Figura 53 – Inserção do objeto painel de filtro do botão Gráficos

5. Como vamos criar muitos filtros, insira pelo menos quatro objetos painel de filtro lado a lado na área de
trabalho, como mostra a Figura 54.
6. No caso destes quatro objetos painel de filtro utilizaremos dados qualitativos que servirão para que o
usuário crie filtros dinâmicos enquanto navega nos dados.
Para cada um deles, clique no botão Campos do lado esquerdo da tela → clique em Filtrar por
tabela → selecione a tabela que contém o campo que deseja utilizar, e então, clique e arraste o
campo desejado. No nosso caso, clique em Customer Segment e o arraste para o primeiro painel
de filtro. Veja a Figura 54.
Figura 54 – Preenchendo o primeiro painel de filtro

7. Repita o passo 6 para preencher os outros painéis de filtro conforme mostra a Figura 55.
Figura 55 – Preenchendo os quatro objetos do tipo painel de filtro

8. Neste passo vamos adicionar um objeto para a visualização de dados (e não somente para filtragem de
dados), tal como exibido na Figura 56, na qual utilizamos um objeto Tabela.
Para adicionar um objeto de visualização você deve clicar no botão Gráfico no canto esquerdo da tela e
escolher o objeto Tabela, clicando e arrastando-o logo abaixo dos filtros previamente criados (veja Figura
56).
Figura 56 – Criando visualização de dados - inserindo objeto Gráfico Tabela

9. O Qlik indica áreas (sugeridas) para o tamanho do objeto a ser inserido. Você pode acatar o tamanho e
posição do objeto sugerido e depois redimensionar de acordo com sua necessidade ou gosto.
Para inserir dados na tabela, você deve clicar no botão Campos e encontrar os campos Customer Name e
Order Quantity. Arraste o campo Customer Name para a área da tabela e, quando perguntado, insira-o como
uma dimensão. Em seguida arraste o campo Order Quantity e quando perguntado escolha medida com
agregação de tipo soma (ou sum).
A Figura 57 mostra o resultado dos dados inseridos no objeto de visualização do tipo tabela.
Figura 57 – Dados adicionados ao objeto de visualização de tipo tabela
Observe que, ao clicar e arrastar um campo de descrição ou de valor, você será perguntado sobre
qual o “papel” daquele campo que está sendo arrastado para o objeto de visualização. Você
deverá escolher opção dimensão para dados descritivos e medida para dados de mensuração.
Sendo que neste último caso você deverá também indicar qual é a regra de agregação, se será
agregação por soma, média, contém etc.
Após adicionar um objeto em um gráfico, tabela ou painel de filtros, dependendo do tipo de campo
inserido (se qualitativo ou quantitativo) você poderá ser perguntado sobre como agregar aquele
dado. No caso dos dados de medidas (quantitativos) como order quantity, sales etc., você
precisará indicar qual a regra de agregação que será utilizada, ou seja, se será feito o cálculo de
média, de soma ou de contagem. Para definir a regra de agregação para um dado quantitativo
(medida) basta indicar a regra quando o Qlik apresentar esta questão tão logo você clicar e
arrastar um campo como medida.
10. Continuando a criação da pasta de visualização, repita os passos 8 e 9, porém, desta vez, escolha o objeto
Gráfico de Pizza, disponível em Gráficos, e o coloque à direita da tabela previamente inserida. Adicione os
campos Product Category (como dimensão) e Sales como medida (utilizando o cálculo de agregação de
soma para esta medida). Veja a Figura 58.
11. Repita os passos 8 e 9 para inserir abaixo da tabela um Gráfico de Barra, disponível em Gráficos, que terá
como dimensão a coluna automaticamente gerada pelo Qlik chamada Year, esta que estará disponível
dentro da opção Order Date da tabela F_Sales (estas opções de colunas estão disponíveis em Campos, que
fica à esquerda no alto da tela, conforme a Figura 57). Em seguida arraste o campo Sales da tabela F_Sales
(como medida agregada por soma) para dentro do gráfico de barra. Veja a Figura 58.
12. Repita os passos 8 e 9 para inserir, abaixo do gráfico de pizza, um gráfico de correlação do tipo Sankey.
Este objeto, denominado Sankey Chart, está disponível na área Objetos Personalizados que aparece na
barra lateral do lado esquerdo. Arraste o objeto para o lado direito do gráfico de barras e abaixo do gráfico
de pizza. Em seguida arraste para dentro do Sankey Chart os dois campos de dimensão: Customer Segment
e Product Category; ambos estão disponíveis na área Campos no lado esquerdo da tela. Como medida
arraste o campo Order Quantity que também está disponível em Campos. Indique Soma como cálculo de
agregação, ao ser perguntado. Veja a Figura 58.
Figura 58 – Construindo a pasta de visualização

13. Após criar sua pasta de visualização, clique no botão Edição concluída no canto superior direito da tela
(em amarelo na Figura 58). Veja o resultado final nas Figuras 59 e 60.
Os objetos de visualização de dados são os protagonistas da análise/visualização de dados, pois
são eles que exibem as informações que serão analisadas pelos tomadores de decisão. Estes
objetos podem ser tabelas, gráficos ou outros tipos de displays úteis aos usuários das áreas de
negócio.
Enquanto estiver em modo de edição você terá como interagir com os objetos do painel de filtro
de modo simplificado. Mas esta interação torna-se muito mais dinâmica e responsiva no modo
de visualização. Para alternar entre os modos de edição e visualização você precisa clicar no
botão Edição concluída que aparece em cor amarela no canto superior direito da tela (veja Figura
56). Ao mudar de modo de trabalho você verá que os objetos para construção de pastas deixam
de ser exibidos, que a grade de referência de layout desaparece e que a visualização ocupa
praticamente toda a tela.
14. Ao acionar o botão Edição concluída, você poderá interagir com a aplicação no modo de usuário. Se você
clicar na opção Customer disponível no primeiro painel de filtro (Customer Segment) você notará que ele
ficará na cor verde e que todos os painéis irão responder à seleção feita por você.
Observe que o Qlik Sense irá criar uma guia (tab) na parte superior da tela de visualização que
indica que um filtro está sendo aplicado para tal campo e registro.
Se você clicar também no item Furniture, disponível no segundo painel de filtro (Product
Category), você notará que a tabela e os gráficos irão responder também a esta seleção.
Você poderá remover o filtro clicando novamente no dado previamente selecionado (removendo
a sua cor verde) ou clicando no (x) correspondente à tab/guia automaticamente criada na parte
superior da tela.
A Figura 59 mostra o resultado com filtros aplicados e a Figura 60 mostra o resultado com os
filtros desativados.
Figura 59 – Visualização criada no Qlik Sense com filtros aplicados pelo usuário
Figura 60 - Visualização criada no Qlik Sense sem filtros acionados pelo usuário
Na Figura 59 temos uma visualização com dois filtros ativos (cada guia corresponde a um bloco
de filtros ativos). Na Figura 60 temos a análise sem filtros acionados; observe que não há as
tabs/guias na parte superior da tela de análise. Cada objeto pode manter a associação
automática para interação com os filtros aplicados (herdando o status do filtro selecionado) ou
você poderá configurá-los individualmente de modo a torná-lo independente. Você encontra
essas opções de estado de interação dos filtros nas propriedades de exibição de cada objeto de
layout.
Videoaula - Criação de Displays e Dashboards no ambiente Qlik -
parte 1
4.4.1 Recomendações para outras atividades do Qlik
Agora que você já sabe como criar uma aplicação de visualização ou de frontend no ambiente
Qlik, recomendamos que exercite com diferentes exemplos de dados para que adquira a prática
necessária. É essencial que você considere:
Que um dos objetivos principais das soluções de BI é proporcionar aos usuários das áreas de negócio
um ambiente de fácil utilização, que proporcione uma experiência analítica ao mesmo tempo
simples e rica para gerar insights de negócio.
Que a aplicação precisa ter tempo reduzido de resposta para o usuário e, para que isso ocorra, não é
recomendável que os dados sejam recuperados direto das origens de dados transacionais (pois
concorreria com as operações em andamento da empresa).
Que as visões transacionais podem não corresponder à visão necessária à equipe de gestores e
tomadores de decisão, e que as diferentes origens de dados podem apresentar nomenclaturas,
terminologias e regras de negócio distintas para cada campo, descrição, medida etc. Assim é
necessária a realização de um cuidadoso processo de ETL que proporcione uma visão única das
regras de negócio.
Que é importante criar um ambiente estável, escalável e de fácil manutenção das camadas de
aplicação utilizadas tanto para transformação de dados quanto para geração de visualizações ou
visões de negócio frontent para os usuários finais.
Que é importante apresentar aos usuários uma interface que proporcione a melhor experiência
possível em termos de visões de negócio relevantes aos seus processos de tomada de decisão.
Conhecer os objetivos de negócio, as estratégias da organização, seus desafios e metas

permitirá a você e à sua equipe melhores condições para propor visões de negócio relevantes. Os
ambientes de visualização normalmente dão suporte não somente a outras soluções de
Business Intelligence, mas também apoiam ambientes de monitoramento (soluções de
Scorecard) e de Planejamento – tornando completo o ciclo de soluções de Gestão de
Performance Corporativa ou o Corporate Performance Management.
Videoaula - Criação de Displays e Dashboards no ambiente Qlik -

parte 2
1) Leia as afirmativas e assinale a INCORRETA:
No Modelo Star a tabela de fato ocupa a posição central e as tabelas de dimensão se

espraiam em torno dela como se fossem pontas de uma estrela.
Se uma empresa faz registros bastante limitados de informações, como um estaleiro que
fabrica poucos navios por ano, nada impediria que o modelo de dados gerencial fosse o de
flat table.
Ralph Kimbal tornou o modelo Snowflake popular nos anos 1990 ao empregá-lo largamente
em recomendações para projetos de Data Warehouses e Data Marts.
As tabelas qualitativas ou de descrição que tratam de um mesmo assunto e que foram

agrupadas, formarão as dimensões do modelo de dados multidimensional.
2) A pessoa responsável por desenhar modelos de dados que darão suporte a soluções de BI
parte de um cenário marcado pela ______ das bases de dados _______, ou seja, os modelos
________. As lacunas são correta e respectivamente preenchidas com:
Complexidade; transacionais normalizadas; relacionais
unicidade; desnormalizadas; transacionais
inclusão; desnormalizadas; relacionais
variedade; dimensionais normalizadas; multidimensionais

Recapitulando
Vimos que, para elaborarmos modelos de dados para os bancos de dados

gerenciais/multidimensionais, normalmente partimos de modelos relacionais
complexos tendo como horizonte, ou objetivo, criarmos um modelo mais simples
possível a ser posteriormente conectado às ferramentas de BI.
Cada fabricante de ferramentas de BI ou de ferramentas de visualização de dados

indicam os modelos que melhor se adequam às suas tecnologias. Alguns fabricantes
irão recomendar origens de dados em modelagem Estrela, outros em modelagem
Snowflake, outros indicarão o uso de flat tables e até mesmo podem indicar o uso de
modelos relacionais. É necessário consultar a documentação de cada provedor de
solução de BI e fabricante para elaborar o melhor modelo possível para a ferramenta.
Nesta unidade, construímos um modelo de negócios para nosso projeto ForteBI, que
utilizou inicialmente um modelo Snowflake, que, posteriormente, foi convertido em um
modelo Estrela. Utilizamos uma base de dados constituída por arquivos Excel e arquivos
do tipo CSV. Criamos uma conta de teste no ambiente Qlik Sense Cloud, criamos uma
aplicação e importamos os arquivos de exemplo. Ao construirmos a aplicação,
exercitamos na prática a criação de relacionamentos entre tabelas, indicando as
respectivas chaves primárias e estrangeiras. Observamos como o ambiente Qlik
disponibiliza o script correspondente às criações que fizemos utilizando o ambiente
gráfico da ferramenta.
Por fim criamos um exemplo de visualização/análise no ambiente Qlik com o objetivo de

explorar os dados da base de dados e identificar como o usuário final se beneficia do
ambiente criado para o negócio.
Videoaula - Revisão do conteúdo prático
Considerações finais
Ao longo desta disciplina, tivemos a oportunidade de conhecer aspectos teóricos e práticos
relacionados ao desenvolvimento de soluções de BI. Vimos que conhecer o histórico dos
problemas das organizações e os tipos de ferramentas e tecnologias utilizadas ao longo do
tempo ajudam a melhor compreender as necessidades do negócio e orientar a empresa nas
soluções que você poderá propor como profissional da área.
Vimos também que usuários gerenciais e operacionais tendem a ter problemas distintos para
serem resolvidos e, consequentemente, precisam de tecnologias, soluções e dados organizados
de modo também diferenciado de acordo com seus respectivos perfis.
Estudamos as principais diferenças entre os ambientes de bancos de dados com finalidades

transacionais e gerenciais, bem como o tipo de modelagem típicos de cada um deles.
Observamos como diferentes autores dedicados à temática da construção de bases de dados

gerenciais propuseram modelos e arquiteturas de Data Marts e Data Warehouses que dão
suporte às soluções de BI.
Aprendemos a como implementar uma metodologia simples e efetiva para transpor modelos de
dados relacionais/transacionais para modelos de dados multidimensionais/gerenciais e as
diferenças entre os modelos Estrelae Snowflake.
Na parte prática, trabalhamos com o desenvolvimento de uma aplicação no ambiente Qlik Sense.
Elaboramos uma camada de transformação de dados, necessária para dar suporte a um
ambiente integrado e ágil para recuperação dos dados de negócio e para a elaboração de uma
camada de frontend utilizada para disponibilizar aos usuários das áreas de negócio um ambiente
de visualização de dados interativo e de fácil utilização.
Esperamos que este conteúdo introdutório sobre ambientes de BI proporcione a você o

necessário impulso para o seu desenvolvimento na área.
Recomendamos que você exercite ao máximo os conhecimentos aqui tratados, que busque
aprofundamento sobre teorias, técnicas e ferramentas de BI de sua preferência, associando este
conteúdo aos demais que já teve oportunidade de explorar ao longo de sua formação!
Exercícios de fixação - respostas
1) Os _______ são desenvolvidos para estarem disponíveis a um grupo de usuários de dados
gerenciais de modo quase sempre circunscrito a um assunto ou área da organização. Quando o
projeto de um banco de dados gerencial é desenhado para atender ao conjunto das áreas de
modo corporativo, este inicia-se pela criação do ________. As lacunas são correta e
respectivamente preenchidas com
Bancos de Dados Relacionais; Modelo de Dados Multidimensional.
Data Marts; Data Warehouse.
Modelos de Dados Relacionais; Modelo de Dados Multidimensional.
Data Warehouses; Data Mart.
2) Entre os anos 1980 e 1990, antes da consolidação das soluções de BI no mercado, os

problemas que as organizações tiveram que enfrentar incluem os seguintes, EXCETO:
integração dos processos operacionais: junção de tarefas comuns entre diferentes sistemas
formando um sistema único como o ERP- Enterprise Resource Planning, ou seja, um sistema
integrado de gestão empresarial.
informatização dos processos operacionais: criação dos primeiros sistemas que atendiam
otimização das ferramentas OLAP: inclusão de técnicas mais avançadas de ETL para melhoria
da visualização dos dados em cubos ou hipercubos.
divisão do ambiente gerencial/operacional: construção de bancos de dados gerenciais

dedicados a suprir as áreas de negócio para tomada de decisão.
1) Ao tratarmos dos dados qualitativos estamos basicamente tratando _______ de um banco de

dados gerencial, que utiliza modelagem multidimensional. A lacuna é corretamente preenchida
com:
das tabelas fato
das medidas não aditivas
das operações transacionais
das dimensões
2) Considere as afirmativas e assinale a INCORRETA:
é desejável transformar uma flat table com poucas redundâncias em um conjunto de tabelas
normalizadas que garanta a integridade e o máximo de redundância de dados.
quando falamos de problemas a serem resolvidos no nível operacional, de modo geral,

estamos tratando de questões de curtíssimo prazo.
quando uma medida ou dado quantitativo pode ser utilizado nos diversos cruzamentos de
dimensões em seu nível máximo de detalhe, esta medida é considerada uma medida aditiva.
uma coluna calculada agregada depende da leitura de um conjunto de linhas para que seja
possível chegar ao cálculo agregado.
1) Associe a função com o nível administrativo e marque a resposta correta.
1- Estratégico 2- Tático 3-Operacional
A - Os gerentes de nível médio desenvolvem planos de curto e médio prazo e orçamentos, e

especificam as políticas, procedimentos e objetivos para as unidades da organização.
B- Os gerentes da supervisão desenvolvem recursos de planos de curto prazo como os

programas de produção.
C- Os principais executivos desenvolvem as metas globais, estratégias, políticas e objetivos da

organização por meio de um planejamento estratégico de longo alcance.
1B; 2C; 3A
1A; 2B; 3C
1C; 2B; 3A
1C; 2A; 3B
2) Dentre as afirmativas, está INCORRETO afirmar:
tratados para que os algoritmos de identificação de padrões qualitativos ou quantitativos
sejam aplicados.
Nos anos 2010 passou a ocorrer a intensificação de um processo de ampliação do escopo

(downsizing) similar ao que a computação transacional experimentou nos anos 1990 em
termos de hardware.

sistemas usados para monitorar e gerenciar o desempenho dos negócios de uma empresa.
Balanced Scorecard (BSC) é uma abordagem de medição e gestão de desempenho que

reconhece que os indicadores financeiros por si só não são suficientes para a análise e
1) Leia as afirmativas e assinale a INCORRETA:
No Modelo Star a tabela de fato ocupa a posição central e as tabelas de dimensão se

espraiam em torno dela como se fossem pontas de uma estrela.
Se uma empresa faz registros bastante limitados de informações, como um estaleiro que
fabrica poucos navios por ano, nada impediria que o modelo de dados gerencial fosse o de
flat table.
Ralph Kimbal tornou o modelo Snowflake popular nos anos 1990 ao empregá-lo largamente
em recomendações para projetos de Data Warehouses e Data Marts.
As tabelas qualitativas ou de descrição que tratam de um mesmo assunto e que foram

agrupadas, formarão as dimensões do modelo de dados multidimensional.
2) A pessoa responsável por desenhar modelos de dados que darão suporte a soluções de BI
parte de um cenário marcado pela ______ das bases de dados _______, ou seja, os modelos
________. As lacunas são correta e respectivamente preenchidas com:
Complexidade; transacionais normalizadas; relacionais
unicidade; desnormalizadas; transacionais
inclusão; desnormalizadas; relacionais
variedade; dimensionais normalizadas; multidimensionais

Autoria
Allan Herison Ferreira
Autor
Formado em Sistemas de Informação e Administração de Empresas, Mestre em Sociologia do
Trabalho em TI pela Universidade de São Paulo, 20 anos de experiência em Business Intelligence
e Corporate Performance Management. Foi professor de Business Intelligence na FIAP-
Faculdade de Informática e Administração Paulista (2004 a 2008). Hoje é doutorando pela
Universidade Nova de Lisboa, Portugal.
Elisamara de Oliveira
Autora revisora
Possui doutorado em Engenharia Elétrica pela Universidade de São Paulo, mestrado em Ciência
da Computação pela Universidade Federal de Minas Gerais e é Bacharel em Ciência da
Computação pela Universidade Federal de Minas Gerais. Possui mais de 30 anos de experiência
profissional na área de TI, com atuação mais recente como Designer Pedagógica EAD, realizando
a supervisão de qualidade técnica de conteúdo EAD, além de elaborar, credenciar, autorizar e
coordenar projetos e cursos de pós-graduação EAD na área de TI.
Glossário
Benchmark
O benchmarking consiste na pesquisa e conhecimento profundo de quem são os concorrentes
do setor e como eles trabalham. É uma investigação contínua de comparação de produtos,
serviços e práticas empresariais entre uma organização e seus concorrentes. A partir desse
estudo é mais fácil entender o seu competidor e até prever qual será o próximo passo. Fonte:
ibccoaching.com.br [https://www.ibccoaching.com.br/portal/o-que-e-e-como-funciona-o-
benchmarking/] . Acesso em 12 ago. 2020.
Enterprise Resource Planning (ERP)

Software capaz de consolidar todos os setores da empresa em apenas um sistema simples e
fácil de operar. Permite, assim, uma visão panorâmica do negócio, em tempo real. Esse tipo de
sistema é composto por uma série de módulos integrados que utilizam apenas uma base de
dados comum. Cada um deles é responsável por uma área determinada da empresa. Sendo
assim, ao implantar essa solução, o gestor terá a visibilidade sobre todos os aspectos de seu
negócio. Fonte: mega.com.br [https://www.mega.com.br/blog/enterprise-resource-planning-
afinal-o-que-e-erp-3792/] . Acesso em 12 ago. 2020.
Howard Dresner
Em 1989, Howard Dresner (mais tarde analista do Gartner Group) propôs Business Intelligence
como um termo genérico para descrever "conceitos e métodos para melhorar a tomada de
decisões de negócios usando sistemas de suporte baseados em fatos". Somente após o final
dos anos 1990 que seu uso foi generalizado. Fonte: en.wikipedia.org
[https://en.wikipedia.org/wiki/Business_intelligence] . Acesso em 12 ago. 2020.
Operational Data Store (ODS)

Um armazenamento de dados operacional (ODS) é uma alternativa para que aplicativos de
Sistemas de Suporte à Decisão operacional acessem dados diretamente do banco de dados que
suporta o processamento de transações. Embora ambos exijam uma quantidade significativa de
planejamento, o ODS tende a se concentrar nos requisitos operacionais de um processo de
negócios específico (por exemplo, atendimento ao cliente) e na necessidade de permitir
atualizações e propagar essas atualizações de volta ao sistema transacional de origem a partir
do qual os elementos de dados foram obtidos. O Data Warehouse, por outro lado, fornece uma
arquitetura para os tomadores de decisão acessarem dados para realizar análises estratégicas, o
que geralmente envolve dados históricos e interfuncionais e a necessidade de suportar muitos
aplicativos. Fonte: gartner.com [https://www.gartner.com/en/information-
technology/glossary/ods-operational-data-store] . Acesso em 12 ago. 2020.
Bibliografia
Bibliografia Clássica
CONNELLY, Richard; MACNEILL, Robin; MOSIMANN, Roland. The Multidimensional Manager-24
Ways to Impact Your Bottom Line in 90 Days. Otawwa: Cognos Inc., 1996.
CONSTANTINO, Walter; SURIAN, Jorge. Metodologias para Desenvolvimento de Sistemas. São

Paulo: Cenaum, 1998.
INMON, William. Building the Data Warehouse. New York: Wiley, 2005.
KIMBALL, Ralph; et al. The Data Warehouse Lifecycle Toolkit: practical techniques for building
dimensional data warehouse and business intelligence systems. New York: Wiley, 2006.
GARTNER. Gartner Glossary. 2020. Disponível em: gartner.com

[https://www.gartner.com/en/glossary] ; gartner.com [https://www.gartner.com/en/information-
technology/glossary] . Acesso em: 6 jul. 2020.
Bibliografia Geral
LABBLE, Pablo et al. Hands-on Business Intelligence with Qlik Sense. Birmingham: Packt
Publishing, 2019.
POVER, Karl. Mastering QlikView Data Visualization. Birmingham: Packt Publishing, 2019.
QLIK. Support. Knowledge Base – Design an Application. 2019. Disponível em: support.qlik.com
[https://support.qlik.com/QS_PopularTopics#design] . Acesso em: 9 jul. 2020.
SHARDA, Ramesh; DELEN, Dursun; TURBAN, Efrain. Business Intelligence e Análise de Dados
para Gestão do Negócio. Porto Alegre: Bookman, 2019.

Plataformas de BI Na Prática

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Plataformas de BI Na Prática

Enviado por

Direitos autorais:

Formatos disponíveis

Plataforma de BI na Prática

Enfatizamos a importância dos dados históricos para processos de tomada de decisão.

Prof. Allan H. Ferreira

1.1 Histórico deiBusiness Intelligencei

Além disso, as soluções de BI desenvolveram-se de modo orgânico por diferentes organizações

Figura 1 – Howard Dresner

Ou seja, a necessidade de resolver problemas, as tecnologias que estavam disponíveis e a

Começamos aqui com a deﬁnição do termo Serviços de BI ou Business Intelligence Services,

suportar e gerenciar as aplicações e plataformas tecnológicas relacionadas. Estas [ofertas] incluem

aplicações de negócios e infraestrutura para plataformas de BI, necessidades analíticas e

infraestrutura de data warehousing. As soluções incluem áreas como Corporate Performance

Warehouse e da área de qualidade de dados. (GARTNER, 2020)

1. o bloco de arquitetura e processos

As soluções de BI são propostas por proﬁssionais que reúnem conhecimentos de

1.2 Histórico do desenvolvimento de soluções de BI

Ao conhecermos esse histórico podemos observar que as soluções de BI surgiram, em grande

Videoaula - Problemas e soluções em BI - um breve histórico

1.2.1 Dos ambientes transacionais para os gerenciais

Figura 3 – Ambiente Transacional x Ambiente Operacional

Fonte: Autoria própria

Estudante, se um gestor que não tivesse conhecimentos fundamentais de programação ou

O problema da concorrência entre usuários transacionais/operacionais e usuários gerenciais pelos

Neste caso teremos:

Se, ao longo de 1 ano, há aproximadamente 250 dias úteis, teremos aproximadamente 50

Tabela 1 – Relatório de Vendas Anual

Quantidade Vendida (em milhares) 1º Trim. 2º Trim. 3º Trim. 4º Trim. 2020

Fonte: Elaborado pelo autor.

A concorrência entre demandas gerenciais e operacionais pelos recursos computacionais

Videoaula - Ambientes transacionais e gerenciais- um breve

A modelagem multidimensional é uma técnica de criação, projeto e desenvolvimento de um

A modelagem multidimensional é utilizada no projeto de um Data Warehouse (DW). Este projeto

Na arquitetura independente, os DMs fornecem suporte à decisão para os grupos de usuários ou

Um Data Mart pode ser deﬁnido como um subconjunto de dados do DW.

Os cinco componentes que formam a arquitetura de uma solução de BI baseada em Data

as fontes de dados transacionais;

A Figura 4 mostra os principais componentes de uma solução de BI com DW e DMs.

Figura 4- Componentes de uma arquitetura de DW com DMs

Fonte: Adaptado de senior.com.br [https://www.senior.com.br/noticias/agilidade-e-conﬁabilidade-na-

1.3.1 Ralph Kimball versus Bill Inmon

A Figura 5 traz a imagem de Ralph Kimball.

Figura 5- Ralph Kimball

De acordo com a proposta de Ralph Kimball (2006), podemos destacar:

Em um ambiente que visa atender a complexidade das mais diversas corporações ou

Link: youtube.com [https://www.youtube.com/watch?v=fQp7HL_gSW4] Acesso em 11 Ago. 2020

A Figura 6 traz a imagem de Bill Inmon.

Figura 6 - Bill Inmon

De acordo com a proposta de Bill Inmon (2005), podemos destacar:

Figura 7 – Modelo aproximado de Bill Inmon

Fonte: stitchdata.com [https://www.stitchdata.com/resources/operational-data-store/]

Link: youtube.com [https://www.youtube.com/watch?v=qVWbPEg9-dU] Acesso em 11 ago. 2020.

Se de um lado os modelos relacionais utilizados em ambientes transacionais são complexos

Quadro 1 - Comparativo entre visões de Ralph Kimball e Bill Inmon

Necessidade Imediata Escala de tempo mais ampla

Orientado a Áreas de negócios Corporativo

Orçamento Orçamento reduzido Orçamento maior

Requisitos Voláteis Mais estáveis e escaláveis

Cliente Base de usuários Corporativo

Origens de dados Estáveis Modiﬁcáveis

Investimento inicial Mais baixo Superior

Projetos Mais complexos Menos complexos

Fonte: Elaborado pelo autor.

Mas, há outros aspectos a considerar: os DBAs (Database Administrators) responsáveis pela

O mais simples possível de se modelar?