Introdução à Ciência de Dados - ICDA6

Aula 2

Resumo
1. Transformação de dados
2. ETL
3. Armazenamento analítico
4. Prática: Dashboards e cubo de dados

Transformação de Dados
Transformar dados é alterar sua estrutura para torná-lo adequado a um processo específico,
normalmente um processo de análise ou mesmo construção de data warehouse. Normalmente
ocorrem transformações estruturais significativas nos dados, resultando, inclusive, no aumento
do volume.

A transformação de dados é necessária porque dados são produzidos em uma estrutura

otimizada para persistência e processamento: estas estruturas não são boas para outras
operações, como análise de dados.

Apesar de existirem vários motivos e métodos que requerem transformação de dados, existem
estruturas que historicamente são otimizadas para a análise. Uma delas, consagrada desde os
anos 1990, são os modelos dimensionais. O outro, mais recente, é a construção de depósitos de
dados em sistemas de arquivos distribuídos, HDFS – Hadoop Distributed File System, utilizando
o modelo MapReduce.

ETL
O uso de processos de ETL (Extract, Transform and Load) compreende carga de dados em data
warehouse, assim como integração de dados e construção de modelos analíticos. Um ETL possui
conexões com fontes de dados que podem ser heterogêneas e geograficamente dispersas;
processos de extração que irão, através da conexão, copiar dados destas fontes; um processo
de arquivamento que conservará dados em disco temporariamente para a etapa seguinte e,

1
finalmente, os procedimentos de transformação e o arquivamento que carrega os dados na sua
fonte definitiva. Alguns produtos permitem que a etapa de staging seja executada em memória,
sem a necessidade de persistir os dados em disco. Os dados de staging podem ser mantidos
mantidos entre os diferentes processos, ou são apagados e totalmente reconstruídos. A Figura 1
mostra um processo simplificado de ETL.

Figura 1. Processo de ETL

O processo de transformação pode ter muitos objetivos: transformar um modelo relacional para
um modelo multidimensional, o que incluirá operações de junção, sumarização e cálculos
diversos. A transformação também pode executar rotinas de qualidade e limpeza de dados,
como remoção de duplicados e mudança de codificação. Normalmente, o processo de ETL é um
batch executado em determinados intervalos quando os sistemas de origem possuem uma carga
de uso menor ou simplesmente não estão sendo operados. Outros processos mais críticos
podem ser executados em tempo real ou quase real, são os processos conhecidos como
streaming. O tempo entre as cargas de um processo de ETL é conhecido como latência. No
arquivamento, não ocorre atualização ou exclusão de dados. Um data warehouse sofre apenas
operações de leitura e inclusão.

Fontes de dados, como notas fiscais eletrônicas, podem vir na forma de arquivos. Boas
ferramentas de ETL são capazes de monitorar pastas e iniciar a importação de arquivos assim
que eles são adicionados ao diretório. Este processo pode apagar os arquivos após a
importação ou manter informações históricas para que os dados não sejam importados em
duplicidade. Um processo de ETL tem um alto custo computacional e está sujeito a uma
variedade de tipos de falhas: indisponibilidade da rede, falhas em discos, indisponibilidade dos
sistemas de origem. Bons produtos de ETL devem ser capazes de se recuperarem de falhas, no
sentido de continuarem o processo de um ponto de parada, minimizando os impactos causados
por problemas diversos.

Integração de Dados

2
Um processo de ETL é um processo de integração de dados. As organizações normalmente
dependem de muitos processos de integração que são vitais para o funcionamento de
departamentos, por exemplo, integrar a folha de pagamento com a contabilidade. A integração
de dados também permite que dados sejam trocados com fornecedores, clientes, parceiros etc.

Armazenamento Analítico
Data Warehouse

Um data warehouse guarda informações históricas por um período de 3 a 10 anos. Normalmente,

a informação armazenada provém de muitos sistemas transacionais diferentes. Em um sistema
transacional, não há uma preocupação em se manter o histórico dos dados. Em um data
warehouse, a informação é constantemente atualizada, mantendo-se um histórico. Ao contrário
de um SGBD operacional no qual são feitas operações de inclusão, alteração e atualização, no
data warehouse apenas se inclui dados.

Características do Data Warehouse

1. Orientado ao assunto

Os data warehouses normalmente fornecem uma visão concisa e direta em torno de um assunto
específico, como cliente, produto ou vendas, em vez das operações contínuas da organização
global. Isso é feito excluindo dados que não são úteis em relação ao assunto e incluindo todos
os dados necessários aos usuários para entender o assunto, como mostra a Figura 2.

Figura 2. Característica do data warehouse: orientando ao assunto (Extraído de

https://www.javatpoint.com/data-warehouse)

3
 2. Integrado

Um data warehouse integra várias fontes de dados heterogêneas, como RDBMSs, arquivos
simples e registros de transações online. Requer a execução de limpeza e integração de dados
durante o armazenamento de dados para garantir consistência nas convenções de
nomenclatura, tipos de atributos, etc., entre diferentes fontes de dados, como mostra a Figura 3.

Figura 3. Característica do data warehouse: integrado (Extraído de

https://www.javatpoint.com/data-warehouse)

3. Tempo variável

As informações históricas são mantidas em um data warehouse. Por exemplo, pode-se recuperar
arquivos de 3 meses, 6 meses, 12 meses ou até mesmo dados anteriores de um data warehouse.
Essas variações com um sistema de transações, onde muitas vezes apenas o arquivo mais atual
é mantido.

4. Não volátil

O data warehouse é um armazenamento de dados fisicamente separado, que é transformado a

partir do RDBMS operacional de origem. As atualizações operacionais dos dados não ocorrem
no data warehouse, ou seja, as operações de atualização, inserção e exclusão não são
realizadas. Geralmente requer apenas dois procedimentos no acesso aos dados: carregamento
inicial dos dados e acesso aos dados (Figura 4). Portanto, o DW não requer recursos de
processamento, recuperação e simultaneidade de transações, o que permite uma aceleração

4
substancial da recuperação de dados. Não Volátil define que, uma vez inserido no warehouse, os
dados não devem ser alterados.

Figura 4. Característica do data warehouse: não volátil (Extraído de

https://www.javatpoint.com/data-warehouse)

Data Marts

Um data warehouse normalmente é dividido em partes menores e melhor gerenciáveis, os data

marts. Departamentos corporativos estão agrupados em diferentes data marts, como por
exemplo, finanças, contabilidade, recursos humanos, CRM etc. É possível ainda encontrar data
marts gerenciados por departamentos, de forma autônoma e isolada do restante da organização.
A Figura 5 mostra conceitualmente como um data warehouse é estruturado.

Figura 5. Estrutura de um data warehouse.

5
Fatos, Dimensões e Medidas

Um data warehouse utiliza o modelo multidimensional que tem como elemento central um fato.
O fato é a informação central, o tema ao qual se quer analisar. Um fato possui medidas que são
valores a serem analisados e pré-calculados. Um fato também possui dimensões que são os
diversos pontos de vista sobre o qual se quer analisar o fato. A Figura 6 mostra a estrutura de um
fato ”Vendas”, com suas dimensões e medidas. Uma dimensão tempo também é obrigatória, pois
um data warehouse traz dados históricos. Um fato ”Vendas” pode responder a perguntas como:
quem vendeu mais no bimestre? Qual produto apresentou a maior margem de lucro? Quem foi
nosso maior cliente? (Figura 7).

Figura 6. Fatos, dimensões e medidas

Figura 7. Fato vendas

6
Um fato não é construído para gerar um único tipo de relatório ou gráfico: ele pode produzir uma
variada gama de elementos, de acordo com o que se está analisando (Figura 8).

Figura 8. Elementos gráficos de um BI

Outra possibilidade é utilizar um indicador de performance, conhecido como KPI (Key

Performance Indicator), que é um elemento gráfico que mostra o desempenho de um objetivo. O
valor a ser atingido, a meta do indicador, é parametrizada. Os dados de desempenho
normalmente vêm de algum sistema informatizado da organização. A Figura 9 é um exemplo de
um KPI de vendas.

Figura 9. Indicador de performance

Na modelagem multidimensional utilizada em data warehouses, um fato central está relacionado

às suas dimensões por uma chave substituta. A chave substituta é produzida no processo de
construção do data warehouse e não tem valor semântico, porém, ela é a garantia de que o
histórico das transações será mantido. Por exemplo, se o tipo do cliente mudar, um novo registro
terá que ser incluído na dimensão ”Cliente”. Caso se utilizasse a chave primária do cliente ao
invés da chave substituta, perderíamos o histórico da atualização. As medidas são armazenadas
junto à tabela fato.

O modelo multidimensional é esquematizado na notação conhecida como estrela. Uma segunda

forma, conhecida como floco de neve, mantém uma relação de um para muitos em dimensões
com dados que normalmente não são alterados.

7
A Figura 10 mostra o fato “Vendas” modelado no esquema estrela. O fato se encontra ao centro.
Junto à tabela fato são registradas as medidas que tiveram seus valores já calculados durante o
processo de carga: quantidade, total, impostos, lucro. Ao seu redor, temos as dimensões
“Cliente” e “Produto” e uma dimensão “Data”. As dimensões “Cliente” e “Produto” têm chave
substituta: “IDVenda” e “IDCliente”. A chave primária do banco relacional também é mantida, mas
como um atributo comum, denominado “Código”.

Figura 10. Modelo estrela

O modelo floco de neve tem os mesmos princípios de organização do modelo estrela, porém,
onde existam atributos de dimensões que não mudem constantemente, pode-se adicionar um
relacionamento um para muitos com outra tabela. Na figura 11 o atributo ”País”: a cada novo
registro, o país é incluído. No modelo floco de neve, é criada uma tabela ”Países” e é adicionado
um relacionamento com a dimensão.

8
 Figura 11. Modelo floco de neve

Granularidade

O nível de detalhamento em que a informação gerencial é armazenada é conhecido como

“Grão”. Quanto menor o “Grão”, maior o nível de detalhe, mais performance e armazenamento é
exigido do data warehouse. Definir o “Grão” é uma etapa fundamental na construção de um fato.
A Figura 12 mostra como diferentes níveis de ”Grão” podem ser definidos.

Figura 12. Grão

OLAP

OLAP (Online Analytical Processing) é um gerenciador de banco de dados multidimensional, que

normalmente está associado à construção de cubos, o que suporta a análise complexa.. Um data

9
warehouse normalmente é construído em um OLAP Server, que é um tipo de aplicação otimizado
para gerenciar dados em formato multidimensional. Alguns gerenciadores de banco de dados
relacionais também oferecem produtos a fim de implementar os modelos multidimensionais para
a construção de data warehouses. Ele pode ser usado para executar consultas analíticas
complexas sem prejudicar sistemas transacionais.

Os bancos de dados que uma empresa usa para armazenar todas as suas transações e registros
são chamados bancos de dados OLTP (processamento de transações online). (Figura 13).

Figura 13. Exemplo de OLAP. (Extraído de

https://docs.microsoft.com/pt-br/azure/architecture/data-guide/relational-data/online-analytical-pr
ocessing)

Business Intelligence

Business Intelligence (BI) ou inteligência de negócios, normalmente está associado a gráficos

interativos e cubos, mas a expressão é muito mais abrangente. BI se refere à metodologia,
ferramentas e técnicas de produzir dados para apoio à decisões. Normalmente, um BI está
estruturado sobre um data warehouse, porém, pode estar ainda relacionado diretamente a um
sistema transacional, planilhas ou até mesmo em arquivos planos.

Alguns elementos visuais como relatórios e dashboards podem ser resultantes de um BI.

Relatórios

Relatórios produzem informação detalhada, de forma estática e sem interatividade, ou seja, não
é possível aumentar ou reduzir o grão na própria interface do relatório. Um relatório tem caráter
operacional, para atividades de conferência.

10
 Figura 14. Exemplos de relatório.

Cubos

Cubos são representações multidimensionais de dados, que normalmente representam um único

fato, em que através de operações de drill down (executar o processo do menor detalhe para o
maior) e drill up (executar o processo inverso), o usuário pode aumentar ou diminuir o nível de
detalhamento da informação. Nas linhas e colunas, um cubo representa dimensões, ao centro,
medidas. Sua representação principal é textual, porém, algumas ferramentas podem facilmente

11
produzir gráficos. Outras, mais sofisticadas, permitem ainda a inclusão de indicadores de
performance dentro de células de medidas.

Figura 15. Exemplos de cubo (data cube)

Dashboards

Dashboards são painéis visuais que mostram indicadores de um mesmo assunto. Trazem
informação resumida, normalmente de cunho estratégico ou gerencial, mas também têm
aplicações nas áreas operacionais. Oferece características de navegação dos dados, como
filtros, drill downs e drill ups. Embora não deva conter detalhes, pode trazer os melhores ou os

12
piores. Também pode conter indicadores de performance. Estão normalmente conectados a data
marts.

Infográficos

Infográficos são elementos extremamente ricos visualmente, mas que não estão conectados a
uma fonte de dados: a informação é um retrato estático em um ponto no tempo.

Mini projeto 2
Todos os seus mini-projetos deverão ficar disponíveis no GitHub. Use-o como repositório para
seu portfólio.

1. Acesse o link com demos https://shiny.rstudio.com/gallery/.

2. Modifique o código https://shiny.rstudio.com/gallery/telephones-by-region.html e obtenha
um app que mostre o montante x ano/mês. O usuário poderá selecionar por estado.
3. Analise a base_data.csv. Construa um dashboard para que apresente as informações
relevantes que possam ser oferecidas para os tomadores de decisão.

Material complementar
olapR (pacote de R nos Serviços de Machine Learning do SQL Server)

https://docs.microsoft.com/pt-br/sql/machine-learning/r/ref-r-olapr?view=sql-server-ver16

Referências
Amaral, Fernando. Introdução à Ciência de Dados. 2016. Alta Books.

Provost F, Fawcett T. Data Science for Business. Sebastopol: O’Reilly, 2013.

Provost F, Fawcett T. Data Science and its Relationship to Big Data and Data-Driven Decision
Making.Big Data.Mar 2013.51-59.http://doi.org/10.1089/big.2013.1508. Disponível em
https://www.liebertpub.com/doi/full/10.1089/big.2013.1508

13
14