1 - Princípios de Big Data-Combined - Compressed

9/5/23, 3:15 PM Princípios de Big Data
Princípios de Big Data

Prof. Sérgio Assunção Monteiro
Descrição
Conceitos e aplicações dos princípios de Big Data, Internet das Coisas, computação distribuída, plataformas
em nuvem, processamento e fluxo de dados.
Propósito
Conhecer os conceitos e as tecnologias de Big Data, como grande diferencial para o profissional de
tecnologia da informação com sólida formação.
Objetivos
Módulo 1
Introdução e Aplicações ao Big Data

https://stecine.azureedge.net/repositorio/00212ti/04085/index.html# 1/77
Reconhecer os conceitos e as aplicações de Big Data.
Módulo 2
Conceitos de IOT e Computação

Distribuída
Categorizar conceitos de Internet das Coisas e computação distribuída.
Módulo 3
Plataformas em Nuvem para Aplicações de

Big Data
Categorizar plataformas em nuvem para aplicações de Big Data.
Módulo 4
Processamento e Streaming de Dados

Identificar aplicações de processamento e streaming de dados.
Introdução
Atualmente, o termo Big Data é usado com muita frequência para descrever aplicações que envolvem
grandes volumes de dados. Porém, mais do que isso, trata-se de um conjunto de tecnologias que
gerenciam aplicações que, além do grande volume de dados, trabalham com dados que podem ser
gerados com muita velocidade, de diversas fontes e em diferentes formatos. Com a popularização
das tecnologias de computação em nuvem e da Internet das Coisas (IoT, do inglês Internet of
Things), o ecossistema de aplicações de Big Data se ampliou bastante.
Os provedores de serviços na nuvem oferecem facilidades para que os clientes possam escalar seus
sistemas – nos aspectos de hardware e software – com um custo muito inferior ao que teriam se
tivessem de investir em infraestrutura própria. De fato, é um modelo de negócio que terceiriza a base
tecnológica para empresas que são extremamente eficientes em lidar com ela, desse modo as
organizações possam se concentrar no desenvolvimento de soluções de negócios que as
diferenciem em relação à concorrência.
Ao longo deste conteúdo, entenderemos os conceitos relacionados à tecnologia de Big Data e como
ela se relaciona com outras tecnologias, como computação na nuvem e IoT. Assim, teremos uma
visão ampla sobre o assunto e conseguiremos conectá-lo a temas muito populares, como a
inteligência artificial e o aprendizado de máquina.
1 - Introdução e Aplicações ao
Big Data
Ao final deste módulo, você será capaz de reconhecer
os conceitos e as aplicações de Big Data.
Ligando os pontos
Você sabe o que é Big Data? Qual estratégia você adotaria para desenvolver uma aplicação e trabalhar com
grande volume de dados de formatos diferentes, gerados com alta velocidade?
Para respondermos a essas perguntas, vamos analisar algumas situações práticas.
A popularização do uso da internet aumentou a capacidade de as pessoas se comunicarem. Dessa maneira,

serviços que, até então, eram realizados de forma presencial passaram a ser prestados remotamente. Hoje,
podemos consultar nosso extrato de conta bancária on-line, assim como podemos agendar uma consulta
médica e interagir com diversas pessoas simultaneamente em redes sociais, por exemplo.
Essa facilidade de interação em grande escala implica o tráfego, a geração e o consumo de gigantescos
volumes de dados. Aplicações que se encaixam nessa categoria passaram a ser chamadas de Big Data.
Apesar de esse termo ser muito comum hoje em dia, não é apenas mais uma tendência do momento.
Existem conceitos muito bem consolidados a respeito de aplicações de Big Data que são resumidos nos 5
Vs: Volume, Velocidade, Variedade, Veracidade e Valor. Por exemplo, o Volume trata da quantidade de dados
com a qual a aplicação opera.
Para ser caracterizada como Big Data, a aplicação deve trabalhar com dados da ordem de Petabytes que
correspondem a aproximadamente mil vezes um Terabyte. Além disso, essas aplicações trabalham com
dados em diversos formatos que são agrupados em: estruturados, não estruturados e semiestruturados.
Com toda essa diversidade, trabalhar com Big Data envolve muitos desafios. O primeiro deles é a formação
de profissionais qualificados que devem ter uma visão holística das tecnologias, identificando como elas se
combinam para criar um ecossistema colaborativo que atenda às demandas solicitadas pelos usuários.
Outro desafio é lidar com a manutenção de um sistema desse tipo. Certamente, quem fornece uma
aplicação de Big Data lida com negócios de grandes proporções que, se tiverem problemas, podem levar a
seríssimos prejuízos financeiros, materiais e de reputação.
É inegável que há grandes oportunidades em trabalhar com Big Data. É uma necessidade da sociedade
moderna. E a tendência é que aumente muito mais. Podemos vislumbrar um mundo onde diversos serviços
como de saúde, segurança e públicos, de um modo geral, sejam prestados com muita eficiência com o
auxílio das tecnologias de Big Data.
Esta é uma realidade. Cabe a nós percebermos isso e investirmos em nossa qualificação para atuar
proativamente nesse processo.
Após a leitura do case, é hora de aplicar seus conhecimentos! Vamos ligar esses pontos?
Questão 1
As aplicações de Big Data fazem parte de nosso dia a dia. Pensando em termos de aplicabilidade,
assinale a alternativa que, em sua visão, apresenta um exemplo de Big Data:
A Os serviços de transações bancárias on-line.
B Um sistema cliente x servidor com acesso a um banco de dados em MySQL.
C Um sistema de controle de estoques de uma loja de médio porte.
D Um sistema de controle de livros de uma biblioteca de uma grande metrópole.
E Um sistema para controlar a produção de alimentos de uma fazenda.
Parabéns! A alternativa A está correta.

As aplicações de Big Data são caracterizadas pelos 5 Vs: Volume, Velocidade, Variedade, Valor e
Veracidade dos dados. Essas características são determinantes para a aplicação de tecnologias e de
estratégias de desenvolvimento, operação e manutenção. Portanto, das opções apresentadas, a única
que se encaixa nesse perfil é a de serviços de transações bancárias on-line.
Questão 2
Considere o seguinte cenário: você trabalha em uma empresa de grande porte que designou você para
um projeto de Big Data que já está em operação. Você será o responsável pela manutenção do sistema.
Nesse caso, que estratégia deve adotar para ser bem-sucedido no trabalho?
A Começar a monitorar a aplicação.
B Mapear cada um dos 5 Vs com os aspectos estruturais e operacionais da aplicação.
C Estudar os conceitos de Big Data e tentar contextualizá-los.
D Não fazer nada, pois o sistema já está em funcionamento.
E Propor melhorias no sistema para que acompanhe as tendências tecnológicas.
Parabéns! A alternativa B está correta.

As aplicações de Big Data são naturalmente complexas. Dificilmente, você vai seguir um caminho linear
para desenvolver projetos, operá-los e dar manutenção. No caso tratado na questão, o sistema já está
em operação, e seu desafio é dar manutenção a ele. Portanto, a melhor estratégia para começar a
trabalhar é conhecer os detalhes de como o sistema opera por meio do mapeamento de seus aspectos
estruturais e operacionais, com cada um dos 5 Vs: Volume, Velocidade, Variedade, Valor e Veracidade
dos dados.
Questão 3
Não há dúvida quanto à importância das aplicações de Big Data para a sociedade moderna. Mas essas
aplicações são desenvolvidas por pessoas. Por isso, certamente, é necessário investir na formação de
profissionais que atendam a essa necessidade. Neste cenário, quais seriam seus argumentos para investir
na formação profissional e desenvolver aplicações de Big Data?
Digite sua resposta aqui
Chave de respostaexpand_more
Introdução e Contextualização
Desde a popularização da Internet, com o avento da World Wide Web, na década de 1990, utilizamos, cada
vez mais, aplicações e serviços que armazenam nossos dados e os utilizam para fazer previsões sobre
nosso comportamento. Não é à toa que muitas empresas da Internet nos fazem ofertas que, de fato,
coincidem com nossos interesses. Isso só é possível porque produzimos constantemente uma quantidade
gigantesca de dados em diversas atividades, por exemplo quando:
Fazemos buscas na internet.
Fazemos compras on-line.
Assistimos a um vídeo.
Ou seja, mesmo sem estarmos cientes, fornecemos dados que podem ser utilizados para um estudo de
nosso padrão comportamental.
Esse crescimento do volume de dados e de toda a complexidade que os envolve

demandou um tratamento especializado de armazenamento, gerenciamento e
análise, popularmente conhecido como Big Data.
Os dados precisam ser tratados por um ciclo de vida, de modo que possamos extrair informações úteis
deles e, em um passo seguinte, transformar essas informações em conhecimento. Como consequência
desse processo, áreas como a Ciência de Dados (Data Science) e o Aprendizado de Máquina (Machine
Learning) cresceram muito nos últimos anos.
Quando escutamos falar sobre o termo Big Data, trata-se, normalmente, de uma descrição para enormes
conjuntos de dados; no entanto, existem outros aspectos importantes que estão envolvidos e que precisam
ser tratados, como:
add_chart
Volume e disponibilização
Quando comparamos os conjuntos de dados tradicionais com aplicações de Big Data, além do volume de
dados, temos de considerar a forma como esses dados são disponibilizados.
miscellaneous_services
Técnica adequada
Em muitos casos, os dados não são estruturados e precisam de técnicas de análise que produzam
respostas em tempo muito curto.
O principal estímulo para analisar dados nesse contexto é a possibilidade de descobrir oportunidades que
podem se materializar por meio da detecção de segmentações de mercado, aumento de engajamento de
público-alvo e compreensão aprofundada dos valores ocultos. Por tudo isso, essa área tem grandes
desafios para aplicar métodos eficazes e eficientes de organização e gerenciamento desses conjuntos de
dados.
Devido ao potencial de valor que as aplicações de Big Data podem gerar, tanto empresas como agências
governamentais têm investido nessa área, por meio do desenvolvimento de soluções que capturem dados
com mais qualidade para, posteriormente, facilitar as etapas de armazenamento, gerenciamento e análise.
Saiba mais
Dados provenientes de fontes distintas permitem fazer um mapeamento muito detalhado do
comportamento das pessoas. Isso também desperta discussões nos campos ético e legal. No Brasil, temos
disposições constitucionais sobre a inviolabilidade do sigilo de dados e das comunicações, e a Lei Geral de
Proteção dos Dados (Lei nº 13.709/2018), que visa proteger os cidadãos quanto ao uso indevido dos seus
dados. Porém, ainda há muito a ser feito a respeito disso, o que acaba gerando novas oportunidades de
pesquisa e desenvolvimento de projetos envolvendo segurança e privacidade.
Conceitos sobre Big Data

De modo geral, associamos o termo Big Data a um grande volume de dados e entendemos que este viabiliza
a aplicação de métodos estatísticos e outras análises para extrairmos informações importantes. No
entanto, Big Data é bem mais amplo que essa percepção, pois abrange conjuntos de dados que não podem
ser tratados pelos métodos tradicionais de gestão da informação, ou seja, serem adquiridos, reconhecidos,
gerenciados e processados em um tempo aceitável. Assim, o Big Data pode ser visto como uma fronteira
para inovação, competição e produtividade.
Arquitetura básica de Big Data

A complexidade que envolve o gerenciamento de todas as características do Big Data exige que tratemos
sua arquitetura de modo específico, o que, mais uma vez, o diferencia dos sistemas de banco de dados
tradicionais que teriam dificuldade em lidar com operações de dados em sistemas heterogêneos. Esses
sistemas são chamados de data lake, que, literalmente, pode ser traduzido como “lago de dados”.
Basicamente, trata-se de um enorme repositório de arquivos e objetos de dados. Portanto, as soluções da
arquitetura de Big Data precisam ser eficientes para que possam produzir resultados com tempos de
resposta aceitáveis. Os componentes da arquitetura de Big Data são:
Fontes de dados (data sources) expand_more
Além das fontes de dados tradicionais, os sistemas de Big Data podem ser alimentados por meio de
dados que estão na nuvem e são produzidos por sistemas de IoT, sendo que, em muitos casos, esse
processo ocorre em tempo real. Trata-se do processo de aquisição de dados.
Armazenamento de dados (data storage) expand_more
Os dados precisam ser armazenados de modo eficiente para otimizar o seu acesso e segurança.
Esse armazenamento pode ser feito de diversas maneiras na nuvem ou em bancos de dados
estruturados ou não estruturados, que tenham:
Escalabilidade: capacidade de crescer com consistência.
Disponibilidade: prontos para serem acessados sempre que forem demandados.
Segurança: mecanismos que garantam a privacidade e restrição de acesso.
Padronização: armazenamento seguindo um padrão que facilite, posteriormente, a sua

recuperação.
Processamento em lote (batch processing) expand_more
É o processo de armazenar os dados em lotes, para, então, fazer o seu processamento. Isso é feito
para lidar com grandes volumes de dados, não sendo viável fazer o processamento dos dados em
fluxos.
Ingestão de mensagens (message ingestion) expand_more
Consiste em agrupar os dados e trazê-los para um sistema de processamento de dados, onde

podem ser armazenados, analisados e acessados.
Processamento de fluxo (stream processing) expand_more
É o processamento de dados à medida que são produzidos ou recebidos. Essa situação ocorre com
frequência em processos de eventos produzidos por sensores, atividades do usuário em um site,
negociações financeiras que têm como característica comum o fato de os dados serem criados
como uma série de eventos de fluxo contínuo.
Armazenamento de dados analíticos (analytical data store) expand_more
Consiste no armazenamento de dados de negócios, mercado e clientes para posterior análise. As

aplicações desses dados são chamadas de business intelligence (BI) – inteligência de negócios. Os
bancos de dados analíticos são otimizados para consultas rápidas.
Análise e relatórios (analysis and reporting) expand_more
Os relatórios são uma organização dos dados com o objetivo de fazer resumos informativos e
monitorar o desempenho de diferentes áreas de uma empresa. A análise, por sua vez, consiste em
explorar dados e relatórios para extrair informações que agreguem valor e que possam ser usadas
para melhor compreender e melhorar o desempenho dos negócios. Os relatórios de Big Data podem
ser:
Predefinidos: são relatórios prontos para uso que podem ser entregues de forma recorrente a um
grupo de usuários finais. Normalmente, trazem informações estáticas com a possibilidade de
diferentes níveis de detalhes. O termo usado para se referir ao detalhamento de um relatório é
chamado de granularidade.
Painéis (dashboards): esses relatórios apresentam uma visão abrangente do desempenho dos
negócios. Ele é composto por indicadores de desempenho, conhecidos, principalmente, pela sigla
KPI – key performance indicator – que ajudam a medir a eficiência de um processo. Para facilitar a
compreensão, abordaremos os KPI mais adiante.
Alertas: esses relatórios são usados para emitir notificações sempre que determinada condição
previamente estabelecida ocorra, para que os responsáveis pelo processo sejam acionados e
tomem as medidas adequadas.
KPI
Os KPI são indicadores de desempenho que integram os painéis (dashboards). Esses indicadores podem
ser de três tipos:
Estratégicos
Oferecem uma visão geral do negócio e são utilizados pela presidência e diretoria de uma empresa. Como
exemplo, temos o faturamento bruto de uma empresa em determinado período.
Táticos
São um detalhamento dos KPI estratégicos e têm como público-alvo a gerência da empresa. Como exemplo,
podemos citar o faturamento das vendas de um determinado segmento da empresa, que pode ser um
produto ou serviço específico.
Operacionais
Ajudam no acompanhamento detalhado de uma atividade da empresa. Como exemplo, podemos citar o KPI
MTBS, que é um acrônimo para tempo médio de parada para manutenção – do inglês: mean time between
stopages – usado para medir o tempo médio que um equipamento está disponível para uso até que ele pare
para manutenção.
Os 5 Vs do Big Data
Uma forma de definir a complexidade do Big Data é por meio da descrição de suas características. Hoje há 5
características conhecidas como os 5 Vs do Big Data, mas nem sempre foi assim. Vamos conhecer um
pouco da história:
Os 3 V’s do Big Data: Volume, Velocidade e

Variedade
Em 2001, o analista Doug Laney, da empresa META (atual Gartner Group), apresentou um
relatório de pesquisa no qual tratou sobre os desafios e oportunidades trazidos pelo aumento
de dados com um modelo 3Vs, sendo que cada V representa as características Volume,
Velocidade e Variedade (LANEY, 2001). Esse modelo foi usado durante muitos anos para
descrever a tecnologia de Big Data.
Os 4 V’s do Big Data: Volume, Velocidade,

Variedade e Valor
Posteriormente, o conceito evoluiu para a inclusão de mais um V, que representa Valor, por
meio da publicação de um relatório do IDC ( International Data Corporation) em 2011, que
associou Big Data ao conjunto de tecnologias e arquiteturas projetadas para extrair valor de
grandes volumes e variedades de dados, permitindo a captura, descoberta e análise de alta
velocidade (GANTZ; REINSEL, 2011).
Os 5 V’s do Big Data: Volume, Velocidade,

Variedade, Valor e Veracidade
Atualmente, a forma mais comum de encontrarmos uma definição sobre Big Data inclui mais
um V, além dos que já vimos: Veracidade (RUSSOM, 2011).
Essa evolução para explicar o conceito de Big Data vem do fato de estarmos trabalhando com um
ecossistema complexo, que envolve aspectos tecnológicos de software e hardware, além de questões
econômicas, sociais e éticas que ainda estão sendo compreendidas. Agora, vamos analisar com mais
detalhes os 5Vs que compõem a tecnologia de Big Data.
Volume de Dados
Volume.
Essa característica está relacionada com a escala da geração e coleta de massas de dados. Temos muitos
exemplos práticos de aplicações em que o volume de dados é gigantesco, como sistemas de transações
bancárias e de trocas de e-mails e mensagens. É fato que a percepção de grandes volumes de dados está
relacionada com a tecnologia disponível em um determinado momento.
Precisamos conhecer como o volume de dados é medido. Basicamente, temos:
Byte (B)
Unidade de informação
digital, também chamado de
octeto, que consiste em uma
sequência de 8 bits (binary
digits).
Kilobyte (KB)
Corresponde a
1KB = 2
10
B = 1024 bytes.
Megabyte (MB)
E i l
Equivale a
1M = 2
10
KB = 2
20
B .
Gigabyte (GB)
Temos que
10 20 30
1GB = 2 MB = 2 KB = 2 B
Terabyte (TB)
Corresponde a
1T B = 2
10
GB .
Petabyte (PB)
Temos que 1P B = 2
10
TB .
Exabyte (EB)
Equivale a 1EB = 2
10
PB .
Zetabyte (ZB)
Temos que 1ZB = 2
10
EB .
Yottabyte (YB)
E i l 1Y B 2
10
ZB
Equivale a 1Y B = 2
10
ZB .
Atenção
Quando nos referimos ao volume de uma aplicação de Big Data, normalmente, estamos tratando de
petabytes (PB) de dados.
Velocidade
Essa característica se refere a dois aspectos:
timer
A velocidade da geração de dados.
timer
A velocidade de processamento dos dados.
Basicamente, temos o problema clássico de computação: produtor x consumidor. O consumidor representa
o papel do analista que precisa fazer consultas rapidamente, mas pode sofrer limitações do tempo de
resposta do produtor, ou seja, o sistema pode possuir um ritmo mais lento para disponibilizar os dados para
consulta.
Um projeto de Big Data precisa equilibrar os tempos

de consumo e geração de dados.
Variedade
Um projeto de Big Data pode ter vários tipos de dados, como áudio, vídeo, página da web e texto e tabelas
de bancos de dados tradicionais. Esses tipos de dados podem ser classificados como:
Dados estruturados
São armazenados de maneira organizada, e fáceis de serem processados e analisados. Normalmente, são
dados numéricos ou de texto que podem ser armazenados em um banco de dados relacional e manipulados
usando a linguagem SQL (do inglês Structured Query Language).
Dados não estruturados

Não possuem uma estrutura predefinida. Como exemplo, temos as imagens e arquivos de áudio. São
armazenados em um banco de dados não relacional, também denominado NoSQL (do inglês Not Only SQL).
Semiestruturado
Os dados semiestruturados mesclam as duas formas de dados. Como exemplo de dados semiestruturados,
temos arquivos nos formatos XML (do inglês eXtended Markup Language) e JSON (do inglês Java Script
Object Notation).
Veracidade
Essa característica está relacionada à qualidade dos dados. Isso é essencial, especialmente do ponto de
vista de suporte para a tomada de decisão, pois é a veracidade dos dados que nos dá o grau de confiança
para fazer o que precisamos por meio da integridade e da precisão dos dados.
Veracidade.
Um projeto de Big Data precisa utilizar técnicas que

façam limpeza dos dados e garantam a sua qualidade,
para que possam ser consumidos pelo processo de
análise.
Valor
Valor
Essa é a principal característica de um projeto de Big Data e justifica todo o trabalho de extrair valor dos
dados, que são a matéria-prima do negócio e, por isso, precisam passar por diversas etapas de tratamento e
gerenciamento, até que possam ser consumidos pelo processo de análise. Podemos aplicar técnicas de
ciência de dados e machine learning para obter informações e conhecimentos que vão direcionar ações
para as diversas frentes de um negócio.
Aplicações de Big Data

Atualmente, existem muitas aplicações de Big Data que dão suporte para diversos setores da sociedade
tomarem decisões e adquirirem conhecimento que, de outra maneira, seria muito difícil. Entre as aplicações
de Big Data relacionados a setores da sociedade, podemos destacar os seguintes exemplos:
local_hospital
Área de saúde
Por meio das análises de dados, os pesquisadores podem encontrar o melhor tratamento para determinada
doença e ter uma compreensão detalhada sobre as condições de uma região monitorada, tendo a
possibilidade de propor ações com impacto positivo na saúde das pessoas.
account_balance
Governo
Os setores ligados ao governo que utilizam sistemas de Big Data podem melhorar a prestação de serviços
para os cidadãos por meio da integração dos dados das diversas áreas, conseguindo, assim, detectar
fraudes, melhorar a educação, segurança pública, entre tantos outros serviços.
live_tv
Mídia e entretenimento
Os anúncios que são feitos quando vemos vídeos na Internet são mais efetivos quando combinam com
nosso perfil. As empresas de mídia e entretenimento analisam os dados dos usuários e trabalham para
personalizar a oferta de produtos e serviços.
connected_tv
Internet das coisas (IoT)
Dispositivos de IoT geram dados contínuos e os enviam para um servidor. Quando esses dados são
extraídos, podem ser analisados para compreender padrões e traçar estratégias mais efetivas para melhorar
os resultados dos processos monitorados.
video_library
Visão geral de Big Data
No vídeo a seguir, falaremos sobre os principais conceitos da tecnologia de Big Data, com destaque especial
aos 5V’s.
Falta pouco para atingir seus

objetivos.
Vamos praticar alguns conceitos?

Questão 1
Gerenciar um projeto de Big Data é uma tarefa complexa. Isso ocorre devido às características próprias
desses projetos, que, além de lidar com grandes volumes de dados, ainda precisam tratar de diversas
questões da sua arquitetura. Nesse sentido, assinale a alternativa correta a respeito da arquitetura de
um projeto de Big Data.
Entre os aspectos que devem ser considerados em um projeto de Big Data, está a
A necessidade de garantir a privacidade dos dados, para que apenas as pessoas
autorizadas possam acessá-los.
Um dos fatores que precisam ser tratados na arquitetura de um projeto de Big Data é a
B
padronização dos dados, de modo que possam ser armazenados em tabelas.
As fontes de dados constituem a base da arquitetura dos projetos de Big Data, uma vez
C
que garantem que os dados não sejam corrompidos.
Os projetos de Big Data podem crescer rapidamente, por isso é fundamental tratar
D
aspectos relacionados às fontes de dados.
A complexidade da arquitetura de um projeto de Big Data está relacionada a dois

E
fatores, que são o volume e a diversidade dos dados.

Os projetos de Big Data são complexos, pois possuem muitas variáveis, tais como a diversidade e o
volume dos dados, e a velocidade com que são gerados. Além disso, é necessário considerar aspectos
como as diversas tecnologias envolvidas e a segurança dos dados.
Questão 2
O termo Big Data é bastante popular atualmente. Um dos motivos para isso ocorre devido à
popularização do uso das aplicações que funcionam na Internet. Nesse sentido, selecione a opção
correta a respeito das aplicações de Big Data:
Uma das dificuldades atuais associadas aos projetos de Big Data é o uso para
A prestação de serviços públicos, uma vez que são caros e seu benefício não é facilmente
quantificável.
Dispositivos eletrônicos podem ser conectados diretamente à Internet, transmitindo

B dados sem a necessidade de garantir a sua qualidade, pois ela será tratada pela
aplicação de Big Data.
A tecnologia de Big Data pode ser usada para monitorar os sinais vitais de pacientes
C
que podem ser transmitidos via Internet.
Apesar de ainda não serem aplicados na área de entretenimento, existe um grande

D potencial de uso dos projetos de Big Data para proporcionar experiências específicas de
acordo com o perfil do usuário.
Uma possível aplicação de Big Data é na prestação de serviços de utilidade pública, mas
E os benefícios só podem ser percebidos se houver total integração entre todos os
sistemas dos diversos setores que compõem o Estado.
Parabéns! A alternativa C está correta.

Muitos benefícios podem ser obtidos pela utilização de projetos de Big Data para prestação de serviços
públicos, entretenimento, segurança e aplicações na área da saúde, entre tantas outras aplicações. O
potencial desses benefícios aumenta sempre que for possível fazer uso de diversas fontes de dados,
pois essa diversidade permite identificar padrões complexos que dificilmente seriam detectados de
outra maneira.
2 - Conceitos de IOT e
Computação Distribuída
Ao final deste módulo, você será capaz de categorizar
conceitos de Internet das Coisas e computação
distribuída.
Ligando os pontos
Você sabe o que é Internet das Coisas (IoT)? O que você faria diante da necessidade de transferir dados de
sensores para locais a muitos quilômetros de distância?
Para entendermos essas questões na prática, vamos analisar uma situação.
A necessidade de melhorar a capacidade de prestar serviços de maior qualidade em diversas áreas levou à
criação da Internet das Coisas (IoT): um conjunto de tecnologias que utilizam os protocolos de
comunicação da internet para trafegar dados na rede mundial.
A IoT já está presente em nossas vidas, mas ainda tem muito espaço para crescer. Com ela, os governos
podem criar cidades inteligentes com serviços de controle de trânsito, monitoramento de regiões de risco e
de segurança mais eficientes.
Na iniciativa privada, a IoT já é aplicada com muito sucesso para monitoramento de plantações, na
mineração e exploração de petróleo. A ideia é simples: equipamentos com sensores monitoram
determinada região com o objetivo de detectar a ocorrência de algum evento anormal.
Esses dados de monitoramento são enviados para uma central via internet, que os processa e os analisa. Na
ocorrência de algum padrão de anomalia, o sistema direciona os responsáveis sobre quais ações devem
aplicar, para que a situação volte à normalidade.
Com a descrição do que é a IoT, é fácil encontrarmos muitas aplicações práticas. Mas quais são os passos
que devemos tomar para concretizá-las?
O primeiro deles é determinar qual é a necessidade. Tudo começa por aí:
O que queremos monitorar?

O que esperamos desse monitoramento?
Em seguida, vem a etapa tecnológica: quais recursos vamos utilizar para fazer o monitoramento?
A parte tecnológica da IoT é bem consolidada. Além de haver muitos sensores ofertados no mercado,
também temos à disposição tecnologias como Arduino, NodeMCU e Raspberry PI, que facilitam o
desenvolvimento de aplicações sofisticadas.
Outro ponto importante são os protocolos de comunicação entre os dispositivos e a internet, que também
são bem conhecidos.
Como sempre, o componente mais importante de tudo isso é a qualificação de profissionais que
desenvolvam habilidades para perceber a oportunidade de aplicações dessas tecnologias e a capacidade
para implementá-las.
Questão 1
Você já conhece a importância da IoT para atender diversas demandas da sociedade. Nessa linha de
raciocínio, qual é a relação entre os aspectos tecnológicos e as aplicações de IoT?
A As aplicações de IoT utilizam tecnologias de um único fornecedor.
B Todas as aplicações de IoT têm baixa tolerância de falhas.
C As diversas fontes das aplicações de IoT devem produzir resultados distintos.
D A melhor linguagem de programação para trabalhar com IoT é Python.
E A diversidade de tecnologias envolvidas na IoT demanda conhecimento holístico.
Parabéns! A alternativa E está correta.

As aplicações de IoT são caracterizadas pela diversidade de tecnologias que se integram por meio de
protocolos e são capazes de trafegar dados pela internet. Portanto, não é possível limitar o escopo dela
à tecnologia de um fornecedor específico nem à determinada linguagem de programação. É necessário
ter um amplo conhecimento que integre as diversas partes de um projeto e, principalmente, ter como
objetivo resolver um problema.
Questão 2
Você sabe que as aplicações de IoT utilizam diversas tecnologias para coletar, realizar tráfego e
tratamento dos dados. Nesse contexto, assinale a alternativa que, em sua visão, apresenta um exemplo
concreto de uma dessas três ações:
Enviar dados de monitoramento de sensores por e-mail para serem processados por um
A
sistema de machine learning.
Aplicar um sistema de monitoramento de condições de um equipamento sensível e

B
registrar os dados em um banco local.
Utilizar um protocolo HTTP para um dispositivo de monitoramento transmitir dados via

C
internet.
Utilizar um sistema de interação com o usuário para analisar os dados coletados por
D
dispositivos de monitoramento.
Aplicar um sistema que controle a quantidade de água que deve ser aplicada em
E
determinada plantação de acordo com o monitoramento das condições do solo.

As aplicações de IoT têm como principal característica a utilização das tecnologias de comunicação da
internet para trafegar dados obtidos por sistemas de monitoramento. Portanto, precisamos procurar
esses dois elementos em uma aplicação de IoT: dispositivos de monitoramento e controle (coisas), e
tráfego de dados (uso das tecnologias de comunicação da internet).
Questão 3
A diversidade de tecnologias aumenta o potencial de benefícios de uma aplicação, mas também traz
desafios. O primeiro deles é a formação de profissionais. Nesse sentido, que estratégia você adotaria para
sensibilizar os responsáveis por empresas que potencialmente se beneficiariam de aplicações de IoT a
investirem na qualificação de profissionais nessa área?
Introdução e Contextualização
O avanço da tecnologia criou dispositivos e sensores eletrônicos que geram enormes quantidades de
dados. Esses equipamentos podem ser utilizados em diversas aplicações, tais como:
monitoramento da temperatura de uma câmara frigorífica;
segurança de transporte de cargas;
acompanhamento e alerta da poluição dos níveis de poluição do ar;
avaliação da pressão arterial de pacientes que precisam de atenção especial com cuidados de saúde etc.
A lista de aplicações é muito grande! Para que todas essas aplicações sejam
possíveis, precisamos ter à disposição uma tecnologia de coleta e troca de dados
que conecte os dispositivos por meio de componentes de hardware e software.
A Internet das Coisas (IoT) é a infraestrutura que viabiliza a conexão e comunicação por meio da Internet
desses objetos remotos.
A IoT é uma tecnologia que aumenta as conexões entre pessoas, computadores e dispositivos eletrônicos –
estes últimos são chamados de “coisas”. Trata-se de uma revolução, pois a IoT viabiliza a extensão da
realidade física para além de limitações espaciais, como, por exemplo, o acompanhamento da saúde de
pacientes em regiões de difícil acesso. Essa tecnologia nos fornece acesso a dados sobre o meio físico
com grande nível de detalhes, os quais, posteriormente, podemos analisar, compreender e tomar as ações
adequadas, para otimizar processos, corrigir problemas, detectar oportunidades de melhorias e aumentar o
nosso conhecimento a respeito de um contexto.
Internet das Coisas (IoT).
Um dos aspectos interessantes que devemos observar sobre a IoT é que os dados podem vir de diferentes
fontes, oferecendo uma visão mais nítida sobre o que estamos monitorando. Nesse momento, já podemos
notar uma estreita relação entre as tecnologias de IoT e Big Data:
Dados de fontes diferentes

Viabiliza que possamos verificar a veracidade dos dados, ou seja, o quão confiáveis eles são para
representar o que está sendo observado.
Diferentes formatos
Podemos ter dados que são emitidos por diferentes sensores que retratam a variedade de representações
do que estamos monitorando.
Frequência de geração dos dados

Os dados são enviados para a rede em uma velocidade característica da tecnologia que estamos aplicando.
Em relação à frequência de geração dos dados, refletimos sobre as seguintes questões:
1. Com que velocidade nossas aplicações devem consumir esses dados?
2. Qual é a velocidade adequada para analisá-los e produzir uma resposta adequada?
3. Qual é o volume de dados que devemos armazenar e tratar?
4. Qual é o valor dos dados que os dispositivos nos fornecem para que possamos priorizá-los
adequadamente?
Resposta
A compreensão dos dados gerados pelos dispositivos de IoT nos oferece oportunidades para melhorar
nossa relação com as pessoas e aperfeiçoar processos e atividades sociais sobre aprendizado, saúde,
trabalho e entretenimento. Ao mesmo tempo, abre discussões sobre aspectos éticos e legais, pois todo
esse detalhamento abre a possibilidade de um conhecimento detalhado sobre a nossa privacidade que
precisa ser tratado com bastante cuidado.
Além dos aspectos legais e éticos, devemos notar que as aplicações de IoT são, naturalmente, distribuídas
com sensores e dispositivos capazes de enviar e receber dados usando protocolos de comunicação para a
Internet. Outra questão tecnológica que devemos observar é que esses equipamentos possuem restrições
de recursos de memória e processamento, portanto, é necessário utilizá-los com bastante eficiência, apesar
de que eles, normalmente, são usados para uma tarefa específica.
Para tratar de aplicações de IoT, utilizamos

algoritmos distribuídos que reconhecem os
dispositivos e os utilizam de forma eficiente para
transmitir e receber dados.
Computação Distribuída e IoT

A tecnologia de IoT consiste na coexistência colaborativa de quatro componentes:
device_thermostat
Objetos físicos (ou "coisas")
Componentes eletrônicos e sensores responsáveis pela coleta de dados e aplicação de ações. Exemplo:
termostatos usados para controlar a temperatura de um ambiente.
storage
Computação
Faz o gerenciamento do ciclo de vida dos dados, desde a coleta e o armazenamento até o processamento
dos dados.
sync_alt
Protocolos de comunicação
Viabilizam a troca dados via Internet entre os objetos físicos e outros sistemas.
room_preferences
Serviços
Provêm autenticação e gerenciamento de dispositivos, além de oferecer a infraestrutura.
Para tratar da integração desses componentes de IoT, utilizamos a computação distribuída, pois é um
modelo mais adequado para gerenciar essas unidades não centralizadas por meio do compartilhamento de
responsabilidades e riscos. Apesar de, nesse cenário, os componentes estarem geograficamente
espalhados, eles são executados como um sistema para melhorar a eficiência e o desempenho.
Aspectos da computação distribuída

Na computação distribuída, todos os elementos conectados na rede – servidores e nós – trabalham em
conjunto de forma descentralizada para gerenciar toda a complexidade do sistema e ajustar-se ao
crescimento do volume de dados e de dispositivos conectados. Para alcançar esse objetivo, a computação
distribuída segue alguns princípios-chave, que são:
Distribuição e processamento
Distribuição de armazenamento e processamento de dados entre os nós da rede, para que a
eficiência dos processos seja otimizada.
Transferência de dados e análises

A transferência de dados e as análises devem ser realizadas conforme necessário, pois
diferentes níveis de processamentos podem ser realizados pelos nós da rede. Isso significa
que o custo global de processamento e análise dos dados é minimizado, uma vez que os nós
menos onerosos realizam pré-processamentos que reduzem o custo do processamento final
dos nós mais caros da rede.
Tolerância a falhas
Outro princípio importante diz respeito à tolerância a falhas, pois é muito provável que haja
intermitência da operação dos nós das redes, portanto a política de computação distribuída já
deve estar preparada para reorganizar o fluxo de dados na rede, de maneira que possam ser
roteados de um outro modo e que a rede continue em operação.
Otimização dos recursos computacionais da rede

Em especial, no caso da IoT, em que os dispositivos possuem uma restrição de recursos de
memória e processamento, a computação distribuída trabalha com baixos níveis de consumo
de energia.
Computação distribuída e Big Data

Em um projeto de Big Data, de modo geral, temos que coletar uma grande quantidade de dados, armazená-
los, processá-los e analisá-los para detectar padrões relevantes que demandem, quando necessário, algum
tipo de ação. Agora, quando aplicamos Big Data para IoT, precisamos tratar a complexidade das
características intrínsecas dos seus componentes, ou seja, utilizar uma solução que dê suporte para o alto
volume de dados e consiga se comunicar com os dispositivos. Mas qual solução seria essa?
A computação distribuída se torna a solução mais

adequada no sentido de distribuir a computação para
os nós da IoT.
Uma arquitetura básica de computação distribuída de IoT é composta pelas camadas de:
Computação em nuvem (cloud computing) expand_more
É a tecnologia que permite o uso remoto de recursos computacionais de software e hardware. Por
exemplo, quando utilizamos repositórios na Internet para armazenar dados ou servidores de
aplicação, estamos trabalhando com computação em nuvem. Essa camada é responsável por:
processamento de Big Data;
lógica de negócios;
armazenamento de dados – mais conhecido como data warehousing.
Computação em névoa (fog computing) expand_more
É uma extensão da camada de nuvem que aproxima servidores aos dispositivos de IoT. Esses
servidores podem colaborar entre si por meio de trocas de dados e realizar processamentos que vão
otimizar a operação do sistema como um todo. Entre suas principais características, temos:
processamento de Big Data;
análise e redução de dados;
controle de respostas;
virtualização e padronização.
Computação de borda (edge computing) expand_more
Essa camada relaciona-se diretamente com os sensores e controladores que ficam na “borda” da
arquitetura. Dessa forma, os dados podem ser armazenados e processados para, então, serem
enviados à camada de névoa. Podemos destacar os seguintes aspectos dessa camada:
processamento de grande volume de dados em tempo real.
visualização de dados da fonte, ou seja, que vêm dos dispositivos eletrônicos.
uso de computadores industriais que são específicos para trabalhar com determinados
dispositivos eletrônicos.
uso de sistemas integrados – também chamados de sistemas de bordo – que já vêm configurados
nas placas.
utilização de Gateways para interconectar os dispositivos com a rede por meio da conversão de
protocolos e de sinais.
sistema de armazenamento de microdados.
Sensores e controladores expand_more
São os dispositivos responsáveis por gerar os dados e, quando acionados, realizar ações. Por
exemplo, em um sistema de irrigação, temos sensores que fazem o monitoramento da umidade do
solo e controladores que fazem a irrigação até obter o nível adequado de umidade.
A figura 1 ilustra a arquitetura básica de computação distribuída aplicada para IoT.
Figura 1 – Arquitetura básica de IoT.
Um aspecto que podemos perceber rapidamente é a mudança da velocidade do fluxo de dados ao longo da
arquitetura que mostramos na imagem. Em sua parte inferior, temos os dados gerados pelos sensores a
uma velocidade superior, à medida que vamos avançando até a camada de nuvem.
Protocolos de comunicação
Os sistemas de IoT precisam de protocolos que permitam que os dispositivos eletrônicos possam se
comunicar com outros nós da rede ‒ sendo que um nó pode ser um dispositivo eletrônico, um computador
ou um servidor. Alguns dos principais protocolos de comunicação de IoT são:
HTTP
O HTTP (Hyper Text Transport Protocol) é o Protocolo de Transporte de Hipertexto. É o protocolo do modelo
cliente-servidor mais importante utilizado na Web, em que a comunicação entre um cliente e um servidor
ocorre por meio de uma mensagem do tipo “solicitação x resposta”. A dinâmica básica da comunicação
segue os seguintes passos:
O cliente envia uma mensagem de solicitação HTTP.
O servidor retorna uma mensagem de resposta, contendo o recurso solicitado, caso a solicitação tenha
sido aceita.
MQTT
O MQTT (Message Queuing Telemetry Transport) é o Protocolo de Transporte de Filas de Mensagem de

Telemetria. Ele foi lançado em 1999, sendo que sua primeira aplicação foi para o monitoramento de
sensores em oleodutos. É um protocolo aberto e sua comunicação é baseada em um servidor que faz a
publicação e o recebimento de dados com o padrão de mensagens “publicação x assinatura”, chamado de
broker. O broker faz o trabalho intermediário de recebimento das mensagens dos nós da rede e as envia aos
nós de destino. O MQTT é executado em um protocolo de transporte TCP (Transmission Control Protocol), o
que garante a confiabilidade do tráfego de dados.
CoAP
O CoAP (Constrained Application Protocol) é o Protocolo de Aplicação Restrita. Utiliza a arquitetura REST
(Representation State Transfer ou Transferência de Estado Representacional) e oferece suporte ao
paradigma de “solicitação x resposta”, exatamente como ocorre no caso REST/HTTP. Além disso, ele é
executado em um protocolo de transporte UDP (User Datagram Protocol).
XMPP-IOT
O XMPP-IOT (Extensible Messaging and Presence Protocol for the IoT) é o Protocolo de Mensagem
Extensível e de presença para a IoT. Também é um protocolo aberto que foi projetado para trocas de
mensagens instantâneas. Ele usa a arquitetura cliente-servidor rodando sobre TCP, onde sua comunicação é
baseada em XML e possui extensões que possibilitam o uso do modelo de “publicação x assinatura”.
Plataformas para IoT

Quando trabalhamos com um sistema de IoT, precisamos desenvolver programas para que os dispositivos
possam operar da forma adequada e enviar dados para a rede. Para isso, precisamos de plataformas de
desenvolvimento que nos ofereçam recursos de software e hardware que nos auxiliem a trabalhar com a
interoperabilidade e a conectividade dos dispositivos à rede. A seguir, apresentamos algumas das principais
plataformas de desenvolvimento para dispositivos de IoT.
Arduino
Arduino.
Foi criado no Ivrea Interaction Design Institute em 2002. Ele oferece um ecossistema de hardware,
linguagem de programação, bibliotecas e dispositivos que nos ajudam a desenvolver projetos que podem ter
diversas aplicações. Uma das principais características do Arduino é que todas as suas placas e seu
software são de código aberto. Essa característica ajudou a popularizar o Arduino, que possui uma
comunidade de desenvolvedores engajada em divulgar projetos e conhecimentos em fóruns on-line.
NODEMCU
É um dos principais kits eletrônicos de código aberto para desenvolvimento de aplicações de IoT. Ele é
baseado na família do microcontrolador ESP8266 e possui recursos que facilitam trabalhar com
dispositivos conectados à Internet para monitoramento e controle.
NODEMCU.
Raspberry PI
Raspberry PI.
É uma plataforma de computação de placa única. Seu propósito inicial foi a aplicação no ensino de ciência
da computação, evoluindo para funções mais amplas. Possui uma interface de baixo nível de controle auto-
operado por portas de entrada-saída, chamado GPIO (General Purpose Input-Output), e usa o Linux como
seu sistema operacional padrão.
video_library
IoT e Computação Distribuída
No vídeo a seguir, abordaremos os conceitos das tecnologias de IoT e Computação Distribuída,
relacionando-os com Big Data.

objetivos.

Questão 1
As aplicações de Internet das Coisas (IoT) estão cada vez mais presentes em nosso dia a dia. Algumas
das características dos projetos de IoT são a produção de um grande volume de dados e o uso de
computação distribuída, e, por isso, devem ser tratados como projetos de Big Data. Em relação às
tecnologias de IoT e de computação distribuída, assinale a alternativa correta.
A camada de computação em nuvem é responsável por tratar diretamente da qualidade

A dos dados produzidos pelos dispositivos de IoT e transmiti-los aos servidores de
aplicações de Big Data.
Um dos aspectos da arquitetura de computação distribuída é utilizar camadas

B responsáveis por atividades específicas, como é o caso da cama de computação em
névoa.
As camadas da arquitetura de computação distribuída são equivalentes quanto ao

C
tratamento dos dados, sendo diferenciadas apenas pela tecnologia que utilizam.
Uma das vantagens da computação distribuída é padronizar a tecnologia utilizada em

D
um projeto de IoT.
Projetos de IoT são considerados complexos, devido à grande quantidade de

E tecnologias envolvidas, e, por isso, a arquitetura de computação distribuída deve ser
aplicada apenas com duas camadas: de nuvem e de dispositivos.

A arquitetura de computação distribuída, aplicada para projetos de IoT, envolve camadas que são
especializadas em tratar determinados aspectos da gestão de dados, para que eles possam trafegar na
rede com segurança e qualidade. As camadas da arquitetura de computação distribuída para IoT são a
de computação em nuvem, computação em névoa, computação de borda e a dos dispositivos de
sensores e controladores.
Questão 2
Os projetos de Internet das Coisas (IoT) têm sido utilizados com sucesso em diversas áreas. De
maneira simplificada, os sensores geram dados que são enviados para servidores de aplicação por
meio da tecnologia de Internet. Nesse sentido, selecione a opção correta a respeito dos protocolos para
aplicações de IoT:
Projetos de IoT são exemplos típicos de aplicações de Big Data e, portanto, devem ser
A
desenvolvidos com o protocolo UDP, como é o caso do XMPP-IOT.
O HTTP é o protocolo padrão para aplicações de IoT, sendo utilizado por todos os
B demais protocolos como uma camada intermediária que garante a qualidade dos
dados.
Dispositivos de IoT são caracterizados por possuírem muitos recursos de memória e

C processamento para tratar do grande volume e diversidade dos dados, e, por isso,
utilizam protocolos como o HTTP e MQTT.
MQTT é um protocolo de IoT que usa uma estrutura de comunicação em que os

D dispositivos publicam seus dados, que são consumidos por um broker, que os transmite
para determinadas aplicações.
E Alguns dos protocolos usados pelos projetos de IoT são construídos com tecnologias
proprietárias mais adequadas para tratar a diversidade de dados, como é o caso do
CoAP.
Parabéns! A alternativa D está correta.

O MQTT é um protocolo aberto de IoT, baseado no padrão publicação X assinatura, que, na prática,
significa que os dispositivos publicam seus dados, e as aplicações que vão consumir esses dados o
fazem por meio de uma formalização (assinatura). Esse processo de recebimento e transmissão de
dados é intermediado por uma aplicação chamada broker.
3 - Plataformas em Nuvem para

Aplicações de Big Data
Ao final deste módulo, você será capaz de categorizar
plataformas em nuvem para aplicações de Big Data.
Ligando os pontos
Você sabe como utilizar serviços na nuvem? Que estratégia adotaria para implementar uma solução em
que os clientes pagariam apenas pelos serviços computacionais que utilizassem?
Para entendermos esses conceitos na prática, vamos analisar uma situação.
A necessidade de interação com diversas tecnologias levou ao desenvolvimento de soluções criativas e

economicamente viáveis. Um exemplo desse tipo de situação é a computação em nuvem. A ideia básica é
que clientes e usuários podem utilizar serviços de computação como plataformas de desenvolvimento de
programas e infraestrutura de sistemas gerenciadores de banco de dados que estão hospedados na
internet.
Portanto, toda a preocupação com configuração, atualização, segurança e manutenção do ambiente fica
sob a responsabilidade do prestador de serviços. Isso é excelente para clientes e usuários desses serviços,
que podem focar a atenção em detalhes de seu negócio.
A computação em nuvem possui muitos modelos de serviços. Alguns exemplos de modelos são: Software
como Serviço (SaaS), Plataforma como Serviço (PaaS) e Infraestrutura como Serviço (IaaS). Cada um deles
é focado em um escopo.
Isso tem uma implicação direta na forma como os clientes desses serviços devem pagar por eles: pagar
pelo que usa. É uma forma muito inteligente de separar responsabilidades, aumentar a produtividade e
reduzir a necessidade de correções de problemas de ambiente de trabalho.
Outra questão que devemos considerar sobre a computação em nuvem é sua aplicação para Big Data e IoT.
É natural que isso ocorra, pois o tratamento de toda essa diversidade de tecnologias já faz parte de seu
escopo.
Novamente, precisamos pensar na importância de qualificação de profissionais que dominem os conceitos

e uso dessas tecnologias e que possam atender a tantas demandas que só tendem a aumentar com o
passar do tempo.
Questão 1
Os nomes das tecnologias nem sempre fazem referência a termos técnicos, mas, ainda assim,
precisam comunicar bem a ideia do que realizam. Um exemplo disso é a computação em nuvem.
Assinale a alternativa que, em sua visão, apresenta uma aplicação nesse sentido:
A Virtualização de sistema operacional.
B Aplicação cliente x servidor de banco de dados de grande porte.
C Todas as aplicações de IoT.
D Uso do Dropbox para armazenar e compartilhar arquivos.
E Qualquer aplicação hospedada na internet.

Os serviços de computação em nuvem são caracterizados por estarem hospedados na internet e
possuir recursos bem definidos, de modo que possam ser verificados pelo cliente. Essa caracterização
é importante, pois implica a relação contratual entre o prestador de serviço e o cliente que vai consumi-
lo. No caso do exercício, apenas o Dropbox possui uma relação bem definida sobre quais serviços são
prestados e que utilizam a tecnologia da internet para hospedá-los.
Questão 2
Você já conhece a relevância dos serviços de nuvem para atender às demandas de mercado atuais.
Esses serviços podem ser encaixados em categorias específicas. Em sua visão, um modelo de nuvem
em que o usuário pode utilizar editores de texto colaborativos hospedados na nuvem é:
A Plataforma como Serviço.
B Editor de texto como Serviço.
C Banco de dados como Serviço.
D Infraestrutura como Serviço.
E Software como Serviço.

Editores de textos são aplicações muito úteis para produzir documentos. Quando são hospedados na
nuvem, muitas pessoas podem colaborar no mesmo arquivo, possibilitando uma interação mais
produtiva. Esse tipo de situação é classificado como Software como Serviço (SaaS).
Questão 3
Considere o seguinte cenário: você é o responsável pela aquisição de um serviço que potencialize a
colaboração dos membros de uma equipe de desenvolvimento. Você foi informado ainda que são previstas
as inclusões de novas funcionalidades no sistema e que ele sempre deve utilizar a última versão estável da
linguagem de programação. Quais escolhas você faria para seu projeto?
Conceitos
Computação em nuvem (do original em inglês Cloud Computing) é o termo usado para se referir a uma
categoria de serviços de computação sob demanda disponíveis na Internet. Além de reduzir os custos
necessários para oferecer os serviços, a tecnologia de computação em nuvem também aumenta a
confiabilidade do sistema. Por isso, é cada vez mais comum encontrarmos aplicações que fazem a
integração entre as diversas tecnologias e que oferecem os meios para que programas e dispositivos
possam se comunicar na Internet.
Modelos de Serviços na Nuvem

Os modelos mais comuns de prestação de serviços na nuvem são:
SaaS
SaaS (Software as a Service) ocorre quando uma aplicação é oferecida via Internet e seu preço é dado de
acordo com as necessidades de uso da parte contratante, tais como a quantidade de licenças, por exemplo.
Esse tipo de serviço é bastante interessante para o cliente, pois ele vai pagar apenas as funcionalidades do
sistema que lhe serão úteis. Além disso, não é necessário que o usuário se preocupe com instalação,
ambiente para execução, manutenção e atualizações, pois tudo isso fica sob a responsabilidade do
prestador de serviço.
PaaS
PaaS (Plataform as a Service) disponibiliza o sistema operacional e um ambiente de desenvolvimento na

nuvem para o contratante, que, dessa forma, pode criar seus próprios programas com acesso a ferramentas
adequadas, bibliotecas e bancos de dados.
IaaS
IaaS (Infrastructure as a Service) disponibiliza servidores de armazenamento e serviços de firewall e

segurança da rede para os contratantes.
DaaS
DaaS (Desktop as a Service) oferece computadores (desktops) virtuais aos usuários finais pela Internet, que
são licenciados com uma assinatura por usuário. A forma como os dados podem ser persistidos nas
máquinas virtuais também é tratada por esses serviços. Os computadores podem ser persistentes e não
persistentes:
Persistente: os usuários podem personalizar e salvar uma área de trabalho para que mantenha a
aparência sempre que fizer logon na máquina.
Não persistente: os desktops são apagados cada vez que o usuário se desconecta, pois eles são apenas
um meio de acessar os serviços de nuvem compartilhados.
XaaS
XaaS (Everything as a Service) é um termo geral usado para se referir à entrega de qualquer coisa como um
serviço. Entre os exemplos de XaaS, podemos citar modelos gerais de computação em nuvem, como
Software como Serviço (SaaS), Plataforma como Serviço (PaaS) e Infraestrutura como Serviço (IaaS); e
modelos mais especializados, como comunicação como um serviço (CaaS), monitoramento como serviço
(MaaS), recuperação de desastres como serviço (DRaaS) e redes como serviço (NaaS).
Tipos de Nuvem
Existem três diferentes maneiras de implantar uma infraestrutura de nuvem e disponibilizar programas que
possuem vantagens e desvantagens associadas ao contexto em que serão utilizadas. Os três tipos de
nuvens são:
Nuvem pública.
Nuvem pública
Essa configuração é adequada para as empresas que ainda estão na etapa de crescimento de sua
infraestrutura e nas quais a demanda por serviços é instável, podendo estar muito baixa em alguns
momentos e muito alta em outros. Desse modo, as empresas podem pagar apenas pelo que estão
usando e, se necessário, ajustar a sua infra na nuvem com base na demanda, sem a necessidade de fazer
um investimento inicial em hardware, economizando dinheiro e tempo de configuração.
Nuvem privada.
Nuvem privada
Todos os serviços são executados por servidores dedicados que dão ao contratante total controle sobre a
gestão dos programas e da segurança da rede. Na prática, o usuário contratante pode monitorar e
otimizar o desempenho da execução dos serviços de acordo com suas necessidades. O principal valor de
uma nuvem privada é a privacidade que ela oferece. Essa característica é especialmente interessante para
empresas que trabalham com dados confidenciais e querem isolamento da Internet aberta.
Nuvem híbrida.
Nuvem híbrida
Combina aspectos das implementações de nuvem pública e privada. Por exemplo, os dados confidenciais
permanecem na nuvem privada, devido à segurança que esse tipo de nuvem oferece. As operações que
não usam dados confidenciais, por sua vez, são feitas na nuvem pública, onde as empresas contratantes
podem dimensionar a infraestrutura para atender às suas demandas com custos reduzidos. No caso de
operações de Big Data, as nuvens híbridas podem ser utilizadas para atuar com dados não confidenciais
na nuvem pública e manter os dados confidenciais protegidos na nuvem privada.
Plataformas de Big Data na Nuvem

Uma plataforma de Big Data na nuvem é um conjunto de tecnologias de software e hardware que permite
que o usuário contratante faça o gerenciamento de projetos de Big Data por meio de aplicações para
desenvolvimento, implantação e operação de programas, além do controle de uma infraestrutura voltada

para Big Data. Do ponto de vista econômico, essa estratégia é bastante interessante, pois o contratante não
precisa se preocupar com vários detalhes operacionais que, nesse modelo, ficam sob a responsabilidade do
prestador de serviços.
Ao longo dos anos, a demanda por soluções de Big Data tem aumentado e a oferta de serviços
acompanhou esse processo. As soluções das plataformas de Big Data tratam de:
dns
Gestão de dados
Disponibilização de servidores de banco de dados para gerenciamento de Big Data.
analytics
Análise de dados
Inteligência de negócios por meio de programas utilitários para tratamento e extração de dados de Big Data.
handyman
Ferramentas de desenvolvimento
Oferta de ambientes de desenvolvimento de programas para fazer análises personalizadas que podem se
integrar com outros sistemas.
Além de todos esses aspectos, a plataforma oferece os serviços de segurança e proteção aos dados por
meio do controle de acesso. Portanto, é um modelo muito interessante para quem trabalha com Big Data,
devido à redução de complexidade da gestão de tantos detalhes e possibilidade de focar no negócio em si.
Toda a facilidade oferecida por uma plataforma de Big Data ajuda os profissionais a se concentrarem na
excelência dos seus trabalhos, em especial, porque estão trabalhando com conjuntos de dados de grande
volume. Alguns dos perfis dos profissionais que trabalham com essas plataformas são:
engineering
Engenheiros de dados
Profissionais que fazem toda a gestão do fluxo dos dados: coleta, agregação, limpeza e estruturação dos
dados, para que possam ser utilizados em análises.
manage_search
Cientistas de dados
Profissionais que utilizam a plataforma para estudar padrões e descobrir relacionamentos em grandes
conjuntos de dados.
Saiba mais
Normalmente, existem dois perfis distintos em ciência de dados, que são:
Análise exploratória e visualização de dados: consiste na análise dos dados por meio de técnicas
estatísticas.
Algoritmos de aprendizado de máquina: nesse perfil, os dados são analisados com o objetivo de encontrar
associações não triviais que possam ser úteis para desenvolver estratégias de negócios, como aumentar
engajamento de clientes e potencializar vendas.
Exemplos de Plataformas na Nuvem

Vamos conhecer, agora, algumas das principais plataformas na nuvem, mas, antes disso, vamos ver um
conceito muito importante de Big Data, o data lake. Trata-se de um repositório centralizado onde é possível
armazenar grandes volumes de dados estruturados e não estruturados. É um recurso bastante útil para
armazenar os dados sem precisar estruturá-los e ter a possibilidade de executar diferentes tipos de análises
de Big Data com painéis que facilitam as visualizações e funcionam como suporte para a tomada de
decisão.
O data lake é recurso essencial nas plataformas de Big Data, pois as organizações utilizam os dados como
a base para realizar análises e desenvolver estratégias que as auxiliem a potencializar seus negócios. Cada
plataforma oferece uma tecnologia de data lake. Agora, veremos algumas dessas plataformas:
Amazon AWS expand_more
Sua primeira oferta como serviço ocorreu em 2006 e seu modelo é usado como referência por outras
plataformas de armazenamento e computação em nuvem. Ainda em 2006, a Amazon lançou uma
plataforma de computação chamada Elastic Cloud Compute (EC2), que fornece serviços de
processamento de dados virtualizados, que podem ser ajustados para atender às necessidades do
contratante. O nome do serviço de data lake da Amazon é Amazon Simple Storage Service (S3),
utilizado por muitas empresas para o desenvolvimento de soluções de Big Data na nuvem.
Microsoft Azure expand_more
É a plataforma de nuvem da Microsoft que foi lançada em 2010. Ela oferece ferramentas e serviços
que foram projetados para permitir que organizações que trabalham com grandes conjuntos de
dados realizem todas as suas operações na nuvem. Entre os seus pontos positivos, estão a
segurança e a governança de dados, bem como a integração com ferramentas analíticas. Além
disso, ela possui o Azure Data Lake, que permite trabalhar com dados complexos.
Google Cloud Plataform expand_more
É a plataforma de nuvem do Google. Ela utiliza a mesma tecnologia dos serviços de Big Data
proprietários do Google, como YouTube e pesquisa Google. Ela também oferece serviços de
armazenamento. Seu data lake é o Google Cloud Storage, projetado para trabalhar com exabytes de
dados.
Oracle Cloud expand_more
É a plataforma de banco de dados da Oracle na nuvem. A Oracle é uma empresa especialista em

soluções de bancos de dados. O seu serviço de nuvem inclui armazenamento flexível e escalável
junto com os serviços de análise e processamento de dados. Sua plataforma possui fortes recursos
de segurança, como criptografia em tempo real de todos os dados enviados para a plataforma.
IBM Cloud expand_more
É a plataforma de nuvem da IBM. Ela oferece várias soluções de data lake com o objetivo de atender
aos diferentes perfis de necessidades dos seus clientes. Também é uma solução que tem
dimensionamento ajustável, como as demais vistas. Com essa plataforma, os usuários podem
escolher entre três tipos de armazenamento: de objeto, em bloco ou armazenamento de arquivo,
dependendo das estruturas de dados com as quais estão trabalhando. Além disso, a IBM possui, na
sua plataforma Watson, ferramentas analíticas que podem se integrar totalmente aos dados
armazenados nos serviços em nuvem da IBM.
video_library
Plataformas em Nuvem para Aplicações de
BigData
No vídeo a seguir, abordaremos a programação em nuvem, as plataformas e suas aplicações para Big Data.

objetivos.

Questão 1
Os serviços de nuvem oferecem diversas facilidades para projetos de Big Data. Eles são uma
combinação de tecnologias que envolvem hardware e software por meio da Internet. Nesse sentido,
assinale a alternativa correta a respeito dos modelos de serviços na nuvem.
Os serviços de nuvem são utilizados apenas para transmissão e recepção de dados,

A ficando o armazenamento e processamento dos dados sob a responsabilidade do
contratante.
B Quando contratamos um modelo PAAS, esperamos que sejam disponibilizadas

aplicações que gerenciem os dados.
Os modelos de serviço de nuvem só podem ser usados para projetos de Big Data
C
voltados para aplicações de Internet das Coisas.
Apesar da redução de custos para montar uma infra, os serviços de nuvem têm como
D desvantagem a dificuldade para expandir o uso de novas tecnologias em um projeto de
Big Data.
Os serviços de nuvem de software tratam de diversos aspectos, tais como rede,

E
servidores, virtualização, sistema operacional, dados e aplicações.
Os serviços de nuvem são muito úteis para projetos de Big Data, pois flexibilizam o uso de tecnologias e
a adequação do tamanho da infraestrutura para atender às demandas dos clientes. Existem vários
modelos, como, por exemplo, o SaaS (software como serviço), PaaS (plataforma como serviço) e IaaS
(infraestrutura como serviço).
Questão 2
A tecnologia de computação na nuvem é um importante recurso para projetos de Big Data. Para atender
a essa demanda de mercado, grandes empresas da Internet oferecem plataformas com soluções de
hardware e software. A respeito das plataformas de Big Data na nuvem, selecione a opção correta.
Ao utilizar plataformas na nuvem, os contratantes podem fazer análises personalizadas

A por meio do uso de programas especializados que são úteis para dar suporte à área de
negócios de uma organização.
As plataformas de nuvem são protocolos de comunicação que fazem a intermediação

B entre as aplicações responsáveis pela coleta de dados até o processamento analítico,
permitindo a elaboração de sofisticados relatórios.
A Amazon é uma das gigantes da Internet que disponibiliza uma plataforma de nuvem
C
chamada MQTT, que pode ser utilizada para projetos de Internet das Coisas.
Um dos perfis dos profissionais que trabalham com plataformas de Big Data na nuvem é
D o de engenheiro de dados que se caracteriza por desenvolver aplicações de aprendizado
de máquina.
As plataformas de Big Data na nuvem são utilizadas para desenvolver, exclusivamente,

E aplicações voltadas para gestão do ciclo de vida dos dados caracterizada,
principalmente, pelo uso da tecnologia de data lake.

Os principais fornecedores de plataformas de Big Data na nuvem são a Amazon, Microsoft, Google,
Oracle e IBM. Suas plataformas cobrem aspectos de hardware e software em que o contratante faz uso
de um data lake e, posteriormente, pode utilizar ferramentas analíticas para detecção de padrões que
apoiam no desenvolvimento de estratégias de negócios.
4 - Processamento e Streaming de
Dados
Ao final deste módulo, você será capaz de identificar
aplicações de processamento e streaming de dados.
Ligando os pontos
Você sabe como utilizar a arquitetura REST para implementar Web Services com Java? Que estratégia
adotaria para implementar um Web Service para prover serviços a outras aplicações?
Para entendermos esses conceitos na prática, vamos analisar uma situação.
A velocidade com que a tecnologia avança cria situações curiosas e até mesmo impensáveis para os que
não passaram por ela. Por exemplo, na década de 1990, era muito comum alugar fitas de filmes para assistir
no final de semana e não esquecer de devolvê-las rebobinadas na segunda-feira.
Hoje, temos à disposição diversos serviços de streaming, onde podemos escolher vários filmes em um
catálogo, assistir a uma parte deles, continuar quando quisermos e, ainda, classificá-los de acordo com
nosso grau de satisfação.
Há muitas questões envolvidas nesse exemplo. Vamos tentar destacá-las!
A primeira é a velocidade com que podemos acessar um grande volume de dados. Essas características são
típicas de aplicações de Big Data.
Outra questão importante é a classificação que damos aos filmes. Esses dados serão processados
posteriormente com os dados de outros consumidores para identificar perfis de usuários. Dessa forma, o
prestador de serviço pode nos oferecer filmes que se encaixem melhor com nossas preferências, sem, no
entanto, impedir que escolhamos outro filme do catálogo.
Semelhante ao exemplo que acabamos de apresentar, podemos encontrar muitas outras aplicações de
streaming na prática, como é o caso de IoT com Big Data. Inúmeras situações precisam ser monitoradas em
tempo real para verificar condições do ambiente.
A partir do processamento e da análise desses dados, pode ser necessário tomar uma ação que vai prevenir
perdas materiais e, principalmente, preservar a vida das pessoas. Essas aplicações são caracterizadas pelo
grande volume e pela grande velocidade de fluxo de dados, o que demanda técnicas muito eficientes para
detecção de anomalias.
As aplicações de Big Data se encaixam em diversos cenários. É uma miscelânea de tecnologias e métodos
eficientes para coletar, processar e analisar dados. O profissional que deseja trabalhar com essa área tem
muitas oportunidades de atuação e está investindo em uma carreira com muitas demandas para serem
atendidas.
Questão 1
Você já sabe o que é um serviço de streaming. Também já conhece a definição de IoT. Nesse sentido,
assinale a alternativa que apresenta um exemplo de uso de tecnologia com Big Data:
A Monitorar o desempenho de um banco de dados de grande porte via internet.
B Monitorar a operação de equipamentos de extração de petróleo.
C Monitorar o nível de água de uma represa.
D Gerenciar automaticamente os elevadores de um prédio comercial.
Gerenciar o controle de acesso de usuários a documentos compartilhados e

E
hospedados na nuvem.

Aplicações de IoT utilizam dispositivos para coletar dados e protocolos para trafegar dados via Web. Já
as aplicações de streaming são caracterizadas pelo grande fluxo de dados. No caso da questão, o
único exemplo que se encaixa com essas tecnologias é o monitoramento da operação de um
equipamento para extração de petróleo, pois são necessários dispositivos que tenham a capacidade de
coletar dados gerados rapidamente e que possam ser enviados para uma central onde serão
analisados.
Questão 2
Atualmente, é comum que muitos influenciadores digitais façam “Lives” em plataformas Web, onde
apresentam suas opiniões e interagem com seu público. Essas “Lives” são um exemplo prático de
aplicações de streaming. Em sua visão, que característica justifica essa afirmação?
Os usuários utilizam equipamentos de acesso à internet típicos de aplicações de IoT

A
com streaming.
A interação entre os usuários e influenciadores gera dados que podem ser utilizados
B
para aumentar o engajamento nas redes sociais.
Ao fazer uma interação com seus seguidores na internet, os influenciadores utilizam

C
serviços hospedados na nuvem.
D O fluxo de dados gerado é muito grande durante a “Live”.
E Os serviços de streaming utilizam protocolos de comunicação Web para trafegar dados.
Os serviços de streaming são caracterizados pelo grande volume e pela grande velocidade com a qual
os dados são gerados. Ao realizar “Lives”, os influenciadores digitais e o público estão gerando um
grande volume de dados que precisam ser tratados de forma eficiente para manter a qualidade da
interação e que podem ser utilizados para aumentar o processo de interação com aplicações de
algoritmos de aprendizado de máquina.
Questão 3
Considere o seguinte cenário: você acompanha a ocorrência de desastres ambientais que, além da
destruição de bens materiais, ceifam muitas vidas. Atualmente, você tem estudado sobre as possibilidades
de aplicações de processamento e streaming de dados. Que sugestões de aplicações você faria para evitar
esses desastres, ou, pelo menos, minimizar as consequências deles, utilizando processamento e streaming
de dados?
Conceitos
O streaming de dados é o processo de transmissão de um fluxo contínuo de dados. Por sua vez, um fluxo de
dados é formado por diversos elementos de dados que são ordenados no tempo. Como exemplo, temos a
transmissão de dados de uma gravação de vídeo, pois as imagens que vemos são séries de dados que
seguem uma ordem cronológica. Assim, os dados representam que algo ocorreu – que chamamos de
“evento” – de modo que houve uma mudança de estado sobre um processo que pode fornecer informações
úteis. Por isso, muitas organizações investem para obter, processar e analisar esses dados.
Streaming de dados.
Atenção
Em muitas situações, essas análises podem ser feitas ao longo de dias ‒ o que é, por exemplo, bastante
comum na manutenção preditiva de equipamentos ‒ mas, em outros casos, esses processos entre coletas e
análises devem ser feitos em tempo real – situação típica de processos de operação de equipamentos com
riscos à vida e ao patrimônio.
Podemos encontrar exemplos típicos de fluxos de dados nas seguintes situações:
Dados de
sensores
embarcados em
equipamentos.
Arquivos de logs
de atividades de
d d
navegadores da
web.
Logs de
transações
financeiras.
Monitores de
saúde pessoais.
Sistemas de
segurança
patrimonial.
Esses foram apenas alguns exemplos, mas temos muitas outras situações que envolvem grandes volumes
de dados que são transmitidos em fluxos contínuos, como se estivessem sendo transportados por uma
esteira alimentando continuamente um sistema de processamento de dados.
Atualmente, o fluxo de dados e seu processamento aumentaram sua importância devido ao crescimento da
Internet das Coisas (IoT), pois o fluxo de dados dessas aplicações é muito grande e precisa de um
tratamento específico. Os sistemas de IoT podem ter vários sensores para monitorar diferentes etapas de
um processo. Esses sensores geram um fluxo de dados que é transmitido de forma contínua para uma
infraestrutura de processamento, que, por sua vez, monitora qualquer atividade inesperada em tempo real ou
salva os dados para analisar padrões mais difíceis de detectar posteriormente.
Características e desafios em relação ao

processamento de fluxos de dados
Os conceitos de aplicações de Big Data sempre precisam levar em consideração a complexidade em que
estão contextualizados. Isso ocorre com os dados de streaming de sensores, navegadores da web e outros
sistemas de monitoramento que possuem características que precisam ser tratadas de um modo diferente
em relação aos dados históricos tradicionais.
Características do processamento de
fluxos de dados
Devido aos aspectos que envolvem o processamento de fluxo de dados, podemos destacar algumas
características, que são:
Sensibilidade ao Tempo expand_more
Independentemente de onde sejam aplicados, os elementos em um fluxo de dados estão associados

a uma localização de tempo por meio de uma data e hora. Essa característica é usada junto com o
contexto de aplicação para medir o valor do dado. Por exemplo, os dados de um sistema de
monitoramento de saúde de pacientes que indiquem uma mudança grave dos níveis vitais devem ser
analisados e tratados dentro de um curtíssimo período, para preservar a integridade da saúde do
paciente, ou seja, permanecerem relevantes.
Continuidade expand_more
Especialmente para processos de tempo real, os fluxos de dados são contínuos e acontecem sempre
que um evento é disparado ou quando ocorre uma mudança de estado no sistema. Portanto, o
sistema de processamento deve estar preparado para ser acionado sempre que for requisitado.
Heterogeneidade expand_more
Os dados de fluxo podem vir de diferentes fontes com diferentes formatos e que podem estar
geograficamente distantes. Uma das características de Big Data é a variedade que abrange estas
situações: formatos, fontes de dados e localização geográfica.
Imperfeição expand_more
Muitos fatores podem influenciar para que os elementos de um fluxo de dados sejam prejudicados
por perda e corrupção. Devido à variedade das fontes e dos formatos, esse processo é ainda mais
complexo de ser gerenciado. Ainda há a possibilidade de que os elementos de dados em um fluxo
possam chegar fora de ordem. Isso implica que o sistema também precisa levar em consideração
essas falhas e ter uma medida de tolerância para fazer ajustes, quando for possível, e o
processamento dos dados.
Volatilidade expand_more
Os elementos de fluxo de dados são gerados em tempo real e representam estados de um sistema
que está sob monitoramento. Isso implica que a recuperação desses dados, quando ocorre uma
falha de transmissão, é bastante difícil. Não se trata apenas de retransmitir os dados, mas também
da impossibilidade de reproduzir o estado do sistema quando os dados foram gerados. Portanto, é
necessário desenvolver estratégias que minimizem esse problema, como redundâncias de
monitoramento e armazenamento de dados.
Desafios do processamento de fluxos de

dados
Agora que entendemos as características do processamento de fluxos de dados, precisamos analisar os
desafios para desenvolver aplicações. Entre esses desafios, podemos citar os seguintes:
Escalabilidade expand_more
Uma aplicação de processamento de fluxo de dados precisa ter flexibilidade para gerenciar o
aumento brusco de volume de dados. Uma situação desse tipo pode ocorrer quando partes do
sistema falham e uma grande quantidade de dados de logs é enviada para alertar sobre a ocorrência
do problema, podendo aumentar a taxa de envio dos dispositivos para o servidor de aplicação.
Portanto, o projeto do sistema deve contemplar tais casos com estratégias para adição automática
de mais capacidade computacional à medida que a demanda por recursos aumenta.
Ordenação expand_more
Os elementos de um fluxo de dados estão associados a uma marcação no tempo. Essa marcação é
fundamental para que os dados possam ser agrupados em estruturas sequenciais que façam
sentido. Podemos pensar em uma transmissão de vídeo ao vivo, em que é esperado que o conteúdo
siga uma sequência linear, pois não faria sentido ver um vídeo em que os quadros são transmitidos
fora de ordem. Portanto, um projeto desse tipo precisa evitar que haja discrepâncias sobre a ordem
de transmissão dos dados, além de ter mecanismos de controle de qualidade.
Consistência e durabilidade expand_more
Os dados em um fluxo de dados são voláteis, mas, em muitas situações, é útil mantê-los
armazenados, para que possamos analisá-los posteriormente. Para isso, precisamos aplicar técnicas
que garantam a condição de originalidade dos dados, ou seja, que eles não foram modificados e que,
além disso, tenham informações sobre sua qualidade. Essas situações implicam que o
desenvolvimento de um projeto de processamento de fluxo de dados deve garantir a consistência
dos dados, para que possam ser armazenados e analisados em outro momento. Quando os dados
passam por essas etapas, eles têm a propriedade de durabilidade.
Tolerância à falhas e garantia de dados expand_more
Os sistemas são sujeitos a falhas. E quando falamos em sistema, precisamos visualizar toda a
complexidade que envolve programas, dispositivos físicos e infraestrutura. Esse tipo de situação
pode ser tratado por meio de algumas abordagens, como, por exemplo:
redundância de elementos de transmissão e coleta;
uso de sistemas não centralizados;
análise estatística periódica dos dados para medir a sua qualidade.
Descoberta de Conhecimento a partir de Fluxo

de Dados
Data warehouse.
Os dados de uma organização podem vir de diversas fontes, como registros de vendas, sistemas de
controle de estoque e interações com usuários – que são aquelas pesquisas em que a empresa pergunta
sobre a qualidade do seu atendimento. Esses dados são armazenados em um data warehouse e, então,
processados em lotes por um sistema de análise de dados.
Esse modelo de gestão de dados funciona bem em

contextos em que não temos urgência para extrair
informações que nos deem suporte para intervir em um
sistema.
Por outro lado, temos muitas situações práticas em que o tempo entre a coleta do dado e a ação sobre uma
determinada configuração é crucial. Alguns dos casos típicos em que isso ocorre estão relacionados às
seguintes situações:
Prestação de serviços essenciais

Como fornecimento de água, energia elétrica e gás.
Monitoramento
De saúde e prestação de socorro a vítimas.
Operação de equipamentos
Como transportadores de carga em aviões e caminhões aplicados à mineração.
Ajustes ad hoc
De eventos de divulgação de produtos e de prestação de serviços que tenham como objetivo aumentar o
engajamento do público.
Comentário
A lista não se encerra com esses exemplos, mas eles já ilustram bem o fato de que existem muitas
situações reais em que o processamento em lote não é adequado para aplicações de tempo real e, portanto,
precisamos aplicar estratégias de processamento do fluxo de dados para obtermos informações que nos
permitam atuar rapidamente e com maiores chances de alcançar o nosso objetivo com sucesso.
Big data e machine learning.
Já é um fato consolidado que a ciência de dados e, em especial, as técnicas de aprendizado de máquina,

têm sido aplicadas com sucesso em contextos de Big Data para detectar padrões e produzir conhecimento
que oriente as nossas decisões. Um dos motivos para que esse processo seja bem-sucedido é que essas
técnicas de aprendizado são beneficiadas pela diversidade dos dados, o que permite obter algoritmos que
generalizem as soluções, em vez de ficar restrito a um conjunto de dados. Como exemplos de algoritmos de
aprendizagem de máquina que são naturalmente incrementais, temos: k-vizinhos mais próximos e o Bayes
ingênuo. Além da aprendizagem incremental, as técnicas precisam se autoajustar para refletir o estado mais
recente dos dados e esquecer informações que perderam sua utilidade para o cenário atual.
Sistemas como os de IoT são modelados de forma mais adequada, como fluxos de dados transitórios,
apesar de também ser útil armazená-los em tabelas para registro e fazer estudos posteriores. A análise
desses dados permite que possamos fazer a sua mineração, ou seja, realizar processamentos que nos
auxiliem a detectar tendências e mudanças de estado. Como resultado desse trabalho, podemos:
Identificar perfis
O que nos permite direcionar estratégias mais eficientes para aumentar o engajamento de clientes e
oferecer serviços personalizados.
Fazer estimativas sobre a demanda

De modo que possamos dimensionar os recursos que precisamos alocar para operar com segurança.
Detectar falhas e atividades anormais

nos sistemas
Para que possamos intervir rapidamente.
video_library
Processamento e Streaming de Dados
No vídeo a seguir, abordaremos os conceitos de processamento e streaming de dados, relacionando-os à
tecnologia de Big Data em aplicações de aprendizado de máquina.

objetivos.

Questão 1
Projetos de Big Data são complexos, pois muitos aspectos devem ser considerados. Um desses
aspectos corresponde ao fluxo de dados que são conhecidos como streamings. Nesse sentido,
assinale a alternativa correta a respeito das características e desafios em relação ao processamento de
fluxo de dados em projetos de Big Data.
Quando um sistema de fluxo de dados de Big Data falha, é possível recuperar os dados
A
reiniciando-o.
Aplicações de streaming são caracterizadas por fluxos não contínuos de dados, sendo,
B desse modo, um desafio dimensionar uma infraestrutura, para evitar a ociosidade do
sistema.
Os fluxos de dados de aplicações de tempo real precisam de garantia de qualidade de

C
serviço, pois não é possível fazer análises confiáveis com dados voláteis.
Muitas das aplicações de Big Data que utilizam fluxos de dados são de tempo real,
D cujos dados precisam ser processados com muita velocidade, pois, em muitos casos, o
seu valor é reduzido ao longo do tempo.
Uma das vantagens de trabalhar com sistemas de fluxos de dados é o fato de que eles
E são oriundos da mesma fonte, o que reduz a complexidade da infraestrutura necessária
para o processamento.

Aplicações como monitoramento de sinais vitais de pacientes e de segurança, de modo geral, precisam
ter seus dados processados com grande velocidade, pois, depois de algum tempo, o paciente pode
sofrer graves consequências por não ter sido atendido, como uma equipe de segurança também pode
perder a oportunidade de intervir contra uma atividade criminosa. Projetos desse tipo são muito
complexos, pois precisam garantir a disponibilidade dos dados e a velocidade de transmissão e
processamento, para detectar padrões e permitir que ações sejam tomadas dentro de um tempo
adequado.
Questão 2
A utilização de estatística e métodos de aprendizado de máquina em aplicações de Big Data é cada vez
mais comum. Um dos fatores que influencia para que isso ocorra é o fato de ter à disposição grandes
volumes de dados com variações que permitam que os modelos generalizem as soluções. Nesse
sentido, assinale a alternativa correta a respeito da descoberta de conhecimento a partir de fluxo de
dados em projetos de Big Data.
Uma das estratégias mais adequadas para lidar com fluxo de dados para algoritmos de
A aprendizado de máquina é submeter os dados a um processo de tratamento para
garantir a qualidade deles antes de submetê-los aos algoritmos.
Aplicações de Internet das Coisas produzem dados que podem fornecer informações
B úteis a respeito da topologia de sistemas monitorados, possibilitando, assim, a atuação
mais precisa.
Os projetos de Big Data que envolvem fluxos de dados são úteis apenas para avaliar o
C estado do sistema em certo período e não devem ser armazenados com o objetivo de
obter histórico de comportamento.
Para aplicar um algoritmo de aprendizado de máquina em um projeto de Big Data que

D envolva fluxo de dados é necessário utilizar um data warehouse, que é uma tecnologia
adequada para consultas ad hoc.
Existem poucas situações práticas que justificam a aplicação de algoritmos de

aprendizado de máquina para projetos de Big Data que envolva fluxo de dados, no
E
entanto, apesar disso, é uma boa prática preparar uma infraestrutura adequada para
esses algoritmos, pois o valor dos dados pode aumentar ao longo do tempo.

Os projetos de Big Data que envolvem fluxo de dados de tempo real podem fornecer informações
importantes para direcionar os esforços de atuação. Para que esse processo funcione adequadamente,
é necessário adaptar os métodos de aprendizado de máquina para procurar padrões e detectar
anomalias, enquanto os dados ainda estão em fluxo, ou seja, sem passar pelo processo tradicional de
tratamento e treinamento em lote.
Considerações finais
Ao longo deste conteúdo, estudamos o conjunto de tecnologia que envolve o conceito de Big Data. É
interessante notarmos que, em um primeiro momento, associamos Big Data a aplicações de banco de
dados. Porém, quando analisamos um pouco mais, vimos que estamos tratando de uma tecnologia que vai
além de banco de dados, relacionando-se às tecnologias de redes, processamento eficiente, Internet das
Coisas (IoT), computação distribuída, análise estatística e aprendizado de máquina.
Estudamos os conceitos de IoT e computação distribuída e as plataformas em nuvem para aplicações de

Big Data. Vimos, ainda, alguns dos principais provedores de serviço e entendemos a importância da
tecnologia de data lake. Além disso, estudamos sobre processamento e streaming de dados.
Atualmente, vivemos em uma época com grandes oportunidades de demanda de profissionais para
desenvolver aplicações nas mais variadas áreas, como no entretenimento, na prestação de serviços de
monitoramento, e nas áreas de segurança, saúde, finanças, entretenimento, mídia e agronegócio. Portanto,
Big Data é uma excelente área para se especializar e procurar oportunidades de desenvolvimento
profissional.
headset
Podcast
Para finalizar o seu estudo, ouça o podcast a seguir, que aborda os principais conceitos de Big Data e sua
relação com as tecnologias de IoT, Computação Distribuída, Plataformas em Nuvem e Streaming de Dados.
Explore +
Acesse o site do Arduino e estude os diversos exemplos didáticos de como construir projetos
superinteressantes. Em seguida, tente programar esses projetos no site do Tinkercad.
Acesse o site oficial do Spark e procure por Streaming Programming. Desse modo, você vai aprofundar seu
conhecimento sobre processamento de fluxo de dados, além de encontrar exemplos práticos desenvolvidos
no Spark.
Referências
BRASIL. Lei nº 13.709 de 14 de agosto de 2018. Dispõe sobre a proteção de dados pessoais e altera a Lei
nº 12.965, de 23 de abril de 2014 (Marco Civil da Internet). Diário Oficial da República Federativa do Brasil, 15
ago. 2018. Consultado na Internet em: 10 set. 2021.
GANTZ, J.; REINSEL, D. Extracting value from chaos. IDC iView, pp 1–12, 2011.
LANEY, D. 3-d data management: controlling data volume, velocity and variety. META Group Research Note,
2001.
RUSSOM, P. Big Data Analytics. TDWI Best Practices Report, Fourth Quarter 2011. TDWI Research, 2011.
Material para download

Clique no botão abaixo para fazer o download do conteúdo completo em formato PDF.
Download material
O que você achou do conteúdo?
Relatar problema
9/5/23, 3:16 PM Conceito de Business Intelligence e seu componente Data Warehouse
Conceito de Business Intelligence e seu componente Data Warehouse

Profª Vivian Monteiro
Prof. Antonio Felipe Podgorski Bezerra, Prof. Sérgio Assunção Monteiro
Descrição
Conceitos de Business Intelligence (BI) e sistemas de suporte à tomada de decisão, entendimento de Data Warehouse (DW), seus
componentes e sua arquitetura, bem como a compreensão do ciclo de vida do projeto.
Propósito
Compreender os conceitos basilares de Business Intelligence e Data Warehouse como requisitos essenciais para a análise e o
entendimento do ambiente organizacional, e para uma maior assertividade durante o levantamento de requisitos com os usuários
envolvidos e na elaboração de documentos para apoiar o projeto de DW.
Objetivos
Módulo 1
Business Intelligence
Definir o conceito de Business Intelligence e seus componentes nos diferentes níveis organizacionais.
Módulo 2
Projeto de Data Warehouse
Reconhecer a arquitetura e o ciclo de vida de um projeto de Data Warehouse.
Módulo 3
Requisitos e fontes para Data Warehouse
Descrever o processo de levantamento de requisitos e mapeamento de fontes de dados para Data Warehouse.
Introdução
O crescimento de uma empresa revela desafios relacionados ao conhecimento do seu próprio negócio e sobre o
comportamento do mercado, que pode influenciar direta ou indiretamente na saúde da empresa. O conhecimento permite aos
gestores de uma organização tomarem decisões mais direcionadas, focando em aspectos de melhoria das atividades,
aumentando as oportunidades de crescimento e minimizando riscos que possam impactar em seus resultados.
No entanto, poucos sabem que esse conhecimento já se encontra em posse da organização: em sistemas destinados às
operações diárias, sistemas de controle de estoque, nas planilhas de vendas, nos e-mails trocados com fornecedores e
clientes, e até mesmo em feedbacks e menções recebidos nas redes sociais. Todos são exemplos de dados brutos, que, se
lapidados por meio de técnicas e processos bem definidos, podem se transformar em conhecimento. Por isso, devem ser
tratados como um ativo extremamente importante da organização para obtenção da inteligência organizacional, também
conhecida como Business Intelligence (BI).
Neste conteúdo, vamos compreender as diferentes necessidades informacionais dentro de uma organização, os tipos de
sistemas que as apoiam e como é possível projetarmos estruturas para organizarmos esses dados e informações,
denominados Data Warehouse (DW), reconhecendo seus componentes e sua arquitetura, o funcionamento do ciclo de vida de
um projeto de DW e as fases de levantamento de requisitos e mapeamento de fontes de dados para Data Warehouse.
1 - Business Intelligence
Ao final deste módulo, você será capaz de definir o conceito de Business Intelligence e seus componentes nos
diferentes níveis organizacionais.
Ligando os pontos
Você sabe o que é Business Intelligence? Em um cenário em que fosse contratado para auxiliar no aumento das vendas de um cliente,
qual estratégia você adotaria? Para respondermos a essas perguntas, vamos analisar algumas situações práticas.
A popularização das tecnologias trouxe inúmeros benefícios para a sociedade. Um exemplo prático disso são os bancos de dados
que permitem armazenar diversos dados, criando, assim, um histórico dos eventos que ocorreram em uma empresa de vendas. Esses
dados podem ser analisados posteriormente e fornecer importantes entendimentos a respeito do negócio. É aí que entra a Business
Intelligence (BI) ou simplesmente Inteligência de Negócios.
A BI utiliza um conjunto de técnicas para obter informações relevantes a respeito de um processo. Obviamente, é pré-requisito
fundamental ter fontes de dados disponíveis e confiáveis. A partir dessas fontes de dados, começamos a construir as perspectivas do
negócio que estamos analisando por meio de Data Marts (DMs). As perspectivas correspondem às diferentes visões dos atores a
respeito do negócio. Já os DMs são uma organização resumida dos dados que traduzem essas perspectivas. Vamos a um exemplo.
Uma loja virtual vende diversos tipos de roupas. Depois de seis meses de operação, os responsáveis perceberam alguns padrões e
querem formalizá-los para construir estratégias que ajudem no aumento das vendas.
Agora, como a BI pode ajudar os responsáveis por essa loja?
O primeiro ponto a ser observado, como já vimos, é ter um banco de dados que registre tudo o que está acontecendo sobre detalhes
das vendas: qual a roupa, o valor, o dia da venda e informações sobre o cliente.
Em seguida, passamos a estudar os perfis dos clientes em grandes grupos com o objetivo de detectar padrões:
Existem preferências relacionadas à idade?

Em que época determinados modelos de roupas vendem mais?
Qual perfil de cliente é mais aderente com a proposta da loja?
Aplicar BI para organizar um negócio é um passo estratégico muito eficaz para tomar decisões baseadas na realidade dos
acontecimentos. Precisamos ficar atentos aos aspectos tecnológicos e utilizá-los como suporte para o fortalecimento e o
crescimento de um negócio.
Após a leitura do caso, é hora de aplicar seus conhecimentos!
Questão 1
Imagine que você seja o responsável por uma rede de lojas e queira utilizar soluções de BI para aumentar suas vendas, mas não
possua um registro de suas operações. Para aplicar BI em seu negócio, o que você deve fazer?
A Criar uma base de dados que possa ser explorada por técnicas de BI.
B Utilizar a intuição para construir dados próximos da realidade e, em seguida, implementar BI.
Adquirir um software de BI no mercado que seja capaz de produzir excelentes análises do negócio sem a
C
dependência de um banco de dados.
D Como não há uma cultura de gerenciamento de dados, não há como aplicar BI.
E Compensar a falta de dados com comparações de rede de lojas semelhantes.
As técnicas de BI são muito úteis para construir estratégias eficazes que fortalecem um negócio. No entanto, elas são baseadas
em fontes de dados confiáveis. Na ausência deles, tudo é especulação e envolve enormes riscos. No caso em questão, é
fundamental que o responsável pela rede de lojas organize seus dados, para que possa aplicar BI posteriormente.
Questão 2
Suponha que você seja o responsável pelo treinamento de uma equipe de desenvolvedores para criar uma solução de BI. Essa
equipe é formada por profissionais que já sabem trabalhar com banco de dados e são experientes com linguagens de
programação orientadas a objetos, como Java, C# e Python. Nesse caso, qual deve ser seu foco no treinamento dessa equipe
para maximizar o aprendizado?
A No desenvolvimento de um DM com estudo de caso aplicado.
B Nos conceitos de banco de dados, para melhorar o desempenho das consultas.
C Na otimização do uso de uma linguagem de programação e de um banco de dados para manipular dados.
D No estudo detalhado de um negócio, para compreender todos os detalhes relevantes.
E No debate teórico sobre os grandes benefícios potenciais que as técnicas de BI podem produzir para um negócio.
As técnicas de BI são usadas para extrair informações relevantes obtidas dos dados de um negócio. Para implementá-las, são
necessárias uma visão detalhada do negócio e uma qualificação técnica que permita o desenvolvimento de soluções práticas. No
caso em questão, a equipe já tem experiência em banco de dados e linguagens de programação. Então, para potencializar o
aprendizado, é necessário mergulhar em um exemplo prático que terá como resultado a produção de um Data Mart (DM).
Questão 3
Considere o seguinte cenário: você foi contratado para desenvolver uma solução de BI para uma livraria que trabalha apenas com
material digital. Um dos grandes problemas enfrentados por esse tipo de negócio é a pirataria. Apesar disso, a livraria consegue
realizar boas quantidades de vendas mensais, mas deseja aumentar as vendas em, pelo menos, 30%. Nesse caso, que solução você
indicaria aos responsáveis pela livraria a fim de atingir esse objetivo?
A BI pode ajudar os responsáveis pela livraria de muitas formas. A primeira delas é com o estudo do perfil dos clientes, que,
apesar do problema descrito, continuam comprando os livros na loja. É necessário trabalhar para aumentar o engajamento
desses clientes com o envio de informações a respeito de produtos e promoções que realmente sejam interessantes para eles.
A partir dessa fidelização, esses clientes devem ser estimulados a convidar outras pessoas para conhecer a livraria. Nesse meio
tempo, a BI ajuda a entender se essas estratégias estão surtindo efeito e quais os segmentos que demandam mais atenção.
Business Intelligence: visão geral

As plataformas de Business Intelligence (BI) fornecem apoio à construção do conhecimento para a tomada de decisão, utilizando um
conjunto de técnicas e ferramentas que coletam dados, aplicam tratamentos necessários, integram os dados, organizam e
disponibilizam informações que darão suporte às decisões estratégicas da organização.
Esse conjunto resulta em um ambiente analítico com informações gerenciais em formato de relatórios e dashboards, que facilitam a
visualização, de forma mais ampla, do que aconteceu, do que está acontecendo ou do que ainda poderá acontecer na empresa.
Exemplo
Para que o gerente do supermercado possa realizar uma análise do que já aconteceu e identificar quais são os produtos mais
vendidos no verão, é necessário analisar os dados dos três últimos anos nos meses de dezembro a março. Se esse mesmo gerente
possui a necessidade de acompanhar a venda dos produtos para que seu estoque não seja zerado, ele precisa de relatórios diários ou
semanais do fluxo de venda.
Mas como as análises sobre os dados podem auxiliar na tomada de decisão sobre o que acontecerá?
O estudo de acontecimentos passados pode revelar comportamentos futuros. Então, é possível analisar os produtos comprados
pelos clientes, traçar os perfis de consumo destes e sugerir novos produtos que se encaixem nos perfis mapeados, pois, de acordo
com os produtos comprados, há uma probabilidade que eles se interessem por alguns itens relacionados às suas compras passadas.
Esses tipos de análises são classificados como diagnóstica, descritiva, preditiva e prescritiva. De acordo com o Glossário do Gartner
Group (GARTNER, 2020), tais análises são descritas da seguinte forma:
Análise diagnóstica
Examina os dados do passado para responder a perguntas como “O que aconteceu?”, caracterizando a questão sobre os
produtos mais vendidos no verão, como no exemplo do supermercado.
Análise descritiva
Examina os dados para responder perguntas como: “O que aconteceu?” ou “O que está acontecendo?”. Um exemplo disso é a
análise semanal de vendas.
Análise preditiva
Utiliza técnicas de mineração de dados e se baseia nos dados do passado para responder perguntas sobre o que acontecerá.
Análise prescritiva
É considerada uma análise mais avançada, na qual os dados são analisados para determinar ações que podem ser tomadas
para que algo aconteça.
Exemplo: “O que pode ser feito para que a venda de produtos do setor de higiene pessoal seja alavancada?”
A análise prescritiva utiliza análise gráfica, simulação, processamento de eventos complexos, redes neurais, motores de
recomendação, heurística e aprendizagem de máquinas.
A forma de analisar os dados está relacionada aos objetivos da organização, cujo interesse é visualizar os dados relevantes para
facilitar a tomada de decisão.
Data Warehouse (DW)
Sistema de Informação Gerencial (SIG)
Conforme Laudon e Laudon (2014), os objetivos de um Sistema de Informação Gerencial (SIG) em uma organização
são:
Obter a excelência operacional;

Desenvolver novos produtos, serviços e modelos de negócio;
Estreitar o relacionamento com os clientes e fornecedores;
Melhorar a tomada de decisão;
Obter vantagem competitiva;
Sobreviver.
O SIG disponibiliza relatórios para usuários no nível de gerente que possuem objetivos mais específicos.
Sistemas de Apoio à Decisão (SAD)
Já os Sistemas de Apoio à Decisão (SAD) são baseados em conhecimentos que apoiam a tomada de decisão nas
organizações com ferramentas de análises e visão por diferentes perspectivas de análises. Eles processam grandes
volumes de dados, consolidam e disponibilizam ambientes analíticos com consultas em formato de relatórios e
dashboards.
Sistema de Informação Executiva (SIE)
Há i d Si t d I f ã E ti (SIE) d ti d àt d d d i ã d ti d S
Há ainda o Sistema de Informação Executiva (SIE), destinado à tomada de decisão dos executivos da empresa. Suas
análises são mais resumidas e a interface de análise é mais fácil e objetiva.
Os três tipos de sistemas de informação gerencial possuem o objetivo de apoiar a tomada de decisão, cada qual destinado a um
público específico.
O Data Warehouse (DW) é um sistema de informação gerencial focado no apoio à tomada de decisão, que, normalmente, é realizada
pelos gestores da organização. O conceito Data Warehouse (DW) ou armazém de dados surgiu entre os anos 1980 e 1990, com o
trabalho desenvolvido pelos pesquisadores Devlin e Murphy (1988), com o nome Business Data Warehouse (BDW), que buscava
integrar dados para apoiar as análises sobre os dados de uma organização.
Comentário
Apesar de Bill Inmon já usar o termo Data Warehouse nos anos 1970 (KEMPE, 2012), o artigo citado (DEVLIN; MURPHY, 1988)
descreveu o problema a ser resolvido e a solução a ser implementada para a integração dos dados empresariais. Posteriormente,
Inmon difundiu o conceito do Data Warehouse e hoje é conhecido como o pai do DW. O professor Ralph Kimball também é uma
referência no conceito de Data Warehouse e possui uma abordagem de implementação diferente da apresentada por Inmon
(KIMBALL, 1998).
Abordagem de Inmon (top-down)

A abordagem de Inmon (top-down) parte de uma estrutura que abrange amplamente os assuntos contidos em uma organização (DW).
A partir dessa visão, os Data Marts (DM), que serão detalhados mais adiante, são desenhados (INMON; IMHOFF, 2001).
Abordagem de Kimball (bottom-up)

A abordagem de Kimball (bottom-up) se dedica a criar visões menores com os Data Marts (DM) e, depois, integrar esses módulos,
resultando no Data Warehouse (DW) organizacional.
A imagem a seguir apresenta as abordagens defendidas pelos dois autores:
Abordagens de projeto de DW.
Atenção
A escolha da abordagem a ser implementada por uma organização ocorre conforme a sua necessidade de análise. Contudo, muitas
vezes, a abordagem bottom-up é escolhida por ser mais fácil de implementar, explorando um assunto por vez e evoluindo com o
desenvolvimento dos Data Marts até que se obtenha o Data Warehouse desejado.
Data Mart (DM)
O Data Mart é um armazém de dados focado em um assunto da organização. Ele é um subconjunto de um Data Warehouse. O Data
Warehouse é formado por vários Data Marts ligados por perspectivas de análises em comum. Para uma implementação mais rápida
do ambiente analítico, ele pode ser construído por Data Mart.
Nesse caso, é importante compreender o Data Mart como parte de um todo (DW) que será integrado aos
demais assuntos, fornecendo análises para toda a organização.
Agora, vamos analisar o cenário hipotético de um estudo de caso: uma locadora de veículos.
Cenário de análise: locadora de veículos

Com o objetivo de prestar um excelente serviço aos seus clientes, uma locadora de veículos mantém um portfólio de veículos 0 Km
ou com até um ano de uso para alugar aos seus clientes. Ao completar um ano de uso, os veículos são vendidos, e novos veículos são
comprados para a reposição.
Para aumentar os lucros e fidelizar os clientes, oferecendo benefícios em seus aluguéis, a locadora deseja conhecer quais são os
clientes que alugaram veículos nos últimos seis meses, pelo menos uma vez por mês. Para isso, foi construído um ambiente de
análise com o Data Mart AlugueDM, tornando possível responder à pergunta sobre os clientes, conforme observado na imagem a
seguir.
Data Mart dos clientes fidelizados.
Com o passar do tempo, a locadora sentiu a necessidade de responder à outra pergunta:
Os clientes que compraram carros conosco participam do programa de fidelidade?
Para responder a essa pergunta, foi construído o Data Mart VendaDM, conforme observado na imagem a seguir.
Data Mart da venda de veículos usados
O Data Mart VendaDM possui a mesma perspectiva de análise que o Data Mart AlugueDM. Essa perspectiva é a visão de cliente. Com
a perspectiva de análise em comum nos dois Data Marts, é possível relacioná-los e analisar as informações de aluguel e venda de
veículos para os clientes da locadora, conforme observado na imagem a seguir.
Relacionamento dos Data Marts.
Com o exemplo da locadora de veículos, é possível verificar que o Data Warehouse e o Data Mart fornecem análises gerenciais que
facilitam e melhoram a performance das atividades das organizações com análises consistentes ao longo tempo.
Principais características do Data Warehouse/Data Mart

O Data Warehouse/Data Mart é orientado a assunto, possui dados integrados, não é volátil e apresenta análises ao longo do tempo. À
diferença dos sistemas transacionais, que são orientados a aplicações, como estoque e faturamento, o DW/DM se preocupa com os
principais assuntos da organização.
Vejamos algumas de suas características:
O processo de extração captura dados de diversas fontes, aplica tratamentos, padroniza e integra os dados, fornecendo consultas por
diferentes visões de análises.
Nos ambientes analíticos, ao carregarmos os dados no DW/DM, eles não sofrerão atualizações, garantindo, assim, que uma mesma
consulta feita no mês passado e hoje apresentarão o mesmo resultado. Nos sistemas transacionais, por sua vez, os dados sofrem as
operações básicas de inclusão, alteração e deleção de registros.
O DW/DM permite análises ao longo do tempo. A visão Tempo é muito importante no ambiente analítico, pois os dados históricos são
referentes a um momento no tempo. É essa característica que permite avaliar, por exemplo, qual foi o percentual de crescimento de
vendas de produtos do setor de higiene pessoal no primeiro trimestre do ano em relação ao primeiro trimestre do ano passado.
eleção
Remoção, perda, destruição.
Além das características principais, os sistemas DW/DM diferem dos sistemas transacionais por:
1. Apresentarem consolidação dos dados.
2. Serem voltados aos gestores da organização que atuam na tomada de decisão.
3. Acessarem grandes quantidades de linhas para montar as consultas.
4. Possuírem redundância dos dados.
Os sistemas transacionais possuem dados detalhados e são usados, principalmente, pelos usuários que, por exemplo, ao realizarem
atendimento ao público ou controle de estoque, acessam poucas linhas por transação e são normalizados.
Sistemas de Apoio Operacional X Sistemas de Apoio à Decisão

Um sistema de informação necessita apoiar os diferentes níveis de tomada de decisão, devendo, portanto, prover suporte aos
diversos tipos de decisão, conforme ilustrado na imagem a seguir:
Níveis de decisão.
Sistemas de Apoio Operacional

Os Sistemas de Apoio Operacional utilizam um tipo de processamento conhecido como On-Line Transaction Processing (OLTP) ou
Processamento de Transações On-line. São normalmente usados pelos gerentes operacionais para realizar as atividades diárias da
organização, como os sistemas integrados de gestão. Eles buscam responder a perguntas de rotina, registrando os eventos ocorridos
a cada operação realizada.
Exemplo
O sistema de apoio ao fluxo de vendas do cenário de análise de um supermercado recebe todas as ocorrências de eventos de
compras realizadas pelos clientes em várias lojas físicas e pelo e-commerce.
Todas as operações de inclusão, alteração e deleção de registros ocorrem durante o período do atendimento ao cliente. Assim, esse
sistema deve estar disponível para que a operação do supermercado não seja prejudicada. Em outras palavras, não pode haver
concorrência de acesso aos dados, gerando lentidão a esse ambiente.
As análises realizadas nas bases de dados dos Sistemas de Apoio Operacional são pontuais e coletam poucos registros por vez.
Exemplo
Quais foram os produtos que o cliente João comprou hoje na loja física?
Seu funcionamento é baseado em consultas ao banco de dados da empresa, que são formuladas por critérios predefinidos e
altamente estruturados.
Caso seja necessário analisar o volume de compras efetuadas pelo cliente João nos últimos dois anos, nas lojas física e pelo e-
commerce, isso não será possível. O volume de dados a ser analisado é muito grande para concorrer com as operações que estão
sendo realizadas no Sistema de Apoio Operacional (transacional).
Sistemas de Apoio à Decisão

Os Sistemas de Apoio à Decisão ou On-Line Analytical Processing (OLAP) são mais adequados para lidar com decisões não rotineiras,
pois visam gerar informações e conhecimentos para a resolução de problemas, para os quais não existe um procedimento
previamente definido.
Saiba mais
Além das informações internas de outros sistemas organizacionais, os SADs buscam fontes de dados externas, como as cotações
das bolsas de valores e os preços dos concorrentes. Esses sistemas são usados pelos gerentes de nível mais alto, que usam técnicas
analíticas e modelos estatísticos e matemáticos sofisticados para produzir conhecimento.
Nesse ambiente analítico, os dados ficam disponíveis para responder às perguntas com eficiência sem concorrer com as operações
transacionais da organização. Em um Data Warehouse/Data Mart, as análises históricas são respondidas com bastante eficiência,
pois sua arquitetura é projetada para explorar grandes volumes de dados, como veremos no próximo módulo.
video_library
Principais características de sistemas de BI
No vídeo a seguir, abordamos os conceitos basilares de sistemas de Business Intelligence. Vamos lá!
Falta pouco para atingir seus objetivos.
Questão 1
Sobre o conceito de Business Intelligence (BI), que tem como objetivo fornecer análises para a tomada de decisão em
organizações privadas ou públicas, é possível afirmar que:
A É um sistema que fornece relatórios sobre os dados produzidos pela organização.
B É uma ferramenta que transforma os dados para a construção das análises solicitadas pela organização.
É um conjunto de técnicas e ferramentas que dão suporte à criação de um ambiente analítico, no qual as análises
C
podem ser feitas por meio de relatórios e dashboardss.
D É uma ferramenta de criação de dashboardss com as possíveis análises que a organização possa precisar.
É um ambiente que fornece análises somente sobre os fatos que estão ocorrendo atualmente na organização,
E
como, por exemplo, “Quantos produtos foram vendidos essa semana?”.
O conceito de Business Intelligence (BI) fornece apoio à construção do conhecimento para a tomada de decisão, utilizando um
conjunto de técnicas e ferramentas que coletam, integram e organizam os dados, com os tratamentos necessários, e
disponibilizam informações que darão suporte às decisões estratégicas da organização.
Questão 2
Sobre as características do Data Warehouse, é possível afirmar que:
A É orientado a assunto, não integra dados, é não volátil e apresenta dados históricos.
É orientado a assunto, possui dados integrados, que são alterados ao longo do tempo, e apresenta dados
B
históricos.
C Possui foco departamental, não integra dados, é não volátil e apresenta dados históricos.
D É orientado a assunto, possui dados integrados, é não volátil e apresenta dados históricos.
E Possui foco departamental e dados integrados, é não volátil e apresenta dados históricos.
O Data Warehouse é orientado a assunto, integra dados de vários sistemas, não é passível de alterações dos acontecimentos
passados e armazena dados históricos, possibilitando análises ao longo do tempo.
starstarstarstarstar
2 - Projeto de Data Warehouse

Ao final deste módulo, você será capaz de reconhecer a arquitetura e o ciclo de vida de um projeto de Data
Warehouse.
Ligando os pontos
Você sabe o que é Data Warehouse? Quais são os benefícios do Data Warehouse para um negócio? Vamos entender melhor esse
conceito na prática.
O Data Warehouse (DW) é um sistema que concentra dados de diferentes fontes de forma estruturada e é usado para fornecer
subsídios às análises que serão realizadas posteriormente pelas técnicas de BI. Portanto, estamos falando sobre ter uma política de
gerenciamento de dados. Não há como obter sucesso na aplicação de técnicas de BI sem ela.
O DW não é uma fonte primária, e sim o resultado da combinação e do tratamento de diversas fontes que são relevantes para o
negócio. Um processo muito comum para construí-lo é aplicar técnicas de ETL, que, basicamente, é formado de três etapas distintas:
E = extração dos dados

T = transformação dos dados
L = carga dos dados
Resumindo, significa obter os dados já mapeados de uma fonte que pode ser formada de tabelas ou arquivos, submetê-los a um
processo de transformação, convertendo-os em um formato padronizado, e salvar esses dados no DW. Existem muitas ferramentas
para essa finalidade como, por exemplo, SAP BODS e Pentaho.
Alguns aspectos fundamentais do gerenciamento do ciclo de vida do DW são a organização e a confiabilidade dos dados, a
periodicidade com que são incrementados e utilizados, e a segurança da informação.
Em especial, devemos olhar com cuidado a segurança da informação, pois os dados do DW são o resultado de um processo de
transformação, ou seja, já há valor agregado. Então, uma violação de segurança pode causar muitos danos. Por isso, as empresas de
médio e grande porte que trabalham com serviços on-line podem ter muitas vantagens ao utilizar o DW.
Um processo de descoberta de conhecimento em banco de dados é chamado de Knowledge Discovery in Databases (KDD). Consiste
no estudo dos dados e como se relacionam de forma a compreender padrões sobre os perfis dos clientes, periodicidade de consumo
de serviços e outras características que ajudem a melhorar o desempenho do negócio.
Questão 1
Você já sabe que manter um DW é fundamental para aplicar técnicas de BI. Nesse sentido, que aspecto sobre o DW é essencial?
A A fonte primária dos dados.
B A possibilidade de ser não estruturado.
O fato de corresponder a uma tecnologia que só pode ser aplicada por alguns fornecedores de sistemas
C
gerenciadores de banco de dados.
D A dependência de uma linguagem de programação.
E A necessidade de uma política de segurança de acesso e gerenciamento de ciclo de vida dos dados.
Os dados que o DW armazena são resultado de um processo de extração de diversas fontes, transformação e carga em um
repositório estruturado que será utilizado por outras etapas para aplicação das técnicas de BI. Portanto, devem ser protegidos e
ter seu ciclo de vida gerenciado por políticas bem definidas.
Questão 2
Uma importante técnica para obter informações relevantes que deem apoio à tomada de decisão é a KDD. Para que ela possa ser
aplicada, é necessário ter um DW confiável. Nesse contexto, que exemplo de resultado pode ser obtido por uma técnica de KDD?
A A lista de nomes e idade de todos os clientes do banco de dados.
B O volume de dados de todas as tabelas do DW.
C As pessoas com qualificação em BI que são grandes consumidores de novas tecnologias no mês de novembro.
D As políticas de segurança de informação para gerenciar um DW.
E Os serviços oferecidos por determinada empresa.
A KDD é caracterizada pela descoberta não trivial de como os dados se relacionam. Portanto, não é o resultado de uma consulta
simples em uma tabela do DW. Os resultados que esperamos de uma técnica de KDD é a descoberta de perfis de usuários,
periodicidade e relacionamento entre eventos. No caso em questão, a KDD relacionou determinada qualificação com o consumo
de um tipo de produto em determinado mês do ano.
Questão 3
Considere o seguinte cenário: você foi designado para gerenciar a etapa de ETL para fornecer dados a um DW que já está em
operação. Logo depois que assumiu a função, você descobriu que os programas de conversão possuem muitos problemas, apesar de
estarem funcionando corretamente. Nesse contexto, que estratégia você adotaria para melhorar a qualidade desses programas?
Em time que está ganhando, não se mexe, certo? Bem, não é esse o caminho que devemos adotar. É claro que não devemos
chegar a um projeto e fazer modificações profundas logo no início, em especial quando já exista uma rotina que, apesar de ser
problemática, funcione. No entanto, também não devemos deixar o problema continuar e gerar danos que possam ser muito
prejudiciais. O ideal é mapear todos os programas de conversão, qualificar e conscientizar o time nas melhores práticas de
desenvolvimento e, passo a passo, melhorar e testar cada um dos programas para evitar transtornos no futuro. Nunca devemos
esquecer que a BI depende de dados confiáveis.
Arquitetura do Data Warehouse

O Data Warehouse pode ser construído com uma visão integrada de Data Marts ligados por perspectivas comuns dentro da
organização, ou por Data Marts, de forma independente, que tratam assuntos mais específicos.
A construção do DW/DM envolve alguns pontos que devem ser considerados pela organização, como a infraestrutura disponível, o
escopo, a disponibilidade dos dados e os profissionais capacitados que executarão as atividades relacionadas à arquitetura do
ambiente.
Um projeto de construção de um DW/DM é composto por alguns passos importantes. São eles:
1. Entendimento do negócio
Levantar os requisitos para conhecer a necessidade da organização é um passo fundamental para o início de um
projeto de DW/DM. O escopo a ser definido deve conter as análises desejadas pela organização para as perspectivas
de análises e os indicadores que serão analisados. É necessário definir o grão que será analisado no ambiente e
entender como o tempo deve se comportar no ambiente a ser criado.
2. Mapeamento dos dados
Esse passo verifica a disponibilidade e a viabilidade dos dados necessários para a construção das análises.
3. Construção da área de manobra dos dados (staging area)
Área em que os dados são armazenados temporariamente para que sejam tratados.
4. Construção do processo ETL (Extract, Transform and Load)
Processo de extração de dados das fontes de origem, transformação dos dados para adequar à análise e carga dos
dados no DW/DM.
5. Construção das análises
Especificação e desenvolvimento de consultas, relatórios, aplicativos de análise e outros componentes das aplicações
de BI.
rão
Nível de detalhamento dos dados.
Saiba mais
Grão: Nível de detalhamento dos dados.
Segundo Kimball e Ross (2013), a arquitetura de um DW/DM possui quatro componentes distintos no ambiente de BI:
Fontes de dados transacionais (source transactions);

Sistema ETL (ETL system);
Área de apresentação dos dados (presentation area);
Aplicações de BI (BI applications).
A imagem a seguir apresenta esses componentes:
Elementos centrais da arquitetura DW/BI.
Fontes de dados transacionais (source transactions)
As fontes de dados são, em geral, provenientes de sistemas transacionais da organização, que contêm elementos de dados de onde
informações possam ser extraídas e analisadas.
Os sistemas transacionais são aqueles que interessam para a análise de dados, como, por exemplo: sistemas de vendas, contas a
pagar e a receber, folha de pagamento, controle de estoque, controle de crédito. Esses dados são conhecidos como estruturados, ou
seja, é possível recuperar o conteúdo a partir de uma estrutura previamente estabelecida e padronizada.
No entanto, outras fontes de dados, como planilhas em Excel, documentos em Word, log file (arquivos de log), menções em redes
sociais, arquivos de áudio, arquivos de imagens podem ser utilizados na análise. Essas fontes são denominadas semiestruturadas ou
não estruturadas, pois possuem pouco ou nenhum padrão inicialmente preestabelecido e seu tratamento é mais complexo. Esses
dados podem conter conhecimento extremamente valioso para o negócio.
Sistema ETL (ETL system)
O sistema ETL é definido por Kimball e Ross (2013) como um ambiente composto por uma área de trabalho, estruturas de dados
instanciadas e um conjunto de tarefas organizadas em três etapas: extração, transformação e carga.
og file (arquivos de log)

Arquivo, em geral com extensão .log, que contém registro de eventos e ocorrências em um sistema de computação.
Extração
A extração é a etapa que coleta os dados, identifica-os, copia os que são necessários para as análises e armazena esse conjunto
de dados em uma base de dados temporária. Além das fontes de sistemas transacionais, outras fontes de dados podem ser
consideradas, como dados semiestruturados (arquivos XML, JSON) e dados não estruturados (texto). Essas fontes podem
complementar as análises de DWs/DMs ou ainda compor Data Marts baseados apenas em dados extraídos de fontes de dados
não estruturados.
Transformação
A transformação dos dados consiste em aplicar tratamentos para limpar e padronizar os dados, colocando-os em conformidade,
converter campos numéricos, formatar datas, integrar dados, aplicar metadados em dados não estruturados etc.
Essa etapa contribui com a melhoria dos sistemas transacionais, apontando inconsistências que possam ser encontradas nos
dados que foram extraídos. Devido ao grande volume de dados manipulados, é inviável que, a cada problema encontrado, o
analista responsável pelo DW/DM informe ao sistema transacional. Para resolver esse problema, há mecanismos de controle de
carga/log que registram as inconsistências e que podem ser consultados conforme a necessidade.
Carga
A carga dos dados ocorre após a transformação. Eles são inseridos na estrutura definitiva, representada pela área de
apresentação do DW/DM, onde são acomodados de forma organizada no modelo de dados multidimensional definido para o
DW/DM.
Área de apresentação dos dados (presentation area)
A área de apresentação é o local onde os dados estão organizados no modelo dimensional e disponibilizados para usuários e
aplicações de BI. Nesse momento, os dados estão prontos para uso e podem ser consumidos pela organização para apoiar a tomada
de decisão.
Aplicações de BI (BI applications)

As aplicações de BI consultam os dados que estão organizados na área de apresentação dos dados. Por meio das aplicações de BI,
os usuários podem desenvolver suas análises ou utilizar relatórios e dashboards prontos, desenvolvidos conforme a necessidade dos
usuários.
Metadados do Data Warehouse/Data Marts

O banco de metadados, construído com o ambiente do DW/DM, é um ativo importante tanto para a equipe de BI quanto para os
usuários da organização, pois mantém informações importantes sobre os dados contidos no ambiente, permitindo a identificação
dos dados, como nome, tipo, tamanho. Esse conjunto de informações (dados sobre os dados) é conhecido como dicionário de dados.
Além dessas informações, são armazenados os tratamentos aplicados, o relacionamento entre os dados, o entendimento de
conceitos e definições de negócio, a verificação das regras de negócios aplicadas e todas as demais informações importantes para o
desenvolvimento desse ambiente.
Kimball e Ross (2013) afirmam que os metadados são análogos à enciclopédia do DW/BI. Por isso, o analista deve estar atento para
povoar e manter o repositório de metadados.
Barbieri (2020) explica que os metadados definem os dados sob várias óticas, tais como:
Características daquilo que está se contextualizando

Nome, peso, tipo, comprimento, formato, altura, distância, preço etc.
Relacionamentos
“Trabalha para”, “mantido por”, “tem como gestor(es) o(s”), “localizado em” etc.
Formas de tratamento
Fórmulas, cálculos, manipulações, procedimentos etc.
Regras
Obrigatoriedade de presença dos dados naquele contexto, regras de qualidade exigidas para formas, valores, conteúdos etc.
Informações históricas
“Inventado em”, “descoberto por”, “desativado em” etc.
A principal vantagem de trabalhar com os metadados é o fato de que todas as informações importantes estão armazenadas e podem
ser consultadas sempre que for necessário.
Data Warehouse/Data Marts Self-Service

A arquitetura tradicional de um Data Warehouse/Data Mart fica sob os cuidados dos analistas de BI, que têm como objetivo manter
um ambiente de dados consistente e confiável, disponibilizando análises para os usuários, ou para que as aplicações de BI e usuários
avançados realizem as análises conforme a necessidade.
Esse fluxo de atividades é apoiado por um conjunto de tarefas de entendimento, levantamento de requisitos e documentação,
realizado pelos analistas de BI. Tais artefatos geram um banco de metadados sobre o ambiente analítico com informações
importantes sobre o conhecimento produzido neste.
Comentário
Apesar de o atendimento e a atuação da equipe de BI serem eficientes quanto à entrega de um ambiente controlado, assistido e
apoiado por metadados, em organizações onde a demanda é muito volumosa e a equipe de BI não consegue atender às
necessidades dos usuários de forma rápida, surge a necessidade de um modelo Self-Service, no qual o usuário pode acessar,
modelar e analisar os dados sem o auxílio da equipe de BI.
Com essa forma de acesso aos dados, os usuários podem gerar suas análises de maneira mais rápida, obtendo os resultados
desejados com um tempo inferior ao atendimento do analista especializado em BI. No entanto, apesar de o modelo Self-Service
oferecer maior rapidez na confecção das análises pelos usuários, alguns pontos de atenção devem ser observados. São eles:
Nesse modelo, os dados ficam descentralizados, onde cada usuário cria seu próprio conjunto de dados e aplica regras de negócio sob
seu ponto de vista.
Não há o desenvolvimento dos metadados do ambiente.
A falta de tratamento e observação das inconsistências de dados pode apresentar resultados errados.
Análises sobre o mesmo assunto podem apresentar resultados diferentes, prejudicando a tomada de decisão.
Mineração de dados e Descoberta de Conhecimento em Bases de

Dados (KDD)
O Data Warehouse disponibiliza uma base de dados organizada com diversas perspectivas de análises ao longo do tempo. Esse
repositório de dados oferece consultas predefinidas e análises no formato Self-Service.
Além dessas possibilidades, ir em busca da descoberta de conhecimento e da mineração de dados é uma das etapas da Descoberta
de Conhecimento em Bases de Dados, ou Knowledge Discovery in Databases (KDD), e está relacionada com o Data Warehouse no
que diz respeito a dados tratados e disponíveis para análises, pois o DW pode fornecer dados para os processos de KDD, gerando
valor para a organização. Porém, lembre-se: uma solução não substitui a outra. Elas são complementares no processo de busca pelo
conhecimento.
Essas técnicas podem revelar padrões de comportamento, auxiliando a tomada de decisão. No cenário de análise do supermercado,
o DW fornece consultas sobre o volume de compras realizadas pelos clientes, e os processos de KDD podem descobrir padrões
existentes nas compras realizadas.
Vejamos alguns exemplos:
Exemplo 1
Você já ouviu falar sobre a relação da fralda descartável com a cerveja?
Apesar de não haver uma fonte confiável que valide essa descoberta, é um fato muito conhecido no mundo de BI e interessante
para ser analisado.
Um grande varejista dos EUA, observando os padrões de compra de seus clientes, verificou que o aumento da venda de fraldas às
sextas-feiras estava relacionado à venda de cerveja, e, na maioria das vendas, os clientes eram do sexo masculino. A explicação
para esse fato curioso é que os papais iam comprar fralda para seus pequenos e acabavam levando a cerveja para seu final de
semana.
De posse desse conhecimento, o varejista posicionou estrategicamente as fraldas ao lado das cervejas para aumentar os lucros.
Exemplo 2
Outro exemplo voltado ao bem-estar de pacientes e com foco na diminuição de gastos é a descoberta antecipada de possíveis
cirurgias de alto risco realizadas por pacientes que possuem problemas relacionados à coluna. O estudo sobre a recorrência de
consultas com ortopedistas e as ocorrências de exames correlacionados e terapias dedicadas a essa patologia pode sinalizar
futuras cirurgias.
Com esse conhecimento, os gestores responsáveis pelo acompanhamento clínico dos pacientes podem oferecer tratamentos
direcionados e efetivos para que cirurgias desnecessárias não sejam realizadas, reduzindo os riscos ao paciente e diminuindo os
gastos com internações.
Ciclo de vida do Data Warehouse

O Data Warehouse coleta, trata e armazena os dados mais relevantes para uma organização, com o objetivo de apoiar a tomada da
decisão. A implementação desse ambiente está relacionada à necessidade da organização de unificar os dados para analisá-los
historicamente, a fim de observar seu comportamento ao longo do tempo ou mapear futuros comportamentos no negócio.
Atenção
Sua implementação deve se preocupar com os recursos disponíveis para sua concepção, de modo que o resultado seja alcançado.
Além disso, é muito importante que o objetivo da construção esteja bem definido e seja orientado às necessidades dos usuários da
organização, à disponibilidade de recursos e dos dados. A construção do DW deve considerar esses pontos e ter um plano de
desenvolvimento para que os objetivos sejam alcançados.
O desenvolvimento de um projeto é dividido em fases e possui um início e um fim. Para iniciar qualquer atividade que envolva várias
fases, você precisa planejar a execução dessas fases, como ilustrado na imagem a seguir:
Arquitetura Seleção e instalação

Crescimento
tecnológica dos produtos
Definição
Planejamento do dos Especificação e
Modelagem Implantação
requisitos Projeto físico desenvolvimento
projeto dimensional
de negócio de ETL
Especificação da Desenvolvimento da
aplicação de BI aplicação de BI Manutenção
Gerenciamento do projeto
Ciclo de Vida de um Projeto de Data Warehouse.
Primeira fase: Planejamento
O planejamento do projeto é a primeira fase do ciclo de vida de um projeto de DW. Nessa fase, são definidos o escopo do projeto, a
viabilidade de recursos, as tarefas a serem desenvolvidas no projeto e o encadeamento delas.
Saiba mais
Kimball e Ross (2013) afirmam que um bom planejamento e a definição bem elaborada dos requisitos aumentam a probabilidade de
sucesso de um projeto de DW, pois seu desenvolvimento é baseado nas necessidades dos usuários do negócio. Isso apoia a
importância dessas duas fases para o desenvolvimento do DW.
Segunda fase: Definição dos requisitos de negócios

A segunda fase do ciclo de vida é a Definição dos requisitos de negócios e está diretamente relacionada à primeira fase, devido à
necessidade do conhecimento dos requisitos, pois o escopo do projeto é definido pelos requisitos do usuário. A relação entre essas
duas fases é representada na imagem pela seta de mão dupla (↔).
Saiba mais
Kimball e Ross (2013) afirmam que um bom planejamento e a definição bem elaborada dos requisitos aumentam a probabilidade de
sucesso de um projeto de DW, pois seu desenvolvimento é baseado nas necessidades dos usuários do negócio. Isso apoia a
importância dessas duas fases para o desenvolvimento do DW.
Terceira fase: Desenvolvimento
Observe que o ciclo de vida do projeto, após a definição dos requisitos do negócio, é dividido em três trilhas
distintas da fase de desenvolvimento.
Trilha tecnológica
A primeira trilha se dedica às tecnologias que serão utilizadas no desenvolvimento do DW.
Atenção
A etapa arquitetura tecnológica se preocupa com a definição estrutural e compreende os componentes necessários à implementação
de um DW. Esses componentes estão relacionados à arquitetura de dados, à infraestrutura utilizada e às tecnologias necessárias na
construção e utilização de um DW.
Essa etapa é seguida da seleção e instalação dos produtos, que define as ferramentas que serão utilizadas na construção, realiza a
instalação, faz o teste de integração e as executa.
Trilha de dados
A segunda trilha se dedica ao tratamento dos dados e encadeia as fases: modelagem dimensional, projeto físico e especificação e
desenvolvimento de ETL.
Modelagem Dimensional
A etapa modelagem dimensional estuda as análises que serão desenvolvidas no ambiente analítico e une o conhecimento dos
requisitos definidos para criar uma estrutura capaz de acomodar os dados dimensionalmente. Nessa etapa, é definido o modelo de
dados dimensional do DW/DM.
Projeto Físico
Na etapa seguinte, projeto físico, é definida a estrutura física para a construção do modelo de dados dimensional, como a definição do
padrão de nomenclatura utilizada e a configuração do ambiente do banco de dados.
Especificação e Desenvolvimento de ETL

Após a definição da estrutura física da base de dados, é o momento de definir e construir os processos que extrairão os dados dos
sistemas origens, transformar e carregar os dados nas tabelas definitivas do DW. Esta é a etapa especificação e desenvolvimento de
ETL.
O tamanho das caixas de cada etapa não representa o esforço realizado em cada uma delas. A construção
do ETL é uma tarefa muito custosa, que demanda aproximadamente 70% do esforço empregado na trilha
de dados.
Trilha da aplicação de BI
A terceira trilha do ciclo de vida está concentrada na definição e construção da camada de visualização
dos dados.
O desenho das consultas desejadas pelos usuários é um artefato muito interessante e contribui com o alinhamento das expectativas
dos usuários que acessarão o DW por meio de análises predefinidas. Essa definição é realizada na etapa de especificação da
aplicação de BI.
Seguindo a tarefa de especificação, a etapa desenvolvimento da aplicação de BI constrói as consultas na ferramenta de relatórios
analíticos definida para o projeto.
Quarta fase: Implantação
A fase de implantação é a união das tarefas desenvolvidas em cada trilha do ciclo e deve ocorrer quando todas as fases estiverem
concluídas. Novas necessidades surgirão após a implementação do ambiente analítico, o que faz parte do processo de
desenvolvimento e crescimento do DW de uma organização.
Quinta fase: Crescimento e manutenção

O crescimento é representado pela fase que inicia com o planejamento de um novo projeto, mas, nesse caso, será um projeto de
complemento.
Por fim, a manutenção é representada no ciclo de vida de um projeto de DW.
Neste módulo, foi abordada a arquitetura tradicional de um Data Warehouse, além de outras possíveis abordagens, e foram
apresentadas as fases do ciclo de vida de um projeto de Data WareHouse.
video_library
Arquitetura de Data Warehouse e ciclo de vida de projeto
Assista, no vídeo a seguir, a uma apresentação da arquitetura DW, na qual visitamos cada fase do ciclo de vida do projeto, culminando
com a ideia da sobreposição da arquitetura DW contida nesse ciclo de vida do projeto.
Questão 1
Metadados são muito importantes para sistemas de Business Intelligence (BI) e mantêm informações relevantes sobre os dados.
O banco de metadados de um projeto de BI:
A Documenta os processos de extração, conceitos e histórias dos usuários da organização.
Documenta os dados contidos no DW/DM, os tratamentos sobre os dados, o relacionamento entre eles, o
B entendimento de conceitos e definições e a verificação das regras de negócios aplicadas sobre os tratamentos
realizados.
Documenta os processos de extração, conceitos e definições de negócio e os erros que ocorrem nos sistemas
C
transacionais, que são fontes para os sistemas de BI.
Documenta o mapeamento dos processos de extração e os resultados obtidos pelas consultas, mas não registra
D
regras de negócio e conceitos.
Não apresenta conhecimento sobre o ambiente, e sim estatísticas das execuções de consultas realizadas pelos
E
usuários.
Os metadados de um projeto de BI documentam as informações sobre os dados, sobre o relacionamento do conjunto de dados
contido no DW/DM, os tratamentos aplicados, além das informações voltadas ao negócio.
Questão 2
O desenvolvimento de um projeto possui início e fim, além de ser dividido em fases. Em qualquer atividade composta por fases, é
necessário, inicialmente, planejar a execução dessas fases, com o objetivo de viabilizar que o projeto consiga ser, de fato,
implantado na organização. Dentre as diversas fases de um projeto, o planejamento é a primeira fase do ciclo de vida de um
projeto de Data Warehouse. Nessa fase, são definidos:
O escopo do projeto, o processo ETL, as tarefas a serem desenvolvidas no projeto e o mapeamento das fontes de
A
dados.
A viabilidade de recursos, as tarefas a serem desenvolvidas no projeto e o encadeamento delas e as consultas

B
predefinidas.
O escopo do projeto, a viabilidade de recursos, a matriz de granularidade e o encadeamento das atividades do

C
projeto.
D
O escopo do projeto, a viabilidade de recursos, as tarefas a serem desenvolvidas no projeto e o encadeamento

delas.
O escopo do projeto, a viabilidade de recursos, as tarefas a serem desenvolvidas no projeto e o encadeamento

E
delas.
Na fase de planejamento, deve ser considerado o escopo do projeto, no qual as necessidades dos envolvidos no negócio ―
denominadas requisitos do usuário ― são levantadas e servem para delimitar a abrangência do projeto, que tem de se manter
alinhado ao objetivo organizacional. Já a viabilidade de recursos, as tarefas a serem desenvolvidas no projeto e seu
encadeamento, que também ocorrem na fase de planejamento, servem como base para que, na fase do gerenciamento do
projeto, seja possível coordenar a devida condução e execução das tarefas, aumentando, assim, a probabilidade de sucesso do
projeto de DW.
3 - Requisitos e Fontes para Data Warehouse

Ao final deste módulo, você será capaz de descrever o processo de levantamento de requisitos e mapeamento de
fontes de dados para Data Warehouse.
Ligando os pontos
Você já ouviu falar sobre o conceito de granularidade de um Data Warehouse e como ele pode ajudar a melhorar o desempenho de
um negócio? Que estratégia você adotaria para implementar solução de BI usando um DW? Vamos entender melhor esses conceitos
na prática.
Para obtermos um bom resultado, precisamos estabelecer metas bem definidas. Para atingirmos as metas, precisamos cumprir uma
série de pré-requisitos. E tudo isso precisa ser acompanhado. É aí que entram os indicadores de desempenho, mais conhecidos como
KPIs (Key Performance Indicator). Por meio desses indicadores, podemos acompanhar o desempenho dos processos e atuar, quando
necessário, para corrigir falhas, ou melhorar processos que nos ajudem a atingir nossas metas.
Os KPIs são apenas mais um instrumento que a BI nos fornece para gerenciar com melhor transparência os processos. Portanto, eles
devem reproduzir esses processos. Outro ponto que devemos considerar é o nível de detalhe que esperamos desses indicadores. É o
que chamamos de granularidade.
Certamente, as informações que os membros da diretoria de uma empresa de vendas de produtos eletrodomésticos esperam ver são
muito mais agregadas do que o time da parte operacional. Esse exemplo nos ajuda a perceber que os indicadores podem ser
formados por outros indicadores em uma estrutura hierárquica que nos auxilia a detectar problemas.
O painel dos indicadores de desempenho é chamado de Dashboard. Aqui, cabe uma curiosidade: utilizamos esses nomes em inglês,
pois eles se popularizaram e são comumente referenciados em livros e artigos científicos.
Conhecer os KPIs, construir hierarquia de indicadores com diferentes níveis de granularidade, padronizar processos de análise e
desenvolver uma boa política de ciclo de vida de gerenciamento dos dados de um DW constituem-se elementos estruturais basilares
para uma aplicação bem-sucedida de técnicas de BI.
Questão 1
Você já sabe que é essencial conhecer os KPIs para escolher aqueles que fazem sentido em seu negócio. Suponha que você
tenha desenvolvido um projeto e pretenda usar um KPI como recurso de BI para melhorar a qualidade do gerenciamento. Nesse
caso, o KPI deve:
A ser mensurável.
B ser conhecido.
C estar relacionado a uma cadeia hierárquica.
D ser compreensível para todas as pessoas da empresa.
E ser compreensível, pelo menos, para a diretoria da empresa.
Um KPI, obrigatoriamente, deve ser mensurável. É fundamental que ele produza um número que auxilie o responsável a investigar
a ocorrência de problemas e que possa atuar para corrigi-lo. Para atingir esse objetivo, é basilar que os dados estejam
disponíveis no DW, pois eles são a fonte para calcular os KPIs.
Questão 2
A granularidade de um KPI é o resultado da estruturação hierárquica da informação que reflete os processos que estão sendo
monitorados. Considere que você seja o responsável por uma empresa que possui equipamentos pesados, como caminhões,
carregadeiras, tratores e escavadeiras aplicados para mineração de cobre. Nesse contexto, um KPI operacional é:
A a venda de cobre em determinados períodos do ano.
B o tempo médio entre falhas de equipamentos.
C o lucro anual da empresa com a produção de cobre.
D a aquisição anual de caminhões.
E o retorno médio do investimento em relação aos custos anuais.
Os KPIs ajudam a controlar as diversas partes de um negócio. Estruturá-los em níveis hierárquicos é muito útil para dar a visão
necessária a cada grupo de uma empresa, a fim de que possa agir conforme seu nível de responsabilidade. No caso em questão
– um exemplo de KPI operacional para uma empresa que trabalha com equipamentos pesados de mineração –, é essencial que a
equipe de operação tenha informações sobre o tempo médio de falha dos equipamentos para tomar decisões sobre quais devem
ir para a manutenção e que estratégias devem ser tomadas para atingir as metas de produção.
Questão 3
Considere o seguinte cenário: você foi contratado para gerenciar uma equipe responsável pela análise de KPIs do departamento de
desenvolvimento de software de uma empresa de grande porte. Ao assumir o cargo, você descobriu que o responsável anterior fazia
todo o controle usando planilhas eletrônicas, e que os dados não eram confiáveis. Além disso, os “KPIs” eram controlados por meio
de cores: vermelho é muito ruim, amarelo demanda atenção, e verde significa que está tudo bem. Quais escolhas você faria para
melhorar esse processo?
Nunca é uma boa prática chegar a um projeto e criticar quem estava à frente dele anteriormente. Em contrapartida, o cenário
descrito – que, infelizmente, é muito comum – demonstra claramente que não havia na empresa um projeto de BI. É bastante
habitual ver pessoas no mercado usando termos de BI sem fazer a mínima ideia do que estão falando.
O primeiro item que um sistema de BI precisa é de dados confiáveis. Esses dados devem estar organizados em um DW, e nunca
em planilhas. Além disso, o KPI deve ser mensurável, ou seja, deve produzir um número de dados que tenha significado, para
que os responsáveis possam atuar na correção de falhas quando for necessário. O BI tem como objetivo melhorar os processos
de um negócio, ou seja, jamais pode ser visto como um instrumento de punição. Portanto, no caso em questão, é essencial
elencar um plano para mapear processos, estruturar o DW e criar KPIs adequados com as devidas granularidades.
Análise de cenário de um projeto de Data Warehouse

Vamos analisar juntos um cenário hipotético de uma grande rede de fast-food.
Cenário 1
Marcos é gerente de vendas em uma grande rede de fast-food. Todos os dias, às 16 horas, ele precisa verificar se é necessário fazer a
reposição de algum item utilizado na confecção dos lanches da lanchonete. Se o item estiver com a disponibilidade comprometida,
ele deverá enviar a solicitação de reposição ao setor de reabastecimento, para que o item seja entregue na manhã seguinte.
Para fazer o controle dos itens, Marcos imprime a lista dos pedidos, conta a quantidade de lanches servidos em cada pedido e faz o
cálculo de kits utilizados, para saber se é necessário repor ou não algum item. Esse processo é tão custoso para Marcos que, há dias,
ele não consegue terminar a análise em tempo de solicitar os itens para o dia seguinte.
Qual é a solução mais adequada para ajudar Marcos?
Vamos analisar o problema:
Analisando o cenário
Qual é o problema de Marcos? expand_more
É a dificuldade em saber se é necessário ou não solicitar a reposição de itens, até às 17 horas, todos os dias da semana.
Qual é o objetivo de Marcos? expand_more
Saber se há necessidade de solicitar a reposição de algum item diariamente e fazer a solicitação dentro do prazo de forma
mais rápida.
De que forma Marcos faz a análise dos itens? expand_more
Ele verifica todos os pedidos e calcula a média, manualmente, dos itens utilizados, com o objetivo de saber se há algum item
que precisa ser reposto.
O que podemos oferecer para resolver o problema de Marcos?
Soluções propostas
Podemos propor como solução do problema de Marcos projetar um Data Mart e construir consultas, onde o menor nível de análise
estivesse em Mês.
Exemplo
Consulta de quantidade de itens por Mês.
Essa solução resolveria o problema de Marcos? Não resolveria!
Primeiramente, o tempo de desenvolvimento desse cenário poderia durar em torno de dois meses. A consulta por quantidade de itens
por mês pode até ser útil para outro tipo de tomada de decisão, inclusive para a melhoria do processo de Marcos, mas não para sua
necessidade atual.
Resposta
Uma investigação mais detalhada sobre o problema de Marcos permitiu verificar a solução mais adequada para resolver seu
problema. De acordo com a necessidade descrita anteriormente, um relatório no sistema de vendas fornecerá a informação sobre os
itens que precisam ser repostos.
Conclusão do cenário
Com a observação e análise do caso, é fácil concluir que o planejamento do projeto e o levantamento de requisitos produzem o
entendimento sobre a necessidade da organização e o conhecimento do objetivo para a construção do DW, que deve estar bem
definido e justificar essa necessidade.
Sem essas definições, o sucesso do projeto está comprometido, pois, se não houver um objetivo para tal solução, o ambiente não
será utilizado, ou sua construção poderá não ser finalizada.
Levantamento de requisitos para construção do Data Warehouse

Você já deve ter escutado comentários sobre um projeto que não deu certo, e o desenvolvimento foi cancelado, ou que o
desenvolvimento foi finalizado, mas os usuários não utilizaram o produto entregue.
Atenção
O entendimento sobre o problema a ser resolvido deve ser a primeira tarefa realizada para o desenvolvimento de um projeto, pois a
investigação permite conhecer o cenário, os stakeholders (partes interessadas), o problema e as possíveis soluções a serem
adotadas.
Essa primeira fase é o levantamento de requisitos e se aplica a qualquer tipo de projeto, inclusive ao projeto de DW.
O levantamento de requisitos para o DW possui características particulares em relação ao levantamento de requisitos para os
Sistemas de Apoio Operacional.
São elas:
Saiba mais
Levantamento de requisitos DW
1. Entender as necessidades do negócio (stakeholders)
2. Elaborar documento com perspectivas de análises (visões)
3. Elaborar documento com as medidas que serão analisadas (indicadores)
4. Elaborar documento que descreva as análises desejadas (consultas)
5. Elaborar documento com apontamento das origens dos dados
Essas características estão presentes em Sistemas de Apoio à Decisão (SAD). Vamos conhecê-las a seguir.
Passo 1: Entender as necessidades do negócio (stakeholders)
O entendimento da necessidade é realizado pelo analista de negócios. Ele é responsável por investigar a necessidade, entender as
dores dos usuários e traduzir o entendimento em requisitos para o projeto.
Kimball e Ross (2013) abordam o levantamento de requisitos focado na necessidade do negócio e afirmam que os requisitos
determinam quais dados devem estar disponíveis no DW, como são organizados e com que frequência são atualizados.
Dica
O primeiro passo é entrevistar os usuários e entender quais são as atividades realizadas por eles. Conhecer a atividade realizada pelo
usuário auxilia no entendimento do fluxo dos dados que será analisado. Você pode realizar reuniões mais específicas com usuários
individuais, pequenos grupos ou grupos que reúnem todos os interessados no desenvolvimento do DW. A estratégia pode ser traçada
conforme a necessidade.
O levantamento de requisitos é apoiado por técnicas que auxiliam a condução das entrevistas. Durante essa fase, as informações
coletadas devem ser anotadas. O resultado do levantamento conterá a descrição de cenário do negócio com as dores, os objetivos,
as análises desejadas etc.
Nas análises desejadas, podem ser identificadas as possíveis perspectivas de análise e os indicadores. As perspectivas de análise
descrevem os fatos que ocorreram em determinado assunto, e os indicadores são as medidas que podem ser descritas pelas
perspectivas de análise.
Atenção
Uma importante informação que deve ser verificada no levantamento de requisitos para o DW é a periodicidade com a qual os dados
serão carregados no ambiente. A periodicidade pode ser diária, semanal ou mensal, ou ainda quase que em tempo real. Essa decisão
depende da necessidade da organização.
Quando a carga dos dados ocorre diariamente, o processo de ETL acessa a base de dados do sistema transacional, todos os dias,
obedecendo a uma janela temporal para a extração dos dados. Normalmente, a extração ocorre no período em que as transações dos
sistemas de origem são diminuídas, como, por exemplo, à noite. Essa estratégia é usada para que a extração dos dados não concorra
com as operações transacionais, prejudicando o andamento das operações na organização.
Quando a carga é realizada mensalmente, o processo de ETL acessa a base de dados do sistema transacional após o fechamento
mensal do negócio, populando a base do DW apenas uma vez ao mês. Essa informação deve estar registrada no documento principal
de especificação do projeto.
Passo 2: Elaborar documento com perspectivas de análises (visões)

Todo entendimento deve ser documentado para que os demais analistas tenham acesso às informações do projeto. Normalmente,
cada organização usa uma metodologia que melhor se encaixa às suas necessidades. No entanto, independente da metodologia
adotada, as perspectivas de análise precisam ser definidas e descritas. Elas são representadas pelas tabelas Dimensões do modelo
de dados do DW e contêm os dados que descrevem os fatos.
Vamos entender com um exemplo!
Cenário 2
Vamos relembrar o cenário de análise do supermercado.
Paulo e Ricardo são gerentes de uma grande rede de supermercados. Eles contrataram o desenvolvimento de uma solução que apoie
a tomada de decisão da organização.
Para entender as necessidades de Paulo e Ricardo, algumas reuniões de levantamento foram feitas com eles e com alguns usuários
que constroem análises gerenciais. Durante as reuniões, foram coletadas as seguintes informações:
opulando a Base
Inserindo dados nas tabelas que compõem a base.
1ª Característica
O supermercado possui um sistema de apoio ao fluxo de vendas que recebe todas as ocorrências de eventos de compras realizadas
pelos clientes em lojas físicas e pelo e-commerce.
2ª Característica
Todas as operações de inclusão, alteração e deleção de registros ocorrem durante o período do atendimento ao cliente.
3ª Característica
Sempre que uma venda ocorre, um serviço informa ao sistema de estoque quais produtos foram vendidos e a quantidade vendida.
Paulo e Ricardo precisam realizar as seguintes análises:
Quais são os produtos mais vendidos no verão?

Quais são os clientes com maior potencial de compras em determinado grupo de produtos?
O estoque está zerado?
Quais são os fabricantes dos produtos que oferecem maior lucro na comercialização de seus itens?
Perspectivas das análises

De acordo com o cenário 2, é possível entender que, para analisar quais são os produtos mais vendidos no verão, precisamos saber a
quantidade vendida de cada produto e em que momento ela ocorreu.
Comentário
Aqui, temos a visão Produto, a visão Tempo e a medida Quantidade de Produtos Vendidos. As visões Produto e Tempo descrevem a
medida Quantidade de Produtos Vendidos, ou seja, informam qual produto foi vendido e em que momento ele foi vendido.
Para acompanhar a venda de produtos e o estoque, identificamos, novamente, as visões Produto e Tempo. No entanto, precisamos
saber qual a Quantidade do Produto no Estoque. A Quantidade de Produto no Estoque é mais uma medida identificada.
Exemplo
As medidas são os fatos que ocorreram em determinado momento. Por exemplo, o produto foi vendido. O fato ocorrido é a venda do
produto. Nesse caso, além de sabermos que a venda ocorreu, também sabemos a quantidade que foi vendida.
Exemplo: “Foram vendidas 10 unidades do produto sabonete”.
Esse conceito será detalhado mais à frente.
Na última análise desejada pelos usuários, além da visão Produto, qual(is) outra(s) visão(ões) ou medida(s) pode(m) ser
identificada(s)? expand_more
Resposta: A visão Fabricante do Produto e a medida Lucro.
Contudo, durante o levantamento de requisitos, foi informado pelos usuários que o Lucro não está no sistema origem. Para obter o
lucro no final do mês, o valor da venda do produto é extraído por meio de um relatório do sistema SisVendas, assim como o preço do
produto comprado no fabricante é extraído do sistema SisEstoque. Com as duas informações em uma planilha, o lucro é calculado.
Aqui, temos uma medida calculada que precisa ser documentada com a fórmula de cálculo, para que seja possível apresentar o
resultado esperado.
Após identificar as visões de análise, é hora de documentar as informações obtidas sobre elas. Essas informações podem ser
verificadas com os gestores e aprofundadas com os analistas responsáveis pelos sistemas de origem (sistemas transacionais).
A Visão (Dimensão) contém os dados referentes ao domínio que está sendo tratado. Por exemplo, a visão Produto contém o código
do Produto, que é importante na identificação do produto no sistema origem, e a descrição do produto permite saber qual é o produto
analisado.
O quadro a seguir ilustra a documentação da visão Produto:
Visão de análise Atributo Conceito Exemplos Observação
Descreve os
- produtos do DW - -
Supermercado.
Códigos de produtos
Identifica que deixaram de ser
unicamente um comercializados não
Código do produto 1, 2, 3
produto no sistema podem ser
SisVendas. reutilizados em
novos produtos.
Nome do produto
Descrição do que está sendo Pode conter até 100
Detergente
Produto produto comercializado no caracteres.
SisVendas.
Fabricante do
produto que está
Fabricante do Pode conter até 200
sendo Limpa+
produto caracteres.
comercializado no
SisVendas.
Grupamento do
produto que está
Categoria do Pode conter até 50
sendo Limpeza
produto caracteres.
comercializado no
SisVendas.
Quadro: Visão da análise do produto.

Elaborado por: Vivian Gabriela Santos Monteiro.
A coluna Visão de análise contém o nome da visão, a coluna Atributo apresenta os dados referentes ao produto, e a coluna Conceito
descreve cada um dos atributos. O conceito é extremamente importante para um ambiente analítico, pois o usuário e os analistas
saberão o que é o dado, tanto na construção das análises quanto na manutenção do ambiente.
A coluna Exemplos contém alguns exemplos dos dados para auxiliar nas próximas etapas do projeto. A coluna Observação é livre
para adicionar comentários importantes sobre cada um dos dados, caso tenham, e regras de negócio que deverão ser aplicadas aos
dados.
Além das visões citadas, há mais duas importantes para o cenário. Você consegue identificá-las? expand_more
Resposta: Visões Cliente e Categoria do Produto.
Passo 3: Elaborar documento com as medidas que serão analisadas (indicadores)
Após a documentação das visões de análise, é hora de documentar as medidas, também conhecidas como indicadores. Os
indicadores são organizados em tabelas-fato, que registram os fatos ocorridos.
No cenário do supermercado, foram identificados os seguintes indicadores:
Quantidade de Produtos Vendidos;

Quantidade de Produto no Estoque;
Preço do Produto Vendido;
Preço do Produto Comprado do Fabricante;
Lucro do Produto Vendido.
O quadro a seguir ilustra a conceituação dos indicadores identificados durante o levantamento com os usuários:
Indicador Conceito Fórmula de cálculo Observação
Apresentar o cálculo da
Quantidade de Quantidade do produto Soma das unidades do
função soma de
Produtos Vendidos vendido em um pedido. produto.
quantidades vendidas.
Apresentar o cálculo da
Quantidade de Produto Preço do produto no Soma das unidades do
função soma de
no Estoque momento da venda. produto.
quantidades em estoque.
Preço do produto quando Apresentar o valor com

Preço do Produto
foi comprado do fabricante Não há. formatação de moeda e
Vendido
ou distribuidor. com duas casas decimais.
Preço do Produto Apresentar o valor com

Lucro obtido na venda do
Comprado do Não há. formatação de moeda e
produto.
Fabricante. com duas casas decimais.
Indicador Conceito Fórmula de cálculo Observação
Preço do Produto Vendido ‒ Apresentar o valor com

Lucro do Produto Lucro obtido na venda do
Preço do Produto formatação de moeda e
vendido produto.
Comprado do Fabricante. com duas casas decimais.
Quadro: Visão da análise do produto.

Elaborado por: Vivian Monteiro.
A coluna Indicador lista o nome dos indicadores, a coluna Conceito lista os conceitos ou as definições dos indicadores, a coluna
Fórmula de cálculo descreve como os indicadores devem ser calculados, e a coluna Observação contém informações adicionais.
Matriz de granularidade
Para facilitar o entendimento e a compreensão da relação entre as visões e os indicadores do DW/DM, temos a matriz de
granularidade. Em formato de matriz, são organizados as visões (atributos) e os indicadores que estão relacionados com essas
visões.
O quadro a seguir ilustra a relação entre as visões identificadas no levantamento e os indicadores que serão analisados nas consultas
predefinidas:
Visões
Venda ao cliente Estoque Cliente Produto Fabr
Descrição do produto
Código do fabricante
Código do produto
Número do cliente
Data do estoque
Nome do cliente
Mês do estoque
Ano do estoque
Data da venda
Mês de venda
Ano da venda
Indicadores
Quantidade
de
x x x x x x x x
produtos
vendidos
Quantidade
de
x x x x x x
produtos
no estoque
Preço do
produto x x x x x x x
vendido
x x x x x
Preço do
produto
Visões
Venda ao cliente Estoque Cliente Produto Fabr
comprado
do
fabricante
Lucro do
produto x x x x x
vendido
Quadro: Matriz de granularidade.

Elaborado por Vívian Monteiro.
Comentário
Como podemos observar, no eixo X da matriz, estão organizadas as Visões Tempo, Cliente, Fabricante e Produto. No eixo Y da matriz,
estão organizados os Indicadores Quantidade de Produtos Vendidos, Quantidade de Produto no Estoque, Preço do Produto Vendido,
Preço do Produto Comprado do Fabricante e Lucro do Produto Vendido.
De acordo com a matriz, sabemos que a Quantidade de Produtos Vendidos pode ser analisada pela data de venda do produto ao
cliente. Por exemplo, sabemos a quantidade de sabonetes vendidos no dia 20/08/2020, no mês 08/2020 ou ainda no ano de 2020.
Em nosso exemplo, há poucas visões e indicadores, o que facilita saber quais são os possíveis cruzamentos entre eles. No entanto,
no levantamento de um DW/DM real, há inúmeros cruzamentos, e a matriz permite a visualização das análises que serão possíveis no
ambiente analítico de forma mais simples e objetiva. Além disso, a matriz de granularidade apoia os analistas que estão atuando no
projeto.
Você observou que essa matriz se chama matriz de granularidade?
A granularidade é referente ao grão de análise do DW/DM, ou seja, o nível de detalhamento dos dados. Quanto mais granular/menor a
granularidade, mais detalhada é a informação. Quanto mais alta a granularidade, menos detalhada é a informação.
Comentário
Por exemplo, é possível analisar o Preço do Produto Vendido por data da venda (dia, mês e ano), mas o Preço do Produto Comprado
do Fabricante só pode ser analisado por mês e pelo ano. Isso significa que a informação sobre a venda dos produtos ao cliente é
mais granular do que a informação sobre a compra do produto com o fabricante para o abastecimento do estoque.
Passo 4: Elaborar documento que descreva as análises desejadas

(consultas)
O documento das análises predefinidas deve conter o layout de todas as consultas desejadas pelos usuários e identificadas durante o
levantamento das necessidades. Pode acontecer de novas análises surgirem ao longo do projeto.
Se essa nova análise utilizar as visões e indicadores já mapeados no levantamento, será simples desenhar esse novo layout e
entregar a análise ao cliente, deixando-o satisfeito com a entrega e agregando valor à organização.
Contudo, se as visões ou os indicadores não estiverem mapeados, os participantes do projeto ― tanto analistas quanto usuários ―
deverão ser reunidos, para que seja estudada a melhor forma de atendimento da nova necessidade. Para isso, alguns pontos
precisam ser considerados no impacto no projeto, como tempo e dinheiro.
A seguir, veja um exemplo de especificação de consulta:
Quantidade de
Mês de venda Produto Categoria
Produtos Vendidos
Código Descrição Descrição
1 Sabonete Higiene 1523
Abril / 2020
2 Pão de Forma Padaria 150
Suco de Uva
3 Bebida 63
Integral
Quadro: Vendas de produtos por mês.

Elaborado por: Vivian Monteiro
Descrição
O objetivo do relatório é apresentar a quantidade de produtos vendidos por mês.
Visões
• Mês da venda.
• Produto (código e descrição).
• Categoria do produto.
Indicadores
Quantidade de produtos vendidos.
Filtros
• O filtro Mês é de preenchimento obrigatório.
• O relatório deve permitir filtrar por Categoria de Produtos.
A descrição de uma análise deve conter o desenho do relatório ou dashboard para que seja possível o alinhamento das expectativas
com o cliente. O desenho permite que ele visualize suas futuras análises de forma mais fácil e mais aproximada do produto que será
entregue.
Além dos desenhos, devem estar presentes: a descrição de cada análise, com o objetivo, os atributos que estarão na análise, os
indicadores, filtros obrigatórios e filtros dinâmicos, caso sejam necessários.
Passo 5: Elaborar documento com apontamento das origens dos

dados
Com o mapeamento das visões de análise e dos indicadores, é possível verificar a origem dos dados. Essa verificação, normalmente,
é feita com os analistas responsáveis pelos sistemas transacionais. A existência de cada uma das visões e dos indicadores no
sistema origem deve ser checada.
O quadro a seguir ilustra um exemplo:
Dado Sistema de Origem Tabela Tela
Código do Produto
Qtd
Cada
Produto TB
Produto Sisvendas
Produto Código Nome do produto valor Unitário Preç
Quadro: Apontamento de origem do dado.

Elaborado por: Vivian Monteiro
O apontamento da origem dos dados é muito importante, pois pode ser que o dado não exista no sistema transacional, ou ainda, pode
não ser possível extraí-lo do sistema origem. Uma vez que essa situação ocorra, deve ser levado ao gestor para que o entendimento
seja alinhado sobre o dado.
Mapeamento das fontes de dados

Dando sequência à fase de levantamento de requisitos, temos o mapeamento das fontes de dados, conforme observado na imagem:
Levantamento de
Requisitos
1. Verificar as origens apontadas

Mapeamento das
2. Elaborar documento com o mapeamento das
fontes de Dados
fontes dos dados
Mapeamento das fontes de dados.
Verificar as origens apontadas é uma análise mais detalhada da origem dos dados mapeados nas etapas anteriores, em que ocorre a
especificação da necessidade, e os conceitos são definidos. O analista que realiza essa tarefa poderá localizar o dado no sistema
origem, conhecer sua real localização, com o nome da tabela que será acessada, o nome, o tamanho e o tipo de dado do campo.
Comentário
Se o sistema transacional for muito antigo ou não houver documentação sobre ele, a investigação mais profunda da origem poderá
trazer surpresas que precisão ser tratadas e contornadas.
A conceituação obtida com os gestores auxiliará na identificação do dado no sistema origem e será utilizada na integração de dados,
caso venham de sistemas diferentes. Durante o mapeamento das origens, podem ser definidas regras a serem aplicadas na etapa de
construção do ETL.
O quadro a seguir ilustra um exemplo:
Dado Sistema origem Tabela Tela
Cadastro do Produto
Código do Produto
Qtd
Produto Cada
Produto SisVendas
TB_Produto
Código Nome do produto valor Unitário Pre
Quadro: Mapeamento das fontes de dados.

Elaborada por Vivian Gabriela dos Santos Medeiros, adaptada por João Paulo Coelho.
Saiba mais
String: Tipo de dados formado por uma cadeia de caracteres de um idioma (letras, números, caracteres especiais).
Elaborar documento com o mapeamento das fontes de dados pode ser uma versão estendida do documento de apontamento da
origem de dados, acrescentado as informações levantadas pelo analista técnico.
video_library
Levantamento de requisitos e matriz de granularidade
No vídeo a seguir, demonstramos o processo de levantamento de requisitos dentro do ciclo de vida de um projeto, mostrando a
importância da matriz de granularidade ao longo desse ciclo de vida.
Questão 1
O levantamento de requisitos é uma importante fase do desenvolvimento de projetos:
A Apenas em Sistemas de Apoio Operacional.
B De quase todos os tipos, menos projetos de Data Marts, pois possuem um escopo menor.
C De todos os tipos, inclusive projetos de Data Warehouse.
Mas, caso o objetivo e as fontes de dados sejam conhecidos pelos analistas de BI, não é necessário realizar essa
D
fase.
E Que se aplica tão somente a projetos em que temos o Data Warehouse já estruturado como visões de Data Marts.
O levantamento de requisitos é inerente ao desenvolvimento de projetos, aplicável em diversos contextos e independe da

metodologia utilizada. Pode ser considerado ponto de partida do desenvolvimento de um projeto, além de ser primordial. Afinal,
nessa fase, as necessidades dos envolvidos no negócio são levantadas, as expectativas são alinhadas, e os processos do
negócio são elucidados. O objetivo é maximizar a assertividade do entendimento entre as partes, buscando, assim, aumentar a
probabilidade de o projeto atingir seus objetivos e chegar à fase de implantação.
Questão 2
A matriz de granularidade é um documento que:
A Relaciona visões e indicadores, bem como explicita o grão dos dados nas análises do DW/DM.
B Relaciona visões e indicadores, bem como define as consultas que deverão ser construídas.
C Relaciona os indicadores às consultas em que serão apresentados.
D Apresenta o grão contido no Sistema de Apoio Operacional ― fonte do DW/DM desenvolvido.
Relaciona as visões que serão desenvolvidas com seus conceitos e explicita o grão dos dados contidos no
E
DW/DM.
A matriz de granularidade tem como objetivo apresentar, de forma visual, a relação entre as visões e os indicadores, pois, à
medida que o projeto cresce, a quantidade de relações aumenta, tornando difícil a gestão dessas relações. A matriz serve como
norteadora para auxiliar quais perguntas feitas pelo usuário serão possíveis responder com o modelo atual. O termo
“granularidade” faz referência ao grão da informação, ou seja, em que nível de detalhamento os dados estão armazenados:
quanto mais granular/menor a granularidade, mais detalhada a informação está armazenada.
Considerações finais
Ao longo deste conteúdo, trabalhamos os conceitos de Business Intelligence (BI) e seu componente Data Warehouse (DW), e
compreendemos as diferenças entre os Sistemas de Apoio Operacional e os Sistemas de Apoio à Decisão. Em seguida, abordamos a
arquitetura do DW como um conjunto de Data Marts (DM) e o ciclo de vida do projeto de DW. Neste ciclo, focamos na fase de
levantamento de requisitos, em que são analisadas as necessidades dos usuários.
Ressaltamos, aqui, a importância de documentar o conhecimento adquirido no levantamento de requisitos, pois os artefatos
produzidos nessa fase são utilizados pelos analistas que participam da construção do DW/DM, pelos usuários que farão suas
análises no ambiente e pelas pessoas que futuramente possam interagir com o ambiente analítico, auxiliando no crescimento e na
manutenção do projeto.
headset
Podcast
Encerramos o nosso estudo falando sobre os principais tópicos abordados no tema. Ouça tudo isso no podcast a seguir.
Explore +
Conheça o guia Business Analysis Body of Knowledge (BABOK), que reúne os principais conceitos e técnicas que apoiam a análise de
negócios, e aprofunde seus conhecimentos sobre a análise de requisitos por meio do Portal de Análise de Negócios para o público
brasileiro ― IIBA (International Institute os Business Analysis).
Conheça o primeiro artigo técnico que utilizou o termo Business Intelligence, de autoria de H. P. Luhn, em 1958: A Business
Intelligence System, publicado no IBM Journal of Research and Development.
Veja como a polêmica sobre as arquiteturas de Inmon x Kimball ainda persistem, mesmo após mais de duas décadas de discussões,
no artigo Data Warehouse Design ― Inmon versus Kimball, publicado no The Data Administration Newsletter.
Veja a aplicação prática do uso de dados não estruturados para complementar ambientes de análises nos trabalhos desenvolvidos
por João Luiz Moreira, Kelli de Faria Cordeiro e Maria Luiza M. Campos:
DoctorOLAP: Ambiente para análise multifacetada de prontuários médicos;
JoinOLAP ― Sistema de informação para exploração conjunta de dados estruturados e textuais: um estudo de caso no setor
elétrico.
Referências
BARBIERI, C. Governança de dados: práticas, conceitos e novos caminhos. Rio de Janeiro: Alta Books, 2020.
DEVLIN, B. A.; MURPHY, P. T. An architecture for a business and information system. In: IBM Systems Journal, v. 27, n. 1, p. 60-80,
1988.
GARTNER. Gartner glossary. Consultado em meio eletrônico em: 10 jun. 2021.
INMON, B.; IMHOFF, C. Corporate Information Factory (CIF) overview. Colorado: Inmon Consulting Services, 2001.
KEMPE, S. A short history of Data Warehousing. California: Dataversity, 2012.
KIMBALL, R. The Data Warehouse toolkit ― técnicas para construção de Data Warehouses dimensionais. 1. ed. Rio de Janeiro:
Makron Books, 1998.
KIMBALL, R.; ROSS, M. The Data Warehouse toolkit ― the definitive guide to dimensional modeling. 3. ed. Indianapolis: John Wiley
Sons, 2013.
LAUDON, K. C.; LAUDON J. P. Sistemas de Informação Gerenciais. 11. ed. São Paulo: Pearson, 2014.
MONTEIRO, V. G. S. Arquitetura de Data Warehouse e Data Marts. Rio de Janeiro: YDUQS, 2020.
Material para download

Clique no botão abaixo para fazer o download do conteúdo completo em formato PDF.
Download material
O que você achou do conteúdo?
Relatar problema
DESCRIÇÃO
Conceitos do modelo dimensional de dados, tabelas de fatos e dimensões, abordagens do esquema
estrela (star schema) e floco de neve (snowflake schema), processo de modelagem para a construção
do modelo dimensional de dados.
PROPÓSITO
Compreender o objetivo das consultas analíticas em um Data Warehouse, dominar as técnicas e
Ask me anything...
ferramentas de modelagem dimensional e saber desenvolver modelos de dados para atender às
análises organizacionais de forma simples e rápida são competências esperadas do profissional de
Business Intelligence.
0/1000
Please enter a request

PREPARAÇÃO
O exemplo realizado neste conteúdo foi construído na ferramenta SQL Power Architect, que pode ser
utilizada opcionalmente para acompanhar o exercício e viabilizar ao aluno exercitar seu entendimento da
parte prática. Em relação à dimensão Data, foi utilizada a especificação original de Ralph Kimball, em
planilha disponível para download no website do livro do autor, que contém os comandos SQL para
criação da tabela e as instruções de inserção para popular a dimensão Data. A planilha original em
inglês pode ser baixada aqui.
OBJETIVOS
MÓDULO 1
Definir o modelo dimensional de dados e seus elementos principais: fatos e dimensões
MÓDULO 2
Descrever o processo de modelagem dimensional
INTRODUÇÃO
Em uma organização, existem diferentes níveis de tomada de decisão e, geralmente, os níveis
gerenciais mais altos tomam decisões cruciais para o direcionamento estratégico e a sobrevivência
organizacional. Esses problemas exigem, inclusive, o uso do chamado bom senso, visto que, por vezes,
não existem processos mapeados pela organização, e envolvem cenários complexos, não totalmente
claros, sem procedimentos bem-compreendidos ou predefinidos. Nesse cenário, os sistemas de apoio à
decisão provêm consultas analíticas oriundas de diversas fontes, servindo como apoio na tomada de
decisão. 0/1000
Devido à sobrecarga informacional dos bancos de dados para Business Intelligence, sob forma de Data
Warehouse (DW)/Data Marts (DM), bastante volumosos por consolidar dados históricos, a análise de
Please enter
dados requer alto desempenho para prover suporte aos diversos a request
tipos de decisão em tempo hábil.
Nesse contexto, o paradigma do modelo relacional de banco de dados, utilizado largamente em grande
parte dos sistemas transacionais, não performa satisfatoriamente, por ser otimizado para o
processamento de transação.
A abordagem denominada modelagem dimensional faz uso de princípios diferentes do paradigma

relacional, trazendo vantagens para o suporte à decisão, pois facilitam a leitura dos dados,
particularmente dados agregados e na montagem de consultas analíticas.
Neste conteúdo, vamos compreender os principais conceitos da modelagem dimensional e suas

abordagens, bem como realizar, a partir de um cenário de análise, a construção do modelo dimensional
baseado nos requisitos levantados nesse caso hipotético.
MÓDULO 1
 Definir o modelo dimensional de dados e seus elementos principais: fatos e dimensões
LIGANDO OS PONTOS
Você sabe o que é um modelo dimensional? Qual estratégia você adotaria para organizar os
dados de um data warehouse para dar suporte às análises de negócios?
Para respondermos a essas perguntas, vamos analisar algumas situações práticas.
0/1000
Imagem: Shutterstock.com Please enter a request
Em vários cenários, tomar decisões pode ser uma tarefa muito complexa. Isso ocorre porque existem
inúmeros fatores que influenciam no resultado, e boa parte deles está fora de nosso controle. Então, ter
uma base de dados confiável é muito importante, pois, com eles, conseguimos ter uma visão mais clara
do que podemos realizar e a que risco estamos expostos.
De fato, ter dados confiáveis é o passo inicial para realizar análises, mas precisamos avançar nesse
processo. Nesse contexto, entra o modelo multidimensional de dados, que organiza os dados de forma a
possibilitar o estudo detalhado de um processo. Há duas formas de realizar a modelagem
multidimensional: modelo estrela e modelo floco de neve.
No modelo estrela, os dados são organizados entre tabelas de dimensão e fato. A tabela fato trata do
processo que estamos analisando. Por exemplo, ela pode se referir ao processo de vendas de uma loja
virtual. É essa tabela que vai nos ajudar a responder perguntas como:
Quais foram os produtos mais vendidos em determinado período?
Existe uma relação forte do aumento de vendas com campanhas promocionais?
Para fornecer dados a essas tabelas fato, usamos as tabelas de dimensão.
O modelo floco de neve também utiliza uma tabela fato, mas com uma estrutura de normalização para
organizar as tabelas de dimensão.
As duas modelagens têm o mesmo objetivo, diferenciando-se entre si apenas na forma como os dados
são organizados. No entanto, a escolha de como fazer essa modelagem não é apenas uma questão de
preferência.
O modelo estrela é indicado quando são feitas poucas atualizações nas tabelas de dimensão, enquanto
o modelo floco de neve deve ser escolhido quando essas atualizações são realizadas frequentemente.
O principal impacto desses modelos está no tempo necessário para atualizar e consultar os dados.
Existem muitas ferramentas de modelagem multidimensional disponíveis no mercado, como: IBM

Cognos, Pentaho BI e Microsoft Analysis Services. Todas elas possuem vantagens e desvantagens. O
ponto mais importante é a qualificação do profissional que vai utilizá-las, pois as suas escolhas é que
farão a diferença para um projeto de modelagem multidimensional ser bem-sucedido.
1. IMAGINE QUE VOCÊ COMPÕE UMA EQUIPE0/1000

RESPONSÁVEL PELA
ORGANIZAÇÃO DOS DADOS DE UMA EMPRESA QUE TRABALHA COM VENDAS
ON-LINE, CUJO MODELO ESCOLHIDO PARA FAZER A MODELAGEM
MULTIDIMENSIONAL FOI O ESTRELA. ESSAPlease
ESCOLHA PARA REPRESENTAÇÃO
enter a request
DOS DADOS
A) está correta, pois a quantidade de consultas é muito superior à quantidade de atualizações.
B) está correta, pois a ocorrência de atualizações é superior à ocorrência de consultas.

C) está incorreta, pois o modelo floco de neve é o mais adequado para gerenciar empresas de comércio
eletrônico.
D) está incorreta, pois o modelo floco de neve garante a normalização dos dados.
E) é indiferente, pois o mais importante é que o profissional implemente o modelo corretamente,

independentemente do tipo.
2. CONSIDERE O SEGUINTE CENÁRIO: VOCÊ FOI CONTRATADO PARA

APERFEIÇOAR UM SISTEMA IMPLEMENTADO COM O USO DO MODELO
ESTRELA. LOGO QUE VOCÊ COMEÇOU A ANALISAR A ESTRUTURA DO
MODELO, PERCEBEU QUE ALGUMAS TABELAS FATO NÃO POSSUÍAM UMA
DIMENSÃO DE DATA ASSOCIADA. NESSE CASO, O QUE VOCÊ DEVE FAZER?
A) Não modificar o modelo, pois representa bem o negócio.
B) Não alterar o modelo, pois já está em produção.
C) Associar uma dimensão para cada tabela fato.
D) Acrescentar um campo de data em cada tabela fato.
E) Implementar o modelo floco de neve para representar o negócio.
GABARITO
1. Imagine que você compõe uma equipe responsável pela organização dos dados de uma
empresa que trabalha com vendas on-line, cujo modelo escolhido para fazer a modelagem
multidimensional foi o estrela. Essa escolha para representação dos dados
A alternativa "A " está correta.
Empresas de comércio eletrônico produzem muitos dados que precisam ser consultados com
0/1000
frequência. Nesse tipo de aplicação, a velocidade de resposta é muito importante. O modelo mais
adequado para esse cenário é o estrela. Portanto, a escolha está correta.
2. Considere o seguinte cenário: você foi contratado para

Pleaseaperfeiçoar um sistema implementado
enter a request
com o uso do modelo estrela. Logo que você começou a analisar a estrutura do modelo,
percebeu que algumas tabelas fato não possuíam uma dimensão de data associada. Nesse caso,
o que você deve fazer?
A alternativa "C " está correta.

Um dos aspectos mais básicos na modelagem multidimensional é a representação da periodicidade da
ocorrência dos eventos. Portanto, no caso descrito, é necessário rever todas as tabelas fato e
acrescentar a cada uma delas uma dimensão de data.
3. SUPONHA, AGORA, QUE VOCÊ É O RESPONSÁVEL PELO

DESENVOLVIMENTO DE UM SISTEMA QUE DEVE APOIAR A
DECISÃO DE PARAR OU NÃO EQUIPAMENTOS DE
MINERAÇÃO DE FERRO PARA FAZER MANUTENÇÃO
PREVENTIVA. OS DADOS DE QUE DISPÕE SÃO AQUELES
DOS SISTEMAS DE MANUTENÇÃO E DE MONITORAMENTO
DE CONDIÇÕES GERADOS POR SENSORES DOS
PRÓPRIOS EQUIPAMENTOS. NESSE CENÁRIO, QUAIS
SERIAM SUAS ESTRATÉGIAS PARA DESENVOLVER ESSE
SISTEMA DE APOIO À TOMADA DE DECISÃO?
RESPOSTA
0/1000
Inicialmente, é necessário ter um conhecimento detalhado do negócio que será modelado, pois o objetivo do
sistema é dar apoio à tomada de decisão. Isso só será possível se a modelagem dos processos for
Please enter
adequada. Em seguida, é preciso construir um data warehouse queafornecerá
request dados confiáveis para o
sistema de modelagem multidimensional que será desenvolvido. As tabelas fato devem reproduzir etapas
essenciais do estado dos equipamentos, a fim de que a análise proporcione informações relevantes para a
decisão de parar preventivamente ou não um equipamento para manutenção.
MODELAGEM DIMENSIONAL DE DADOS
A modelagem dimensional, também chamada de multidimensional, é uma técnica que visa organizar
os dados de forma adequada, para facilitar a leitura destes e a montagem das consultas analíticas. Ela
difere da modelagem de dados para sistemas de apoio operacional, que não possuem o objetivo de
gerar consultas analíticas, pois são voltados aos processos transacionais. A principal diferença entre
eles é que o modelo dos sistemas transacionais é normalizado, com restrições de integridade e sem
redundância de dados, enquanto o modelo dimensional não é rígido nesse aspecto, e pode se
apresentar desnormalizado, composto por tabelas dimensão e tabelas fato, com redundância de dados
A normalização em uma base de dados visa eliminar ou reduzir a redundância de dados, manter a
integridade destes e reduzir o espaço de armazenamento.
O objetivo é diminuir problemas durante a inserção, exclusão e alteração dos registros nas tabelas e
facilitar a manutenção dos dados. Já um modelo dimensional não tem essas preocupações, pois seu
foco principal é responder as consultas analíticas de forma rápida e com eficiência.
No modelo desnormalizado, os dados nas tabelas de dimensões podem se repetir, porque não são
sujeitos a mudanças frequentes. Essa abordagem ocupa mais espaço de armazenamento, mas
responde de forma mais rápida às consultas, por evitar as operações de junção das tabelas de
dimensões com a tabela de fato.
A imagem a seguir ilustra um exemplo de dimensão Produto com tabelas normalizadas e tabela
desnormalizada.
 ATENÇÃO
Nas tabelas normalizadas, os dados da Categoria do Produto estão em uma tabela separada dos
dados do Produto, visando evitar redundância de dados.
0/1000
Imagem: Vivian Gabriela Santos Monteiro.

 Esquema normalizado x desnormalizado.
A tabela Categoria do Produto é composta pelos campos de identificação da categoria e descrição da
categoria. O campo SK Categoria é o campo de identificação das categorias e ele é o campo de ligação
com a tabela Produto.
No exemplo de tabela desnormalizada, a descrição da categoria está contida na tabela Produto,

dispensando a tabela Categoria do Produto e gerando, em consequência, redundância dos dados de
descrição da categoria (e outros dados próprios da categoria) para todo produto pertencente à mesma
categoria.
Por estarem todos os dados em uma única tabela Produto, evita-se a junção entre tabelas, melhorando
o desempenho das consultas que envolvam categorias de produtos.
Por outro lado, a tabela Produto ocupará mais espaço de armazenamento e estará sujeita a anomalias
de atualização que ocorrem em tabelas desnormalizadas.
Como a frequência de mudanças nas tabelas de dimensão é baixa (no exemplo, é rara a mudança de
categoria de um produto), essa desvantagem é largamente compensada pela melhoria no desempenho
das consultas.
 COMENTÁRIO
Note que as soluções de tabela Produto desnormalizada ou de normalização em tabelas Categoria e

Produto não são as únicas modelagens possíveis para a dimensão Produto. Dependendo das análises
requeridas pelo negócio, a melhor alternativa talvez seja considerar Categoria e Produto como
dimensões separadas que não se relacionam diretamente, mas através de suas ligações com os fatos
registrados na tabela de fatos, como se verá ao longo deste conteúdo.
A seguir, será apresentada a metodologia 5W3H, que tem por objetivo auxiliar na identificação das
tabelas do modelo dimensional.
5W3H − IDENTIFICANDO AS TABELAS DO 0/1000
MODELO DIMENSIONAL DE DADOS

A metodologia 5W3H é uma técnica gerencial, que tem por objetivo auxiliar na modelagem de processos
de negócios de maneira fácil e organizada, reconhecendo as ações, definindo responsabilidades,
métodos de execuções, prazos e recursos associados.
No contexto de Business Intelligence, é usada no mapeamento de atividades organizacionais e auxilia o

entendimento e a identificação das tabelas do modelo dimensional de dados.
Imagem: Vivian Gabriela Santos Monteiro
 5W3H − Esquema estrela (star schema).
Como observado na imagem anterior, no centro do desenho estão as perguntas que tratam os dados
mensuráveis (How many?/How much?), no modelo dimensional, representados pela tabela fato, que
responderá, por exemplo, quantos produtos foram vendidos e por qual valor.
As perguntas ao redor da tabela fato auxiliam a identificação das tabelas dimensões, que fornecem
descrições do fato ocorrido:
WHEN – QUANDO?
Sugere a dimensão temporal muito utilizada em DW/DM, por tratar de dados históricos (por exemplo, a
data de uma venda).
WHERE – ONDE?
Sugere a dimensão espacial, descrevendo o local onde aconteceu o fato (por exemplo, em qual loja
ocorreu uma venda).
WHAT – O QUÊ?
0/1000
Sugere a dimensão objetiva, descrevendo o objeto do fato ocorrido (por exemplo, qual produto foi
vendido).
WHO – QUEM? Please enter a request
Sugere a dimensão subjetiva, descrevendo o(s) sujeito(s) que participou(aram) do fato (por exemplo, o
cliente que comprou o produto ou o vendedor que realizou a venda).
WHY – POR QUÊ?

Sugere a dimensão causal, explicando o motivo pelo qual o fato ocorreu (por exemplo, porque o cliente
comprou o produto).
HOW – COMO?
Sugere a dimensão formal, explicando a forma pela qual o fato ocorreu (por exemplo, como foi feito o
pagamento pela venda).
O desenho em forma de estrela, com o fato no centro e as dimensões nas pontas, originou a
denominação dos tipos mais usuais de esquemas do modelo dimensional:
Estrela (star schema);
Floco de neve (snowflake schema).
Os tipos de dimensão mais comuns na modelagem dimensional são:
WHAT (O QUÊ)
WHEN (QUANDO)
WHERE (ONDE)
WHO (QUEM)
0/1000
ESQUEMA ESTRELA (STAR SCHEMA)

Neste esquema, como podemos observar nas imagens anteriores, temos no centro os dados
mensuráveis, contidos na tabela fato, e, ao redor, são organizadas as tabelas dimensão.
Simplificadamente, podemos definir que as dimensões descrevem ou explicam os fatos ocorridos. Essas
dimensões podem representar hierarquia de dados e, no esquema estrela, essa hierarquia fica contida
na tabela de dimensão, deixando os dados desnormalizados, à custa de redundância de dados,
conforme foi apresentado na imagem Esquema Normalizado x Desnormalizado.
ESQUEMA FLOCO DE NEVE (SNOWFLAKE SCHEMA)
O esquema floco de neve é uma derivação do esquema estrela, e apresenta as tabelas dimensões em
hierarquia. Nesse esquema, os dados ficam normalizados, evitando redundância nas dimensões e
problemas de integridade de dados.
A imagem a seguir ilustra genericamente o esquema floco de neve, no qual as dimensões 2 e 3 estão
ligadas à dimensão 1.

 Esquema floco de neve (snowflake schema).
A recuperação dos dados no esquema floco de neve é mais custosa para a montagem das consultas,
em tempo de processamento, pois a quantidade de junções resultantes dos relacionamentos entre as
0/1000
dimensões é maior. Além disso, pode dificultar o entendimento do usuário e a implementação das
consultas nas ferramentas de análise OLAP (do inglês On Line Analytical Processing ou Processamento
Analítico On-line).
 COMENTÁRIO
Como mencionado anteriormente, a desnormalização pode ocasionar problemas na integridade dos
dados decorrentes da redundância na tabela de dimensões. No entanto, o esquema estrela apresenta
maior velocidade na recuperação dos dados, facilitando o entendimento do usuário e a montagem das
consultas.
Há, ainda, modelos que utilizam a combinação dos dois esquemas, de forma a aplicar os benefícios que
cada um oferece e elaborar a melhor solução para as necessidades de análise da organização.
Nesses casos, cabe um estudo sobre o trade-off que existe entre:
Normalizar
Quando a frequência de atualizações da tabela de dimensão for alta.
OU
Desnormalizar
Quando essa frequência for baixa.
Esse trade-off deve ser resolvido mediante a comparação dos tempos de processamento de consulta
com a tabela de dimensão normalizada ou desnormalizada. Assim, algumas dimensões serão
normalizadas, adotando o esquema floco de neve, enquanto outras serão desnormalizadas, adotando o
esquema estrela.
 DICA
Uma tabela de dimensão que não deve ser normalizada é a tabela de Data, pois os dados descritivos de
uma data (dia da semana, do mês, do trimestre, do semestre, do ano etc.), assim como outros dados
específicos (feriados, datas festivas etc.), são praticamente imutáveis e pouco sujeitos a alterações.
Como vimos, tanto no esquema estrela quanto no esquema0/1000

floco de neve, o modelo dimensional
organiza os dados em tabelas dimensão e tabelas fato. Uma forma de organização em um modelo
dimensional que facilita a visualização é a representação como um cubo de dados (ou hipercubos, pois
Please enter
podem ter número ilimitado de dimensões). Neles, as dimensões a request
estão localizadas nos eixos do cubo, e
as medidas, contidas na tabela fato, estão localizadas na interseção das dimensões.
Imagem: Shutterstock.com, adaptada por Heloise Godinho.
 Representação de fatos e dimensões em cubo.
A organização dos dados em um modelo dimensional visto como um cubo permite realizar consultas
sobre um fato por diversas visões.
 EXEMPLO
A quantidade de um determinado produto, vendido para um determinado cliente, em uma determinada

data.
No próximo módulo, vamos estudar esses dois tipos de tabelas, conhecer sua estrutura e entender
como ocorre sua implementação no modelo dimensional de dados.
0/1000

O MODELO DIMENSIONAL DE DADOS
No vídeo a seguir, o especialista apresentará conceito de modelo dimensional, os esquemas estrela e
snowflake, além das principais diferenças ao modelo transacional.
0/1000
VERIFICANDO O APRENDIZADO
1. A MODELAGEM DIMENSIONAL É UMA TÉCNICA:

A) que visa organizar os dados de forma simples, para facilitar a leitura destes e a montagem das
consultas analíticas, e é igual à modelagem de dados para sistemas de apoio operacional compostos
por tabelas dimensão e tabelas fato.
B) que visa organizar os dados de forma simples, para facilitar a leitura destes e a montagem das
consultas analíticas, e seu modelo de dados é normalizado.
C) que visa organizar os dados de forma simples, para facilitar a leitura destes e a montagem das
consultas analíticas, e seu modelo de dados é normalmente desnormalizado, composto por tabelas
dimensão e tabelas fato.
D) que visa organizar os dados de forma simples, para facilitar as transações processadas no sistema
transacional, e é composto por tabelas dimensão e tabelas fato.
E) que visa organizar os dados de forma simples, para facilitar a leitura destes e as operações diárias da
organização, e seu modelo de dados é normalizado.
2. O MODELO DIMENSIONAL DE DADOS PODE SER BASEADO NO ESQUEMA

ESTRELA OU NO ESQUEMA FLOCO DE NEVE. SOBRE ISSO, É CORRETO
AFIRMAR QUE:
A) no esquema estrela, o modelo dimensional é composto por tabelas dimensão, que ficam no centro do
modelo, descrevem os fatos e se apresentam desnormalizadas, trazendo o benefício de consultas mais
eficientes.
B) no esquema estrela, o modelo dimensional é composto por tabelas dimensão e tabelas fato, onde as
dimensões descrevem os fatos e se apresentam desnormalizadas, trazendo o benefício de consultas
mais eficientes.
C) no esquema floco de neve, o modelo dimensional é composto por tabelas dimensão e tabelas fato,
onde as dimensões descrevem os fatos e se apresentam desnormalizadas, trazendo o benefício de
consultas mais eficientes.
D) no esquema floco de neve, o modelo dimensional é composto

0 1000
por tabelas fato normalizadas,
/
trazendo o benefício de consultas mais eficientes.
E) no esquema estrela, o modelo dimensional é composto por tabelas dimensão e tabelas fato, onde as
Please enter
dimensões descrevem os fatos e se apresentam normalizadas, a request
trazendo o benefício de consultas mais
eficientes.
GABARITO
1. A modelagem dimensional é uma técnica:

A alternativa "C " está correta.
O modelo dimensional, composto por tabelas dimensão e tabelas fato, tem como objetivo organizar os
dados de forma simples, para facilitar a leitura destes, visando a montagem das consultas analíticas com
maior rapidez. O modelo de dados dimensional pode ser desenhado baseado em dois esquemas:
estrela (desnormalizado) e floco de neve (normalizado). Normalmente, se apresenta desnormalizado,
visando melhor tempo de resposta nas consultas.
2. O modelo dimensional de dados pode ser baseado no esquema estrela ou no esquema floco
de neve. Sobre isso, é correto afirmar que:
A alternativa "B " está correta.
As dimensões são tabelas que armazenam os elementos textuais que descrevem os fatos ocorridos. O
esquema estrela apresenta maior velocidade na recuperação dos dados, facilita o entendimento do
usuário e a montagem das consultas, pois as tabelas dimensões encontram-se desnormalizadas.
MÓDULO 2
 Descrever o processo de modelagem dimensional
LIGANDO OS PONTOS
Você sabe como funciona o processo de modelagem dimensional? Como as escolhas desse
processo impactam na utilização prática de um modelo multidimensional de dados?
Para entendermos esse conceito na prática, vamos analisar0/1000

uma situação.

Imagem: Shutterstock.com
Não há dúvidas sobre os benefícios que a modelagem multidimensional pode gerar para os negócios
das empresas dos diversos setores da sociedade. Muitas dessas empresas, inclusive, já têm a cultura
de utilizar esses modelos em seu cotidiano. No entanto, ainda há algumas empresas que não adotaram
a prática de aplicar técnicas de BI para realizar a análise de negócios, mas que querem passar a usá-
las. Nesse caso, é natural a pergunta: por onde começar a estruturar um sistema de modelagem
multidimensional?
Antes de tudo, é fundamental entender que a modelagem multidimensional é um instrumento para

auxiliar a obtenção de melhores resultados mais rapidamente. Mas ela não substitui os projetistas do
sistema nem mesmo os profissionais que vão utilizá-la no dia a dia para realizar análises. Portanto, é
essencial contar com mão de obra qualificada, que tenha domínio teórico e prático de técnicas e
ferramentas de análise, além de ter conhecimento do negócio em si.
Um sistema multidimensional de dados inicia com a determinação das metas que se pretende atingir.
Por exemplo:
Que estratégias devem ser adotadas para aumentar as vendas de determinado produto?
Como reduzir o tempo em que os equipamentos ficam fora de operação?
0 1000
/
Como aumentar a velocidade de entrega de funcionalidades dos produtos de uma fábrica de
software?
Please
Após a determinação dos objetivos, vem a construção das enter
tabelas a request
fato e dimensionais, que têm como
propósito fornecer subsídios para atingir os objetivos preestabelecidos na etapa anterior. No processo de
construção dessas tabelas, utilizamos os dados que estão no data warehouse. Às vezes, precisamos
submetê-los a um processo de ETL, para que fiquem em um formato que nos permita utilizá-los.
Tudo isso envolve tempo e muito estudo, e é natural que algumas etapas sejam revistas. É por isso que
a utilização de metodologias ágeis é muito bem-vinda, pois reduzem as chances de necessidade de
fazer grandes correções na etapa final do projeto e de realizar entregas gradualmente.
1. DIGAMOS QUE VOCÊ SEJA UM EMPRESÁRIO DO RAMO DE SOFTWARES.

COMO RESPONSÁVEL POR SEU NEGÓCIO, VOCÊ SABE QUE A UTILIZAÇÃO DE
TÉCNICAS DE BI PODE AJUDAR BASTANTE NO DESEMPENHO DE SUA
EMPRESA. NESSE CONTEXTO, QUE POSSÍVEL BENEFÍCIO SUA EMPRESA
PODE TER AO UTILIZAR TAIS TÉCNICAS?
A) Aumentar a segurança dos dados.
B) Utilizar tecnologias modernas e seguras para analisar os dados.
C) Aumentar a transparência de um setor de vendas.
D) Aumentar a confiabilidade dos dados.
E) Reduzir a quantidade de paradas de equipamentos para manutenção corretiva.
2. A ETL É UMA DAS ETAPAS UTILIZADAS PARA CONSTRUÇÃO DE UM MODELO

MULTIDIMENSIONAL. INCLUSIVE, EXISTEM MUITAS FERRAMENTAS
DISPONÍVEIS NO MERCADO COM ESSA FINALIDADE. EM SUA VISÃO, UM
EXEMPLO DE APLICAÇÃO DE ETL É
A) obter os itens mais vendidos em determinado período.
B) detectar tentativas de fraudes de cartão de crédito.
C) identificar as causas de paradas de equipamentos.
D) converter dados de 0 para m (masculino) e de 1 para f (feminino).
E) aumentar a velocidade das consultas do data warehouse.

0/1000
GABARITO
1. Digamos que você seja um empresário do ramo de softwares. Como responsável por seu
negócio, você sabe que a utilização de técnicas de BI pode ajudar bastante no desempenho de
sua empresa. Nesse contexto, que possível benefício sua empresa pode ter ao utilizar tais
técnicas?
A alternativa "E " está correta.

As técnicas de BI estão associadas a benefícios mensuráveis e às metas de um negócio. Portanto, é
essencial que essas metas estejam vinculadas a dados que podem ser relacionados entre si, a fim de
gerar um entendimento sobre o que está ocorrendo em determinada etapa de um processo e qual ação
deve ser tomada para corrigi-la. No caso em questão, a única alternativa que atende a esses critérios é
a redução de paradas de equipamentos para manutenção corretiva, pois a análise vai auxiliar a
encontrar os fatores que obrigam a realizar tal manutenção.
2. A ETL é uma das etapas utilizadas para construção de um modelo multidimensional. Inclusive,
existem muitas ferramentas disponíveis no mercado com essa finalidade. Em sua visão, um
exemplo de aplicação de ETL é
A alternativa "D " está correta.
O objetivo de um processo de ETL é extrair os dados de fontes primárias, submetê-los a uma etapa de
transformação (quando for necessário) e carregá-los no banco destino. No caso em questão, a única
alternativa que se encaixa no processo de ETL é a conversão dos dados de 0 para m e de 1 para f,
representando, respectivamente, os sexos masculino e feminino. Esse exemplo, inclusive, é bastante
comum na prática.
3. CONSIDERE O SEGUINTE CENÁRIO: VOCÊ É O

RESPONSÁVEL POR FAZER A MODELAGEM
MULTIDIMENSIONAL DE UM SISTEMA DE MONITORAMENTO
DE EQUIPAMENTOS DE PERFURAÇÃO DE POÇOS DE
PETRÓLEO. ESSES EQUIPAMENTOS SÃO MUITO CAROS, E
É MUITO DIFÍCIL SUBSTITUÍ-LOS. POR ISSO, A
MANUTENÇÃO DELES PRECISA SER REALIZADA COM
EXCELÊNCIA. NESSE CONTEXTO, QUE ESTRATÉGIA VOCÊ 0/1000
ADOTARIA PARA FAZER A MODELAGEM

MULTIDIMENSIONAL DO SISTEMA?
RESPOSTA
A primeira etapa a ser cumprida é determinar o objetivo principal do sistema: garantir que a manutenção seja
realizada com grande qualidade. Equipamentos de grande porte já têm um processo de manutenção
preventiva estabelecido pelos fabricantes, mas, dependendo da utilização durante a operação deles, pode
ser necessário reduzir a periodicidade com que devem passar por manutenções. Portanto, é fundamental
mapear todas as fontes de dados que forneçam informações sobre as condições dos equipamentos, para
que sejam agregadas no data warehouse e, posteriormente, alimentem as tabelas multidimensionais do
sistema. Dessa forma, os analistas poderão observar detalhadamente o estado dos equipamentos e estudar
a necessidade de aplicar manutenções preventivas antes da ocorrência de uma situação que envolva grande
risco.
TABELAS DIMENSÃO
As dimensões são tabelas que armazenam os elementos textuais que descrevem os fatos ocorridos.
Elas respondem às perguntas: O quê?; Quem?; Quando?; Onde?; entre outros.
 EXEMPLO 0/1000
Fato ocorrido: venda do produto.

O que foi comprado? Resposta: O produto leite em pó.
Quem comprou esse produto? Resposta: O cliente José.
Quando o produto foi comprado? Resposta: No dia 14/05/2020.

Onde o produto foi comprado? Resposta: Na loja do bairro Centro da cidade do Rio de Janeiro.
A tabela dimensão possui uma coluna que identifica um elemento univocamente na tabela. Essa coluna
é a chave primária (PK – primary key), também conhecida como surrogate key (SK) ou chave artificial,
do tipo numérico e normalmente preenchida por um número sequencial incremental (tipo inteiro de 4
bytes).
 ATENÇÃO
Note que o inteiro de 4 bytes possui limite superior de +2.147.483.647, número mais do que suficiente
para conter a quantidade de linhas das tabelas de dimensão usuais − não é razoável se pensar em uma
dimensão contendo mais de 2 bilhões de produtos ou clientes.
Para dimensões com poucas ocorrências, por questão de economia de espaço, principalmente na tabela
de fato, pode-se optar por usar o tipo smallint ou equivalente, com 2 bytes, que possui limite superior de
+32.767. Isso pode se aplicar, por exemplo, para dimensões como lojas ou departamentos.
A chave primária da tabela de dimensão serve como a ligação entre a dimensão e a tabela fato.

 Exemplo da tabela dimensão Produto.
A imagem anterior ilustra a dimensão Produto, na qual a coluna "SK Produto" é a chave da dimensão,
"Codigo Produto" é o código do produto no sistema origem, "Descricao Produto" é a descrição do
produto (nome) e "Descricao Fabricante" é o nome do fabricante.
Caso a modelagem fosse normalizada, a coluna "Descricao Fabricante" daria lugar à coluna "SK
Fabricante", representando a chave primária da "Dimensão0/Fabricante".
1000
De acordo com Kimball (2013), as dimensões são tabelas geralmente largas, isto é, com várias colunas,
planas e desnormalizadas, com muitos atributos de texto de baixa cardinalidade. Isso porque a
dimensão pode conter diversas colunas descritivas, baixa quantidade de registros, colunas que agrupam
os elementos da tabela e colunas com pouca variação no seu conteúdo. Mas, apesar de largas, as
dimensões são tabelas curtas, isto é, possuem poucas linhas − raramente chegando à casa dos milhões
−, se comparadas às tabelas fato, que podem chegar à casa dos bilhões.
 COMENTÁRIO
Imagine o DW de uma rede gigantesca de lojas de varejo, com fatos de vendas de cada produto, em
cada loja, ao longo de décadas de histórico das vendas!
As colunas da tabela dimensão são chamadas de atributos.
 EXEMPLO
Na dimensão Produto, há 4 atributos além da chave primária SK Produto. Esta identifica um elemento na
dimensão e se relaciona com a tabela fato.
A relação da dimensão com a tabela fato é do tipo um para muitos, ou seja, um elemento da dimensão
Produto pode estar ligado a N (vários) registros da tabela fato.
Os elementos contidos nas dimensões qualificam as consultas, agrupam e sumarizam os fatos contidos
na tabela fato. Os elementos atuam como filtros, consolidando milhares de linhas da tabela fato em
algumas linhas.
 EXEMPLO
A tabela fato Vendas possui 2 milhões de linhas, que detalham as vendas dos produtos no ano de 2019.
Uma consulta para exibir o valor de produtos vendidos por mês no ano de 2019 apresentará apenas 12
linhas, uma para cada mês.
Assim, as dimensões apresentam maior ou menor detalhe dos dados nas consultas em que são
utilizadas. Esse movimento é realizado pelas operações de análise sobre os dados. Por exemplo: drill
down, quando detalhamos o dado; e drill up ou roll up, quando agregamos o dado.
0/1000

 Exemplo de operações de drill up e drill down.
Conforme ilustrado na figura anterior, as operações de drill down e drill up podem ser observadas em
hierarquias de atributos, nas quais um atributo pode ser agrupado por outro. Por exemplo, os produtos
podem ser agrupados em categorias de produtos, no qual o produto sabonete faz parte da categoria
Higiene.
Com a hierarquia de atributos da visão de datas, podemos realizar a operação de drill down, detalhando
a venda de produtos por dia, ou agrupar os dados, aplicando a operação drill up. O relatório apresenta
os sabonetes vendidos por mês, o drill up realizado para o ano e o drill down realizado para o dia.
TABELAS FATOS
As tabelas fatos ficam no centro do modelo dimensional de dados e se relacionam com no mínimo duas
tabelas dimensões.
0/1000
As tabelas armazenam as medidas/métricas dos fatos ocorridos que são descritos pelas dimensões.
As chaves primárias das tabelas dimensão são adicionadas na tabela fato como chaves estrangeiras, e
a combinação delas forma a identificação dos registros (chave primária) na tabela fato.
As colunas que representam as chaves das tabelas dimensão são numéricas, como já foi visto (inteiros
de 2 ou 4 bytes), e as colunas que representam as medidas/métricas, também chamadas de fatos, são,
em geral, também do tipo numérico, representando quantidades ou valores que respondem a questões
do tipo “Quanto?”.
Em algumas situações, colunas de outros tipos podem estar na tabela fato para resolver questões
pontuais do negócio − por exemplo, um dado alfanumérico representando um objeto do sistema
transacional, como uma nota fiscal, denominado de dimensão degenerada, por não haver uma tabela de
dimensão correspondente.
A tabela fato possui muitas linhas, que são agregadas pelos atributos das dimensões. Ela pode conter
medidas aditivas, semiaditivas e não aditivas.
Os fatos aditivos são dados numéricos que podem ser sumarizados por todas as visões do DW/DM
que fazem parte do contexto da tabela fato sob a forma de tabelas de dimensões. Por exemplo, a
Quantidade Vendida de Produtos pode ser somada pelas dimensões Produto, Data, Loja.
Os fatos semiaditivos são também dados numéricos, mas não podem ser somados por todas as visões
do DW/DM, devido à sua semântica. Por exemplo, a quantidade em estoque de um produto pode ser
somada pela dimensão Loja (estoque de um determinado produto em várias lojas), mas não faz sentido
se somarmos o estoque pela dimensão Data (Data do Estoque).
Os fatos não aditivos são dados que, mesmo sendo numéricos, não podem ser sumarizados pelas
visões do DW/DM. Por exemplo, uma coluna que contenha o percentual de desconto oferecido aos
clientes.
Além desses três tipos, temos a medida derivada. Ela é calculada com base em outras medidas
contidas na tabela fato. Como exemplo, o lucro de um produto vendido, em que pode haver uma medida
calculada com base nas medidas Preço do Produto Vendido e Preço do Produto Comprado do
Fabricante.
O GRÃO DO FATO
Durante a fase de levantamento de requisitos, devemos levar em consideração a matriz de

granularidade, que ajuda a identificar o grão em que as medidas serão armazenadas na tabela fato.
0/1000
 ATENÇÃO
Please enter
Esse grão é muito importante para a agregação e apresentação dos adados;
requestem outras palavras, o grão
de uma tabela fato representa o quão detalhado está o dado naquela tabela.
O grão atômico é referente ao dado no nível mais baixo extraído do sistema transacional.
Quanto mais baixo o nível de granularidade dos dados, mais detalhado será o dado, e isso pode garantir
que as perguntas feitas pelo usuário serão respondidas. Por exemplo, na visão de data, temos
informado que as medidas de quantidade de produtos vendidos e o valor da venda podem ser
analisadas no grão dia, de uma hierarquia que possui dia, mês e ano.
 ATENÇÃO
É importante que os fatos contidos em uma tabela fato estejam no mesmo nível de granularidade.
Durante o levantamento de requisitos, vimos que a quantidade de produtos vendidos está no grão dia, e
que a quantidade de produtos comprados do fabricante está no grão mês. Isso significa que só será
possível avaliar as duas medidas pelo grão mínimo mês. Logo, essas duas medidas não podem estar
em uma mesma tabela fato.
TIPOS DE TABELA FATO
A partir do entendimento da importância do grão do fato, podemos elencar os tipos de tabelas fato
possíveis.
A tabela fato transacional é a mais comum no DW/DM. Ela armazena o nível mais detalhado do fato,
considerando o grão definido para a tabela fato. O dado é extraído do sistema de origem no nível de
detalhe estabelecido e é carregado na tabela fato. É importante observar que, quanto mais detalhado for
o dado, mais linhas serão armazenadas na tabela fato. Um exemplo típico é a tabela que registra cada
venda de produto por filial, por vendedor, por dia.
A tabela de snapshot periódico registra dados em um período predefinido; por exemplo: diariamente,
semanalmente ou mensalmente. É uma fotografia da tabela de fato transacional em um período a ser
capturado. Um exemplo típico é a tabela que registra o estoque corrente de cada produto por dia, por
filial.
A tabela de snapshot acumulado descreve um processo de negócios com data de início, datas de
marco intermediário e data de fim. A cada etapa concluída, o registro sofre atualização para adicionar o
0 1000
/
novo marco. Um exemplo típico é a tabela que registra o processo de recebimento, inspeção,
armazenagem e liberação para venda de produtos em cada armazém ou depósito.
A tabela fato agregada representa um nível de granularidade

Pleasemais
enterelevado.
a request Os dados são sumarizados
pelas visões do contexto, diminuindo a quantidade de linhas na tabela e, às vezes, diminuindo a
quantidade de dimensões relacionadas à tabela fato. O objetivo de tabelas agregadas é oferecer
análises mais rápidas para visões com um objetivo mais específico. Por exemplo, volume de vendas por
mês, por filial, por produto. O menor nível de análise será o mês. Caso seja necessário avaliar um
determinado dia do mês, a análise deve ser submetida à tabela fato transacional, que é mais detalhada.
Nos sistemas de banco de dados, o recurso usado para criar a tabela fato agregada é a visão (VIEW),
que nada mais é do que uma consulta à tabela fato transacional realizando a sumarização desejada. Um
trade-off que existe no projeto de DW/DM é a decisão sobre armazenar ou não o resultado da visão, ou
seja, materializar ou não a consulta criada com a VIEW como uma nova tabela no banco de dados. Note
que o conteúdo da tabela fato agregada pode depender do momento da execução da VIEW sobre a
tabela fato transacional. Isso significa que, nesses casos, quando houver a atualização da tabela fato
transacional com a inserção de novos fatos, a tabela fato agregada pode se tornar obsoleta, requerendo
uma nova execução da VIEW para recriar a tabela. A decisão sobre armazenar ou não a tabela fato
agregada dependerá de estudo de desempenho do sistema quanto ao espaço de armazenamento
necessário (que pode ser exponencial) e ao tempo de execução da reorganização do banco de dados
sempre que uma recarga das tabelas fato transacionais ocorrerem no sistema.
A tabela fato sem fato é chamada dessa forma porque ela não possui uma coluna contendo medida do
fato. Ela estabelece a relação entre dimensões que respondem a uma determinada análise de
ocorrência de evento. Um exemplo é a tabela que registra matrículas de alunos em turmas de disciplinas
de um curso ministradas por um determinado professor, com a finalidade de contagem do tamanho da
turma, para viabilizar uma oferta.
INICIANDO A MODELAGEM DIMENSIONAL DE

DADOS
Agora que você está familiarizado com os termos utilizados, é hora de organizar as etapas para a
construção do modelo dimensional de dados.
Olhando o ciclo de vida de um projeto de DW, na figura a seguir, vemos que o modelo dimensional de
dados está na trilha central, que é realizada após o levantamento de requisitos do negócio. Essa trilha
se dedica ao tratamento dos dados e encadeia as fases modelagem dimensional, a definição do projeto
físico e a especificação de ETL. Com base nas informações documentadas nas fases de levantamento
de requisitos e mapeamento das fontes de dados, o modelo dimensional pode ser construído.
0/1000

Imagem: The Kimball Group Reader. Kimball et al, 2013, p. 404.
 Ciclo de vida de um projeto de Data Warehouse.
CENÁRIO DE ANÁLISE
Durante o processo de análise de um supermercado, foram identificados os requisitos de negócio.
As análises desejadas são:
Quais são os produtos mais vendidos no verão?
Quais são os clientes com maior potencial de compras em uma determinada categoria de produtos?
O estoque fica zerado em quais lojas?
Quais são os fabricantes dos produtos que oferecem maior lucro na comercialização dos seus itens?
As visões ou dimensões de análise são:
Produto (referente a qual produto
Categoria do produto (referente a qual grupo de produto)

0/1000
Fabricante do produto (referente a qual fabricante)
Cliente (referente a quais clientes)

Data (referente a quando foi realizada a venda, quando foi comprado do fabricante e as vendas
ocorridas durante o verão)
Os assuntos são:
Vendas de produtos
Estoque de produtos
As medidas são:
Quantidade de produtos vendidos
Quantidade de produto no estoque
Preço do produto vendido
Preço do produto comprado do fabricante
Lucro do produto vendido
Ainda sobre o modelo de dados, ele pode ser divido em três momentos:
MODELO CONCEITUAL
Que representa o entendimento sobre o negócio e o relacionamento entre as tabelas.
MODELO DE DADOS LÓGICO

Que considera algumas restrições, o padrão e a nomenclatura, chaves primárias e estrangeiras, entre
outros.
MODELO FÍSICO
Que considera os padrões do SGBD escolhido.
MODELO DIMENSIONAL DE DADOS
A concepção do modelo dimensional de dados reúne os requisitos levantados e os organiza por assunto,
desenhando as dimensões e a tabela fato que expressa o relacionamento entre elas.
0/1000
 COMENTÁRIO
O esquema estrela facilita o entendimento para todos os Please

envolvidos
enter no projeto, principalmente para os
a request
usuários do negócio, devido a sua simplicidade.
O modelo dimensional pode ser desenhado de maneira inicial e mais abstrata na fase de levantamento
de requisitos, com o objetivo de auxiliar a compreensão sobre o negócio e facilitar o entendimento da
relação que os dados possuem. Utiliza as técnicas de modelagem de dados − que envolve entidades,
atributos, relacionamentos, cardinalidade etc. − e o conhecimento dos requisitos identificados na fase de
levantamento de requisitos para a construção do Data Warehouse.
Com a união desses conhecimentos, podemos elaborar o modelo dimensional do assunto Vendas de
Produtos.
As visões listadas no cenário de análise serão as dimensões do modelo:
Produto;
Categoria do produto;
Fabricante do produto;
Cliente;
Data.
A visão Produto no sistema origem contém os dados Código do Produto, a descrição do Produto, o
nome do Fabricante do Produto, a descrição da Categoria do Produto, o Código de Barras do Produto e
a Data de Validade do Produto. No entanto, conforme o levantamento realizado, os dados necessários
para as análises são: Código do Produto, Descrição do Produto, o nome do Fabricante do Produto e a
descrição da Categoria do Produto. Logo, somente esses dados serão adicionados na dimensão
Produto.
Como visto anteriormente, podemos modelar a visão Produto de forma normalizada e desnormalizada. A
imagem a seguir ilustra a modelagem normalizada para as visões Produto e Categoria:
0/1000

 Esquema normalizado das tabelas Categoria e Produto.
A leitura da cardinalidade na notação da imagem anterior, de acordo com a definição do modelo
entidades e relacionamentos, é a seguinte:
Uma categoria pode não ter produtos ou pode ter vários produtos.
Um produto pode estar ligado a apenas uma categoria e deve sempre estar ligado a uma categoria.
A ferramenta utilizada para fazer o modelo representa a relação pela linha que liga as duas tabelas. Isso
significa que, durante o desenvolvimento do processo de carga, essas críticas precisam ser validadas.
Outras soluções para esse relacionamento podem ser aplicadas colocando a descrição da Categoria
dentro da visão Produto, ou, ainda, ligar a dimensão Categoria do Produto diretamente na tabela fato.
Segundo Kimball (2013), a dimensão Data é uma dimensão especial, por sua presença nos modelos
dimensionais ser quase certa, em razão do DW ser um banco de dados históricos. Isso se deve ao fato
de a maioria das análises estarem relacionadas ao tempo. Em projetos modernos, a dimensão Data
utiliza a chave primária com a formação de ano, mês e dia (YYYYMMDD), que garante unicidade e
sequência.
 VOCÊ SABIA
Antigamente, no início da modelagem dimensional, eram utilizadas as chaves surrogate key como
identificador da tabela de tempo.
A dimensão Data pode ser criada de forma prévia, pois sua natureza independe de dados de sistemas
origens. A dimensão possui um conjunto de atributos que atende a várias necessidades, mas você pode
adicionar novos atributos de acordo com o projeto a ser desenvolvido.
Vamos utilizar a dimensão Data definida por Kimball (2013) em nossos exercícios, descrita na fase de
preparação deste tema. Você poderá adicionar a tabela ao modelo dimensional de dados ou deixar para
criar e relacionar com a tabela fato após a implementação do modelo físico.
Depois de conhecer as vantagens e desvantagens dos tipos de modelagens, você pode escolher qual se
encaixa melhor na solução que está construindo.
Vamos praticar? Construa a modelagem das visões contidas no levantamento.
 ATENÇÃO
0/1000
Não esqueça de incluir as visões Produto, Categoria e Fabricante!

IMPLEMENTANDO O MODELO DIMENSIONAL
DE VENDAS A VAREJO
Acompanhe no vídeo o especialista implementar o modelo dimensional apresentado no cenário de
análise, utilizando a ferramenta SQL Power Architect.
0/1000
A imagem a seguir demonstra o resultado esperado. Após o desenho das dimensões, devemos
acrescentar a tabela fato ao modelo.
Para a tabela fato Vendas, devem ser consideradas as medidas do assunto Vendas, e as dimensões
devem ser ligadas a ela. A tabela fato conterá as medidas Quantidade de Produtos Vendidos e Preço do
Produto Vendido.
 Esquema dimensional (estrela) de Vendas a Varejo.
Note que a solução adotada no esquema estrela da imagem anterior considerou a separação das
dimensões Categoria e Produto, que se relacionam por meio do fato Vendas.
Outra solução possível seria considerar os dados de Categoria como atributos de Produto; neste caso,
apenas a tabela Produto seria uma dimensão relacionada à tabela fato, estando os dados sobre
Categoria embutidos na tabela de dimensão Produto desnormalizada.
1. SOBRE A OPERAÇÃO DE ANÁLISE DRILL DOWN NA HIERARQUIA DE REGIÃO

GEOGRÁFICA, É POSSÍVEL AFIRMAR QUE:
0/1000
A) A navegação pode ser feita detalhando-se os dados do nível mais alto, Região, para o nível mais
baixo, Bairro, na sequência: Região, Bairro, Cidade e Estado.
B) A navegação não pode ser feita detalhando os dados do nível mais alto, Região, para o nível mais
baixo, Bairro, em sequência.
C) A navegação pode ser feita detalhando os dados do nível mais baixo, Bairro, para o nível mais alto,
Região, na sequência: Bairro, Cidade, Estado e Região.
D) A navegação pode ser feita, mas os dados não podem ser detalhados sem que a dimensão Tempo
esteja contida na análise.
E) A navegação pode ser feita detalhando os dados do nível mais alto, Região, para o nível mais baixo,
Bairro, na sequência: Região, Estado, Cidade e Bairro.
2. APÓS O GESTOR SOLICITAR SABER O VOLUME DE VENDAS POR MÊS, POR

FILIAL E POR PRODUTO, VOCÊ ANALISOU A TABELA FATO DE VENDAS E
CONCLUIU QUE ELA ESTÁ NO GRÃO DE DIA. A PARTIR DESSE CONTEXTO, É
POSSÍVEL FAZER USO DA TABELA FATO:
A) Transacional
B) Snapshot periódico
C) Snapshot acumulado
D) Agregada
E) Sem fato
GABARITO
1. Sobre a operação de análise drill down na hierarquia de região geográfica, é possível afirmar
que:
A alternativa "E " está correta.
A operação de drill down navega de um ponto mais alto para um ponto mais baixo em uma hierarquia de
atributos, detalhando mais ou menos dados contidos na consulta.
2. Após o gestor solicitar saber o volume de vendas por mês, por filial e por produto, você
analisou a tabela fato de vendas e concluiu que ela está no grão de dia. A partir desse contexto, é
0/1000
possível fazer uso da tabela fato:
A alternativa "D " está correta.

Fazendo uso da tabela fato agregada, é possível um nível de granularidade mais elevado. Isso porque a
tabela fato Vendas está em um grão diferente, ou seja, dia. No entanto, é possível sumarizar pelas
visões desse contexto, apresentando o resultado por mês, consequentemente diminuindo a quantidade
de linhas na tabela e atendendo esse cenário específico demandado pelo gestor.
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Ao longo deste conteúdo, trabalhamos os conceitos de modelagem dimensional de dados e os
esquemas estrela e floco de neve. Em seguida, vimos a noção de grão, muito importante para definir o
nível de detalhamento dos dados, além de fundamentos essenciais para a construção das tabelas
dimensão e fato.
Por fim, compreendemos o processo de modelagem conceitual dos dados e realizamos a construção do
modelo dimensional de dados, utilizando a ferramenta SQL Power Architect.
AVALIAÇÃO DO TEMA:
REFERÊNCIAS
0/1000
BARBIERI, C. BI2 Business Intelligence: modelagem e qualidade. 1. ed. Rio de Janeiro: Elsevier,
2011.
KIMBALL R.; ROSS, M. The Data Warehouse toolkit: the definitive guide to dimensional modeling. 3.
ed. Nova Jersey: John Wiley & Sons, 2013.
KIMBALL R.; ROSS, M. The Kimball Group Reader: remastered edition. Nova Jersey: John Wiley &
Sons, 2016.
NAVATHE, S. B.; ELMASRI, R. Sistemas de banco de dados. 6. ed. São Paulo: Pearson Addison
Wesley, 2011.
PITON, R. Data Warehouse passo a passo: o guia prático de como construir um Data Warehouse do
zero. Porto Alegre: Raizzer, 2018.
SANTOS, V. G. Arquitetura de Data Warehouse e Data Marts. Rio de Janeiro: YDUQS, 2020.
EXPLORE+
Para saber mais sobre os assuntos tratados neste conteúdo, procure na internet e leia o artigo:
Tabela Dimensão: os 5 tipos que você deve conhecer, de Rafael Piton.
Explore as ferramentas disponíveis na internet:
Aplicativo IBM Rational Rose.
Dbdesigner.
brModelo.
MySQL Workbench.
SQL Power Architect Community Edition.
Pesquise na internet:
As referências a artigos e dicas de projeto do site do Kimball Group.
0/1000
CONTEUDISTA
Conteúdo original: Vivian Gabriela Santos Monteiro
Adaptação e conversão: Antonio Felipe Podgorski Bezerra

DESCRIÇÃO
Conceitos para aplicação no projeto físico de Data Warehouse, técnicas avançadas de
construção de hierarquias no modelo dimensional, agregação, consolidação de dados para
otimizar consultas analíticas no DW/DM, e a implementação do modelo no SGBD.
PROPÓSITO
Compreender técnicas avançadas com objetivo de auxiliar na construção da estrutura física do
modelo de dados dimensional, definir a padronização da nomenclatura utilizada e a
configuração do ambiente do banco de dados, assim como ter o entendimento da importância
de provisionar a estrutura para o volume de dados esperado, viabilizando assim um tempo de
resposta exequível, são atribuições esperadas em um profissional de Business Intelligence
(BI).
PREPARAÇÃO
Os exemplos deste conteúdo foram construídos na ferramenta SQL Power Architect, que pode
Ask me anything...
ser utilizada opcionalmente para o acompanhamento do aluno, para que esse possa exercitar a
parte prática. Em relação ao banco de dados, para armazenar o DW, você pode utilizar
qualquer SGBD de sua preferência que utilize o paradigma
0 1000
relacional. Para ver algumas
/
opções mais usuais, consulte a seção Explore+.
OBJETIVOS
MÓDULO 1
Descrever o projeto físico do Data Warehouse em um banco de dados relacional
MÓDULO 2
Descrever conceitos avançados de modelagem dimensional envolvendo hierarquias de

dimensões
MÓDULO 3
Descrever o processo de agregação e consolidação dos dados em tabela fato visando à

otimização de consultas
INTRODUÇÃO
Business Intelligence (BI) torna-se cada vez mais presente nas organizações; sendo assim,
projetos que envolvem BI têm sido cada vez mais demandados para auxiliar setores
estratégicos, com o intuito de viabilizar apoio à decisão. Sabemos que o desenvolvimento de
um projeto de software é dividido em etapas e possui um início e um fim, além da necessidade
de ser mantido e possibilitar evoluções incrementais ao longo do seu ciclo de vida.
0 1000
/
Dentro desse ciclo de vida do projeto de BI, os dados são protagonistas e precisam ser
estruturados de maneira que as consultas dos usuários tenham um desempenho satisfatório. A
construção da estrutura física do modelo de dados dimensional é um fator determinante para
atingir esse objetivo.
Neste conteúdo, serão apresentadas as hierarquias que podem ser construídas no modelo de
dados dimensional, tanto no esquema Floco de Neve quanto no esquema Estrela, além das
técnicas para a agregação e consolidação de dados a fim de otimizar as consultas analíticas
realizadas no Data Warehouse (DW). Por fim, será realizada a implementação do modelo
proposto em um sistema gerenciador de banco de dados (SGBD).
MÓDULO 1
 Descrever o projeto físico do Data Warehouse em um banco de dados relacional
PROJETO FÍSICO
No ciclo de vida de projetos de DW/DM (Data Warehouse/Data Mart), temos a trilha de dados,
que se dedica ao tratamento dos dados e encadeia a fase de Modelagem Dimensional, a
definição do projeto físico e a especificação e o desenvolvimento do processo de ETL (do
inglês Extraction-Transformation-Loading ou Extração-Transformação-Carga), conforme
apresentado na imagem a seguir.
0/1000
 Ciclo de Vida de um Projeto de Data Warehouse

A implementação física do modelo de dados dimensional considera o Sistema Gerenciador de

Banco de Dados (SGDB) escolhido para o projeto e alguns outros pontos que serão detalhados
a seguir.
O modelo de dados dimensional físico parte do modelo lógico e une os padrões estabelecidos,
as regras de negócio, as características do SGBD e o envolvimento de alguns especialistas
que darão suporte e aplicarão soluções para que a implementação do modelo seja feita com
sucesso, buscando um bom desempenho nas consultas analíticas.
Para que o projeto do DW/DM continue seu desenvolvimento, o modelo de dados dimensional
lógico desenhado precisa ser transformado em um ambiente físico onde os dados possam ser
acomodados.
Nesse momento, as características do SGBD devem ser observadas, pois o projeto físico
utiliza essas informações para sua construção, e isso pode variar entre os SGBDs.
 COMENTÁRIO
Nesse aspecto, o projeto físico de um DW não difere muito de projetos de banco de dados
convencionais, no sentido de que as funcionalidades específicas do SGBD escolhido devem
ser consideradas no mapeamento do modelo lógico de dados para o modelo físico.
As informações de restrições de integridade e de valores nulos devem ser avaliadas com

atenção para que sejam aplicadas corretamente no projeto físico.
Outra questão importante são os padrões utilizados para os nomes de tabelas, colunas, índices
etc. O padrão da nomenclatura deve ser estabelecido antes mesmo de iniciar o desenho do
modelo de dados dimensional físico para que todos os elementos sigam corretamente a
definição. Não há um padrão obrigatório a ser usado e, normalmente, utiliza-se o padrão
especificado pela organização, através do papel de Administrador de Dados.
O projeto físico envolve, além das tabelas do modelo de dados dimensional, algumas tabelas
de suporte ao processo de ETL que veremos mais à frente. Essas tabelas são chamadas de
0 1000
tabelas temporárias e são a porta de entrada para/ a chamada staging area ou área de
manobras/preparação dos dados.
A staging area é o conjunto de espaço e elementos queenter

Please fica aentre o sistema de origem dos
request
dados e a área de apresentação dos dados.
As tabelas temporárias recebem os dados extraídos do sistema origem para que eles possam
ser tratados no processo ETL. Somente após os tratamentos, os dados são carregados e
acomodados nas tabelas Dimensão e Fato.
Além das tabelas temporárias, outras tabelas de suporte à segurança, tabelas do tipo “De para”
de dados e tabelas de metadados podem ser construídas. A criação dessas tabelas depende
da necessidade do projeto que está sendo desenvolvido.
Também é avaliada nessa etapa a construção de índices, partições e tabelas agregadas por
meio de visões (views), estas podendo ser materializadas ou não. Esses recursos melhoram o
desempenho das consultas que serão submetidas ao ambiente analítico e são muito
importantes para o DW/DM que trabalha com um volume de dados muito grande.
Vamos explorar melhor esses pontos e aplicá-los ao projeto físico do DW, utilizando o modelo
de dados dimensional denominado Vendas a Varejo, ilustrado pela imagem a seguir.
 Esquema dimensional (Estrela) de Vendas a Varejo.
PADRONIZANDO A NOMENCLATURA DOS

ELEMENTOS DO MODELO DE DADOS
0/1000
DIMENSIONAL FÍSICO
Vamos adotar a seguinte nomenclatura para o desenvolvimento dos elementos do modelo de

dados dimensional:
TABELA DIMENSÃO
Os nomes das tabelas dimensões serão iniciados com dim_.
TABELA FATO
Os nomes das tabelas fato serão iniciados com ft_.
TABELA TEMPORÁRIA
Os nomes das tabelas temporárias serão iniciados com tmp_.
COLUNA DE CHAVE IDENTIFICADOR

Os nomes das colunas que representam identificadores serão iniciados com sk_.
COLUNA DE CÓDIGO
Os nomes das colunas que representam códigos serão iniciados com cd_.
COLUNA NUMÉRICA
Os nomes das colunas que representam dados numéricos serão iniciados com num_.
COLUNA DE DESCRIÇÃO
Os nomes das colunas que representam descrições serão iniciados com ds_.
COLUNA DE NOMES
Os nomes das colunas que representam nomes serão iniciados com nm_.
COLUNA DE DATA
Os nomes das colunas que representam datas serão iniciados com dt_.
COLUNA DE VALOR
Os nomes das colunas que representam os valores serão iniciados com vl_.
 DICA
0/1000
Algumas ferramentas são sensíveis a letras maiúsculas e minúsculas, então, para minimizar
problemas futuros, é recomendado definir se os nomes serão criados todos em caixa alta ou
em letras minúsculas. Please enter a request
TABELAS NO SGBD
A seguir, serão apresentados os tipos de tabelas que fazem parte do projeto físico do modelo
de dados dimensional.
TABELA DIMENSÃO
A Dimensão Produto contém os dados Código do Produto e Descrição do Produto.
Apesar de a informação sobre o Fabricante do Produto estar armazenada na tabela Fabricante

no sistema origem, foi adicionada na dimensão Produto como um atributo. A dimensão
receberá o nome dim_produto, junção do prefixo definido na nomenclatura e da palavra
produto que representa os elementos dessa dimensão. As colunas da dimensão devem seguir
o critério estabelecido para a formação dos nomes.
A imagem a seguir ilustra o desenho da dimensão Produto com os nomes físicos dos atributos
nas colunas, o tipo de dados e a informação se a coluna pode ou não ficar nula.
 Tabela: Exemplo da tabela dimensão Produto.
A dimensão contém uma coluna que identifica um registro na tabela, a Surrogate Key. Essa
chave será inserida na tabela fato como chave estrangeira (Foreign Key) para que o
relacionamento entre elas seja realizado.
0/1000
 COMENTÁRIO
Na dimensão Produto, essa chave se chama sk_produto e é identificada pela sigla PK (Primary
Key).
TABELA FATO
Sabemos que a tabela fato reúne as métricas que serão analisadas pelas dimensões e é
relacionada às tabelas de dimensões do modelo. Agora vamos entender os efeitos dessa
relação!
A tabela fato recebe todas as chaves primárias das dimensões que estão ligadas a ela. Como
toda tabela em um banco de dados relacional, a tabela fato possui uma chave primária, que,
em geral, é uma composição de chaves estrangeiras referentes às chaves primárias das
dimensões. Essa chave composta garante que um registro na tabela fato seja único; e caso
haja dois registros com a mesma combinação de chaves, haverá uma exceção que deverá ser
tratada no processo ETL.
Observe o modelo ilustrado a seguir:
A tabela ft_vendas no centro do modelo, recebeu, além das métricas, as chaves estrangeiras
correspondentes às chaves primárias das tabelas dimensões.
0/1000
 Tabela: Exemplo do modelo de dados dimensional físico.
Cada registro da tabela fato representa a venda de um produto de uma categoria para um
cliente, em determinado dia.
Se o mesmo cliente comprar vários produtos no mesmo dia, haverá várias linhas para esse
cliente relacionadas aos diversos produtos comprados.
O campo num_pedido é um dado numérico que não pode ser sumarizado. Ele é o número que
identifica o pedido no sistema transacional. Dados como número de pedido, número de nota
fiscal etc. podem ser importantes para as análises, mas não possuem características que os
definam como uma dimensão. Nesse caso, eles são adicionados diretamente na tabela fato e
são denominados de dimensões degeneradas por não estarem ligados a tabelas de dimensão.
RESTRIÇÕES DE INTEGRIDADE
As restrições de integridade (do inglês integrity constraints ou simplesmente constraints)

servem para garantir que os dados cumpram corretamente as regras estabelecidas para a
carga na base de dados.
 EXEMPLO
No cenário Supermercado, diariamente, ocorrem muitas vendas de produtos.

Obrigatoriamente, temos de informar o produto que está sendo vendido, pois ele possui o
preço que deverá ser pago pelo cliente. No entanto, os dados do cliente podem não ser
informados no ato da venda na loja física, diferentemente da venda realizada pela loja on-line,
onde a identificação do cliente é obrigatória. Com essa particularidade, a informação do cliente
pode ser preenchida ou não, e devemos considerar um tratamento adequado para os casos em
que informação não for preenchida.
As dimensões do DW/DM podem receber os elementos Não Informado e Não se Aplica para
solucionar problemas desse tipo. O elemento Não Informado é utilizado quando um dado
apresenta o valor nulo na área de preparação dos dados. O elemento Não se Aplica é
utilizado quando o preenchimento de um dado para o contexto do registro não se aplica.
0/1000

 Tabela: Exemplo de violação de integridade na tabela fato Vendas a Varejo.
A imagem anterior ilustra um exemplo sobre a unicidade da chave primária na tabela fato e o
caso do cliente não informado. O código sk_cliente igual a 1 representa o dado Não Informado.
Observe que, nas linhas 1 e 3 do exemplo, a coluna relacionada aos clientes está preenchida
com o elemento 1 - Não informado. Além disso, como os clientes compraram o mesmo produto
no mesmo dia, a restrição de unicidade será violada. Para resolver esse problema, o número
do pedido deve ser adicionado na chave primária da tabela fato.
Veja o resultado na imagem a seguir.
 Tabela: Alteração da PK da tabela fato Vendas a Varejo.
Com essa alteração, o problema da unicidade do dado será contornado e o resultado obtido
será conforme ilustrado pela imagem a seguir.
 COMENTÁRIO
As restrições pertinentes às características do SGBD, como, por exemplo, o preenchimento

das chaves primárias e estrangeiras, são facilmente observadas na construção do modelo de
dados dimensional. Contudo, restrições por parte do negócio, como, por exemplo, o cliente Não
Informado, são variadas e devem ser analisadas com atenção para evitar problemas futuros.
 Tabela: Resolução da violação PK na tabela fato Vendas a Varejo.

0 1000
/

TABELAS TEMPORÁRIAS
As tabelas temporárias dão suporte ao processo de ETL. Elas recebem os dados que são
extraídos dos sistemas de origem e auxiliam os tratamentos que devem ser aplicados aos
dados.
Nessas tabelas, não há restrições de chaves e o dado é copiado e carregado sem qualquer
crítica.
Após a carga dos dados, a transformação dos dados pode ocorrer para o conteúdo
armazenado.
Nesse momento, são aplicadas as validações dos dados, a checagem de existência dos
elementos e das chaves, ocorre ainda a integração de dados de sistemas diferentes, entre
outras tarefas.
O resultado das validações, assim como os dados informativos a respeito da limpeza dos
registros, é armazenado nessas tabelas, onde será possível informar que ele deverá ser
carregado na tabela definitiva ou descartado pelo processo.
Assim, normalmente, para cada uma das tabelas dimensões e tabelas fato há uma tabela
temporária que registrará o processo de validação dos dados.
PRATICANDO – COMPLEMENTANDO O MODELO

DE DADOS DIMENSIONAL
Conforme o levantamento de requisitos para a construção das consultas, observou-se a

necessidade de que o modelo de dados dimensional contivesse o desenho apropriado para
acomodar os dados referentes ao estoque dos produtos. Com isso, complete o modelo de
dados dimensional com a tabela fato Estoque (ft_estoque) e os relacionamentos com as
dimensões dim_produto, dim_data e dim_cliente.
 ATENÇÃO 0/1000
Uma observação importante é que, para relacionar a tabela fato Estoque com as dimensões,
não é necessário duplicar as tabelas dimensões,Please enter a request
elas devem ser apenas relacionadas com a
nova tabela fato, compartilhadas com os demais fatos relacionados.
Acrescente também as tabelas temporárias ao modelo. Elas não devem ser relacionadas a
nenhuma das tabelas do modelo de dados dimensional, pois darão suporte ao processo de
ETL. Utilize a ferramenta SQL Power Architect Community Edition para fazer a modelagem.
Na imagem a seguir, vemos o resultado do modelo com a inclusão da tabela fato Estoque e
das tabelas temporárias.
Na cor azul, estão as dimensões;
Na cor laranja, as tabelas fato;
Na cor verde, as tabelas temporárias.
 Modelo de Dados Dimensional DW Supermercado.
 ATENÇÃO
0/1000
Note que não é necessária a criação de uma tabela temporária para a dimensão Data.
POR QUE A CRIAÇÃO DESSA TABELA NÃO É

NECESSÁRIA?
Porque a dimensão Data é carregada previamente, abrangendo o período desejado para o
registro histórico das transações, e não sofre alterações em seu conteúdo, daí sendo
desnecessário manter uma tabela temporária para suportar o processo de ETL.
ARMAZENAMENTO DOS DADOS

A estrutura de armazenamento dos dados de um DW/DM conta com espaço em disco
disponível, processos de backup e deve ser apoiada por um grupo de atividades importantes
para o bom desempenho do DW/DM, como a estrutura correta da criação dos elementos com
os nomes padronizados.
Em caso de extensão do DW/DM, deve ser verificado se os elementos estão adequados, se

não estão sendo criados com repetição, ou se os dados com conceitos já existentes estão
sendo inseridos nas tabelas corretas, entre outras verificações. Importante destacar a
necessidade de manutenção da documentação e do registro das suas versões.
O Administrador de Dados (AD) é o responsável por essas atividades e está presente no

desenvolvimento de projetos de DW, atuando na trilha de Gerenciamento do Projeto, junto ao
gerente do projeto.
Outra atividade importante está relacionada ao Administrador de Banco de Dados (do inglês
DBA – Database Administrator), que é responsável pela criação e manutenção da base de
dados, pela integridade de dados, e se preocupa com o desempenho do sistema de banco de
dados como um todo, muito importante para o DW que possui grandes volumes de dados
armazenados.
O particionamento das tabelas fato e a criação de índices são tarefas realizadas pelo DBA para
que o DW tenha um desempenho melhor nas consultas. O particionamento de tabelas e
0 1000
/
índices é usado para facilitar o gerenciamento de grandes volumes de dados armazenados;
lembre-se de que as tabelas fato podem armazenar milhões ou bilhões de linhas, dependendo
do histórico das transações.
O particionamento divide a tabela em várias tabelas e essa fragmentação pode ser feita
verticalmente ou horizontalmente.
No particionamento horizontal, a quantidade de linhas é reduzida.
No particionamento vertical, a quantidade de colunas é reduzida.

Em geral, o particionamento da tabela fato é feito por fragmentação horizontal baseada no
tempo.
 EXEMPLO
Podem ser criadas partições por mês ou ano, e quando uma consulta for submetida para o ano
2020, apenas a partição que está com o conjunto de dados para 2020 será consultada.
Quando os dados são agrupados nas partições, a busca fica restrita apenas à partição em que
os dados requeridos estão armazenados. Isso minimiza o tempo de consulta, pois evita que a
tabela seja totalmente verificada para trazer os dados solicitados.
Outro recurso que pode ser aplicado pelo DBA são os índices.
Os índices são estruturas que auxiliam a recuperação dos dados de maneira mais rápida. No
DW/DM, que possui alto volume de dados, é recomendado criar os índices para otimizar as
consultas submetidas à base de dados.
Para dados com baixa cardinalidade, isto é, com poucos valores distintos (por exemplo, estado
civil, gênero, forma de pagamento etc.), normalmente são usados índices do tipo bitmap, mas
cada caso deve ser examinado para que a melhor ação seja tomada, dependendo também das
funcionalidades do SGBD utilizado.
Além das partições e dos índices que podem ser criados pelo DBA para melhorar o
desempenho das consultas no ambiente analítico, há também as agregações de dados que
são armazenadas em tabelas. Esse ponto será mais bem explorado nos próximos módulos.
IMPLEMENTAÇÃO DO MODELO DE DADOS 0/1000
DIMENSIONAL
Após a correta preparação da base de dados, a implementação do Modelo de dados
Dimensional pode ser realizada. Como em qualquer projeto de banco de dados, algumas
ferramentas de modelagem geram os scripts para a criação das tabelas, restrições, chaves etc.
Esse recurso facilita a criação dos elementos, que também podem ser criados diretamente no
SGBD seguindo as definições do modelo de dados dimensional físico.
 EXEMPLO
As ferramentas MySQL Workbench e SQL Power Architect, entre outras, possuem esse
recurso.
O SQL Power Architect permite que você escolha o banco de dados onde o modelo será
implementado. No nosso exemplo, vamos criar a base de dados (database) no SGBD
PostgreSQL. A ferramenta usa a conexão feita no início da criação do modelo e executa o
script criando a base de dados, conforme ilustrado a seguir.
 Criação da base de dados.
Nesse momento, a base de dados para o DW Supermercado está criada, no entanto, com o
andamento do projeto e até mesmo depois da conclusão, novas necessidades podem surgir.
Isso significa que o modelo criado pode sofrer alterações
0 1000
para atender às novas demandas.
/

 ATENÇÃO
Esse trabalho deve ser feito com cautela para assegurar que o modelo criado e os dados
contidos nele não sofram perdas devido ao crescimento do ambiente.
É altamente recomendado que as tabelas sejam construídas no ambiente de desenvolvimento
onde os testes são realizados, e somente após esses passos as alterações sejam efetivadas
no ambiente de produção.
Em empresas de grande porte, há ainda um terceiro ambiente chamado Homologação, onde

os elementos desenvolvidos e as alterações feitas no processo são testadas pelo usuário e,
somente após esse passo, a alteração pode ser refletida no ambiente de produção.
CONSTRUINDO O MODELO DE DADOS

DIMENSIONAL E IMPLEMENTANDO NO
SGBD 0/1000
No vídeo a seguir, o especialista construirá o modelo de dados dimensional proposto neste

módulo utilizando a ferramenta SQL Power Architect Community Edition.
MÓDULO 2
 Descrever conceitos avançados de modelagem dimensional envolvendo hierarquias

de dimensões
DIMENSÕES E HIERARQUIAS
As tabelas de dimensões contêm as descrições e explicações dos fatos ocorridos. Geralmente,
possuem muitas colunas de texto de baixa cardinalidade e seus atributos têm importante papel
no filtro das consultas ou nas agregações dos dados contidos na tabela fato.
As tabelas de dimensões podem ser desnormalizadas (esquema Estrela) ou normalizadas no

esquema Floco de Neve, que estende as dimensões em decomposição hierárquica. Assim, as
0/1000
dimensões são organizadas em níveis, onde uma tabela em um nível superior se relaciona com
a tabela do nível abaixo por meio da chave primária.
Essa relação apresenta uma hierarquia que estabelece os níveis dentro de um contexto. A
seguir, vamos entender como as hierarquias se comportam, quais são os seus benefícios e
como elas são representadas no esquema Estrela, que é o modelo dimensional mais utilizado.
Uma hierarquia estabelece a relação entre elementos de um conjunto de dados de um

contexto.
As hierarquias são organizadas em níveis, e o nível mais alto é o elemento que agrupa os
demais elementos que estão abaixo.
Isso permite que os dados da tabela fato sejam visualizados conforme a navegação na
hierarquia, de modo agrupado (nível mais alto) ou detalhado (nível mais baixo).
Algumas dimensões possuem atributos que formam uma hierarquia. Esses atributos possuem
um relacionamento que estabelece a ordem de prioridade dos elementos. Por exemplo, no
modelo de dados dimensional do DW Supermercado, a dimensão Data possui uma hierarquia
formada pelos elementos Dia, Mês e Ano.
 Hierarquia de Data.
A imagem ilustra a hierarquia de Data que é composta pelo Ano, no mais alto nível da
hierarquia; o Mês, no nível intermediário; e o Dia, no nível mais detalhado. Com os dados
básicos de data, é possível criar elementos intermediários que agrupam o dado menos
detalhado. Por exemplo, podemos agrupar os dias em semanas, os meses em bimestre,
trimestre, semestre, entre outros.
No esquema Estrela, os dados ficam desnormalizados

0 1000
em uma única tabela dimensão. Nesse
/
caso, todos os atributos são colunas de uma mesma tabela. Veja o exemplo de outra hierarquia
bastante utilizada nos projetos de Data Warehouse, a de Região geográfica, que relaciona os
dados País, Região, Estado, Cidade e Bairro. A imagem a seguir
Please enter ilustra a Dimensão Região
a request
Geográfica e suas colunas disponibilizam toda a hierarquia de região contendo País, que é o
nível mais alto da hierarquia, Região, Estado, Cidade e Bairro, que é o nível mais granular
dessa visão.
 Hierarquia Região Geográfica.
Algumas hierarquias podem ser representadas sem as repetições dos elementos nas linhas.
Esse tipo de solução utiliza o autorrelacionamento na tabela, em que uma chave estrangeira
aponta para a chave primária da própria tabela.
 Hierarquia de autorrelacionamento.
A imagem anterior ilustra um exemplo da hierarquia de um quadro funcional.
Observe que Joana é a presidente, por isso ela é o primeiro nível da hierarquia. Abaixo de
Joana estão os gerentes Júlia, que possui um subordinado, Miguel, que não possui
0/1000
subordinado, e Ricardo, que possui dois subordinados.
A dimensão acomoda a relação de hierarquia por meio da coluna Código Superior, que é usada
para retornar uma consulta sobre os funcionáriosPlease
e seus superiores.
enter a request
Para retornar os valores, a consulta deverá montar a hierarquia aplicando busca com
recursividade, sendo a coluna Código Superior relacionada com a coluna Código Funcionário
da mesma tabela.
As hierarquias são muito úteis para a navegação dos dados e possibilitam realizar as
operações de Drill Down e Drill Up, detalhando mais ou menos os dados contidos na tabela
fato.
CARGA DAS DIMENSÕES

As dimensões são carregadas com elementos contidos em tabela do banco de dados
transacional. A primeira carga dos dados no Data Warehouse deve inserir todos os elementos
existentes na tabela origem, considerando algumas regras que possam existir, como carregar
no DW somente os registros ativos. Um exemplo disso são clientes antigos, que no sistema de
origem receberam o status inativo por não realizarem compras nos últimos 5 anos.
Após a primeira carga dos dados, os elementos são atualizados conforme forem atualizados no
sistema de origem.
 COMENTÁRIO
Normalmente, as alterações nas dimensões acontecem de maneira esporádica. No entanto, se

pensarmos em uma grande empresa e na sua dimensão de cliente, com 3 milhões de clientes
ativos, ela pode ser atualizada diariamente, já que o volume de dados é muito grande.
Além disso, uma dimensão desse porte pode receber novos clientes diariamente e ainda
cancelar os que estão ativos.
0/1000
 EXEMPLO
Uma operadora de telefonia que diariamente vende pacotes

Please enter apara novos clientes, ou quando
request
vários clientes precisam ser cancelados por terem migrado para outra operada. Os registros
desses clientes precisam ser modificados de acordo com a situação atual, com a data de
cancelamento, entre outros dados.
DIMENSÕES HISTÓRICAS
Alguns negócios precisam, além de acompanhar os fatos ao longo do tempo, manter o histórico
de atributos para analisar os dados conforme a situação em um momento do tempo, mas não
em relação ao fato, e sim ao contexto que o descreve. Para uma organização, pode ser
importante acompanhar a situação de estado civil dos clientes, não somente se estão casados,
mas se eram solteiros quando se tornaram clientes.
Para resolver essas questões, há algumas soluções que podem ser aplicadas, como criar uma
tabela de suporte que armazene as informações históricas dos atributos relacionando a
dimensão e quais são as alterações realizadas; para cada dimensão, criar uma tabela de
suporte que guarde apenas as alterações do atributo desejado; ou ainda, na própria dimensão,
criar colunas para informar a data de início de vigência e a data fim de vigência do registro,
onde o registro com a data de fim de vigência fechada mantém os dados sem alteração e o
novo registro com nova data de início de vigência recebe as alterações realizadas pelo sistema
origem.
A imagem a seguir ilustra:
Um exemplo de alteração direta no registro existente (Dimensão Cliente 1).
Um exemplo de alteração com datas de início e fim de vigência do registro (Dimensão

Cliente 2).
0/1000
 Tabelas: Tabela Dimensão Cliente 1 e Tabela Dimensão Cliente 2.
Com as colunas de data de início e fim de vigência, é possível saber que do dia 11/03/2001 ao
dia 26/06/2010 o José constava na base de clientes com o status Casado. Esse tipo de
informação pode, por exemplo, ser usado para a oferta de produtos destinados à situação que
o cliente se encontra.
APRESENTANDO CONCEITOS AVANÇADOS

DE DIMENSÕES
No vídeo a seguir, o especialista apresentará os conceitos avançados de modelagem
dimensional envolvendo hierarquias de dimensões e dimensões históricas.
0/1000
MÓDULO 3
 Descrever o processo de agregação e consolidação dos dados em tabela fato

visando à otimização de consultas
TABELA FATO AGREGADA

A tabela fato armazena as métricas que serão descritas pelas dimensões.
Quanto maior a granularidade da tabela fato, maior a quantidade de registros contidos na

tabela. O grão atômico armazenado na tabela fato correspondente ao grão do nível mais
detalhado das transações operacionais e garante que qualquer consulta submetida pelo
usuário poderá ser respondida, desde que a transação tenha sido registrada no sistema
transacional.
Para agregar os dados contidos na tabela fato, algumas funções são aplicadas às métricas
para que os dados sejam apresentados conforme a necessidade do usuário. Essas funções
realizam somas nas métricas (SUM), apresentam o menor valor ou o maior valor de uma
métrica (MIN e MAX), realizam contagem (COUNT) e aplicam médias (AVG).
Realizar esses cálculos em uma tabela fato com milhões de registros, no grão mais baixo, é
muito oneroso para as ferramentas de visualização. O relatório ou dashboard demora certo
tempo para a exibir o resultado da consulta, e isso pode causar transtornos pela demora da
informação. Para resolver esse problema, podemos trabalhar com a agregação dos dados,
visando a melhorar a performance das consultas.
0/1000
 COMENTÁRIO
A agregação de dados é um resumo dos dados da tabela fato que visa a um bom desempenho
das consultas do Data Warehouse. Esse recurso não traz custos ao projeto e pode evitar o
investimento em hardware, então a relação custo/benefício se torna muito atraente para a
melhoria de desempenho.
A tabela fato agregada armazena informações pré-calculadas de acordo com nível de
granularidade, mais alto do que a tabela fato transacional, que apresenta os dados no nível
mais detalhado. Por esse motivo, esse tipo de tabela apresenta o volume de dados menor do
que a tabela fato transacional.
A carga e atualização dos dados podem ser feitas com os dados lidos diretamente do sistema
origem ou das tabelas fato transacionais. Se a origem da agregação for as tabelas fato
transacionais, as tabelas agregadas não precisam de tabelas temporárias para darem suporte
ao processo ETL, pois os dados armazenados já estão validados. No entanto, se os dados são
lidos diretamente no sistema transacional, existe a possibilidade de ocorrer um problema, então
é recomendado que a leitura seja feita com base na tabela temporária da tabela fato.
Para criar uma tabela fato agregada, você precisa analisar quais são os fatos submetidos ou
que serão submetidos às funções de agregação constantemente, e por quais atributos eles são
ou serão agregados. Esse conjunto de dados é um forte candidato a virar uma tabela fato
agregada. Caso a consulta submetida apresente os dados de forma resumida, mas contenha
um atributo que não esteja presente na tabela fato agregada, a consulta é direcionada para a
tabela fato transacional que contenha a combinação solicitada.
O exemplo ilustrado a seguir apresenta os dados da tabela fato Vendas no nível de Número do
pedido, Produto, Cliente e Data da venda.
 Tabela fato Vendas a Varejo.
Vamos construir a tabela fato agregada baseada em uma das análises realizadas pelos
0/1000
gerentes do Supermercado:
QUAIS SÃO OS PRODUTOS MAIS VENDIDOS NO

VERÃO?
Observe que a necessidade é avaliar a venda de produtos para construir a tabela agregada
para análises referentes aos produtos. Podemos agregar os dados preservando apenas as
dimensões que fazem parte do contexto da análise. Nesse caso, vamos manter o produto, a
categoria do produto, a data da venda e as métricas.
Veja o resultado na imagem a seguir.
 Tabela fato agregada Vendas Produto.
Esse comportamento é refletido no modelo de dados dimensional que receberá o desenho da

tabela agregada mantendo apenas o relacionamento com as dimensões que atenderão às
análises focadas no produto.
 Tabela: Modelo da tabela fato agregada agr_vendas_produto.
A tabela agregada agr_vendas_produto, ilustrada na imagem anterior, mantém apenas as

chaves da dimensão Produto e da dimensão Data. Na tabela fato agregada, a métrica
qt_produto_venda representa o somatório das quantidades de produtos que foram vendidos no
grão Dia, e a métrica vl_produto_venda representa o somatório dos valores pagos pelos
produtos no grão Dia.
A tabela fato agregada é transparente para os usuários do DW, pois a ferramenta de

visualização direciona as consultas para as agregadas
0 1000 sem que haja interferência e
/
conhecimento de quem está submetendo a consulta.
Ainda sobre as agregações, existem algumas métricas que não podem ser sumarizadas, pois
são métricas não aditivas, ou que só podem ser sumarizadas por determinadas dimensões, as
métricas semiaditivas. Fique sempre atento a quais métricas você aplicará à agregação para
que não obtenha valores errados ou distorcidos.
Agora, adicione a tabela fato agregada ao modelo de dados dimensional e a relacione com as
dimensões Produto e Data. Para as tabelas fato agregadas utilize o prefixo agr_. Na imagem a
seguir, o resultado dessa tarefa é apresentado.
No SGBD, a criação e atualização da tabela fato agregada são realizadas através do recurso
de visão (VIEW), que nada mais é do que uma consulta à tabela fato transacional realizando a
sumarização desejada. Existe um conhecido trade-off no projeto de DW/DM que é a decisão
sobre armazenar ou não o resultado da VIEW, ou seja, materializar ou não a consulta como
uma nova tabela no banco de dados. O conteúdo da tabela fato agregada pode depender do
momento da execução da VIEW sobre a tabela fato transacional, o que significa que a tabela
fato agregada pode se tornar obsoleta, requerendo uma nova execução da VIEW para atualizar
a tabela.
A decisão sobre armazenar ou não uma tabela fato agregada dependerá de estudo de
desempenho do sistema quanto ao espaço de armazenamento necessário (que pode ser
exponencial, dependendo no número de hierarquias e de níveis de agregação) e quanto ao
tempo de execução da reorganização do banco de dados sempre que uma recarga das tabelas
fato transacionais ocorrer no sistema.
0/1000
 Modelo de Dados Dimensional com tabela fato agregada Vendas Produto.

TABELA FATO CONSOLIDADA

Algumas necessidades do negócio envolvem análises compostas por métricas armazenadas
em diferentes tabelas fato. Muito semelhante à tabela fato agregada, a tabela fato consolidada
agrega dados unindo aqueles contidos em mais de uma tabela fato. Para que isso aconteça, os
dados precisam estar no mesmo nível de granularidade de uma dimensão comum aos dois
assuntos. Uma dimensão muito utilizada nesse tipo de análise é a dimensão data.
Para exemplificar esse conceito, vamos utilizar outra análise do cenário Supermercado: Quais
são os fabricantes dos produtos que oferecem maior lucro na comercialização dos seus itens?
Para que seja possível avaliar o lucro referente aos produtos, é necessário consultar dados na
tabela fato Vendas, onde está o valor do produto vendido, e na tabela fato Estoque, onde está
o preço de custo do produto. Contudo, a tabela fato Vendas está no grão Dia e a tabela fato
Estoque está no grão Mês. Isso significa que só será possível avaliar o lucro do produto por
mês, devido à granularidade da segunda tabela fato.
A solução para esse problema é agregar o dado da tabela fato Venda para o mês e então
consolidá-lo com a tabela fato Estoque. A tabela fato Estoque é relacionada à dimensão Data
sempre pelo dia 01 de cada mês, representando o mês.
O primeiro passo é obter o valor das métricas calculadas, o Valor da Receita Total e o Valor do
Custo Total, onde:
VALOR DA RECEITA TOTAL = VALOR DO

PRODUTO VENDIDO X QUANTIDADE DE
PRODUTO VENDIDO
0/1000
VALOR DO CUSTO TOTAL = CUSTO DO

PRODUTO X QUANTIDADE DE PRODUTO
VENDIDO
 Tabelas: Tabela Fato Vendas e Tabela Fato Estoque.
Na imagem anterior, a tabela consolidada reunirá os dados necessários para apresentar o

resultado esperado nas consultas sobre o lucro dos produtos.
 ATENÇÃO
Observe que a data na tabela fato Vendas é nomeada como data_vendas e na tabela fato
Estoque é nomeada como data_estoque.
Para representar a data na tabela consolidada, podemos nomear a data com uma descrição
que represente a união das duas informações. Assim, vamos usar em nosso exemplo o nome
data_competência, pois os registros consolidados competem a determinado mês.
As métricas calculadas Valor Receita Total e Valor Custo Total são adicionadas à tabela fato
consolidada, assim como a métrica calculada Lucro, onde o Lucro é obtido do cálculo Valor
Receita Total menos o Valor Custo Total. Conforme ilustrado na imagem a seguir.
0/1000
 Tabela: Tabelas Fato Consolidada Lucro.
Além das métricas calculadas criadas, podemos deixar pré-calculado o percentual de lucro
obtido. Para isso, basta dividir o lucro pelo valor Please
receitaenter
totalaerequest
multiplicar o resultado por 100.
Por exemplo, o Lucro do produto 1 é R$ 85,88 e a Receita total é R$ 199,88, assim temos:
R$ 85,88 / R$ 199,88 = 0,43 = 43%
 Atenção! Para visualização completa da equação utilize a rolagem horizontal
Logo, para o produto 1, o lucro obtido no mês 09/2020 é igual a 43%. Normalmente, esse tipo
de cálculo é realizado pelas ferramentas de visualização.
Agora, adicione a tabela consolidada ao modelo de dados dimensional do DW Supermercado e

relacione com as dimensões adequadas. Após a inclusão das tabelas no modelo, o resultado
deve estar parecido com a imagem a seguir. Então, gere o script e execute apenas o DDL das
novas tabelas e das constraints no SGBD.
 Modelo de Dados Dimensional com tabela fato consolidada Lucro Produto.
A implementação das tabelas fato consolidadas também se dá por meio de consultas do tipo
0 1000
VIEW, assim como nas tabelas fato agregadas. Assim,
/ o mesmo trade-off entre materializar ou
não as tabelas ocorre com as tabelas fato consolidadas.

EVOLUINDO O MODELO DE DADOS
DIMENSIONAL COM FATOS AGREGADOS E
CONSOLIDADOS
No vídeo a seguir, o especialista evoluirá o modelo de dados dimensional proposto no módulo
anterior com o uso de fatos agregados e consolidados utilizando a ferramenta SQL Power
Architect Community Edition.
0/1000
CONCLUSÃO
CONSIDERAÇÕES FINAIS
Ao longo deste conteúdo, abordamos técnicas a serem aplicadas no projeto físico do modelo
de dados dimensional, algumas restrições que devem ser consideradas e aspectos relevantes
para o armazenamento dos dados.
Por fim, apresentamos conceitos avançados importantes na construção do Data Warehouse,

como estruturas das hierarquias de atributos nas dimensões, as tabelas fato de agregação e
consolidação de dados. Realizamos ainda a implementação do modelo de dados dimensional
físico no SGBD.
O conhecimento dessas técnicas de projeto de banco de dados é essencial para o profissional

de Business Intelligence, por se tratar da base para a qualidade da análise de dados.
 PODCAST
Ouça agora um resumo dos assuntos abordados no conteúdo que você acabou de estudar.
0/1000
AVALIAÇÃOPlease
DOenter
TEMA:
a request
REFERÊNCIAS
KIMBALL, M. R. R. The Data Warehouse Toolkit - The Definitive Guide to Dimensional
Modeling. 3. ed. Indianapolis, Indiana: John Wiley Sons, 2013.
MONTEIRO, V. G. Arquitetura de Data Warehouse e Data Marts. Rio de Janeiro: YDUQS,

2021.
NAVATHE, S. B.; ELMASRI, R. Sistemas de Banco de Dados 6ª ed. São Paulo: Pearson
Addison Wesley, 2011.
PITON, R. Data Warehouse Passo a Passo – O guia prático de como construir um Data
Warehouse do zero. Porto Alegre: Raizzer, 2018.
EXPLORE+
Você já possui um SGBD instalado? A criação da base de dados pode ser feita em qualquer
SGBD relacional, mas caso ainda não tenha um preferido, você pode visitar os sites dos
SGBDs: PostgresSQL e MySQL, e escolher um deles para realizar os exercícios. Eles
possuem licença livre, são simples de instalar e atendem ao padrão SQL do modelo relacional
de banco de dados.
Para saber mais sobre funcionalidades dos SGBDs relacionais existentes no mercado, busque
tabelas comparativas em “Comparison of relational database management systems”, no site
Wikipedia.
O Capítulo 2 do livro The Data Warehouse Toolkit - The Definitive Guide to Dimensional
Modeling, de Ralph Kimball, traz um resumo sobre modelagem dimensional, com seções sobre
hierarquias em dimensões e fatos agregados.
Uma excelente fonte de recursos sobre Modelagem Dimensional, além dos consagrados livros
0 1000
textos do autor Ralph Kimball, estão registrados no/ site do Kimball Group, contendo referências
a artigos e dicas de projeto. Embora o grupo tenha “fechado as portas” em dezembro de 2015,
o site vem sendo atualizado com recursos disponibilizados pelos consultores que sucederam o
patriarca.
O livro Data Warehouse Passo a Passo, de Rafael Piton, também aborda esses temas nas
seções “Dimensão hierárquica: pai-filho” e “Fato agregada”.
CONTEUDISTA
Conteúdo original: Vivian Gabriela Santos Monteiro
Adaptação e conversão: Antonio Felipe Podgorski Bezerra
 CURRÍCULO LATTES
0/1000

1 - Princípios de Big Data-Combined - Compressed

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

1 - Princípios de Big Data-Combined - Compressed

Enviado por

Direitos autorais:

Formatos disponíveis

9/5/23, 3:15 PM Princípios de Big Data

Princípios de Big Data

Introdução e Aplicações ao Big Data

Reconhecer os conceitos e as aplicações de Big Data.

Conceitos de IOT e Computação

Plataformas em Nuvem para Aplicações de

Processamento e Streaming de Dados

Para respondermos a essas perguntas, vamos analisar algumas situações práticas.

A popularização do uso da internet aumentou a capacidade de as pessoas se comunicarem. Dessa maneira,

seríssimos prejuízos financeiros, materiais e de reputação.

A Os serviços de transações bancárias on-line.

B Um sistema cliente x servidor com acesso a um banco de dados em MySQL.

C Um sistema de controle de estoques de uma loja de médio porte.

D Um sistema de controle de livros de uma biblioteca de uma grande metrópole.

E Um sistema para controlar a produção de alimentos de uma fazenda.

Parabéns! A alternativa A está correta.

A Começar a monitorar a aplicação.

B Mapear cada um dos 5 Vs com os aspectos estruturais e operacionais da aplicação.

C Estudar os conceitos de Big Data e tentar contextualizá-los.

D Não fazer nada, pois o sistema já está em funcionamento.

E Propor melhorias no sistema para que acompanhe as tendências tecnológicas.

Parabéns! A alternativa B está correta.

Digite sua resposta aqui

Fazemos buscas na internet.

Fazemos compras on-line.

Esse crescimento do volume de dados e de toda a complexidade que os envolve

Conceitos sobre Big Data

Arquitetura básica de Big Data

Fontes de dados (data sources) expand_more

Armazenamento de dados (data storage) expand_more

Escalabilidade: capacidade de crescer com consistência.

Disponibilidade: prontos para serem acessados sempre que forem demandados.

Segurança: mecanismos que garantam a privacidade e restrição de acesso.

Padronização: armazenamento seguindo um padrão que facilite, posteriormente, a sua

Processamento em lote (batch processing) expand_more

Ingestão de mensagens (message ingestion) expand_more

Consiste em agrupar os dados e trazê-los para um sistema de processamento de dados, onde

Processamento de fluxo (stream processing) expand_more

Armazenamento de dados analíticos (analytical data store) expand_more

Consiste no armazenamento de dados de negócios, mercado e clientes para posterior análise. As

Análise e relatórios (analysis and reporting) expand_more

Os 3 V’s do Big Data: Volume, Velocidade e

Os 4 V’s do Big Data: Volume, Velocidade,

Os 5 V’s do Big Data: Volume, Velocidade,

Precisamos conhecer como o volume de dados é medido. Basicamente, temos:

Um projeto de Big Data precisa equilibrar os tempos

Dados não estruturados

Um projeto de Big Data precisa utilizar técnicas que

Aplicações de Big Data

Falta pouco para atingir seus

Vamos praticar alguns conceitos?

A complexidade da arquitetura de um projeto de Big Data está relacionada a dois

Parabéns! A alternativa A está correta.

Dispositivos eletrônicos podem ser conectados diretamente à Internet, transmitindo

Apesar de ainda não serem aplicados na área de entretenimento, existe um grande

Parabéns! A alternativa C está correta.

Para entendermos essas questões na prática, vamos analisar uma situação.

O primeiro deles é determinar qual é a necessidade. Tudo começa por aí:

O que queremos monitorar?

A As aplicações de IoT utilizam tecnologias de um único fornecedor.

B Todas as aplicações de IoT têm baixa tolerância de falhas.

C As diversas fontes das aplicações de IoT devem produzir resultados distintos.

D A melhor linguagem de programação para trabalhar com IoT é Python.