Prévia do material em texto
W
BA
07
48
_v
1.
0
MODELAGEM E ARQUITETURA
DO DW (DATA WAREHOUSE)
© 2019 por Editora e Distribuidora Educacional S.A.
Todos os direitos reservados. Nenhuma parte desta publicação poderá ser
reproduzida ou transmitida de qualquer modo ou por qualquer outro meio,
eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de
sistema de armazenamento e transmissão de informação, sem prévia autorização,
por escrito, da Editora e Distribuidora Educacional S.A.
Presidente
Rodrigo Galindo
Vice-Presidente de Pós-Graduação e Educação Continuada
Paulo de Tarso Pires de Moraes
Conselho Acadêmico
Carlos Roberto Pagani Junior
Camila Braga de Oliveira Higa
Carolina Yaly
Giani Vendramel de Oliveira
Juliana Caramigo Gennarini
Nirse Ruscheinsky Breternitz
Priscila Pereira Silva
Tayra Carolina Nascimento Aleixo
Coordenador
Nirse Ruscheinsky Breternitz
Revisor
Renata Maria Silva Costa
Wendel Brustolin
Editorial
Alessandra Cristina Fahl
Beatriz Meloni Montefusco
Daniella Fernandes Haruze Manta
Hâmila Samai Franco dos Santos
Mariana de Campos Barroso
Paola Andressa Machado Leal
Dados Internacionais de Catalogação na Publicação (CIP)
Catarino, Iolanda Claudia Sanches
C357m Modelagem e arquitetura do DW (data warehouse)/
Iolanda Claudia Sanches Catarino, Marise Miranda -
Londrina: Editora e Distribuidora Educacional S.A. 2019.
156 p.
ISBN 978-85-522-1536-3
1. Big data. 2. Banco de dados. I. Catarino, Iolanda
Claudia Sanches. II. Miranda, Marise. Título.
CDD 000
Thamiris Mantovani CRB: 8/9491
2019
Editora e Distribuidora Educacional S.A.
Avenida Paris, 675 – Parque Residencial João Piza
CEP: 86041-100 — Londrina — PR
e-mail: editora.educacional@kroton.com.br
Homepage: http://www.kroton.com.br/
http://www.kroton.com.br
MODELAGEM E ARQUITETURA DO DW (DATA WAREHOUSE)
SUMÁRIO
Apresentação da disciplina......................................................................................04
Banco de Dados Transacionais versus Bancos de Dados Analíticos.................05
Conceitos básicos sobre Data Warehouse..............................................................32
Data Marts...................................................................................................................58
Modelagem de dados para um Data Warehouse................................................82
Esquema Estrela e Esquema Floco de Neve .................................................. 110
Ferramentas de Dados em um Data Warehouse ..................................................131
Mineração de Dados em Data Warehouse .............................................................154
3
Apresentação da disciplina
A disciplina Modelagem e Arquitetura de Data Warehouse contempla
a modelagem, arquitetura com seus componentes e os tipos de
ferramentas que integram um ambiente de Data Warehouse. No
primeiro tema da disciplina, contextualiza-se os princípios, elementos
e características dos bancos de dados transacionais e dos bancos de
dados analíticos. No segundo e terceiro temas, fundamenta-se os
conceitos de Data Warehouse e Data Marts, abordando o ambiente,
a arquitetura e a relação entre os componentes de um ambiente de
Data Warehouse. O quarto tema, introduz a modelagem de dados para
Data Warehouse, abordando um comparativo entre o Modelo Entidade
Relacionamento (MER) com os princípios e estrutura da modelagem
multidimensional. O quinto tema compreende a representação da
modelagem multimensional para Data Warehouse, demonstrando
e exemplificando as características, elementos e aplicação do
Esquema Estrela (Star Schema) e do Esquema Floco de Neve (Snow
Flake Schema) que é considerado uma extensão do Esquema Estrela.
O sexto tema, introduz os fundamentos sobre o do Processamento
Analítico Online (Online Analytical Processing – OLAP) em comparação
com o Processamento de Transações Online (Online Transaction
Processing – OLTP), apresenta as operações OLAP e a classificação das
ferramentas OLAP, de acordo com a estratégia de armazenamento
dessas ferramentas. O último tema da disciplina aborda o processo de
Descoberta de Conhecimento em Bases de Dados (Knowledge Discovery in
Databases – KDD) e suas etapas, os fundamentos e as fases do processo
de mineração de dados (Data Mining), enfatizando que a mineração de
dados é considerada a principal atividade do processo KDD. Por fim,
apresenta-se uma síntese dos principais métodos e técnicas aplicadas
nas ferramentas de Data Mining.
4
Banco de Dados Transacionais
versus Bancos de Dados Analíticos
Autora: Marise Miranda
Objetivos
• Reconhecer os contextos em que se aplicam os
bancos de dados transacionais e os bancos de dados
analíticos.
• Acompanhar a estrutura tecnológica e de dados que
suporte às transações dos sistemas de informação.
• Escolher a estrutura tecnológica e de dados para
suportar as atividades analíticas que envolvem áreas
de conhecimento especializadas, como apoio à
tomada de decisão.
1.Consolidação de diferentes fontes de dados
Quantidades de dados crescentes são disponibilizadas, nas
organizações, por meio de diversas fontes internas e externas, todos os
dias e também pela internet. A automação de serviços, como exemplo
as vendas on-line, está constantemente produzindo e divulgando
dados sobre bens de consumo e a respectivas transações associadas a
esse serviço.
Os comportamentos das pessoas são expostos constantemente
em redes sociais, consolidando-se como uma fonte de dados. As
preferências, novidades, datas festivas, dentre outras informações,
são incluídas pelo usuário. O uso de tecnologias integradas nos
serviços por aplicativos, geram enormes volumes de dados, como
uso de transações bancárias, navegação na internet e troca de
informações digitais.
Todos esses dados gerados em larga escala, de diferentes fontes, fontes
externas, dados internos das empresas, forma um conjunto de dados,
que, normalmente, denominam-se de datasource, e quando reunidos
em um único local, são os sistemas de banco de dados. Os sistemas
gerecniadores desses ambientes denominam-se SGBD (Sistema de
Gereciamento de Banco de Dados).
Esses conjuntos de dados, podem ser formados por um arquivo, um
banco de dados específico em um DBMS (Database Management System)
ou até mesmo um feed de dados ativo. SGBD (Sistema de Gerenciamento
de Banco de dados) ou DBMS (DataBase Management System): são
softwares que gerenciam a base de dados, retira da aplicação cliente o
gerenciamento do acesso, a organização e a manipulação dos dados.
Feeds de dados: são fluxos de dados XML gerados a partir de uma fonte
6
de dados on-line e transmitidos para um documento ou aplicativo
de destino.
Os dados podem estar localizados no mesmo computador que o
programa ou em outro computador em algum lugar da rede. O conjunto
de dados provenientes de diversas fontes deve ser modelado em
uma certa estrutura para que possa ser armazenado, manipulado e
recuperado. A necessidade de estruturar esse conjunto em um modelo
de dados serve para explicar as características de funcionamento e
comportamento desses dados.
1.1 Modelo de dados
As fontes de dados são armazenadas segundo um modelo de banco de
dados, organizados em uma estrutura lógica de um banco de dados,
incluindo os relacionamentos, os tipos de dados e as restrições que
determinam como os dados podem ser armazenados e acessados.
Os tipos de modelos de dados estão associados a tipologia, e os mais
comuns estão listados a seguir:
• Modelo de banco de dados hierárquico.
• Modelo relacional.
• Modelo de rede.
• Modelo de banco de dados orientado a objetos.
• Modelo de relacionamento entre entidades.
• Modelo de BD NoSQL.
Cada modelo de banco de dados é tratado de forma personalizadae
é projetado com base em regras e conceitos que são adotados pelos
projetistas. A maioria dos modelos de dados podem ser representados
por um diagrama de banco de dados a ele associado (Figura 1).
7
Figura 1 – Modelo genérico de diagrama de banco de dados
Fonte: elaborada pela autora.
Os diagramas de banco de dados auxiliam na descrição de um banco
de dados e suas dependências, são o modelo dos dados e como se
relacionam. Nesse sentido, é importante adotar um SGBD, para dar
suporte o modelo adotado. A maioria dos sistemas de gerenciamento de
banco de dados é construída sobre um determinado modelo de dados, e
requer que seus usuários abstraiam esse modelo. No entanto, diversos
modelos se aplicam a diferentes estágios do processo de desenho do
banco de dados. Os modelos refletem a forma como o especialista
enxerga os dados. O administrador de banco de dados está ligado
ao modelo físico dos dados, o tipo, os atributos, o armazenamento, a
performance do banco, etc.
Os modelos de dados podem ser, também, conceituais, que é uma visão
de alto nível acerca de como os dados se relacionam e quais dados
integram esse modelo. O modelo conceitual de banco de dados abstrai
o relacionamento entre as entidades e suas especializações. Esses
modelos facilitam o mapeamento dos dados. Já os modelos lógicos
baseados em registros nas tabelas, refletem a proximidade de como os
dados são armazenados no servidor e suas chaves de ligações.
8
Definir qual modelo de dados será usado requer a sua compreensão
e adequação de como aplicar o modelo que será adotado. Nem
todos os modelos definem pontos fortes, mas ajudam a definir as
priorizações como velocidade, redução de custos, usabilidade, dentre
outras características intrínsecas. Ao escolher um modelo, este deve
refletir o ambiente observado em que os dados são gerados; serve para
especificar relacionamentos, documentar e normalizar os dados.
1.2 Modelo de banco de dados hierárquico
O modelo hierárquico organiza os dados em uma estrutura semelhante
a uma árvore, em que cada registro possui um único pai ou raiz (Figura
2). Os registros são classificados por meio da especificação organizada
de suas entidades e relacionamentos. A entidades refletem os objetos
de acordo com sua existência no mundo real, sejam abstratos ou
concretos, por exemplo, cliente, vendas, rodutos, estoque, etc. As
entidades possuem relacionamentos entre si.
Figura 2 – Modelo hierárquico
Fonte: elaborada pela autora.
Esse modelo foi usado em SGBD das décadas de 1960 e 1970,
atualmente mantido apenas em poucos sistemas legados (sistemas
informacionais ou gerenciais existentes na empresa, que podem
9
ser antigos ou recentes). Hoje em desuso por conta de ineficiências
operacionais, é apenas explorado neste contexto para acrescentar um
time line sobre a evolução dos modelos.
1.3 Modelo relacional
O modelo relacional é o mais utilizado atualmente. Machado (2011)
descreve que o este classifica os dados em tabelas, também conhecidas
como relações, em que cada tabela é composta por colunas e
linhas. Cada coluna lista um atributo da entidade em questão, como
produto, preço ou data de venda. Os atributos em uma relação
são chamados de domínio. Na Figura 3, exemplo que mostra um
determinado atributo ou combinação de atributos, é escolhido como
uma chave primária que pode ser referenciada em outras tabelas,
quando então é chamada de chave estrangeira, na tabela para qual
foi referenciada, no caso, ID_Paciente e Cod_convenio. Em um modelo
de banco de dados relacional, a chave primária refere-se a coluna que
nunca se repete e pode ser usada como índice. A chave estrangeira é
formada por meio de um relacionamento com a chave primária de uma
ou mais tabelas.
Figura 3 – Modelo relacional de convênio médico
ID Paciente Nome_paciente Sobrenome_paciente
123456 Maria De Souza
123457 Rosa Cristina Alencar
123458 Alberto Noronha
Cod_convenio Convenio
123456 Maria
123457 Rosa
123458 Albeto
ID Paciente Cod_convenio Tipo_plano Data_adesao
123456 123456 Premium 26/11/2012
123457 123457 Corporativo 01/04/1999
123458 123458 Co participação 01/02/2017
Fonte: elaborado pela autora.
10
Cada uma das linhas, também chamada de tuplas, inclui dados sobre
uma instância específica da entidade em questão, como o ID do
paciente. Este modelo reflete os tipos de relacionamentos entre essas
tabelas, incluindo relacionamentos um-para-um, um-para-muitos e
muitos-para-muitos. Isto significa que a chave primária de uma tabela
está relacionada com a chave estrangeria em outra tabela, formando um
relacionamento entre tabelas. Um exemplo é a escola que tem várias
turmas, um relacionamento de 1 escola relacionado com várias turmas.
Um aluno pertence somente a uma turma (um para um). Alunos cursam
disciplinas (N para N).
Em banco de dados, as tabelas podem ser normalizadas ou trazidas para
obedecer às regras de normalização. Essas regras organizam os dados
em projeto de banco de dados, reduzem as redundâncias, aumentam
a integridade para os dados e melhoram seu desempenho. As regras
de normalização minimizam as anomalias de modificações dos dados,
dando maior flexibilidade em sua utilização.
A utilização das regras de normalização produz resultados adaptáveis
em validações estatísticas. Isto quer dizer que uma query que contenha
função estatística pode ser sempre utilizada para novas entradas de
dados desde que estes obedeçam às regras de normaização. Quando
normalizado, cada dado é atômico ou dividido nas menores partes
úteis. Bancos de dados relacionais geralmente são gravados em SQL
(Structured Query Language).
1.4 Modelo de rede
O modelo de rede em banco de dados baseia-se no modelo hierárquico,
permitindo relacionamentos muitos-para-muitos entre registros que
estão vinculados, por exemplo, alunos matriculados em disciplinas. Isto
implica na necessidade de vários registros pai (MACHADO, 2011). Esse
modelo possibilita relações complexas (Figura 4).
11
Figura 4 – Modelo de rede em banco de dados
Empregado Cliente
Transacoes_Vendas
Vendedor
Produto
Fonte: elaborada pela autora.
1.5 Modelo de BD orientado a objetos
O modelo de banco de dados orientado a objetos é o modelo de banco
de dados pós-relacional mais conhecido, pois incorpora tabelas, mas não
se limita a elas. Esses modelos também são conhecidos como modelos
de banco de dados híbridos, pois contém dados como imagem, áudio,
vídeo ou hipertexto.
1.6 Modelo de relacionamento entre entidades
Esse modelo captura as relações entre entidades do mundo real muito
parecidas com o modelo de rede, mas não está diretamente ligado à
estrutura física do banco de dados. Em vez disso, é frequentemente
12
usado para projetar um banco de dados conceitual. Este modelo auxilia
nas visões existentes dos relacionamentos entre as tabelas e também
na construção de novas visões em um DW, utilizadas para compor as
dimensões e as tabelas fato.
Os dados armazenados em tabelas, como nomes, locais, produto,
etc., são denominados de entidades, em cada uma possui certos
atributos, quando juntos formam seu domínio. A entidade pessoa,
possue dados armazenados com o nome de pessoas, por exemplo. A
entidade endereço, tem que ter o local onde a pessoa mora, a rua e o
número, o CEP, o bairro, a cidade, o Estado e o país. A cardinalidade,
ou relacionamentos entre entidades, também podem e devem serem
mapeados. Por exemplo se a entidade pessoa possui mais de um local,
residência ou trabalho.
Machado (2011) ilustra que este modelo é utilizado em nível de
abstração de projetos de banco de dados, descriminando as
características dos dados, chave primária e estrangeira. A chave primária
pertence a um conjunto de campos que nunca se repetem e, portanto,
podem ser usados como índice. Já a chave estrangeira é utilizada para
criar osrelacionamentos entre as tabelas. A Figura 5 apresenta um
exemplo de modelo ER, ou simplesmentes, MER (Modelo Entidade
Relacionamento).
Figura 5 – MER
Tbl_produto
id_prodt (INT)
prodt_name (TEXT)
prodt_qt (INT)
Id_categoria (INT)
Tbl_categoria
id_categ (INT)
nome_categ (TEXT)
prodt_qt (INT)
descricao categ (INT)
Fonte: elaborada pela autora.
13
O MER é uma forma comum do diagrama de esquema em estrela,
no qual uma tabela de fatos central se conecta a várias tabelas
dimensionais (Figura 6).
Figura 6 – Modelo Estrela
Dimensão 3 Fato
Dimensão 4
Dimensão 1
Dimensão 2
Dimensão 5
Fonte: elaborado pela autora.
As dimensões e fatos são componentes complementares e dependentes
entre si. Em um modelo dimensional, é obrigatório a existência de
ambos (MACHADO, 2011, p 79). Esses elementos são fundamentais
para a compreensão e análise das informações, sem eles no modelo
dimensional, pode haver comprometimento ou inviabilização nas
análises pretendidas.
14
Esta percepção é muito importante para elaborar projetos em DW, uma
série de agregações, sumarizações, tratamentos são necessários para
criar as visões necessárias a partir das dimensões descritas por meio da
tabela fato.
É muito importante perceber que o banco de dados se mantém
preservado, as métricas e visões são construídas em um modelo estrela,
de múltiplas dimensões.
PARA SABER MAIS
Tabela fato: é a principal tabela do MER ou das dimensões
do DW. Na tabela fato são armazenadas as métricas, que
são os fatos propriamente ditos, e as Foreign Keys (FK –
chaves estrangeiras, em português), que são as chaves
que ligam os dados das dimensões com a tabela fato. As
métricas são as medidas de tudo aquilo que a empresa quer
medir para gerar valor e controle, em que suas FK ligam às
dimensões que as descrevem.
Tabela dimensões: é a tabela que qualifica os dados
provenientes da tabela fato. Por meio da tabela dimensão
pode-se criar análises dos dados em múltiplas perspectivas.
1.6.1 Modelo multidimensional
Este modelo é uma variação do modelo relacional. Ele é projetado
para facilitar o processamento analítico. Vale ressaltar que o modelo
relacional é otimizado para o processamento de transações on-line
(OLTP – On-line Transaction Processing), e o modelo multidimensional é
projetado para processamento analítico on-line (OLAP). Cada célula em
um banco de dados dimensional contém dados sobre as dimensões
15
rastreadas pelo banco de dados. De uma forma visível para o analista,
é como uma coleção de cubos, em vez de tabelas bidimensionais, que
podem ser consumidas para consulta (KIMBALL, 2002).
É muito comum encontrar as siglas como referência ao tipo de banco,
se transacional ou analítico. O OLTP refere-se ao banco transacional, a
base de dados original, da qual o acesso deve ser preservado e restrito.
Já quando se trata das análises, das métricas, das visões, e dimensões,
o modelo deve ser projetado para ser consumido em ferramentas
analíticas, dashboards, gráficos e relatórios, neste caso, o OLAP.
1.7 Modelo de BD NoSQL
A obtenção de dados de outras fontes que não são modelos SQL,
surgiram em contraste ao modelo relacional. Por exemplo, um modelo
de banco de dados semi-estruturados e não estruturados, chamados de
NoSQL. Além desse, dados provenientes da web, onde várias consultas
são realizadas, são semi-estruturados, isto significa que há algum
nível de organização, diferentemente da alta organização dos dados
estruturados em um BD relacional.
Já os bancos de dados não estruturados, são dados provenientes dos
vídeos, áudios, texto, das redes sociais, da web. Em geral aqui são dados
que contém algum tipo de organização dos dados aos usuários. As
funções de pesquisa na internet são convertidas em consultas para um
servidor de BD realizar as operações de processamento. Vale ressaltar
que esses dados não estrtuturados ou semi-estruturados precisam ser
pré-processados para serem tradados como dados estruturados.
2. Banco de dados transacionais
Os bancos de dados transacionais são otimizados para executar
sistemas de produção, como desde portais a instituições financeiras até
lojas de varejo. Nestes bancos, leitura e escrita em registros individuais
16
de dados muito rapidamente, mantendo a integridade dos dados. Os
bancos de dados transacionais não são criados com a finalidade voltada
para análises, embora muitas vezes se tornam ambientes analíticos,
pelo fato de já estarem em funcionamento como bancos de dados, em
produção, que estão prontos para serem consumidos pelos usuários.
A estratégia usual de iniciar com as análises dos dados, muitas vezes
é criar uma réplica do banco de dados transacional. Isso garante que
as consultas analíticas não impeçam, acidentalmente, as consultas de
produção, críticas para os negócios enquanto exigem configuração
mínima adicional. A desvantagem é que esses bancos de dados são
projetados para processar transações, não para análises. Usá-los como
análise é um ótimo começo, mas pode ter limitações que impedem a
necessidade de configurações analíticas mais específicas.
2.1 Integridade dos dados
A arquitetura dos bancos de dados transacionais é compatível com
ACID (Atomicidade, Consistência, Isolamento e Durabilidade), o que
garante que as gravações no banco de dados sejam bem-sucedidas
ou falhem juntas, mantendo um alto nível de integridade de dados ao
gravar dados no banco de dados. Os bancos de dados transacionais são,
portanto, essenciais para transações comerciais em que um alto nível de
integridade de dados é necessário.
Exemplo de uma transação bancária: o cliente realizando um débito
de uma conta corrente e crédito para outra conta corrente. Esta ação
do cliente desencadeará um processo de transações financeiras, que
utilizaram um banco de dados, e a arquitetura deste banco/processo
deve garantir o sucesso ou falha na transação.
ACID é um conjunto de propriedades que descreve como os bancos de
dados transacionais são projetados para preservar a integridade das
gravações no banco de dados. As principais propriedades são descritas
no Quadro 1.
17
Quadro 1 – Propriedades ACID – Banco de Dados Transacional
Propriedades Descrição
Atomicidade
Se mesmo uma parte da transação falhar,
toda a transação falhará. Desta forma, todas
as transações devem ser 100% bem-sucedi-
das para serem confirmadas com êxito no
banco de dados.
Consistência
Uma transação é gravada no banco de dados
(trazendo o banco de dados de um estado
válido para outro) ou a transação é revertida.
Isolamento
As transações que ainda não foram concluí-
das não podem ser processadas/modificadas
por outras transações.
Durabilidade
Depois que uma transação é gravada no ban-
co de dados, ela permanecerá lá, mesmo no
caso de uma falha no banco de dados.
Fonte: adaptado de Mysql Reference Manual ([s.d.]).
2.2 Latência
A latência em banco de dados é o período de “dormência” dos dados
que chegam ao ambiente operacional, para armazenamento em um
banco transacional ou deste para um banco analítico (INMON, 2005).
Como bancos de dados transacionais são projetados para executar
sistemas em produção, eles são muito bons em operações que devem
ser concluídas em milissegundos. A baixa latência é uma característica
dos bancos transacionais.
2.3 Principais características do BD transacional
A seguir, um resumo das principais carcaterísticas que identificam um
banco de dados transacional (Quadro 2).
18
Quadro 2 – Características BD Transacional
Requerimentos Descrições
Normalização Altamente normalizado
Esquema Gravação impositiva
Consistência Coerência forte, garantia de ACID
Integridade Alta integridade
Usa transações SIM
Atualizável SIM
Escalável SIM
Carga de trabalho Gravações intensas, leituras moderadas
Indexação Índices primários e secundários
Tamanho do dado De pequeno a médio
Modelo Relacional
Flexibilidade deconsulta Altamente flexível
Escalabilidade Pequeno (MBs) a grande (alguns TBs) (*)
(*) MBs – MegaBytes; TBs – TeraBytes.
Fonte: adaptado de Kimball (2002).
3. Banco de dados analíticos
Um banco de dados analítico é um sistema somente de leitura
que armazena dados para históricos ou métricas de negócios,
como exemplo, o desempenho de vendas e projeção de níveis de
estoque. Os analistas da área de negócios, executivos corporativos e
outros funcionários podem consumir consultas e analisar relatórios
provenientes de um banco de dados analítico. Os conjuntos das
informações, por sua vez, são atualizados regularmente, na medida em
19
que os dados de transações recentes são incorporados ao banco de
dados analítico.
O projeto de um banco de dados analítico permite suportar aplicações
para de Business Intelligence (BI), métricas analíticas e Big Data, em geral,
como de um Data Warehouseou ou Data Mart.
O banco de dados analítico é diferente do banco de dados operacional,
transacional ou OLTP, o primeiro usado para análises e o segundo usado
para processar as transações. Embora os bancos de dados transacionais
possam ser usados para suportar o armazenamento de dados e as
aplicações de BI, não é recomendado por questões de integridade e
escalabilidade. O banco de dados convencial deve ser preservado, e o
banco de dados analíticos devem estar em outro schema.
PARA SABER MAIS
Data Mart (DM) – Representa um subconjunto de dados do DW,
em geral por assunto ou departamento (MACHADO, 2011).
Schema – Um esquema de BD representa a configuração lógica
da totalidade ou de alguma parte da base de dados relacional.
Existem dois esquemas principais em BD. Um é o esquema de
BD lógico, que contempla restrições lógicas, como integridade,
exibições e tabelas, aplicados aos dados armazenados. Já um
esquema de BD físico define como os dados são armazenados
fisicamente no servidor de armazenamento, em termos de
arquivos e índices.
Os bancos de dados analíticos surgiram para atender especificamente
às necessidades das empresas que desejam construir repositórios de
dados de alto desempenho. Atualmente, os bancos de dados analíticos
20
https://searchbusinessanalytics.techtarget.com/definition/business-intelligence-BI
https://searchdatamanagement.techtarget.com/definition/data-warehouse
https://searchsqlserver.techtarget.com/definition/data-mart
são criados para analisar volumes extremamente grandes de dados
com maior rapidez do que os bancos transacionais. Os bancos de dados
analíticos utilizam técnicas que aumentam a performance das respostas
às consultas. Algumas técnicas mais usuais são citadas a seguir, de
acordo Kimball (2002).
1. Técnica do armazenamento de dados colunar. Um banco de
dados analítico tem uma estrutura baseada em coluna, na qual
cada coluna de dados é armazenada em seu próprio arquivo e
organizada geralmente em esquema estrela. Esse design torna o
banco analítico altamente flexível, o que facilita a operação em um
grande conjunto de pontos de dados em uma determinada coluna
com muita rapidez. Bancos de dados transacionais dependem de
armazenamento de dados baseado em linha. Eles são ótimos para
operar rapidamente em uma única linha, mas um design baseado
em linha não pode ser dimensionado para lidar com grandes
volumes de dados da mesma maneira que um design colunar.
A vantagem do processamento orientado por colunas é que os
cálculos em colunas individuais são muito rápidos. Por exemplo,
uma consulta ao banco de dados, que é para determinar o maior
salário mensal – máximo (salário) – entre todos os funcionários,
só precisa procurar a coluna salário. Nesse caso, apenas um bloco
deve ser carregado por um acesso ao disco rígido.
O armazenamento baseado em colunas fornece dados
direcionados para análise, o que melhora significativamente o
desempenho. A abordagem orientada por colunas é usada, entre
outras, por plataformas de banco de dados, tais como Hadoop,
HBase da Apache, Vertica e Sybase IQ da SAP.
2. Eficiente compressão de dados. Como resultado direto de seu
design de armazenamento de dados em colunas, um banco de
dados analítico é capaz de executar eficientemente a compactação
de dados em cada coluna de dados específica. A compactação
21
de dados é fator determinante, quanto ao espaço que os dados
ocuparão, e com que rapidez poderá ser manipulado.
3. Cargas de trabalho distribuídas. Em um sistema distribuído, os
dados são armazenados em um cluster de servidores (geralmente
chamados de nós). Por exemplo, em um warehouse RedShift, os
dados podem ser armazenados em servidores diferentes de 2-14
e o Redshift coordena o processamento paralelo das consultas
analíticas realizadas nessa infraestrutura. Essa paralelização
permite o processamento eficiente de volumes de dados cada vez
maiores. Bases de dados analíticas são tipicamente construídas
com processamento distribuído em seu núcleo.
ASSIMILE
Redshift: está disponível na AWS (Amazon Web Services)
e é um serviço de armazenamento de dados em escala
de petabytes totalmente gerenciado na nuvem. Um Data
Warehouse do Amazon Redshift é um conjunto de recursos
de computação chamados de nós, que são organizados
em um grupo chamado de cluster. Cada cluster executa
um mecanismo do Amazon Redshift e contém um ou mais
bancos de dados.
3.1 Comparação entre banco de dados transacionais e banco de
dados analíticos
Há ainda dúvidas quanto aos bancos de dados transacionais e analíticos,
no que se refere a usar um ou outro. Quando uma transação bancária é
realizada, por exemplo, um depósito em cheque em determinada conta
corrente, um processo transacional é disparado. Essa ação irá gerar um
conjunto de dados para ser associados, armazenados e recuperados,
22
com a informação ali contida, por meio de determinada organização
desses dados. Essa manipulação de dados, quer seja na consulta ou na
gravação são caracterizados pelas transações envolvidas em todo esse
processo ou procedimento.
Essa ação de depósito gera uma transação, que tem como foco
descrever as transações. Esse depósito gera uma transação que tem um
determinado valor, uma origem, um destino, um determinado tempo,
dentre outras informações. Essas ações são processadas por um sistema
que dará a garantia de integridade dos dados, uma ordem temporal
em cada movimento contido na ação do depóstito. Por este motivo, um
dos principais requisitos dos sistemas transacionais é a performance/
desempenho, ou seja, é necessário que a transação ocorra no momento
em que foi requerida, como um sistema em tempo real.
Já o banco de dados analítico é provido de informações advindas do
banco transacional. Os dados coletados no BD transacional servirão
de insumos para darem respostas as decisões organizacionais e
estratégicas. A atividade de análise sobre esses dados, do banco
analítico, em geral ocorre em modo off-line, em que englobam os dados
transacionais, agrupados, sumarizados ou amostrados para responder
as indagações feitas pelos analistas da empresa ou de negócios.
Diferentemente dos dados transacionais, os dados analíticos requerem e
necessitam estruturação em datasets de análise. A aquisição dos dados
analíticos se dá de diferentes maneiras, em geral, por extrações dos
bancos de dados em formato de arquivos tipo .txt, .CSV ou .XLSX.
Datasets ou conjunto de dados são necessários para as análises de
dados, representam agrupamentos, comportamentos e amostragens,
que permitem a aplicação de modelos matemáticos, como tentativa
de explicar e dar um significado aqueles dados. Os datasets são
representações de dados tabulares, formatados em registros nas linhas,
representando os acontecimentos ou ocorrências, e as características
23
desses acontecimentos nas colunas. Esse dataset resultará em um
comportamento associado aqueles acontecimentos e características.
O Quadro 3 representa uma comparação geral entre o BD analítico e o
transacional, paraauxiliar no projeto de uma BD com foco em DW.
Quadro 3 – Comparação geral entre BD ananlítico e BD transacional
Característica Analítico Transacional
Caso de uso.
Analisando grandes
volumes de dados para
análise de negócios.
Processando grandes
volumes de transações em
tempo real.
Objetivo da otimização.
Insere rapidamente e
seleciona um grande
número de linhas.
Inserções, atualizações,
seleções e exclusões
em tempo real em
menos linhas.
Consultas.
especializadas e
personalizadas.
Amplas e genéricas.
Consulta de tempos
de resposta.
Segundos para uma
consulta analítica.
Milissegundos para uma
consulta transacional.
Bancos de dados
de exemplo.
Vertica, Redshift,
Greenplum,
Teradata, ParAccel.
MySQL, PostgreSQL,
Microsoft SQL Server.
Fonte: elaborado pela autora.
Existem questões de relevância quando ocorre uma tentativa
reducionista de comparar um banco de dados transacionais e um
banco de dados analíticos. Neste contexto, vale ressaltar que a
comparatividade serve como apoio a tomada de decisão. Como fazer
um projeto inicial de DW para BI, partindo de um modelo elementar
de um banco de dados existente na organização? O projeto de um DW
para BI pode ser concebido de diferentes maneiras. Queries analíticas
podem rodar na aplicação front end tirando o processamento do
banco de dados.
24
Outro ponto fundamental, os bancos de dados de exemplo no Quadro
3 com capacidade analítica demandam relativa complexidade para
serem implementados. Alguns apresentam solução muito eficaz, mas
demandam uso de memória de máquina virtual, o que acaba elevando o
custo da operação analítica.
Novas ferramentas ou soluções estão sempre em desenvolvimento
para resolver alguns problemas de performance de banco de dados
tradicionais para transações. Mas isso não tira a capacidade de um SGBD
tradicional, para bancos de dados transacionais, de suportar as análises.
A questão não é tão simplista. Deve-se considerar o volume, a
integridade, a velocidade, dentre outras questões, pois o processamento
dos dados para análises depende de cálculos pré-programados. Além
disso, análises em tempo real vão demandar acessos contínuos, e isso
demanda capacidade do banco. A melhor maneira é sempre partir
de um conceito básico; banco de dados de repositório, que armazena
as transações, não é um banco para ser usado para análises ou pré-
processamento. Um projeto de DW para BI, considera um fluxo de
dados, um banco para armazenar as transações e um banco para
processar as análises.
4. Considerações finais
Um banco de dados transacional deve integrar as bases de dados
da organização, os dados brutos dos processos, preservando sua
integridade. Já um banco de analítico não é um banco físico real, como o
transacional, mas sim é um banco de dimensões para construir as visões
analíticas. Portanto, um DW é um repositório que abarca as dimensões,
tabelas fato e visões que serão consumidas como apoio a tomada de
decisão. O DW é o caminho intermediário entre os dados transacionais e
os dados analíticos.
25
TEORIA EM PRÁTICA
Criar um dataset para análises é uma tarefa complexa.
Suponha que você tenha que criar um dataset pelo
Excel, relativo ao desempenho de uma cafeteria. São
vendidos em média 200 cafés diariamente. A cafeteria
abre de domingo a domingo, das 7 horas da manhã até
às 20 horas. Além do tradicional café, vende também
água, chá e leite. Também podem ser consumidos pão
de queijo, pão com manteiga e brigadeiro. A média de
vendas de todos as bebidas, com exceção do café, é
de R$ 77,00 diariamente. A média diária de vendas dos
produtos alimentícios fica em R$ 65,00 por dia. Você
poderá elaborar um dataset simulando as vendas dos
itens descritos. Leve em consideração, o desempenho
de um mês dessa cafeteria. Descrimine o banco de
dados para uma abordagem baseada em cáculos de
maneira que as análises dos dados sejam realizadas
pelo usuário. Por exemplo, simule um dataset com os
dados preenchidos na tabela como data, hora, produto,
tipo de produto, quantidade, número do pedido, ID do
pedido. A simulação precisa ter regras estabelecidas
neste contexto, então pode-se vislumbrar um cenário em
dez anos de vendas de café. Por exemplo, houve uma
variação de 16%, e o preço saiu de R$1,00 há dez anos,
e agora o preço do café custa R$ 4,40. A contabilização
destes 10 anos, resultou em 720.000 cafés vendidos,
aproximadamente. Tabule os dados e crie conceito de
perspectiva analítica, siga o modelo:
26
id_pedido data hora produto tipo de produto qte
nº pe-
dido
preço
unitário preço total
1 14/01/2019 07:23 bebida café expresso 2 321 R$4,40 R$8,80
2 14/01/2019 07:25 bebida média 1 322 R$5,40 R$9,40
comida pão de queijo 1 322 R$4,00
3 14/01/2019 07:27 comida pão manteiga 1 323 R$2,50 R$2,50
4
5
6
etc etc etc etc etc etc etc etc etc
Observe que o pedido 322 já consiste um cálculo da soma
de dois produtos em um mesmo pedido.
Fica mais uma dica: 200 * 30 dias = 6.000 por mês, 72.000
por ano, em dez anos = 720.000 cafés. Simule as condições
de vendas de 30 dias apenas. Avalie quais análises podem
ser extratificadas a partir desse dataset.
VERIFICAÇÃO DE LEITURA
1. Por que um banco de dados transacional não deve ser
usado para análises? Aponte a resposta correta.
a. Um banco de dados transacional deve preservar a
integridade dos dados e portanto não é recomendável
utilizá-lo para análises.
b. Um banco de dados transacional deve preservar
as tabelas fato dos dados e, portanto, não é
recomendável utilizá-lo para análises.
c. Um banco de dados transacional deve preservar a as
visões dos datasets e, portanto, não é recomendável
utilizá-lo para análises.
27
d. Um banco de dados transacional deve preservar a
tecnologia de processamento dos dados e, portanto,
não é recomendável utilizá-lo para análises.
e. Um banco de dados transacional deve preservar o
fluxo dos dados e, portanto, não é recomendável
utilizá-lo para análises.
2. As consultas em banco de dados analítico são diferentes
de um banco de dados transacional. Qual alternativa
apresenta a característica das consultas em um banco de
dados analítico?
a. As consultas em um BD analítico são
genéricas e amplas.
b. As consultas em um BD analítico são genéricas.
c. As consultas em um BD analítico são
especializadas e amplas.
d. As consultas em um BD analítico são especializadas e
personalizadas .
e. As consultas em um BD analítico são genéricas e
modeladas matematicamente.
3. Os bancos de dados analíticos utilizam técnicas que
aumentam a performance no tempo de resposta às
consultas. Qual a técnica de armazenamento nas tabelas
que melhora a performance em um BD analítco.
a. Matricial.
b. Colunar.
c. Em linha.
28
d. Tabular.
e. 1ª coluna e 1ª linha da tabela.
Referências Bibliográficas
KIMBALL, R. The Data Warehouse Toolkit: guia completo para modelagem
dimensional. Rio de Janeiro: Campus, 2002.
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley Computer
Publishing, 2005.
MACHADO, F. N. Tecnologia e Projeto de Data Warehouse: uma visão
multidimensional. São Paulo: Érica, 2011.
MY SQL. MySQL 5.6 Reference Manual. 14.2 InnoDB and the ACID Model.
Disponível em: <https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html>.
Acesso em: 7 abr. 2019.
RASLAN, D. A.; CALAZANS, Angélica T. S. Data Warehouse: conceitos e aplicações.
Brasília, 2014. Disponível em: <https://www.publicacoesacademicas.uniceub.br/gti/
article/viewFile/2612/2400>. Acesso em: 23 mar. 2019.
Gabarito
Questão 1 - Resposta A.
Resolução: A arquitetura dos bancos de dados transacionais é
compatível com ACID, o que garante que as gravações no banco
de dados sejam bem-sucedidas ou falhem juntas, mantendo um
alto nível de integridade de dados ao gravar dadosno banco de
dados. Os bancos de dados transacionais são, portanto, essenciais
para transações comerciais em que um alto nível de integridade de
dados é necessário.
Exemplo de uma transação bancária: débito de uma conta corrente
e crédito para outra conta corrente. A arquitetura deve garantir o
sucesso ou falhar na transação.
29
https://dev.mysql.com/doc/refman/5.6/en/mysql-acid.html
https://www.publicacoesacademicas.uniceub.br/gti/article/viewFile/2612/2400
https://www.publicacoesacademicas.uniceub.br/gti/article/viewFile/2612/2400
Questão 2 - Resposta D.
Resolução: Quadro 3 – Comparação geral entre BD ananlítico e BD
transacional.
Característica Analítico Transacional
Caso de uso. Analisando grandes
volumes de dados
para análise
de negócios.
Processando
grandes volumes
de transações em
tempo real.
Objetivo da
otimização.
Insere rapidamente e
seleciona um grande
número de linhas.
Inserções,
atualizações,
seleções e exclusões
em tempo real em
menos linhas.
Consultas. Especializadas e
personalizadas.
Amplas e genéricas.
Consulta de tempos
de resposta.
Segundos para uma
consulta analítica.
Milissegundos
para uma consulta
transacional.
Bancos de dados
de exemplo.
Vertica, Redshift,
Greenplum,
Teradata, ParAccel.
MySQL, PostgreSQL,
Microsoft SQL Server.
Conforme o quadro comparativo a carcaterística das consultas em
um banco de dados analítico é especializada ou personalizada, pois
tende a representar alguma agragação, sumarização, cálculos dos
dados a serem estudados ou analisados.
Questão 3 - Resposta B.
Resolução Técnica do armazenamento de dados colunar. Um
banco de dados analítico tem uma estrutura baseada em coluna, na
qual cada coluna de dados é armazenada em seu próprio arquivo
e organizada geralmente em esquema estrela. Esse design torna o
banco analítico altamente flexível, o que facilita a operação em um
30
grande conjunto de pontos de dados em uma determinada coluna
com muita rapidez. Bancos de dados transacionais dependem de
armazenamento de dados baseado em linha. Eles são ótimos para
operar rapidamente em uma única linha, mas um design baseado
em linha não pode ser dimensionado para lidar com grandes
volumes de dados da mesma maneira que um design colunar.
31
Conceitos básicos sobre
Data Warehouse
Autora: Marise Miranda
Objetivos
• Viabilizar ambientes para implentações em Data
Warehouse (DW).
• Descrever as características de
construção de um DW.
• Composição do ambiente de inicialização de
projeto DW.
1. A viabilização de um Data Warehouse
Os sitemas transacionais priorizavam o foco nas técnicas estruturadas
para manter a integridade e a qualidade dos dados ali armazenados.
Todos tipos de transações em um processo eram armazenados, por
exemplo, baixa em estoque de peças, venda de produto unitário, dentre
outros. A elevação de rotinas com níveis de erros mínimos, testes
incessantes e integridade física do banco de dados estabeleciam os
elementos de controle do ambiente operacional, por exemplo, a soma
de todas as peças baixadas em estoque, para controle de reposição.
Com a necessidade de informações executivas ou estratégicas,
somando-se informação aos dados armazenados, veio a necessidade de
especificações associadas e modelagens de sistemas que fornecessem
indicadores. Os casos anteriores, como baixa das peças do estoque e
a soma das peças baixadas em estoque para controle são exemplos
de informações executivas. Mas, correlacionar as somas das peças
baixadas com as vendas dos produtos que utilizaram essas peças, pode
determinar a compra de reposição em maior ou menor volume, para
que a empresa não incorra em prejuízo, comprando peças que não
serão utilizadas, ficando ociosas no estoque ou perdendo vendas por
falta de peças que não foram repostas em estoque. Este último exemplo
implica em informações estratégicas.
Nesse sentido, há uma diferença entre um projeto de banco de dados
transacionais, OLTP (Online Transaction Processingn ou Processamento
de Transações em Tempo Real), e um projeto para DW com tecnologia
OLAP (Online Analytical Processing, ou Processamento Analítico em
Tempo Real). O primeiro utilizado no dia a dia da empresa, registrando
cada operação, alimentando um conjunto de informações executivas.
O segundo faz referência às informações estratégicas, em função
do processamento analítico, por meio de sumarizações, agregações,
cálculos e correlações dos seus conjuntos de dados.
33
Como os dados são relativos e descrevem um objeto de interesse,
de modo estático, a informação é algo que se acrescenta ao dado,
e podendo ser um modo dinâmico. Porém, a informação não é
extratificada sistematicamente por diferentes tipos e fontes de
dados. Ela é a combinação de dados e o tratamento inserido a essa
combinação, considerando sua temporalidade. Esse tratamento é a
sentença associada que gera certo conceito, conhecimento, afirmação
dos dados armazenados em tabelas e os relacionamentos entre si. Essas
sentenças são a chave de uma implementação bem suscedida de um
DW, em que este deve permitir a criação de bases de informação para a
realização de análises.
Um repositório ou armazém de dados deve possuir um DW em que se
realizem análises como as listadas a seguir:
• Segmentação de clientes (Figura 1).
• Indicadores da campanha de marketing.
• Performance das vendas.
• Análise da fidelização dos clientes.
• Mensuração do atendimento ao cliente.
• Status da lucratividade (Figura 2).
• Comportamento das oscilações dos negócios.
Figura 1 – Segmentação de clientes
Fonte: AndreyPopov/iStock.com.
34
https://AndreyPopov/iStock.com
o o
o
m-
Figura 2 – Status das oscilações da lucratividade
Fonte: firstpentuer/iStock.com.
Essas análises do DW devem servir para que outras ferramentas
obtenham mais clientes, mantenham os clientes existentes na base, ou
ainda, permitam desenvolver canais novos de clientes, como caso de
um CRM (customer relationship management, ou relacionamento com o
cliente). A integração de dados entre ferramentas pode ser observada
nas figuras abaixo:
Figura 3 – Dados operacionais Figura 4 – DW – Integração e
e relacionamento com o análise dos dados
cliente (CRM)
Fonte: cnythzl/iStock.com. Fonte: priyanka gupta/iStock.com.
35
https://gupta/iStock.com
https://cnythzl/iStock.com
https://firstpentuer/iStock.com
Essa integração entre uma tecnologia que fornece milhares de dados
do relacionamento de clientes, o CRM, e uma ferramenta de análise de
dados, numa arquitetura de DW, pode gerar a possibilidade de conhecer
características de comportamento de clientes afetados pela economia
ou mudança de negócio em um espaço de tempo pequeno – por meio
de análise dos dados do cliente com o momento econômico de uma
determinada época do ano, por exemplo. Este cenário possibilita gerar
um estudo analítico que mostra o comportamento do cliente, explícito
quando analisado isoladamente ou em agrupamentos de clientes, que
podem relevar por meio das análises, comportamentos favoráveis ao
consumo de determinado produto.
Nesse sentido, as organizações precisam se apoiar em tomada de
decisão por meio de diagnósticos mais assertivos, provenientes das
análises obtidas a partir dos dados da organização. Comparativamente,
um médico faz a anamnesi, que é uma entrevista do médico para ouvir
os relatos do paciente sobre suas dores e queixas, com isso estabelece
um diagnóstico, mas com os exames pode realizar um diagnóstico mais
preciso e, assim, instituir condutas terapêuticas.
De forma semelhante, os executivos precisam se apoiar em
informações precisas sobre os dados para diagnosticar tendências e
administrar estratégias com pronfundidade. Por isso, as análises sobre
sazonalidades, tendências e as análises temporais podem apresentar
indicadores de tomada de decisão sobre crescimento ou riscos para os
negócios, conforme o conhecimento de quemanalisa. Os dados estão
lá, mas a forma de como torná-los interpretativos a fim de possibilitar
um diagnóstico, requer técnicas analíticas e suporte de arquiteturas que
permitam combinações de dados.
A tecnologia de DW veio nessa direção para dotar as organizações e a
dinâmica de seus negócios, de capacidade analítica com base na sua
competência operacional amarzenada.
36
2. Construção de um DW
A realidade histórica da organização, seus clientes, fornecedores, suas
operações, suas despesas e lucratividade são a base para construir um
Data Warehouse (armazém de dados). Este armazém, repositório ou
banco de dados deve se manter disponível e acessível para consultas e
análises dos dados ali armazenados.
Observe que não há uma referência a especificidade de um banco de
dados, em que estão armazenados milhões de registros in natura ou
dados brutos, preservados e íntegros. Quando um DW é citado, neste
contexto, dize-se que dimensões são criadas acima desses dados brutos.
Um armazém de dados no contexto de DW, que não é o mesmo do
banco de dados transacional, é referencido assim, como uma área de
stage, uma área estacionária para armazenar somente aqueles dados
que serão utilizados para análises. E o que se armazena é uma cópia
dos dados necessários para as análises, preservavndo os dados originais
guardados no banco transacional.
O conceito de DW mudou também o contexto de banco de dados,
separando os bancos de dados transacionais e o que é um armazém de
dados (que também é um banco de dados), isolado do original. Para que
os dados do armazém possam ser consultados nas análises, em função
da necessidade de diversos arranjos entre esses dados.
Inmon (2005) destaca a mudança na abordagem em relação aos dados
brutos, que no início dos registros de dados não havia a experiência que
pudesse prever arranjos diferentes para suportar análises. O objetivo
de arquiteturas básicas para banco de dados eram apenas armazenar
ou guardar os registros, sem a robustez necessária para suportar
necessidades futuras.
As necessidades analíticas sobre os dados provocaram mudanças na
arquitetura, surgindo demandas provenientes de dados derivados.
Os dados do dia a dia, das operações, são os dados brutos. Os dados
resumidos, agregados, sumarizados ou calculados são os dados
derivados.
37
Essa divisão, dados brutos e informacionais/analíticos, proposta
por Inmon (2005) justifica a necessidade de acordo com os motivos
elencados a seguir na Figura 5.
Figura 5 – Justificativas da divisão entre dados brutos/operacionais
e analíticos/informacionais
Os dados que suportam as demandas
operacionais, são fisicamente
distintos, não servindo para atender
as necessidades informacionais ou
analíticas.
Fonte: blackred/iStock.com.
A tecnologia para o processamento operacional é tecnicamente
diferente da tecnologia necessária em suportar informações
ou análises.
Os usuários de dados operacionais são
diferentes para usuários que consomem
dados informativos ou analíticos.
Fonte: a-image/iStock.com.
O processamento de dados operacionais tem características diferentes
de processamento analítico ou informacional.
Fonte: adaptado de Inmon (2005).
38
https://www.istockphoto.com/br/portfolio/blackred?mediatype=photography
https://www.istockphoto.com/br/portfolio/a-image?mediatype=photography
As justificativas levam em consideração a finalidade de uso dos dados. A
base de dados bruta é consistente, original e necessita ser preservada.
Desta, uma cópia dos dados é feita com o objetivo de agregar e
sumarizar os dados necessários às análises. Os usuários que consomem
as informações das bases de dados transacionais, são usuários que
controlam ou realizam as operações diárias. Os usuários analíticos
consomem análises para encontrar diagnósticos estratégicos e que
possam servir de tomada de decisão. Essas são as principais razões que
motivam a separação de ambientes de uma base de dados operacionais
de uma base de dados para análises.
Ainda com o objetivo de ampliar o entendimento acerca da necessidade
de separar contextos de construção de ambientes para banco de dados,
a Figura 5, proposto por Inmon (2005, p. 16) destaca as diferenças, entre
os dados operacionais e os dados analíticos. Essa diferença é decorrente
na evolução de sistema de suporte a decisão e a inabilidade dos bancos
de dados operacionais fornecerem insumos para esse fim.
Explorando o exemplo da Figura 6, em que uma empresa fabricante de
produtos alimentícios tem três filiais, cada qual com sua base de dados
intermediária, conectada a um único banco de dados que registra todas
as operações. Depedendo de como o relatório é extraído pela matriz,
discrepâncias podem ocorrer, tais como relatórios de todo o período
do ano na perspectiva da filial 3, e relatório de metade do período na
perspectiva da matriz sobre as vendas também, ambos referentes ao
produto 2. Obviamente, os relatórios não vão coincidir, porque a forma
de extração dos dados coletados levando em consideração o período
são diferentes – as amostras são diferentes.
O problema?
• Um departamento precisa dos resultados das vendas anuais e o
outro departamento dos resultados de vendas de alguns meses.
• A base de dados é comum, mas a temporalidade é de cada
departamento.
39
Filial 1
Filial 2
Filial 3
§
ó□'
VENDA VENDA VENDA
PRODUTO 1 PRODUTO 2 PRODUTO 3
PRODUTO 5 VENDA
PRODUTO4
PRODUTO 2
§
/□' D □VENDA
VENDA VENDA PRODUTOS
PRODUTO 3 PRODUTO 2
Figura 6 – Modelo de extração de venda do produto 2 por duas
perspectivas distintas em relação ao período
Matriz
Fonte: elaborada pela autora.
Suponha que os produtos alimentícios sejam os seguintes: produto 1
(feijão), produto 2 (arroz), produto 3 (macarrão), produto 4 (farinha),
produto 5 (tempero). A linha tracejada em vermelho e amarelo
representam a perspectiva de extração de diferentes maneiras em
relação ao produto 2. A diferença consiste da necessidade de extração
de venda do produto 2 da filial 3, e a matriz tem a necessidade de fazer
a extração de venda de todas a filiais juntas, para analisar as vendas do
produto 2, ou seja, a filial 3 analisa as suas vendas de arroz e a matriz
analisa as vendas de arroz, produto 2, de todas as filiais. Se o acesso
a base de dados da filial 3 não tem a mesma referência analítica, as
divergências podem ocorrer. Pois, a filial 3 poderá analisar as suas
vendas mensais de arroz, e a matriz poderá analisar o desempenho
diário de vendas de arroz das filiais.
Este cenário pode remeter a análises distintas, sendo que a filial 3 só
poderá perceber seu desempenho a cada 30 dias, podendo ocorrer
variabilidades diárias nas vendas sem que a filial tome alguma ação, ao
40
contrário da matriz que poderá questionar alguma tomada de decisão
da filial 3, em função das análises diárias.
Para que as divergências nas análises não ocorram, é recomendável
que na construção de um DW, a sua arquitetura deva preconizar
referências analíticas comuns, como desempenho comparativo entre
as filiais, ranking de vendas de produtos, os produtos com maior
rentabilidade, setorização das vendas, aumento da eficiência das
vendas sem afetar as outras filiais, dentre outras análises.
Em grande parte, os dados são estratificados empiricamente, sem
que testes amostrais garantam que o comportamento é o mesmo em
diferentes datasets.
As análises de dados são implementadas para responder as
perguntas sobre os negócios, direcionando a tomada de decisão.
Machado (2011) mostra o percentual de tempo gasto em atividades
sem estratégia e com estratégia de acesso aos dados, conforme o
Gráfico 1. A análise de dados sem aplicações estratégicas, desde
o acesso, a preparação, as decisões e as ações, gastam em média
cerca de 20% a mais do que se houvesse uma aplicação estratégica
em relação aos dados, desde a sua escolhaàs análises e destas às
decisões, consequentemente ações.
O Gráfico 1 mostra a curva descendente quando não há aplicação
de estratégias sobre os dados a serem analisados, consumindo um
esforço maior no acesso aos dados e nas análises. Quando há uma
estratégia desenvolvida, perguntas corretas do que se quer analisar,
os dados necessários às repostas e às análises tem menor esforço
de tempo gasto, deixando maior tempo para o desenvolvimento
das decisões.
41
■ Ac= aos dados
■ Anil li~ dos dados
■ Desenvolvimento das
dec-sôes
Prepa- ação do cenàrio
■ lmplemen a;ão das
ações
35
30
25
20
15
10
s
o 1 1
Sen apli:ações estratégicas Com apl icar;ões estratégieas
Gráfico 1 – Percentual de tempo gasto em atividades
relacionadas aos dados
Fonte: adaptado de Machado (2011, p. 20).
As atividades relacionadas aos dados sem uma estratégia envolvida
em relação ao acesso e análises demadam maior percentual de tempo,
30%, resultando em pouco tempo para transformar essas análises em
decisões, decorrendo daí, pouco tempo na preparação de cenários e
ações de implementação, cerca de 8,6 % de tempo gasto. Ao contrário
de utilizar uma estratégia em relação aos dados, em média 10% do
tempo gasto para acessar os dados e construir as análises qualificadas
o suficiente para serem consumidas em forma de decisões mais
elaboradas, gerando insumos suficientes para preparação de cenários e
ações, em tempo médio 20% maior.
ASSIMILE
Estratégia de dados: aplicar conceitos estratégicos
utilizados nos negócios ou no desenvolvimento de
tecnologia não tem o mesmo resultado dos dados para
suportar a precisão, o acesso, o compartilhamento e até
a reutilização, como acontece no caso de codificação
42
em software. A estratégia de dados garante que todos
os recursos de dados estejam disponíveis para serem
utilizados, compartilhados e manejados de forma fácil e
eficiente. Estratégia de dados garante que os dados sejam
consumidos como ativo dentro da organização. Os datasets
fornecem métricas e indicadores a todos os projetos da
organização.
Gerenciamento de dados: em geral envolve metadados,
gestão de dados mestre, governança, migração, integração
e qualidade de dados.
DW é uma coleção orientada por assuntos, integrada, variante no
tempo e não volátil, para apoiar o processo de tomada de decisão das
organizações (INMONN, 2005). Na definição de Kimball (2002), DW é
a cópia específica de tabelas do banco transacional para consultas e
análises, criando visões funcionais. Um projeto de construção de um
DW depende, fundamentalmente, de arquitetura. Por isso, Machado
(2011) deixa claro que “DW é uma arquitetura e não uma tecnologia”
(MACHADO, 2011, p. 25). A tecnologia, sim, ajuda a construir, operar e
monitorar um projeto DW implantado.
A construção de um DW inicia com a recuperação dos dados históricos
da empresa. Isso significa realizar cópias da história da organização,
pelos dois anos anteriores, recomenda Machado (2011). Porque o banco
de dados de um DW não é o mesmo banco dos dados transacionais,
fisicamente. Os dados armazenados em um DW são a cópia histórica do
banco de dados transacional.
A construção pressupõe necessidades de informações especializadas,
indicadores de performance da organização. Uma base histórica
auxilia na criação de comparações com dados atuais e tendências
43
TPS
r------ ------------.,
GESTÃO
ESTRATÉGICA
GESTÃO TÁTICA
GESTÃO DAS OPERAÇÕES
STAFF OPERACIONAL
1
_J
futuras. A construção prevê também a utilização de ferramentas de
EIS e DSS. Essas ferramentas são utilizadas em diferentes níveis de
gestão das organizações, de acordo com Turban (2005). A Figura 7
representa o modelo de Turban (2005) e os sistemas de informação
relacionados a cada nível organizacional.
Figura 7 – Sistemas de informação versus Níves organizacionais
Ambiente de
Data Warehouse (DW)
Fonte: adaptado de Turban (2007, p. 41).
Os níveis organizacionais necessitam de um determinado tipo de
informação. O nível operacional proecessa os sistemas transacionais
(TPS), o gerenciamento de operações acessa os SIG (Sistema de
Informação Gerencial, MIS em inglês), a gestão tática acessa o DSS
(Sistemas de Suporte a Decisão) para apoio as decisões, e por último a
gestão estratégica acessa o EIS (Sistemas Especialistas). O ambiente de
DW é resultante do DSS e do EIS.
44
PARA SABER MAIS
TPS: Transaction Processing System. São dados capturados
dos processos diários da organização. Exemplo: relatório de
vendas, relatório de salários.
MIS: Management Information System. São relatórios
temporais, comparativos, sumarizados, para
acompanhamento da gerencia para resolver problemas,
supervisionar atividades e rastreabilidade. Exemplo:
relatórios de vendas mensais acompanhado do resultado
financeiro.
DSS: Decision Support System. São análises com abordagens
para tomada de decisão da alta gestão. Exemplos:
análises, dados internos, dados externos que podem
ser manipulados, correlacionados para apoio a tomada
de decisão. Aqui criam-se os modelos analíticos, para
a geração de um ambiente de conhecimento para
consulta e recuperação de informação relevante. Aqui a
modelagem estatística é usada para estabelecer relações
e a programação linear para encontrar otimizações,
modelagem preditiva e criar previsões.
EIS: Expert Information System. São sistemas de informação
especializados, com capacidade de realizar inferências.
Exemplo: técnicas de Machine Learning.
Considerando os níveis organizacionais EIS, DSS e parte do MI, dos quais
a gestão estratégica e tática fazem parte, um projeto final da construção
de DW deverá ter as seguintes características:
45
1. Disponibilidade da informação para a gerência.
2. Views (visões) representadas graficamente mostrando o
comportamento.
3. Rápido tempo de resposta de ferramentes de apoio à tomada
de decisão.
4. Precisão nas informações disponibilizadas.
5. Visão de indicadores expandida.
6. Abragência de recursos para analytics.
7. Acesso às solicitações e expectativas das análises especializadas
da alta gerência supridas por meio da Tecnologia da Informação.
ASSIMILE
O objetivo do DW é disponibilizar informações para o apoio
à tomada de decisão das organizações, por meio de uma
base de dados somente leitura.
Não existe DW pronto para ser utilizado sem esforço
anterior em levantar as necessidades da organização e seus
executivos.
Construir um DW exige estudo e envolvimento da empresa
e seus colaboradores.
Resumindo, a construção de um DW exige a transferência e a
transformação dos dados históricos dos sistemas organizacionais,
coletados nas operações diárias, para uma base de dados independente,
a qual no contexto da DW, são dados somente para operações
de consulta. Nessa construção, o DW tem uma composição de
conjunto específico, orientada por assunto, com vários subconjuntos
denominados Data Marts.
46
3. Composição do ambiente de Data Warehouse
Machado (2011), afirma que a tecnologia de DW é considerada uma
evolução do Ambiente de Apoio à Decisão. Isto significa, que com os
avanços tecnológicos de DW, os Ambientes de Apoio à Tomada de
Decisão passaram a ser denominados de Ambientes de DW, constituidos
de repositórios de Data Marts (DM). Vários DM compõem o DW.
Data Mart representa um subconjunto de dados do DW, em geral por
assunto ou departamento (MACHADO, 2011). Como o DW representa
um alto custo para a organização, os Data Marts podem ser reconhecidos
como uma versão reduzida de um DW, facilitando a implementação
de alanytics departamental. O Data Mart é representado como um
pequeno Data Warehouse projetado para uma unidade de negócio, que
é o departamento da organização (TURBAN, 2005). Como exemplo, o
departamento de vendas de uma empresa pode ser considerado um
Data Mart em relação aos seus dados e informações.Um DW consiste na integração dos dados da organização, para análises
gerenciais e estratégicas, consolidadas por meio das informações de
fontes internas, fontes heterogêneas, fontes externas, por meio de
sumarizações, agrupamentos filtragem e preparação de dados.
Sob um ponto de vista físico o Data Warehouse é um banco descendente
dados relacionais só que projetado para consulta e análise. Tem
dimensões e tabelas fato, que são mescladas para serem consultadas.
Um banco DW nunca poderá ter transações de escrita e leitura, estas
são características do banco transacional. O DW é conceitualmente um
banco Read Only, ou seja, somente de leitura.
O DW contém dados históricos derivados de dados transacionais,
incluindo dados de outras fontes e novos dados, advindos de resultados
da mesclagem dos dados, ou ainda, de fórmulas calculadas incluída na
coluna de uma tabela.
47
O DW tem uma composição que separa a carga de trabalho para análise
da carga de trabalho para transações. No primeiro caso, permite a
consolidação de diferentes fontes nessa carga de trabalho analítica.
Além de ferramentas analytics e demais aplicações para o
gerenciamento da coleta de dados e da entrega dos resultados prontos
para serem consumidos, a composição do DW inclui:
• ETL: Extract Tranform Load – Extração, transformação e
carregamento dos dados para a DW. Por exemplo: uma empresa
no ramo alimentício tem seus dados armazenados no banco de
dados transacionais, e a ferramenta de ETL, irá carregar somente
os dados de interesse para análises, para o banco de dados
repositório do DW. Outro exemplo é que a ETL é feita somente
com as vendas diárias dos produtos alimentícios, mas se houver a
necessidade de uma análise por hora, os dados dos horários das
vendas deverão serem carregados pela ETL
• OLAP: Online Analytical Processing – Processamento analítico em
tempo real. Como exemplo, uma análise que está sendo feita por
ano, na dimensão temporal, na qual o usuário precisar mudar
para uma visão por trimestre ou diária. A ferramenta OLAP tem
que possibilitar essa granularidade da dimensão tempo para que
o usuário tenha as visões por ano, diário e trimestre conforme sua
interação. É interação por meio de filtros na dimensão tempo.
Um DW possui um conjunto carcaterístico personalizado, distintamente
dos ambientes convencionais das organizações. Por este motivo, não há
como replicar um DW de uma empresa para outra. Cada projeto de DW
é único, não na essência, mas no seu modo de operação e aplicação.
Ao final do desenho do projeto, o DW deverá possuir um rol de
atribuições para cumprir a sua finalidade, elencadas a seguir,
no Quadro 1.
48
Quadro 1 – Atribuições de um DW
Atribuição Caracterização Exemplo
a) Extração dos dados. Fontes diversas (internas e
externas).
Data completa,
produtos, preço.
b) Transformação
dos dados.
Necessidade de mesclagem
ou combinação de dados,
gerando novos dados
específicos.
Normalização da data,
valores maiores que zero.
c) Infraestrutura
tecnológica e manutenção.
Específica para essa
finalidade.
Servidores de serviços.
d) Representação
dos dados.
Visualizações gráficas,
tabuladas, sumarizadas
pronta para consumo
conforme perfil
dos usuários.
Gráfico percentual de
desepenho de vendas.
e) Especialização. Dados podem ser extraídos
ou não para níveis mais
específicos, os Data Marts, e
destes para bases de dados
individualizadas.
Inclusão de filtros nas visões
f) Acesso. Personalizado por meio de
ferramentas que promovem
acessos com diferentes
níveis de apresentação.
Usuários com níveis de
acesso as visões.
g) Não há atualização. As atualizações ou
updates não ocorrem
diretamente no DW.
As atualizações de dados
ocorrem no banco
transacional e deste uma
cópia é carregada para o
banco do DW.
Fonte: adaptado de Turban (2005, p. 86-89).
Vale reforçar que os dados atualizados na base transacional e de outras
fontes não são carregados no DW diretamente, ou seja, primeiro, a
carga ocorre em outro banco antes do DW. Isto significa que estes
dados provenientes de atualizaçãoes em outras fontes são extraídos,
49
uj,€,Y~ ___ ,,,,
fRP---77 ETL
transformados e depois carregados para o DW. Em geral ficam em uma
área chamada stage, um banco estacionário, de espera da carga.
Para ilustrar a compreensão, a Figura 8 representa um esquema de fluxo
que antecede a entrada de dados em um banco DW e a saída deste com
resultados prontos para consumo.
Os dados originais ou fontes de dados (data sources) armazenados em
diferentes bancos de dados, internos e externos, no caso, provenientes
de CRM, ERP e supply chain (dados da cadeia de fornecimento), são
extraídos por uma ferramenta de ETL, transformados e carregados para
o banco estacionário do DW. No DW ocorrem as técnicas necessárias
para gerar os processamentos das análises em tempo real (OLAP),
mineração de dados (Data Mining) e visualização de relatórios (reporting).
Figura 8 – Fluxo de dados de um DW
Fonte: vaeenma/iStock.com.
50
https://vaeenma/iStock.com
O DW da Figura 8 mostra que ele armazena dados de forma agrupada
ou por assunto, dados do CRM, dados do ERP e dados da supply chain.
Os bancos de dados transacionais são orientados por processo, e o
DW é orientado por assunto, seu armazenamento é, na realidade,
uma transformação dos dados operacionais, das transações do dia
a dia da organização, com algum tipo de valor agregado por meio de
sumarizações, contagens, filtragens, agregações, correlações, etc.).
Por que sumarizações, contagens, filtragens, agregações, correlações,
etc., geram valor aos dados operacionais? Porque estas técnicas
incluem algum tipo de informação modelada matematicamente.
Uma sumarização é um resumo dos resultados estatísticos básicos.
Por exemplo, um comando summary em linguagem de software
estatístico R, nos retornará para um um conjunto de dados, a média,
mediana, moda, quartis, valores máximo e mínimo. Um filtro pode
associar lógicas como “e”, “ou”, “=”, entre outras lógicas para que
os relatórios mostrem dados com detalhes associados ou não.
Contagens são importantes em análises pois representam o universo
dos dados por meio de quantificações, de certa forma, contribuem
para análises qualificadas quando comparações de contagem
são realizadas, algumas técnicas são a frequência por amplitude,
histogramas, séries temporais, etc.
A filtragem no âmbito de DW tem dois sentidos: um é aquele que
interfere nos resultados das análises e o filtro como extratificador no
ETL. O primeiro como filtro refere-se a lógica e, ou, igual, entre, não nulo,
etc., que no contexto do usuário foi disponibilizado na forma de cubo
para seleção, leitura do banco de dados do DW. No segundo caso, um
filtro como extratificador, na ETL, significa a disponibilização de parte
dos dados, uma amostra, um extrato dos dados que serão carregados
para o banco do DW. A Figura 9, mostra o fluxo dos dados, na entrada e
51
Sexo "m"
Sexo "f'
DATA SOURCE 1
Sexo "masc"
Sexo "fem"
DATA SOURCE 2
Sexo "M" r--.-111'
Sexo "F"
DATA SOURCE 3
ETL
EXTRAÇÃO
FILTRO
RELATÓRIOS
--60
65
RELATÓRIOS FILTRO
m:mmm
M 81
saída do DW, assim como o filtro na ETL como extrator e o filtro no cubo
para análises.
Figura 9 – Entrada e saída do ambiente de DW
Fonte: adaptada de Turban (2005, p. 82, 84, 87).
Todo o fluxo dos dados em um projeto de entrada e saída de um DW
tem por alvo municiar informações a um grupo de pessoas que precisam
de apoio à tomada de decisões. Essa construção vem da necessidade
gerada por esse grupo em um contexto norteado pelas competências
daquele tipo de negócio.
A entrada e saída do DW requer que a composição do ambiente tenha
aspectos orientados ao fluxo dos dados, dentro os quais caracterizam-
se os listados no Quadro 2. De maneira geral, essas orientações são
aquelas que devem nortear a visão macro doprojeto de DW.
52
Quadro 2 – Características da visão macro de um projeto DW
Características Detalhamento
Orientação
por assunto.
• Agrupamento por assuntos de interesse.
• Indicadores analíticos e desempenho.
Variação de tempo. • Datas são componentes chave.
• Janelas de tempo.
• Alta temporalidade.
Volatividade. • Carga incial e incremental.
• Acesso em modo leitura (read).
Integração. • Padronização dos dados.
• Filtragem, amostra, agregação.
Arquitetura. • Ferramentas de carga inicial e atualizações
periódicas.
• Ferramentas de limpeza dos dados.
• Ferramentas de consultas.
• Data Marts.
Papeis. • Recursos Humanos.
Centralização de
competências.
• BI.
Fonte: adaptado de Machado (2011, p. 29-31).
Um DW precisa ser relevante para o grupo de pessoas competentes que
toma as decisões na organização.
Esse grupo precisa olhar para o desempenho da empresa, dos negócios,
que tipo de produto ou serviço está em um ciclo de lucro e de queda.
Quanto tempo o cilco positivo desses produtos ou serviços duram?
Perguntas são feitas por essas pessoas e precisam amparar suas
respostas na relevância dos dados de sua empresa.
De uma maneira ampla, a composição de um DW inclui os dados
estruturados, formas de comunicação dos dados em diferentes pontos
de armazenamento, processamento e representação da informação ao
usuário ou cliente.
53
4. Considerações finais
Fazendo um fechamento, vale reforçar que o DW auxilia a empresa
a entender o desempenho dos negócios a partir do conhecimento
sobre os seus dados. Para isso, não basta disponibilizá-lo a quem
decide, é preciso que se crie um contínuo fluxo de entrada e saída de
dados e que gere valor para quem os consume dentro da empresa. As
considerações apresentadas mostram a necessidade da participação de
várias entidades da organização, como a área de TI, a área de banco de
dados, os gestores de departamentos, os funcionários do operacional, o
alto escalão, de maneira a estarem alinhados com o projeto, bem como
com a preparação da implantação, a manutenção e atualização, e o uso
estratégico efetivo do DW dentro da corporação. Vale refletir em como
criar um fluxo contínuo dentro da organização, desde a origem dos
dados até as análises oferecidas aos analistas, para que o projeto de DW
se torne indispensável as ações estratégicas internas.
TEORIA EM PRÁTICA
A empresa Fisioampla é especailizada em serviços de saúde
de fisioterapia, e possui filiais em diversos locais do país.
A Fisiampla tem cadastrados cerca de 1.200.000 clientes
que utilizam os serviços especilizados de fisioterapia, na
matriz e em 30 filiais. Além dos serviços, presta consultas
especilizadas para reabilitação de acidentados, pessoas com
mobilidade reduzida e idosos. Cada clínica possui um amplo
sistema de reabilitação e atendimento com fisioterapeutas
associados. Há consultas clínicas que além de recomendar
as sessões de fisiterapia, recomendam o uso de produtos
que vão auxiliar na reabilitação ou na redução dos
problemas relacionados.
Para extrair valor dos seus dados, a Fisioampla contratou
você para estruturar um projeto de DW. Analise o cenário
e proponha uma arquitetura para que a Fisioampla
tenha ideia de como os seus dados serão utilizados.
54
Também faça simulações de quais análises poderiam ser
alcançadas com visualizações analíticas que surgiram do
uso dessa arquitetura. Você poderia listar alguns exemplos
de visualizações em relação a dimensão tempo, como
exemplo: Que tipo de paciente é atendido nos quatro
trimestres do ano? Qual tipo de fisoterapia é mais solicitada
e em qual época do ano? Elenque mais oito questões que
poderiam ser de interesse da Fisioampla associadas com a
dimensões tempo.
VERIFICAÇÃO DE LEITURA
1. Com a evolução de sistema de suporte à decisão, por
que os contextos na construção de banco de dados
operacionais e analíticos precisam ser diferentes?
a. Porque há uma inabilidade dos bancos de dados
operacionais.
b. Porque o banco de dados operacional não precisa
ser físico.
c. Porque o banco de dados analítico não pode ser um
banco lógico.
d. Porque a volumetria exigida não pode ser suportada
em bancos operacionais.
e. Porque há uma inabilidade nas execuções
matemáticas dos bancos de dados analíticos.
2. O que garante que todos os recursos de dados
estejam disponíveis para serem utilizados utilizados,
compartilhados e manejados de forma fácil e eficiente?
a. As consultas ao banco de dados.
55
b. A estratégia de dados.
c. As análises e relatórios.
d. A qualidade dos dados.
e. A existência de um DW.
3. O que é uma coleção orientada por assuntos, integrada,
variante no tempo e não volátil, e que apoia o processo
de tomada de decisão das organizações?
a. Um Data Warehouse.
b. Um Data Mart.
c. Um Data Warehouse.
d. Um banco de dados analíticos.
e. Um banco de dados transacionais.
Referências Bibliográficas
MACHADO, F. N. R. Tecnologia e Projeto de Data Warehouse. 5. ed. São Paulo,
Editora Érica, 2011.
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley Computer
Publishing, 2005.
KIMBALL, R. The Data Warehouse Toolkit: guia completo para modelagem
dimensional. Rio de Janeiro: Campus, 2002.
TURBAN, E. Administração de tecnologia da Informação. Editora Campus, 2005.
Gabarito
Questão 1 - Resposta A
Resolução: com o objetivo de ampliar o entendimento acerca da
necessidade de separar contextos de construção de ambientes
para banco de dados, Inmon (2005) destaca as diferenças, entre
os dados operacionais e os dados analíticos. Essa diferença é
decorrente na evolução de sistema de suporte a decisão e a
56
inabilidade dos bancos de dados operacionais fornecerem
insumos para esse fim.
Questão 2 - Resposta B
Resolução: a estratégia de dados garante que todos os recursos
de dados estejam disponíveis para serem utilizados, compartilhados
e manejados de forma fácil e eficiente. Estratégia de dados garante
que os dados sejam consumidos como ativo dentro da organização.
Os data sets fornecem métricas e indicadores a todos os projetos da
organização.
Questão 3 - Resposta C
Resolução: na conceituação dada por Inmonn (2005), DW é uma
coleção orientada por assuntos, integrada, variante no tempo
e não volátil, para apoiar o processo de tomada de decisão das
organizações.
Na definição de Kimball, (2002), DW é a cópia específica de tabelas
do banco transacional para consultas e análises, criando visões
funcionais.
Um projeto de construção de um DW depende fundamentalmente
de arquitetura. Por isso, Machado (2010) deixa claro que “DW é
uma arquitetura e não uma tecnologia”. A tecnologia sim ajuda a
construir, operar e monitorar um projeto DW implantado.
57
Data Marts
Autora: Iolanda Cláudia Sanches Catarino
Objetivos
• Conhecer e compreender os fundamentos sobre
Data Marts.
• Conhecer e compreender a arquitetura padrão de
Data Warehouses.
• Conhecer e compreender os tipos de arquiteturas e
implementação de Data Marts.
..
e
1. Fundamentos sobre Data Marts
As organizações precisam responder de maneira ágil e eficiente às
mudanças e oportunidades de mercado. Tomar decisões estratégicas
exige análise e interpretação de informações analíticas que identifiquem
oportunidades, comportamentos e tendências da sociedade do
conhecimento.
Os ambientes de Data Warehouses (DW) integram sofisticadas
ferramentas para análises complexas de dados históricos e descoberta
de conhecimento, assegurando o suporte à tomada de decisão,
como exemplifica a Figura 1. Ela apresenta diferentes formatos de
consultas dinâmicas e relatórios analíticos disponibilizados aos usuários
estratégicos, a partir de dashboards de ferramentas com recursos
intuitivos para sua geração. A implantação de um DW demanda alto
investimento, tempo e considerável esforço gerencial, sendo usados
principalmentepor grandes empresas.
Figura 1 – Acesso às ferramentas de um ambiente de
Data Warehouse
Fonte: adapatada de cifotart/iStock.com. Fonte: adaptada de zmicierkavabata/
iStock.com.
Uma das principais características do DW é a integração dos dados de
diferentes origens, proporcionando um ambiente estático, que não sofre
59
https://www.istockphoto.com/br/portfolio/zmicierkavabata?mediatype=illustration
https://www.istockphoto.com/br/portfolio/zmicierkavabata?mediatype=illustration
modificações durante o seu acesso. Apenas novas cargas com dados
atuais são inseridos, a partir de critérios previamente estabelecidos,
permitindo, assim, o seu acesso por meio de ferramentas front-end e/ou
aplicativos.
Na concepção de Inmon (1997), o DW é um agrupamento de dados
que devem ser guiados por temas normalizados (integrados) para
facilitar as consultas analíticas. Precisam também possuir um nível
de granularidade e de armazenamento bem apurados, além de que
em hipótese alguma, sejam modificados (não-voláteis), pois esses
dados são uma “fotografia” (snapshot) de determinada situação em
um período específico de tempo. Este procedimento certifica ao DW
uma particularidade em sua utilização, tornando-o um ambiente
com dois propósitos específicos distintos, o de carga de dados e o de
acesso aos usuários. Desta forma, para que um ambiente de DW seja
consistente e eficaz, os dados precisam ser padronizados e consolidados
para só depois serem disponibilizados no sistema, de modo que os
administradores possam utilizá-los como ferramenta de apoio no
processo decisório.
O DW organizacional pode manter um armazém central de dados
da organização inteira, ou pode manter armazéns menores,
descentralizados, denominados Data Marts. Portanto, muitas empresas
iniciam o desenvolvimento de DW estruturando-o em conjuntos
de dados orientados por assunto ou categoria, para atenderem às
necessidades de pequenos grupos de usuários ou níveis funcionais da
empresa, investindo, assim, na implementação de Data Marts.
Segundo Date (2004), os DW surgiram pela necessidade de fornecerem
uma origem de dados única, limpa e consistente para fins de apoio à
decisão e pela necessidade de fazê-lo sem causar impacto sobre os
sistemas operacionais que normalmente têm exigências restritas de
desempenho com cargas de trabalho previsíveis. Porém, percebeu-se
que os usuários executavam extensivas operações de análise de dados
60
sobre um subconjunto do DW completo, repetindo com frequência
as mesmas operações sobre o mesmo subconjunto dos dados. Dessa
forma, a ideia de construir um espaço de armazenamento limitado,
adaptado à finalidade imediata, extraindo e preparando os dados
exigidos diretamente de fontes locais, assim como, fornecendo acesso
mais rápido aos dados, levou ao conceito de Data Marts.
Date (2004) descreve um Data Mart como “um depósito de dados
especializado, orientado por assunto, integrado, volátil e variável no
tempo, que fornece apoio a um subconjunto específico de decisões da
gerência” (DATE, 2004, p. 604). Por especializado, entende-se que ele
contém dados para apoio a uma área específica de análise comercial
e por volátil, entende-se que os usuários podem atualizar os dados, e
talvez até mesmo criar novos dados para algum propósito.
Na concepção de Rob e Coronel (2011), um Data Mart é um pequeno
subconjunto de um DW, sobre um único assunto, que fornece suporte
às decisões de um pequeno grupo de pessoas, que pode ser criado a
partir de dados extraídos de um DW maior, com o objetivo específico de
dar suporte a acessos mais rápido para determinado grupo ou função,
como ilustra a Figura 2, com o DW Organizacional composto por três
Data Marts: marketing, vendas e financeiro.
Rob e Coronel (2011), enfatizam que:
A única diferença entre um Data Mart e um Data Warehouse é o tamanho
e o escopo do problema a ser resolvido. Portanto, as definições de
problemas e as exigências de dados são essencialmente a elas para
ambos. (ROB; CORONEL, 2011, p. 551)
De acordo com Laudon & Laudon (2014), um Data Mart é:
Um subconjunto de um Data Warehouse, no qual uma porção resumida ou
altamente focalizada dos dados da organização é colocada em um banco
61
Data Warehou.se Organizacional
I
Data Mart 1
(Ma rketing)
Data Mart 2
[Vendas)
separado destinado a uma população específica de usuários (LAUDON &
LAUDON, 2014, p. 194)
Assim como na visão de Machado (2013), os Data Marts representam
um subconjunto dos DW que permitem o acesso descentralizado à
informação, podendo ser direcionados a um departamento ou área
específica do negócio.
Figura 2 – Ambiente básico de Data Warehouse
Fonte: elaborada pela autora.
Rainer e Cegielski (2011), destacam que um “Data Mart é um data
warehouse pequeno, projetado para as necessidades do usuário final em
uma unidade estratégica de negócios ou um departamento” (RAINER;
CEGIELSKI, 2011, p. 126). E ainda, Kimball et al. (1998), especialista no
assunto, define que um Data Mart, também conhecido como warehouse
departamental, é uma abordagem descentralizada do conceito de DW,
caracterizando os seus principais benefícios como:
a. Demandam menos investimento porque são mais baratos.
b. Podem ser implementados mais rapidamente.
c. Apoiam as necessidades e o controle local de grupos de usuários
por níveis funcionais.
62
d. Fornecem uma resposta mais rápida aos grupos de usuários.
e. Disponibilizam consultas mais fáceis de serem analisadas e
navegadas.
Machado (2013) afirma que uma das principais vantagens de se
implantar um Data Mart em uma empresa, é a possibilidade de
retorno rápido, garantindo um maior envolvimento do usuário final,
capaz de avaliar os benefícios extraídos de seu investimento.
A partir das definições apresentadas, conclui-se que, um Data Mart é
um subconjunto lógico e físico da área de representação de um DW
que agrupa dados sobre um único assunto para fornecer suporte
às decisões de um grupo de pessoas específicas. Contudo, algumas
empresas optam por implementarem primeiramente Data Marts para
posterior migração para um DW, considerando que pessoas em níveis
organizacionais e funcionais diferentes necessitam de dados com
formatos distintos de agregação, síntese e apresentação, além de
menor investimento.
2. Arquitetura de Data Warehouses e Data Marts
O funcionamento de uma arquitetura padrão de DW consiste na
integração das diversas fontes de dados com o ambiente de extração
e transformação, com a base de dados do DW, mecanismos de
comunicação, processamento e com ambientes intuitivos para os
usuários, a partir de ferramentas de consultas dinâmicas com interfaces
de apresentação das informações interativas.
O processo de extração dos dados obtidos de diversas fontes de
dados operacionais, transformação e carga em DW normalmente
prevê um estágio intermediário de preparação dos dados,
63
sincronização e integração dos dados. Ferramentas de Extraction,
Transformation and Load (ETL) são responsáveis pela extração,
transformação e carregamento dos dados no DW. Durante este
estágio, os dados permanecem em uma área de armazenamento
intermediária entre as bases de dados operacionais e o DW para
realização das ações de limpeza e integração dos dados. Essa área
de armazenamento intermediária é conhecida como Staging Area,
Data Staging ou Operational Data Store (ODS – Depósito de Dados
Operacionais).
Inmon (1997) explica que um depósito de dados operacional é uma
coleção de dados orientada por assunto, integrada, volátil (atualizável),
atual ou quase atual. O objetivo principal do Staging Area é criar um
ambiente intermediário de armazenamento e processamento dos
dados para o processo ETL possibilitando o tratamento dos dados para
permitir sua posterior integração em formato e tempo, evitando, assim,
problemas após a criação do DW e a concorrência com o ambiente
transacionalno que diz respeito ao consumo de recursos. A Figura 3
representa o processo de ETL com o Staging Area.
No lado esquerdo da figura, estão as fontes de dados, que são
compostas respectivamente por sistemas Online Transaction Processing
(OLTP), dados externos, outras fontes e arquivos simples (flat files).
No centro da Figura está a Staging Area e no lado direito está o DW. A
extração é a fase onde os dados dos sistemas são transportados de
diferentes fontes para uma base de dados para serem transformados.
A transformação é a etapa em que os dados são tratados, corrigindo
erros de integridade, de redundância, de digitação etc., e integrando-os
em um modelo único para ser utilizado no DW. A carga é a fase em que
os dados são levados da Staging Area para um ou mais Data Marts, para
então serem consultados, por meio das aplicações dos usuários.
64
OLTP
IF o rntes Externas
·rstagrrng Areai
- (ETL)
t---------~
outras Fontes
oata Warelmuse
Figura 3 – Processo de ETL com Staging Area
Fonte: elaborada pela autora.
PARA SABER MAIS
Online Transaction Processing (OLTP – Processamento
de Transações em Tempo Real): os sistemas OLTP
são transacionais que registram todas as transações
operacionais das organizações. São utilizados no
processamento dos dados que são gerados diariamente por
meio dos sistemas informacionais das empresas.
ASSIMILE
O ambiente de processamento de dados analíticos difere
do ambiente de dados transacionais ou operacionais.
Os sistemas Online Transaction Processing (OLTP –
Processamento de Transações em Tempo Real) servem
como fonte de dados para o ambiente de DW, enquanto
65
as ferramentas Online Analytical Pocessing (OLAP –
Processamento Analítico On-line) auxiliam na análise
dinâmica e multidimensional de dados consolidados,
permitindo que o usuário final tenha uma visão completa
das informações analiticamente.
Machado (2013), descreve que uma Staging Area permite ao
administrador do DW extrair os dados no momento em que estão
disponíveis e, posteriormente, integrá-los, facilitando as extrações dos
sistemas operacionais durante períodos fora de pico de operações.
Um ODS pode ser usado também como área provisória para
reorganização física dos dados operacionais extraídos de várias fontes,
como dos sistemas legados da empresa e de demais sistemas e serviços
da internet, em um único formato que será mantido no DW.
Segundo Kimball (1998), além da Staging Area, o ideal é que exista uma
segunda área intermediária – ODS antes da carga definitiva para o DW.
Um ODS deve ser uma base de dados obtida da extração, transformação
e limpeza de dados dos sistemas fontes operacionais da empresa. Com
um ODS, não é necessário refazer toda a extração para corrigir eventuais
problemas na transferência dos dados para o DW.
Para Machado (2013), o ODS não é um componente indispensável em
um DW, sendo que sua criação é uma decisão de projeto. Contudo,
por economia de espaço de armazenamento em disco muitos DW são
implementados sem ODS.
Muitos projetos de DW possuem ODS e utilizam esta área para fazerem
validações de regras de negócio, e na Staging Area ocorre a limpeza,
verificando chaves repetidas e problemas de integridade referencial. A
Figura 4 ilustra a arquitetura de um DW com Staging Area e Data Marts.
66
Fontes Exter.n:__Js staging
Area
1 j, (ETL)
1-11
I!
j--
Arquivos Simples
Data Warehouse
• Data Mart
Marketing
Data Mart
Financeiro
Relatórios
Analíticos
OLAP
Data Mining
Figura 4 – Arquitetura de um Data Warehouse
com uma Staging Area e Data Marts
Fonte: elaborada pela autora.
No lado esquerdo da Figura estão as fontes de dados que, neste
exemplo, são compostos pelos sistemas operacionais e flat files
(arquivos simples). Um pouco mais a direita, está a Staging Area.
No centro da figura está o DW, que é composto pelos metadados,
dados resumidos e dados brutos, ou seja, os dados obtidos com
seus valores de origem e que são armazenados sem sofrem
nenhum tratamento. Um pouco mais a direita estão os Data Marts
categorizados em marketing, vendas e financeiro. Por fim, no
lado direito da figura estão as ferramentas de apoio à decisão –
Analysis Reporting, OLAP e Data Mining. De acordo com a figura, os
dados são extraídos das fontes de dados e transportados para a
Staging Area, onde os dados são transformados. Após o processo
de transformação, os dados são carregados no DW. Em seguida, os
dados são extraídos do DW e carregados nos Data Marts para uso
posterior e quando necessário, os usuários acessam os Data Marts
utilizando ferramentas de apoio à decisão.
67
Certos casos, um projeto começa com o desenvolvimento de um DW
e se compõe em vários Data Marts. No entanto, um Data Mart pode
também ser criado de modo independente, sem a necessidade de
extrair os dados do DW. Algumas empresas utilizam essa técnica,
criando primeiro os Data Marts conforme a necessidade, e depois
criando finalmente o Data Warehouse como uma consolidação dos
diversos Data Marts (DATE, 2004).
3. Tipos de arquitetura e implementação
A escolha da arquitetura é uma decisão que causa impactos quanto ao
sucesso do projeto, podendo afetar no tempo de execução, retorno do
investimento, velocidade dos benefícios da utilização das informações,
satisfação do usuário e recursos necessários à implementação de uma
arquitetura.
Para a definição de uma arquitetura de DW ou de Data Marts deve-
se levar em conta, principalmente, o porte da empresa, a qualificação
e experiência dos profissionais de tecnologias da informação e
comunicação e os recursos disponibilizados para o investimento.
Contudo a arquitetura pode ser definida ou modificada após o começo
da implementação. Nesse caso, depois que o projeto de DW é iniciado,
para mudar a sua arquitetura, será despendido um longo tempo,
atrapalhando o andamento do projeto. Por isso é importante já estar
definido no início do projeto.
A arquitetura de um DW abrange um conjunto de ferramentas que
envolvem a carga inicial dos dados até à geração de consultas que
apoiam os usuários no processo de tomada de decisão. Alguns
fatores interferem na escolha da arquitetura e implementação,
tais como:
68
a. Tempo para execução do projeto.
b. Estrutura das instalações física da empresa.
c. Rápido retorno do investimento.
d. Satisfação dos usuários estratégicos.
A definição de uma arquitetura determina o local onde o DW ou os
Data Marts estarão alocados fisicamente. Machado (2013) apresenta
a seguinte classificação das arquiteturas: global, independente
e integrada, e o tipo de implementação top down, bottom up e a
combinada.
A arquitetura global é considerada a arquitetura que mais comporta
as necessidades de um DW integrado com alto nível de acessos e
utilização das informações para todos os departamentos de uma
empresa, sendo que a arquitetura global pode ser fisicamente
centralizada ou pode ser fisicamente distribuída nas instalações
da empresa. Normalmente o DW é global, ou seja, reflete o escopo
de acessos em um repositório comum de dados com a geração
das informações para o suporte à decisão, disponível para toda a
empresa. Nesse tipo de arquitetura consome-se muito tempo de
desenvolvimento e administração e seu custo de implementação é
muito alto. (MACHADO, 2013).
A Figura 5 ilustra os dois caminhos de utilização de uma arquitetura
global, a global centralizada e a global distribuída, em que ambas as
arquiteturas observa-se que o acesso aos dados podem ser realizados
de locais fisicamente separados. Mesmo assim todas as estruturas têm
acesso a todas as informações da empresa. O topo da Figura 5 ilustra
que o DW está distribuído em três instalações físicas de uma empresa
e na parte de baixo da figura mostra que o DW está mantido em uma
única instalação física da empresa, ou seja, centralizado considerando
que a empresaexiste em um único local.
69
Dados Op-erac[o.nais e
Ext,enios
.Arquiite ura Gllobal Cen ral izacl1a
....
••• lililiil
llli· llilii :ii
-■■ 1■ 1
■· ■■ li
1
..... ,■
■, ■■ ri
•••• •••••
.Arq;rni ;erura Global D istri tn1 í d'.a
Figura 5 – Arquitetura global do tipo centralizada e distribuída
Fonte: adapatada de Machado (2013).
A arquitetura independente mantém Data Marts stand-alone, onde
tem-se dados específicos da necessidade da empresa, considerando
que cada departamento tem sua informação sem a integração com
outros departamentos. Contudo, há restrição quanto a um mínimo de
integração organizacional e não permite nenhuma visão global. Esse
tipo de arquitetura é controlado por um grupo específico de usuários,
atendendo as necessidades específicas e sua implementação é rápida
e de poucos impactos nos recursos de tecnologia da informação, sendo
assim, a arquitetura mais adotada pelas empresas.
A Figura 6 exemplifica a arquitetura do tipo independente, o qual cada
estrutura ou departamento pode ter suas informações específicas,
categorizando-as em Data Marts separados, não tendo a obrigatoriedade
dessas informações serem integradas.
70
!Dad'os Op eracfo:nais e
Extemos
.. · · rquil:e1urn. lm:f.e;peride-nte ,.,
'' !Data IMart 1
,., ,,
Data IMart .3
A arquitetura integrada de Data Marts é implementada por Data Marts
separadamente por grupos específicos ou departamentos, sendo
integrados ou interconectados, provendo uma visão organizacional
maior dos dados e informações (MACHADO, 2013).
Figura 6 – Arquitetura independente de Data Marts
Fonte: adapatada de Machado (2013).
A arquitetura integrada requer mais complexidade no projeto de
especificação dos requisitos dos Data Marts, devido a proposta de
integração dos dados e informações, aumentando a capacidade e
qualidade de visão corporativa das informações. Uma vantagem da
arquitetura integrada é que os usuários de um departamento podem
acessar e utilizar os dados de um Data Mart de outro departamento. A
Figura 7 ilustra uma arquitetura integrada, em que cada departamento
tem suas informações específicas, mas suas informações são integradas
com os outros departamentos, a partir da integração de dois ou mais
Data Marts.
71
Dad10 011erac.ionais. e
Externos
. rqu itetura I rntegra.da
--lil liiiii'
lüa Mart 1
lüata 1Mart 3
Figura 7 – Arquitetura integrada de Data Marts
Fonte: adapatada de Machado (2013).
As abordagens de implementação de Data Marts são classificadas em top
down, bottom up e a combinada.
A implementação do tipo top down é conhecida como a proposta mais
adotada e recomendada de implementação de Data Marts para um
ambiente de DW. Exige-se inicialmente o envolvimento de todos os
departamentos da empresa para planejamento completo sobre: as
fontes de dados que serão utilizadas, análise e projeto dos requisitos e
das estruturas de dados, especificação da qualidade de dados a serem
consideradas, definição da padronização dos dados, recuperação dos
modelos de dados dos sistemas transacionais vigentes, projeto de
segurança e definições das tecnologias que serão adotadas para o
desenvolvimento do DW.
Esse tipo de implementação força a empresa a definir regras de
negócios de forma corporativa antes de iniciar o projeto de DW. O
processo inicia-se com a extração, a transformação e a integração dos
72
OLTP
Fontes Externas
Sistemas Legados
ODS
j -,
1-- '-------~ 1 _,
1- 1
Arauivos Simoles
- ~ o Data Mart 1 Relatórios
Analíticos
Data Mart 2
OLAP
Data Wa:rehouse
Data Mart 3 Data Míning
dados dos sistemas operativos e dados externos para a Staging Area e/
ou para um ODS, para, posteriormente, serem transferidos para DW. A
partir do DW são extraídos os dados e metadados para os Data Marts
(MACHADO, 2013).
A Figura 8 ilustra a implementação do tipo top down, com a extração
de dados de sistemas transacionais, fontes externas, sistemas
legados e arquivos simples, onde essas informações passam por um
processo de extração e transformação, iniciando na Staging Area e
ODS até o desenvolvimento dos Data Marts, a partir do DW e posterior
disponibilização das informações, a partir de diferentes ferramentas de
apoio à decisão – Analysis Reporting, OLAP e Data Mining.
Figura 8 – Tipo de implementação Top Down
Fonte: elaborada pela autora.
O Quadro 1 elenca as vantagens e desvantagens da implementação top
down, segundo Machado (2013).
73
Quadro 1 – Vantagens e desvantagens da implementação Top Down
Vantagens
1. Herança de arquitetura: os Data Marts originados a partir de um DW utilizam a
mesma arquitetura e os mesmos dados, permitindo uma fácil manutenção.
2. Visão de empreendimento: o DW concentra o histórico de negócio da empresa,
permitindo a extração em níveis menores de informações.
3. Repositório de metadados centralizado e simples: o DW provê um repositório de
metadados central para o sistema, provendo manutenções mais simples.
4. Controle e centralização de regras: garante a existência de um único conjunto de
aplicações para extração, limpeza e integração dos dados, e de processos centra-
lizados de manutenção e monitoração.
Desvantagens
1. Implementações muito longas: os DW são normalmente desenvolvidos de modo
iterativo por áreas de assunto, sendo necessário uma média de 15 ou mais me-
ses para que a primeira área de assunto entre em produção.
2. Alta taxa de risco: dificuldade em garantir e sustentar o investimento neste tipo
de ambiente.
3. Heranças de cruzamentos funcionais: necessidade de equipes de desenvolvi-
mento e de usuários finais altamente qualificados que acompanhem as deman-
das vigentes e emergentes da organização.
4. Expectativas relacionadas ao ambiente: a demora do projeto e a falta de retorno
rápido podem induzir expectativas desagradáveis nos usuários.
Fonte: Machado (2013).
A implementação do tipo bottom up permite a implementação
incremental do DW, por meio do desenvolvimento de Data Marts
independentes. A implementação bottom up vem se popularizando em
virtude de a implementação top down exigir alto investimento financeiro
e tecnológico. O processo dessa implementação começa na extração,
transformação e a integração dos dados para um ou mais Data Marts,
baseados em um modelo dimensional. Esse tipo de implementação
pode trazer um grande problema de redundância de dados e
inconsistências, devido o DW ser desenvolvido de forma incremental,
mas poderá ser minimizado através de planejamentos e boas práticas
de projetos de software.
74
!Lia , · Man: 1
IOlaa Mali1:2
Da a Waretrim.1s e
IlJa a Marl:
A Figura 9 exemplifica a implementação bottom up, em que sua
implementação inicia-se de forma incremental em cada Data Mart
para posterior composição do DW, assim formando uma estrutura de
múltiplos Data Marts.
Figura 9 – Tipo de Implementação Bottom Up
Fonte: adapatada de Machado (2013).
O Quadro 2 elenca as vantagens e desvantagens da implementação
bottom up, segundo Machado (2013).
Quadro 2 – Vantagens e desvantagens
da implementação Bottom Up
Vantagens
1. Implementação rápida: o desenvolvimento dos Data Marts é direcionado por as-
sunto, permitindo um rápido desenvolvimento e, posteriormente, em produção.
2. Retorno rápido: a arquitetura baseada no desenvolvimento incremental de Data
Marts demonstra o seu valor e confiança para o usuário final.
3. Manutenção do enfoque da equipe: a elaboração de Data Marts incrementais
permite que os principais negócios sejam focados inicialmente, sem que haja
gastos no desenvolvimento de áreas que não são essenciais ao problema.
4. Herança incremental: a estratégia de desenvolvimento de Data Marts de forma
incremental porporciona confiança e expertise das equipes, minimizando os ris-
cos e problemas característicos de projetos de software.
75
Data Mart 1
Da a Mart2
Data Mart N
□ata 'W'a raho 1111s,eDesvantagens
1. Perigo de legamarts: os Data Marts independentes transformam-se em Data Mar-
ts legados, ou legamarts que podem dificultar, quando não inviabilizam futuras
integrações, gerando problemas e não soluções.
2. Desafio de possuir a visão de empreendimento: dificuldade em manter um rí-
gido controle de negócio ao extrair e combinar as fontes individuais durante o
desenvolvimento de Data Marts incrementais.
3. Administrar e coordenar múltiplas equipes e iniciativas: dificuldade em manter
um rígido controle durante o processo de desenvolvimento de Data Marts em
paralelo, tentando coordenar os esforços e recursos das múltiplas equipes, es-
pecialmente nas áreas de regras e semântica empresariais.
Fonte: Machado (2013).
A Figura 10 representa a implementação do tipo combinada que tem o
propósito de integrar as arquiteturas top down e a bottom up. Segundo
Machado (2013), nessa abordagem elabora-se a modelagem de dados
da visão macro do DW e posteriormente implementa-se os Data Marts.
A principal vantagem dessa abordagem é a garantia da consistência dos
dados obtida em virtude do modelo de dados único do DW, consistindo
posteriormente no mapeamento e implementação dos Data Marts.
Figura 10 – Tipo de implementação combinada
Fonte: adapatada de Machado (2013).
76
4. Considerações Finais
A busca por informações que amparassem o trabalho dos tomadores de
decisão passou a ser uma constante, pois percebeu-se que as empresas
guardavam um patrimônio digital em seus bancos de dados e que os
administradores poderiam aprimorar seus processos e usufruir desse
patrimônio digital, transformando a informação em conhecimento e,
com isso, potencializar e agregar valor aos negócios.
Ao longo das décadas, identificou-se a necessidade de dividir as tarefas
de gerenciamento e análise dos dados em diferentes níveis gerenciais,
crescendo, assim, a necessidade de respostas mais rápidas, seguras,
confiáveis e que melhor se adaptassem às necessidades do gerenciamento
da empresa e dos negócios. A partir desse cenário, surgiram os ambientes
de DW organizacional, que geralmente mantém um armazém central de
dados da organização inteira, ou armazéns menores, descentralizados,
denominados Data Marts. Assim, um Data Mart é um subconjunto de um
DW que agrupa dados sobre um único assunto para fornecer suporte às
decisões de um grupo de pessoas específicas.
TEORIA EM PRÁTICA
Tornando como base uma das maiores redes de farmácias
e drogarias do segmento de varejo farmacêutico nacional,
com aproximadamente 550 lojas nos 25 estados e Distrito
Federal, que investiu R$ 35 milhoes em novas lojas e
reformas, incluindo a reestruturação da arquitetura global
do tipo distribuída do ambiente de Data Warehouse e
Data Marts da rede que está concentrado nas regiões Sul
e Sudeste do país, e considerando que a rede pretende
aprimorar os serviço de atendimento personalizado
aos seus clientes, faça um levantamento e escolha uma
tecnologia emergente para integrar ao novo ambiente de
Data Warehouse organizacional serviços de inteligência
77
artificial que agreguem inteligência ao negócio e
principalmente proporcione novas funcionaliades para
garantir a customização ágil aos clientes. A partir da
definição da tecnologia emergente de inteligência artificial,
elenque as principais etapas para o projeto da nova
arquitetura do Data Warehouse organizacional e relacione
alguns nos serviços que poderão ser disponibilizados aos
usuários estratégicos e/ou clientes.
VERIFICAÇÃO DE LEITURA
1. Uma das principais características de um ambiente de
Data Warehouse é a interação dos dados de diversas
fontes distintas, proporcionando um ambiente estático,
que não sofre modificações. O Data Warehouse
organizacional pode manter um armazém central
de dados da organização inteira, ou pode manter
armazéns menores, descentralizados, denominados
____________________.
Assinale a alternativa correta que preenche a
lacuna acima:
a. Data Sources.
b. Data Marts.
c. Data Mining.
d. Ferramentas OLAP.
e. Staging Area.
78
2. Um Data Mart é um subconjunto lógico e físico da área
de representação de um Data Warehouse que agrupa
dados sobre um único assunto para fornecer suporte
às decisões de um grupo de pessoas específicas.
Sobre as principais características e/ou benefícios do
desenvolvimento de Data Marts, julgue os itens a seguir:
I. Apoiam as necessidades e o controle local de grupos
de usuários por níveis funcionais ou departamentos de
uma empresa.
II. Demandam menos investimento que o
desenvolvimento do Data Warehouse organizacional.
III. Podem ser implementados mais rapidamente,
fornecendo uma resposta mais rápida aos grupos
de usuários.
IV. Mantém um depósito de dados central com um nível
de granularidade e de armazenamento bem apurado e
não são não-voláteis.
Estão corretos os itens:
a. I – II.
b. II – III.
c. III – IV.
d. I – II – III.
e. I – II – III – IV.
3. A definição de uma arquitetura determina o local onde
o Data Warehouse ou os Data Marts estarão alocados
fisicamente. Para a definição de uma arquitetura, deve-
se levar em conta principalmente o porte da empresa, a
qualificação e expertise dos colaboradores e os recursos
disponibilizados para os investimentos.
79
Assinale a alternativa correta que indica a classificação
dos tipos de arquitetura de Data Warehouse e Data Marts:
a. Independente, centralizada e acoplada.
b. Independente, acoplada e coesa.
c. Transacional, integrada e funcional.
d. Global, transacional e aglomerada.
e. Global, independente e integrada.
Referências Bibliográficas
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro:
Campus, 2004.
INMON, W. H. Como construir o data warehouse. Rio de Janeiro: Campus, 1997.
KIMBALL, R. et al. The data warehouse lifecycle toolkit. New York: John Wiley &
Sons, 1998.
LAUDON, K. C.; LAUDON, J. P. Sistemas de informação gerenciais. 11. ed. São Paulo:
Pearson Prentice Hall, 2014.
MACHADO, Felipe N. Tecnologia e projeto de data warehouse. 6. ed. São Paulo:
Erica, 2013.
RAINER, R. K.; CEGIELSKI, C. G. Introdução a sistemas de informação: apoiando e
transformando negócios na era da mobilidade. 3. ed. Rio de Janeiro: Elsevier, 2011.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e
adminsitração. 8. ed. São Paulo: Cengage Learning, 2011.
Gabarito
Questão 1 - Resposta B.
Resolução: considerando as inúmeras definições sobre Data
Marts, na concepção de Rob e Coronel (2011), um Data Mart é um
pequeno subconjunto de um DW, sobre um único assunto, que
fornece suporte às decisões de um pequeno grupo de pessoas, que
pode ser criado a partir de dados extraídos de um DW maior, com
80
o objetivo específico de dar suporte a acessos mais rápido para
determinado grupo ou função.
Questão 2 - Resposta D.
Resolução: os itens I, II e III estão corretos. O item IV é uma
característica do Data Warehouse e não dos Data Marts, pois
segundo Inmon (1997), o Data Warehouse refere-se a um conjunto
de dados baseado em assuntos, integrado, não-volátil, e variável
ao longo do tempo, de apoio às decisões gerenciais. Uma das
principais características do Data Warehouse é a interação dos
dados de diversas fontes distintas, proporcionando um ambiente
estático, que não sofre modificações.
Questão 3 - Resposta E.
Resolução: a escolha da arquitetura é uma decisão que causa
impactos quanto ao sucesso do projeto, podendo afetar no tempo
de execução, retorno do investimento, velocidade dos benefícios
da utilização das informações, satisfação do usuário e recursos
necessários à implementação de uma arquitetura.
A definição de uma arquitetura determina o local onde o DW ou os
Data Marts estarão alocados fisicamente. Machado (2013) apresenta
a seguinte classificação das arquiteturas: global, independente e
a integrada;e o tipo de implementação top down, bottom up ou a
combinação das duas, denominada intermediária.
81
Modelagem de dados para um
Data Warehouse
Autora: Marise Miranda
Objetivos
• Reconhecer os aspectos da granularidade e como
afeta as análises dos negócios.
• Aplicar as técnicas de modelagem de dados.
• Caracterizar a modelagem multidimensional para
conceber as visualizações e medidas relacionados
sobre um conjunto de dados.
1. Aspectos sobre granularidade de dados
A compreensão sobre os dados e a granularidade assume uma etapa
importante para modelar os dados em estruturas por níveis. Como
exemplo, a venda de determinado produto se relaciona seu preço,
a baixa no estoque desse produto e o cliente que o adquiriu, mas a
quantidade de vendas dos produtos também são dados, no entanto,
representa já um modelo em que vários produtos vendidos foram
somados, não interessando nesse nível elevado de granularidade os
nomes dos clientes para os quais o produto foi vendido. A granularidade
tem a haver com o grau de sumarização, redução ou agregação dos
dados. O produto em si é o grão, o nível mais baixo de granularidade,
mas a quantidade deste mesmo produto vendido representa uma
abstração, um nível e granularidade elevado. O dado, neste caso, faz
referência à soma desses produtos vendidos.
Kimball (2002) explica que especificar o grau de granularidade
dos conjuntos de dados que serão analisados, deve ser de
comum entendimento entre os analistas que estão projetando
o DW e os usuários que consumirão as análises. O grau de
granularidade se apresenta em níveis: baixo nível está relacionado
com o dado bruto sem transformação, alto nível com dados
transformados, por exemplo, uma soma de quantidades vendidas de
determinado produto.
As tabelas utilizadas no processo de análises devem ser construídas no
nível mais baixo de granularidade possível, aumentando a flexibidade e
extensibilidade conforme o tipo de filtragem ou agrupamentos exigidos
nas consultas pelos usuários (KIMBALL, 2002).
Para compreender as recomendações propostas pelo mesmo autor, veja
a seguir um modelo que expressa as restrições relativas a granularidade
(Figura 1).
83
< DETALHAMENTO
< VOLUME
< LATÊNCIA
> DETALHAMENTO
> VOLUME
> LATÊNCIA
<
GRANULARIDADE
REPOSTAS MENOS
FLEXÍVEIS
REPOSTAS MAIS
FLEXÍVEIS
Figura 1 – Níveis de granularidade dos dados
Fonte: adaptada de Kimball (2002, p. 133-134).
Machado (2011) destaca que a granularidade de dados faz referência ao
nível de sumarização dos dados, considerando este como um aspecto
importante em projetos de DW. Quanto mais detalhes dos dados, menor
será a granularidade; já quanto menos detalhe houver, maioe será a
granularidade.
Em bancos transacionais, a granularidade é importante, porque
o dado mais bruto está armazenado lá, diferentemente de
banco de dados anaílicos que operam os ambientes de DW, nos
quais sumarizações e agregações afetam a granularidade. A
granularidade afeta profundamente o volume de dados que estão
armazenados em um DW.
A Figura 2 exemplifica a abordagem da granularidade em baixo
nível e em alto nível, considerando os detalhamentos, pelos dados
ou pelas sumarizações. O modelo mostra a diferença entre os dois
níveis, uma refere-se as vendas por vendedor, e o outro a soma das
vendas no mês.
84
Dâa
Hora
Vendedor
valor
Vendas
Trans<Ção:
venda por vendedor
200 REGISTROS DE
"1: N D AS MENSAIS
Mes
Vendedor
valor
Soma_Vendas
Sumarização das
Trans<Ções:
Soma das vendas de
produtos no mês
1 REGISTRO DA SOMA
TOTAL "1:NDAS DO MÊS
Figura 2 – Exemplo de granularidade e nível de detalhamento
Fonte: elaborada pela autora.
A entidade venda mostra os detalhes relacionados a venda de cada
vendedor, a data, a hora, o vendedor associado e o valor da venda. É
possível extrair um relatório das vendas por vendedor, ou seja, aqui há
um nível baixo de granularidade e nível alto de detalhes. Já na entidade
Soma_Vendas, a granularidade é alta, não expressa especificidade
sobre os detalhes da venda, mas consolida o valor das vendas no mês.
O primeiro modelo pode ser importante para a promoção de algum
vendedor, já o segundo serve de apoio a tomada de decisão da alta
gestão da empresa.
Machado (2011) alerta que a granularidade de um DW auxilia no foco
do projeto, a modelagem fica mais fácil. Tomando como exemplo disso,
uma sumarização mensal é fácil e rápida, mas se a sumarização requer
saber as vendas relativas à semana da Páscoa, com promoções que
iniciam 45 dias antes, há a necessidade da elaboração da sumarização
85
mais detalhada, a cada quinze dias, obtendo três conjuntos quinzenais
de dados sumarizados.
O Quadro 1 contempla o exemplo de forma detalhada, a nível de dado,
baixa granularidade. O quadro consiste o detalhamento de dez vendas,
em que são registradas as vendas por vendedor, o valor, a data e a hora
da venda. Todos os registros são lançandos em uma base de dados
transacional. O ID (identificação) de cada venda está associado a um
número, que relaciona um dos três vendedores, o valor de cada venda
por vendedor, data e hora, respectivamente.
Quadro 1 – Dados armazenados no banco transacional
Id_Vendas Data Hora Vendedor Valor
1 14/06/2012 16:03:12 Paulo M. R$ 2.500,00
2 15/06/2012 16:33:01 Julio W. R$ 1.850,00
3 16/06/2012 18:50:10 Paulo M. R$ 3.300,00
4 17/06/2012 16:33:01 Paulo M. R$ 4.500,00
5 18/06/2012 17:25:06 Maria T. R$ 200,00
6 13/07/2012 12:03:12 Julio W. R$ 2.135,00
7 14/07/2012 14:40:59 Paulo M. R$ 100,00
8 15/07/2012 13:22:08 Paulo M. R$ 130,00
9 16/07/2012 14:15:16 Maria T. R$ 4.750,00
10 17/07/2012 15:17:30 Maria T. R$ 1.889,00
Fonte: elaborado pela autora.
Caso um relatório de vendas seja emitido a partir dos dados do Quadro
1, ele poderia ser executado como na Figura 3.
86
Vendedor Valor
Paulo M R$2.500,00
JulioW R$1.850,00
Paulo M R$ 3.300,00
Paulo M R$ 4 .500,00
Maria T R$ 200,00
Julie W R$ 2 .135,00
Paulo M R$ 100,00
Paulo M R$ 130,00
Maria T R$ 4 .750,00
Maria T R$ 1.889,00
Figura 3 – Relatório de valor de vendas versus vendedor
Relatório Vendedor versus Valor
Fonte: elaborada pela autora.
O relatório de vendedor versus valor das vendas realizadas representa
a totalidade dos dados registrados na base. Este exemplo é meramente
ilustrativo. Em um banco de dados real, os registros de vendas de
grandes lojas têm um volume que impossibilitaria a sua representação.
Por este motivo, é necessário a seleção de conjuntos e realizar as
sumarizações. O Quadro 2 representa a sumarização realizada
mensalmente, a granularidade aumenta e o nível de detalhamento
diminui, pois não se sabe quais dias tiveram a melhor venda, não se tem
o detalhe de qual vendedor vendeu mais, ou ainda, em qual horário está
ocorrendo a venda. Mas, para a tomada de decisão, o mês de junho teve
desempenho de 57% aproximadamente sobre o total das vendas dos
dois meses somados.
87
Qual mês vendeu mais,
das 50 lojas, no ano
de 20127
Quadro 2 – Dados sumarizados para análises
Mês Soma_Valor
Jun/12 R$ 12.350,00
Jul/12 R$ 9.004,00
Fonte: elaborado pela autora.
As vendas somadas nos meses de junho e julho do ano de 2012 foram
de R$ 21.354,00. O exemplo é bastante reduzido e, por este motivo,
a elaboração de sumarazações são didáticas e bastantes simples. No
entanto, em um Data Warehouse em que os dados de diversas lojas são
carregados para analisar o desempenho do ano de 2012, por exemplo,
com 50 lojas de uma rede, com vendas diárias acima de R$ 20.000,00, as
consultas deverão ser elaboradas de maneira a responder à pergunta a
seguir (Figura 4).
Figura 4 – Pergunta analítica
Fonte: adaptado de Deagreez/ iStock.com.
88
https://www.istockphoto.com/br/portfolio/Deagreez?mediatype=photography
https://iStock.com
iijiffi5M.filM#-1·4MM&iMMl·IA i!MSM,Ql■M!i-1I M#dffiitM - 14/01/Wl l lb:03:UPaulo M HSUUU,00 - 14/Ubfl012 l b:03:U l'auloM H$2.!>UU,UU - 15/01/2012 16:33:01 JulluW R$1.550,00 - 15/06/2012 16:33:01 JulluW R$1.SSO,OO - 16/01/2012 18:50:10 Paulo M R$2.500,00 - 16/06/2012 18:50:10 PauloM R$3.300,00 - 17/07/7017 11i:3.'l:01 Paulo M R$1.R'.i0,00 - 17 /OC./7017 1(,:33:01 PauloM R$4500,00 - 18/02/2012 17:25:06 MarlaT R$3.300,00 - 18/06/2012 17:25:06 MarlaT R$200,00 - 13/02/2012 12:03:12 JulioW R$4.SOO,OO - 13/07/2012 12:03:12 JulioW RS2.135,00 - 14/03/2012 14:40:59 Paulo M R$200,00 - 14/07/2012 14:40:59 PauloM R$100,00 - 1S/03/2012 13:22:08 Poulo M R$430,00 - 1S/07/2012 13:22:08 PouloM RS130,00 - 16/Q",/7017 14:15:16 Mi:tt iiil R$7.110,00 - 16/07 /7017 14:15:16 M;tridT R$4.7'i0,00 17/03/2012 15:17:30 MariaT R$1.123,00 17/07/2012 15:17:30 Marial R$1.889,00
IMiiHl■.fü■a:1.a■ae&w1.w iiMSM·JlM■li·ii■&itMMl·I-
14/08/2012 16:03:12 PauloM R$2.600,00 14/04/2012 16:03:12 PauloM R$1.200,00 - 15/08/2012 16:33:01 Julio W RSl.550.00 15/04/2012 16:33:01 JulioW RSlS0.00 - 1f,/OR/7017 1R:~.0:to Paulo M R$1.'!00,00 - tfí/04/7017 1R:r.0:10 P,iuloM R$700,00 - 17/09/2012 16:33:01 PauloM R$4.200,00 - 17/04/2012 16:33:01 PauloM R$150,00 - 18/09/2012 17:25:06 Marial R$800,00 - 18/04/2012 17:25:06 Marial R$3.200,00 - B/O'J[lOl.l ll:O.!:H Jullo W HSl.1:lb,00 - U/04/lOll H:03:ll Jullo W HSl.!>00,UU - 14/10/7017 14:40:59 PauloM R$700,00 - 14/~/7017 14:40:'.'l Paulo M R$700,00 - 15/10/2012 13:22:08 PauloM R$430,00 - 15/05/2012 13:22:08 PauloM R$830,00 - 16/10/2012 1/4:15:16 Marta T R$U10,00 - 16/05/2012 14:15:16 Marial R$5.110,00 -- 1//10/2012 l~:1/:30 Maria 1 H$123,UU -- l//0~/2012 l~:1/:30 Maria 1 H$/.ll3.UU
Para responder a este alto nível de granularidade, foi necessário criar
sumarizações mensais que não estavam armazenadas, mas calculadas
por meio de consultas no banco de dados analítico.
Supondo que na coleta de dados das 50 lojas, apenas quatro diferentes
lojas tinham os dados registrados no banco; ao analisar as tabelas
fornecidas apenas por essas quatro lojas, fica difícil de concluir qual mês
teve melhor desempenho. O nível de granularidade é muito baixo em
função do detalhamento na Figura 5.
Figura 5 – Dados coletados das vendas mensais de quatro lojas
Loja 1 Loja 2
Loja 3 Loja 4
Fonte: elaborada pela autora.
89
Com base nos resultados coletados, extratificados na Figura 5, é possível
responder à pergunta com apenas quatro lojas? Se aguardar a obtenção
dos dados de 50 lojas, pode-se incorrer em demora, ou muitas vezes os
dados nem serem disponibilizados a tempo para a análise de tomada de
decisão, cujo principal objetivo é o de responder o mais rápido possível a
pergunta realizada.
Sendo assim, o modelo de sumarização deve estar preparado para
receber os dados das outras 46 lojas, mas não pode ser impeditivo de
realizar as consultas analíticas, estando claro também para a alta gestão,
que terá uma visão parcial.
A granularidade precisa estar explicita, isto quer dizer que a
sumarização será realizada para apenas quatro lojas com a
expectativa para mais 46 lojas. Uma estratégia de granularidade
deve ser executada em acordo com os projetistas e usuários que
irão analisar os dados. Desta maneira, a sumarização terá como base
inicial as quatro lojas com os respectivos faturamentos mensais,
conforme apresentado no Quadro 3.
As tabelas periféricas servem de insumos para as sumarizações na
tabela central cuja granularidade é maior, sem o nível de detalhamento
das tabelas adjacentes.
90
----------------
Quadro 3 – Tabela sumarizada a partir das tabelas adjacentes
Filial 1
Id_
Vendas
Data Hora Vendedor Valor
1 14/01/2012 16:03:12 Paulo M. R$ 2.200,00 BG
2 15/01/2012 16:33:01 Julio W. R$ 1.550,00
3 16/01/2012 18:50:10 Paulo M. R$ 2.500,00 Fato
4 17/02/2012 16:33:01 Paulo M. R$ 1.850,00
5 18/02/2012 17:25:06 Maria T. R$ 3.300,00 Mês Soma_Valor
6 13/02/2012 12:03:12 Julio W. R$ 4.500,00 jan/12 R$6.250,00
7 14/03/2012 14:40:59 Paulo M. R$ 200,00 fev/12 R$9.650,00
8 15/03/2012 13:22:08 Paulo M. R$ 430,00 mar/12 R$ 3.863,00
9 16/03/2012 14:15:16 Maria T. R$ 2.110,00 abr/12 R$ 6.400,00
10 17/03/2012 15:17:30 Maria T. R$ 1.123,00 mai/12 R$13.763,00
jun/12 R$12.350,00
Filial 3 jul/12 R$ 9.004,00
Id_
Vendas
Data Hora Vendedor Valor ago/12 R$ 5.450,00
1 14/08/2012 16:03:12 Paulo M. R$ 2.600,00 set/12 R$ 6.136,00
2 15/08/2012 16:33:01 Julio W. R$ 1.550,00 out/12 R$ 4.863,00
3 16/08/2012 18:50:10 Paulo M. R$ 1.300,00
4 17/09/2012 16:33:01 Paulo M. R $4.200,00
5 18/09/2012 17:25:06 Maria T. R $800,00
6 13/09/2012 12:03:12 Julio W. R$ 1.136,00
7 14/10/2012 14:40:59 Paulo M. R$ 200,00
8 15/10/2012 13:22:08 Paulo M. R$ 430,00 AG
9 16/10/2012 14:15:16 Maria T. R$ 4.110,00
10 17/10/2012 15:17:30 Maria T. R$ 123,00
Filial 2
Id_
Vendas
Data Hora Vendedor Valor
1 14/06/2012 16:03:12 Paulo M. R $2.500,00
2 15/06/2012 16:33:01 Julio W. R$ 1.850,00
3 16/06/2012 18:50:10 Paulo M. R$ 3.300,00
4 17/06/2012 16:33:01 Paulo M. R$ 4.500,00
5 18/06/2012 17:25:06 Maria T. R$ 200,00
6 13/07/2012 12:03:12 Julio W. R$ 2.135,00
7 14/07/2012 14:40:59 Paulo M. R$ 100,00
8 15/07/2012 13:22:08 Paulo M. R$ 130,00
9 16/07/2012 14:15:16 Maria T. R$ 4.750,00
10 17/07/2012 15:17:30 Maria T. R$ 1.889,00
Filial 4
Id_
Vendas
Data Hora Vendedor Valor
1 14/04/2012 16:03:12 Paulo M. R$ 1.200,00
2 15/04/2012 16:33:01 Julio W. R$ 150,00
3 16/04/2012 18:50:10 Paulo M. R$ 200,00
4 17/04/2012 16:33:01 Paulo M. R$ 150,00
5 18/04/2012 17:25:06 Maria T. R$ 3.200,00
6 13/04/2012 12:03:12 Julio W. R$ 1.500,00
7 14/05/2012 14:40:59 Paulo M. R$ 700,00
8 15/05/2012 13:22:08 Paulo M. R$ 830,00
9 16/05/2012 14:15:16 Maria T. R$ 5.110,00
10 17/05/2012 15:17:30 Maria T. R$ 7.123,00
Legenda: AG – Alta granularidade; BG – Baixa granularidade.
Fonte: elaborado pela autora.
A tabela sumarizada contém os valores das somas de cada mês, é uma
tabela, que é alimentada a partir dos dados provenientes das tabelas
das lojas. Este conjunto forma o DW do exemplo.
Se estes dois níveis de granularidade fossem usados para uma
representação gráfica, como mostra o Gráfico 1, pode-se verificar que o
gráfico com a nível de granularidade baixo fica impossível de analisar, no
91
Valores vendas/dia
R$8.000,00
R$6.000,00
R$4.000,00
R$2.000,00
R$0,00 111.JJ1 •• 1
Valor
R$15.000,00
R$10.000,00
R$5.000,00
R$-
Sumarização: Soma_Valor
1 1 1 1 1 1 1 1
entanto, quando a tabela sumarizada e explicitada em modo gráfico é
possível realizar as leituras de forma eficiente.
Gráfico 1 – Representação dos dados versus granularidade
Fonte: elaborado pela autora.
A representação gráfica Valores vendas/dia remete a uma relação de
alta densidade dos dados para uma baixa granularidade, portanto, sua
interpretação fica prejudicada. No entanto, a alta granularidade propicia
melhor representação da sumarização, tornando mais eficiente as
comparações e a análise do comportamento dos dados em uma visão de
conjunto. Neste caso, o mês de maio de 2012 teve o melhor desempenho.
PARA SABER MAIS
Dados históricos: são os dados provenientes do ambiente
operacional, levemente resumidos (MACHADO, 2011), assim
há dois níveis de granularidade. Os dados históricos em
que possam ser alcançados níveis de detalhes e os dados
resumidos, compactos e fácil acesso, disponíveis para análises.
A medida que a granularidade se eleva, esta corresponde a diminuição
da utilização de consultas as bases dos dados operacionais. Neste
92
sentido, a modelagem dos dados para um projeto DW é diferente da
modelagem de dados de um ambiente operacional.
Este é também o motivo de não ser possível mover um banco
transacional para um banco analítico. Isto acarretará alta complexidade
para realizar consultas ad hoc que exigem cálculos acessórios. E
modelos de dados transacionais são contruídos de acordo com a 3ª
Forma Normal (3FN), não respondem com rapidez às consultas, que
necessitamde mais de cinco joins de tabelas.
PARA SABER MAIS
3FN: é uma forma de normalização, neste caso, cálculos
são excluídos da tabela, pois estes cálculos dependem de
colunas dessa tabela.
Consultas ad hoc: são consultas especializadas ou
específicas, como um cálculo, uma sumarização, uma junção
de duas tabelas, para estabelecer uma correspondência.
Join: são métodos de junção de dados de tabelas diferentes.
Respeitando os modelos de conjuntos. Por exemplo, inner
join da tabela A com a tabela B, retorna os dados que
são comuns nas duas tabelas, left join entre a tabela A e a
tabela B, retorna todos os dados da tabela A mais os dados
comuns entre A e B.
A modelagem de dados é um requisito fundamental para o DW, e não
pode utilizar as mesmas técnicas que são aplicadas para modelar os
bancos transacionais. Existem duas técnicas distintas, a modelagem
ER (Entidade Relacionamento), e a multidimensional, ambas com
abordagem específica para modelos DW.
93
2. Modelagem de dados para DW
Um modelo é uma abstração e tenta refletir o mundo real. Modelar
é uma abordagem que vislumbra o que ser quer realizar ou fazer.
Como exemplo, um esquema ou um desenho que tenta refletir
um pensamento ou uma ideia. A equação de uma reta, que liga
dois pontos do espaço, é um modelo que tenta refletir ou explicar
uma linha feita por um conjunto de pontos alinhados. Funciona da
mesma maneira quando se trata de dados (MACHADO, 2011). O dado
sozinho é um número ou uma variável e pouco representa algo, mas
quando associado a outros dados e transformado, revela contextos e
associa ideias.
O diagrama ER é uma ferramenta que ajuda na análise de requisitos de
negócio e no desenho da estrutura de dados relacionada a esse negócio
(MACHADO, 2011).
Inmon (2005) afirma que há três tipos de modelagem de dados,
mas destaca o ERD (Entity Relationship Diagram – Diagrama Entidade
Relacionamento) e que representa um alto nível de abstração, cuja
integração define os limites do modelo de dados, sendo necessária sua
definição antes que a modelagem ERD comece.
Como exemplo, uma casa tem orçamento mensal para que as
despesas sejam realizadas. Deve haver um controle de despesas em
relação ao orçamento, ou seja, as despesas não podem ultrapassar
o orçamento mensal disponível. Exemplos de despesas podem ser
produtos ou serviços que serão consumidos ou usados, com um valor
monetário associado. Com base nesses requisitos mínimos é possível
fazer a modelagem elaborando uma tabela “Controle de despesas”,
com colunas para o tipo de despesas, o valor das despesas, e com o
orçamento disponível, a ser decrementado do valor total como uma
forma de controle.
94
Orcamento
ld_orc11mento : INTEGER
Mes_orcamento; DATE
Valor _previsto: FLOAT
Diilt.a_pravi sao: DATE -
J ,_<º_• 1_1 .__ __ (0,n)
Classificacao_orcamento
f ld_orcamento: INTEGER
Mes_orcamento: DATE
-
ld_ Cod_t~@: INTEGER
Vi110f _ore.ido; INTEGER
Valor _realizado: INTEGER
Perce.ntual_oro~do: INTEGER
Percentual _realizado; INTEGER
Despesa
t Data_dupua: DATE
Sequencia_despesa; INTEGER
Nome_pessoa: VARCHAR
id_orcamanto: INTEGER
Mes_orcamento : DATE
ld_ Cod_t~t!: INTEGER
Mes ; DATE
V alor _despesa: DECIMAL
(0,n)
( (0,n)
(O,n)
(0, 1)
(0, 1)
Pessoa
Nome_pessoa:VARCHAR
' ld_pesson: INTEGER
ldado,: INTEG ER -
(0, 1)
Tlpo_despesa
f ld_ Cod_t-: INTEG ER
Descricao_tipo: VARCHAF -
As características da modelagem requerem a análise prévia em relação
aos dados. Orçamento disponível, deve ter um valor previsto e uma
data de previsão. Despesas é uma entidade que tem como atributos a
data em que ocorreu a despesa, a sequência da despesa (número de
vezes), nome da pessoa que realizou a despesa, a sua identificação com
a tabela de classificação do orçamento, mês que a despesa ocorreu,
tipo de despesa, e o valor da despesa. Outras entidades são incluídas
na modelagem com o objetivo de associar o nome da pessoa que
realizou a despesa, que tipo de despesa, como é a sua classificação
no orçamento, o valor da despesa foi incluído, e se a depesa cabe no
orçamento mensal.
Para ilustrar as duas abordagens sobre modelagem do exemplo
anterior, sob o o ponto de vista de negócio, o diagrama da Figura 6,
representa um modelo para operacionalizar esse negócio.
Figura 6 – MER da operacionalização do negócio despesa
versus orçamento
Fonte: adaptado de Machado (2011, p. 67).
95
O modelo ER descreve as operações relacionadas ao negócio e às
ligações entre as entidades do modelo. A abordagem desta modelagem
é operacional. Outra abordagem para este contexto do exemplo das
despesas versus orçamento, é a da gestão do negócio. Nesta perspectiva,
pode-se analisar como ocorre a necessidade de encontrar respostas
com respeito à evolução orçamentária anual. Ainda como ponto de
reflexão, qual a taxa da relação entre despesa e orçamento? Pensando
um pouco mais além, quais produtos ou serviços apresentam evolução
histórica de aumento?
Estas respostas permitem encontrar o comportamento do
desempenho do negócio, buscar simulações de cenários para
embasar as análises estratégicas e alocar decisões. Esta abordagem
remete à necessidade de construir um modelo dimensional.
No exemplo, as perguntas feitas são abstrações de localidade
(onde), temporalidade (quando), responsabilidade (quem) e
classificação (o quê).
Essas abstrações podem ser exemplificadas da seguinte forma:
a. Localidade (Onde?) – Local, cidade, região, país, etc.
b. Temporalidade (Quando?) – Trimestral, mensal, anual, semanal,
diário, etc.
c. Responsabilidade (Quem?) – Vendedor, promotor, pessoa,
fornecedor, etc.
d. Classificação (O quê?) – Venda, promoção, despesa, gastos, etc.
Uma modelagem pode ser construída com base nas abstrações de
localidade, tempo, responsáveis e a classificação. Outras abstrações
novas podem ser incluídas conforme o negócio da empresa. A Figura
7 representa um diagrama, sobre o mesmo exemplo, mas em outra
perspectiva, multidimensional.
96
Dim_Tempo
' id_data INTEGER
Data: DATE
Dia_semanda: DATE
Mes: DATE
Dim_Venda
1 Nome_local: CHAR
Vendedor: CHAR
(O,n)
10,1) 1~1) 1
Soma_gastos
[!]Nome_pessoa:CHAR
[!]Nomejocal : CHAR
(O, 1) (!]id_dala: INTEGER
S [!]Num_autentica: INTEGER Valor _gasto: FLOAT ~
(O,n)
0,1)
(O,n) >
Dim_Pessoa
1 Nome_pessoa: CHAR
Funcao: e HAR
(O,n)
(O, 1)
Dim__gastos
1 Num_aulentica: INTEGER
t .. Nome_aulentica: CHAR
Figura 7 – Modelo multidimensional
Fonte: adaptada de Machado (2011, p. 68).
Os questionamentos apresentados não podem ser respondidos por
meio de consultas às bases de dados operacionais, pois são necessários
cálculos de percentuais destinados às despesas que afetaram o
orçamento. Estes dados calculados são provenientes das operações de
entrada dos dados e a relação entre despesa e orçamento calculada em
tabelas acessórias.
Este exemplo permite contextualizar dois modelos de dados: um o
modelo ER e o outro o modelo multidimensional. Um depende do outro,
em que o MER contém os elementos operacionais da empresa, e o
modelo multidimensional reflete as métricas às dimensões relacionadas.
2.1 Modelagem ER
Um modelo ER utiliza três caracterizações para os dados: entidade,
relacionamento e atributos. A entidade é o objeto do mundo real,
97
ld_vendedor
nome
Vendedor
(O,n) (O,n )
ld_produto
tipo_produto
valor _produto
Produto
indentificado e com significado próprio. Pode ser um lugar, uma pessoa, um
evento. Representa classes de objetos, e pode ser observada e classificada
de acordo com suas carcaterísticas e propriedades (MACHADO, 2011). Esses
objetos do mundo remetem a um escopo de integração do mundo real,
que determinam a qual parte poderá refletir um modelo (INMON, 2005). O
modelo é descrito em suas partes e como elas se relacionam, no caso de
dado, é o Modelo Entidade Relacionamento (MER).
Para elucidar esse contexto, a Figura 8 exemplificaum MER de vendas, em
que o vendedor vende o produto. Vendedor e produto são as entidades
e “vende” é o relacionamento entre as duas entidades. O Id_produto e Id_
vendedor são as chaves primárias de cada entidade, e Produto, valro_
produto, Nome são os atributos relativos a cada entidade.
Figura 8 – Modelo ER Vendedor Produto
– modelo conceitual
Fonte: elaborada pela autora.
O reconhecimento de uma entidade é orientado pelo mundo real, no
ambiente onde ela existe, retratando a sua realidade por meio dos
dados. Pelo exemplo, o vendedor tem um nome a ele associado, e tem
uma ação de vender algo, que são produtos, estes, tem um tipo e um
valor (MACHADO, 2011).
98
A nomeação da entidade deve ser clara e refletir uma comunicação
ascessível sobre ela, orientando-se por uma nomenclatura que
represente as características e o escopo a ela atribuído. Por exemplo,
venda, pessoa, produto. Venda é a ação em si, que relaciona a pessoa ao
produto. Pessoa é quem compra ou pode até ser quem vende, e produto
é o objeto que foi vendido.
Cada entidade contém atributos, e um deles é um atributo chave, que
se identifica exclusivamente ao registro ao qual a chave pertence.
Na entidade Vendedor, a chave primária (PK) é o Id_Vendedor, é o
indentificador numérico de cada nome do vendedor. Em uma tabela do
banco de dados a chave primária é incluída em outra tabela e passa a
ser uma chave estrangeira (FK), para que os relacionamentos funcionem.
O mesmo acontece com produto, que tem um Id e um PK, conforme o
modelo da Figura 9.
ASSIMILE
Chave estrangeira (FK – Foreign key) é um atributo em um
sistema relacional, cujos valores são os valores da chave
primária de outra entidade relacionada. Não é uma chave
primária (INMON, 2005, p. 497).
Chave primária (PK – Primary Key) é um atributo que contém
valores que identificam exclusivamente o registro no qual a
chave existe (INMON, 2005, p. 501).
Analisando sob o ponto de vista de tabelas no banco de dados, o modelo
ER Vendas pode ter as tabelas criadas conforme a Figura 9.
99
Vendedor
1 ld_v endedor : INTE GER
no me: CHA R
(O,n)
Produto Venda
1 ld__produto: INTE GER
(0, 1) t ipo_produto : CHA R
v alor _produto : DOUBLE
(I] ld_ v endedor : 1 NTE G E R
Figura 9 – Modelo Lógico “Venda”
Fonte: elaborada pela autora.
O modelo lógico representa as entidades e seus relacionamentos,
com as indicações da chave primária na tabela Vendedor (desenho
da chave preta) e da chave estrangeira na tabela Produto Venda
(desenho da chave verde).
Ao construir as tabelas que serão inseridas no banco de dados,
uma possível organização pode ser verificada na Quadro 4. A tabela
Produto Venda contém o Id_vendedor como FK, para que a venda
possa estar relacionada com a tabela de vendedor.
100
-- -~~-----
- -~~----
t ♦
Quadro 4 – Tabelas dimensão do banco de dados
Vendedor
Id_vendedor Nome
1 Mario
2 Luis
3 Sergio
4 Augusto
5 Juvenal
Produto Venda
Id_pro-
duto tipo_produto
valor_pro-
duto id_vendedor
1 Geladeira soft R$ 2.500,00 4
2 Fogão galaxi R$ 899,00 3
3 Geladeira alfa R$ 1.890,00 3
4
Microondas
wave R$ 450,00 1
5 Ferro pass R$ 120,00 2
6
Aquecedor
ice5 R$ 3.689,00 1
7
Microndas
wavelet R$ 730,00 4
8 geladeira first R$ 1.320,00 2
Fonte: elaborado pela autora.
A partir das tabelas Vendedor e Produto Venda, é possível criar uma
tabela sumarizada do total de vendas de cada vendedor. Essa nova
tabela poderia ser criada a partir da tabela Vendedor e da Produto
Venda (Quadro 5), com o objetivo de representar o resultado do
desempenho de cada vendedor. São duas tabelas dimensões que
participam da tabela fato Desempenho Vendedor, uma dimensão
Vendedor e outra Produto Venda.
Quadro 5 – Tabela fato desempenho vendedor
Desempenho vendedor
Id_vendedor Nome total_vendedor
1 Mario R$ 4.139,00
2 Luis R$ 1.440,00
3 Sergio R$ 2.789,00
4 Augusto R$ 3.230,00
5 Juvenal R$ -
Fonte: elaborado pela autora.
101
O Quadro 5 representa a sumarização dos valores de cada produto
vendido por vendedor. A tabela Fato é concebida para visualizar um
conjunto de medidas que descrevem o desempenho característicos dos
vendedores relacionados com o tipo de negócio, venda de produtos
na categoria eletrodomésticos. A tabela Fato é composta por partes da
tabela Vendedor e partes da tabela Produto vendas incluindo as somas
das vendas por vendedor. Esta abordagem é denominada modelagem
multidimensional, e está representada pelo caso em estudo no Quadro
6. A modelagem multidimensional será explorada em sequência
deste tema, detalhando a composição das tabelas fato e das tabelas
dimensões, formando um cubo de interações.
Quadro 6 – Modelo muldimensional vendas
Vendedor
Id_vendedor Nome
1 Mario
2 Luis
3 Sergio
4 Augusto
5 Juvenal
Desempenho vendedor
Id_vendedor Nome total_vendedor
1 Mario R$ 4.139,00
2 Luis R$ 1.440,00
3 Sergio R$ 2.789,00
4 Augusto R$ 3.230,00
5 Juvenal R$–
Produto Venda
Id_produto tipo_produto valor_produto id_vendedor
1 Geladeira soft R$ 2.500,00 4
2 Fogão galaxi R$ 899,00 3
3 Geladeira alfa R$ 1.890,00 3
4 Microondas wave R$ 450,00 1
5 Ferro pass R$ 120,00 2
6 Aaquecedor ice5 R$ 3.689,00 1
7 Microndas wavelet R$ 730,00 4
8 Geladeira first R$ 1.320,00 2
=
m
ed
id
as
=
Fonte: elaborado pela autora.
102
Machado (2011) observa que a modelagem muldimensional é mais
simples e intelegível do que a modelagem ER, embora o nível de
abstração seja elevado, o modelo muldimensional está mais acessível
em termos de oferta de informação e é usada em projetos de Data
Warehouse, justamente por ser objetiva e compor conjuntos de dados
que possam representar alguma resposta as perguntas.
2.2 Modelagem muldimensional
Uma questão emblemática no projeto de DW é a utilização do modelo
relacional (MER) e o modelo muldimensional para o design do banco
de dados de Data Warehouse. Inmon (2005) orienta o uso do modelo
relacional para projetos DW, no entanto, Kimball ( 2002) orienta que o
modelo multidimensional deva ser levado em consideração em projetos
de DW. Fazendo uma análise das duas orientações, conclui-se que a
modelagem relacional é a abordagem de longo prazo no desenho de
projetos DW, já a modelagem multidimensional permite implementações
a curto prazo quando o escopo é reduzido.
A modelagem multidimensional, segundo Machado (2011, p. 79), é uma
técnica para concepção e visão de dados a partir de um conjunto, que
podem formular respostas as perguntas de negócios. Essa técnica é
utilizada para sumarizar e restruturar dados, de modo a representá-los
em visões que detenham suporte às análises necessárias. Com exemplo,
as companhias aéreas utilizam essa técnica para representar seus DW,
por causa do tipo de negócio, agência reguladora do governo, agências
de viagens e aeroportos.
Machado (2011) esclarece que o modelo multidimensional é composto
de três elementos básicos:
103
a. Fatos.
b. Dimensões.
c. Métricas.
Uma tabela Fato é composta de dados, medidas e contexto,
provenientes de dimensões. Uma Fato representa um item, uma
transação ou um evento relacionado ao negócio, possui valores
numéricos e sua implementação é feita em tabelas denominadas tabela
fato (fact tables).
As dimensões, para Machado (2011) são os elementos, dados, fórmulas,
cálculos, processados, que participam ou são chamadas por meio
de chaves estrangeiras (FK) dentro de uma fato. As dimensões são
os assuntos do negócio, por exemplo, faturamento por mês, gastos
por semana, vendas por região, etc. As dimensões apresentam um
contexto do negócio, supondo uma análise de vendas, ou melhor, em
uma tabela fato de vendas, as dimensões que participam dessa Fato
podem ser vendas dos produtos em relação ao tempo, a localização, aos
clientes, aos vendedores, as sazonalidades, dentre outros cenários que
influenciam no negócio.
Já as medidas, são os atributosvalorados numericamente que
representam uma tabela Fato. Como exemplo de medida, a quantidade
de unidades de um produto vendidas, a quantidade de produtos em
estoque, o percentual de lucro, dentre outras medições.
Portanto, ao casar as três técnicas, as dimensões, a Fato e as
medidas, a melhor maneira de visualizar é por intermédio de um
cubo. A forma facilitadora de representar o modelo multimensional
pelo desenho de um cubo tridimensional, colocando as características
técnicas nele. A Figura 10 mostra uma representação cúbica
multidimensional, considerando um negócio genérico de venda de
produtos por cidade.
104
Figura 10 – Modelagem muldimensional vendas
Vendedores
Pr
od
ut
os
Loj
as
Temporalidade
DIMENSÕES: PRODUTO, CIDADE, TRIMESTRE.
Fato: produtos por cidade no trimestre.
Medidas: soma das vendas trimestrais por produto.
Fonte: hh5800/ iStock.com.
O exemplo demostra claramente como a modelagem multidimensional
pode ser representada, por meio de um cubo,formado por tabelas
que se associam, sumarizam ou se agregam e que compõem alguma
métrica. Cada tabela pode ser interpretada como uma dimensão, todas
as tabelas juntas formam o cubo e hieraquicamente, a granularidade
em nível alto ou baixo, extrai-se as tabelas Fato e destas as medidas. Há
casos em que medidas e cálculos são realizados nas dimensões para
105
https://www.istockphoto.com/br/portfolio/hh5800?mediatype=photography
https://iStock.com
depois serem indexados nas tabelas Fato. A partir das Fatos, medidas,
sumarizações e agregações podem ser representadas por meio de
visualizações a serem consumidas pelos usuários.
3. Considerações Finais
A modelagem de dados é uma das etapas importantes em um projeto
de DW, levando em consideração os níveis de granularidade do dado
e ou do conjunto de dados dos quais se quer obter resultados ou
respostas. Além disso, a modelagem entidade relacionamento propõe
um caminho inicial para sistematizar conceitos mais complexos como
a granularidade e a abordagem sobre como construir tabelas Fato a
partir de tabelas dimensões. A maturidade necessária empregada à
modelagem multidimensional tornar-se-á mais eficiente na medida
em que a base do modelo ER estiver compreendida. Projetos de DW
requerem um acúmulo de experiências dos profissionais, principalmente
na fase inicial, na modelagem. Na prática cubos, dimensões, Fatos e
medidas devem ser modeladas multidimensionalmente em projeto de
DW por serem mais fáceis de implementar.
TEORIA EM PRÁTICA
Uma empresa produtora de grãos para exportação e
abastecimento no mercado brasileiro deseja iniciar um
projeto de Data Warehouse. A empresa compra os grãos
in natura de três fazendas, faz a coleta nos silos, leva
para produção de lotes para comercialização interna e
internacional. Faça uma simulação de uma modelagem
muldimensional, considerando cinco tipos de grãos: feijão
fradinho, feijão carioca, feijão preto, feijão branco e feijão
fava. A produção é trimestral, com variações de 10% em
106
cada trimestre, a melhor safra é nos três ultimos meses
do ano, quando não é afetada pelas variações climáticas
e chuvas. As fazendas estão localizadas nas regiões Norte,
Nordeste e Centro-Oeste, e a fábrica de separação e
ensacamento fica no sul do país. A logistica para transporte
dos silos das fazendas é quinzenal. A produção dos feijões
é afetada pela variação climática, nos seis primeiros meses
do ano – clima muito quente e chuvas. Com base nesse
cenário, projete um banco de DW por meio das técnicas
de modelagem multidimensional. Simule o ambiente
populando as tabelas dimensões com dados fictícios de
produção agrícula, temperatura, tempo e localidade.
VERIFICAÇÃO DE LEITURA
1. Quais os elementos básicos que compõem um
modelo multidimensional e um modelo relacional,
respectivamente?
a. Modelo multidimensional: Fatos, dimensões
e métricas; modelo relacional: entidade,
relacionamento, atributos.
b. Modelo multidimensional: entidade, dimensões e
métricas; modelo relacional: Fatos, relacionamento,
atributos.
c. Modelo multidimensional: Fatos, entidades e métricas;
modelo relacional: entidade, relacionamento,
dimensões.
107
d. Modelo multidimensional: entidade, relacionamento,
atributos; modelo relacional: fatos, dimensões
e métricas.
e. Modelo multidimensional: entidade e dimensões;
modelo relacional: fatos e relacionamento.
2. A sumarização e reestruturação dos dados permite
representá-los em visões que suportam as análises. Para
que isso ocorra, é necessário a utilização de técnica que
auxilia na concepção e o desenho da visão dos dados
em conjunto, indo no nível mais alto ao nível mais baixo
de detalhamento desses dados. Aponte a alternativa
correta que cite essa técnica.
a. Modelagem.
b. Granularidade.
c. Relacionamento.
d. Entidade.
e. Especialização.
3. O que representam atributos valorados numericamente
e que representam as tabelas fato, associando por
exemplo, quantidades de vendas, quantidade em
estoque, percentual de lucro, etc.
a. Relacionamento.
b. Chave estrangeira.
c. Medidas.
d. Modelos.
e. Chave primária.
108
Referências Bibliográficas
INMON, W. H. Building the Data Warehouse. 4. ed. New York: Wiley Computer
Publishing, 2005.
KIMBALL, R. The Data Warehouse Toolkit: guia completo para modelagem
dimensional. Rio de Janeiro: Campus, 2002.
MACHADO, F. N. R. Tecnologia e Projeto de Data Warehouse. 5. ed. São Paulo,
Editora Érica, 2011.
Gabarito
Questão 1 - Resposta A.
Resolução: de acordo com Machado (2011), o modelo
multidimensional é composto de três elementos básicos: Fatos,
dimensões e métricas. Uma tabela Fato é composta de dados,
medidas e contexto, provenientes de dimensões. Essas dimensões
são assuntos do negócio e tem três outros elementos básicos, como
dados, fórmulas, cálculos, processados, que participam ou são
chamados por meio de chaves estrangeiras dentro de uma Fato.
Questão 2 - Resposta B.
Resolução: a granularidade é uma técnica que visa auxiliar nas
sumarizações, nas visões e na concepção de análises de conjuntos
de dados. Esta técnica pode ser utilizada para representar níveis
de detalhamento dos negócios desde as operações até análises
esepcíficas dos negócios. Quanto maior o nível de detalhamento
menor a granularidade, e vice-versa.
Questão 3 - Resposta C.
Resolução: as medidas ou métricas são os atributos valorados
numericamente que representam uma tabela Fato, que será usada
para compor as representações da mensuração pretendida. São
exemplos de medida: a quantidade de unidades de um produto
vendidas, a quantidade de produtos em estoque, o percentual de
lucro, dentre outras medições.
109
Esquema Estrela e Esquema Floco
de Neve
Autora: Iolanda Cláudia Sanches Catarino
Objetivos
• Conhecer e compreender a modelagem
multidimensional e seus elementos.
• Conhecer e compreender o Esquema Estrela (Star
Schema) da modelagem multidimensional.
• Conhecer e compreender o Esquema Floco
de Neve (Snow Flake Schema) da modelagem
multidimensional.
1. Fundamentos da modelagem multidimensional
Nos sistemas transacionais com o uso de bancos de dados
relacionais, a performance em tempo de resposta, bem como a
minimização da redundância e inconsistência dos dados, pode
ser garantida com o processo formal de normalização de dados,
tornando as consultas mais simples para atenderem as tarefas
rotineiras dos usuários. Já nos Data Warehouses (DW), as consultas são
mais complexas, envolvendo um grande volume de dados históricos
com diferentes codificações e predomina-se a não-volatividade.
Para o projeto e especificação dos DW adota-se a modelagem
multidimensional.
A modelagem multidimensional representa uma abstração dos dados
armazenados, consistindo em um modelo composto por tabelas de
Fatos e de Dimensões queproporcionam uma visão multidimensional
de grande quantidade de dados.
Segundo Kimball (1998), os Fatos representam uma coleção de
itens de dados, composta de dados de medidas, representando
uma transação ou um evento de negócio. Um fato é representado
por valores numéricos em um esquema e implementado em
tabelas denominadas de tabelas de Fatos. As dimensões são os
elementos que participam de um fato, ou seja, são as possíveis
formas de visualizar os dados de forma descritiva e classificatória,
determinando o contexto de um assunto de negócio. Os elementos
que representam uma dimensão são especificados em um esquema e
implementados em tabelas denominadas de tabelas de Dimensões.
O modelo multidimensional contém as mesmas informações que
um modelo normalizado, mas agrupa-se os dados com o objetivo de
111
reestruturá-los para facilitar a compreensão dos usuários e melhorar
o desempenho de consulta dinâmicas, a partir de uma representação
conceitual dos dados em várias visões que exibem as informações
no formato de um cubo. Este cubo pode ser fatiado e aprofundado
em cada dimensão ou seu eixo para permitir a extração dos detalhes
e processos internos de uma empresa de forma simples de serem
analisados.
Na visão de Barbieri (2001), a modelagem multidimensional é uma
técnica de projeto que conduz os dados a uma fase (cubo), em que
a informação reside na interseção de várias dimensões, permitindo
que o usuário perceba os dados numa forma próxima de seu
entendimento, com várias perspectivas possíveis, dentre elas o tempo
e o espaço. Elmasri e Navathe (2011) explicam que:
Modelos multidimensionais tiram proveito dos relacionamentos
inerentes nos dados para preencherem os dados em matrizes
multidimensionais, chamadas cubos de dados. Se tiverem mais de
três dimensões, estes podem ser chamados de hipercubos. (ELMASRI;
NAVATHE, 2011, p. 722)
Um processamento Online Analytical Processing (OLAP –
Processamento Analítico On-line) estrutura logicamente dados
multidimensionais no formato de um cubo, o qual os usuários finais
visualizam os dados armazenados como um cubo de dados. O cubo
apresenta várias dimensões que são subconjuntos de atributos. A
Figura 1 mostra um exemplo de cubo de dados com três dimensões:
localização com hierarquia dos dados por estado e cidade; tempo
com hierarquia dos dados por ano e trimestre; e produto, o qual
é possível mensurar o volume de vendas, calculando o valor total/
quantidade de vendas dos produtos por estado/cidade no ano/
trimestre.
112
[1,j m e rns.ã:o Loca l'i~a çã:o e
H iera rq u ia par Estado e
,did!ad:e
IC l ~-1 e 2
E n
Cn
1) i m en,scã,o Produto
Med i:da = Vo l ume de Vendas
Fat o,s. = Va lor t ota l / quant idade de vendas ,de Produtos por Est ado/ Ci dade no Ano/Tr i mestre.
Figura 1 – Exemplo de cubo de dados
Fonte: elaborada pela autora.
PARA SABER MAIS
Online Analytical Processing (OLAP – Processamento
Analítico On-line): o termo representa a característica
de se trabalhar os dados com operadores dimensionais,
possibilitando uma forma múltipla e combinada de análise. O
ambiente de processamento analítico OLAP é caracterizado
por consultas complexas, estruturadas e frequentes,
envolvendo agregação ou relacionamento de dados para
gerar informações que apoiam processos decisórios.
Considerando que um modelo de dados multidimensional pode ser
representado por um cubo tridimensional, não implica que haja um
113
limite para o número de dimensões que podem ser associadas a uma
tabela de Fatos. Não há limite matemático para o número de dimensões
utilizadas (ROB; CORONEL, 2011).
Existem algumas abordagens específicas para modelagem
multidimensional, derivadas da aparência do esquema traçado, a partir
do Diagrama de Entidades e Relacionamentos (DER), relacionando
as tabelas de Fatos com as tabelas de Dimensões, sendo que a mais
utilizada é o Esquema Estrela (Star Schema) e uma variante deste
esquema é denominado de Esquema Floco de Neve (Snow Flake Schema),
as quais são apresentadas nos itens a seguir.
2. Esquema Estrela (Star Schema)
O Esquema Estrela (Star Schema) é a abordagem proposta por Ralph
Kimball que visa criar esquemas físicos mais simples e incrementais. O
nome estrela foi definido em função da disposição em que se encontram
as tabelas, sendo a tabela de Fatos, centralizada no esquema, e as
tabelas de Dimensões são relacionadas nas pontas do esquema, de
forma independente entre as dimensões. Segundo Kimball (1998),
o esquema de dados mais utilizado na especificação de um DW é o
Esquema Estrela.
Na concepção de Poe, Klauer, Brobst (1998), o Esquema Estrela possui
uma estrutura simples com poucas tabelas e associações bem definidas,
aproximando do contexto do modelo de negócio e facilitando a geração
de consultas complexas de forma intuitiva e interativa, por meio dos
vários parâmetros de consultas. Neste esquema, o assunto principal
fica ao centro do esquema, representada pela tabela de Fatos, e suas
características, as dimensões, representadas por tabelas de Dimensões,
ficam posicionadas ao seu redor, permitindo a leitura e compreensão
114
até mesmo de usuários finais que não estão adaptados com estruturas
de banco de dados.
As tabelas de Dimensões contêm a descrição textual do negócio
representada pelos atributos e com a indicação da chave primária,
que serve como base para manter a integridade referencial quando
relacionada com a tabela de Fatos. A tabela de Fatos é a tabela
dominante do Esquema Estrela composta por dois tipos de atributos:
as chaves estrangeiras que caracterizam as métricas estabelecidas
nas tabelas de Dimensões, e os atributos que definem os fatos a
serem medidos.
Na concepção de Colaço (2004), o nome Esquema Estrela foi adotado
pela semelhança com uma estrela, sendo o esquema composto de
uma tabela dominante no centro, chamada de Fatos, rodeada por
tabelas auxiliares, chamadas de tabelas de Dimensões, o qual a tabela
de Fatos conecta-se às tabelas de Dimensões por várias junções e cada
tabela de Dimensão se conecta com apenas uma junção à tabela de
Fatos. O esquema tem como característica básica a presença de dados
altamente redundantes, considerando a desnormalização das tabelas
dimensionais dos dados, para se obter um melhor desempenho em
tempo de execução.
De acordo com Machado (2013), o Esquema Estrela é a estrutura
básica de um modelo de dados multidimensional composto por uma
grande entidade central denominada Fato (Fact Table) e um conjunto
de entidades menores denominadas Dimensões (Dimension Tables),
organizadas ao redor da entidade central, formando uma estrela,
como mostra a Figura 2. Os relacionamentos entre a tabela de Fatos
e as tabelas de Dimensões são definidas por ligações simples em um
relacionamento de um para muitos (1:N) no sentido das dimensões
para o fato.
115
Dimensão
Lacaliz:ação
... -
Dimensão
Tempo
Dimensão
Produto
,,
!Fatos
Vendas
Dimensãio
a iente
Dimensão
Filial
Figura 2 – Esquema Estrela (Star Schema)
Fonte: adaptada de Machado (2013).
Rob e Coronel (2011) descrevem que o Esquema Estrela é uma técnica
de modelagem de dados utilizada para mapear dados multidimensionais
de suporte às decisões em um banco de dados relacional, por meio de
seus fatos e dimensões que são representadas como tabelas físicas no
banco de dados do DW, sendo que a tabela de Fatos é relacionada com
cada tabela de Dimensão em um relacionamento “muitos para um”. Eles
relacionam os seguintes componentes desse esquema:
a. Fatos: são medidas numéricas que representam um aspecto
ou atividade específica do negócio e que também podem ser
calculados ou derivados em tempo de excecução, armazenados
em uma tabela de Fatos que constitui o centro do Esquema
Estrela. Os fatos normalmente utilizados em análise de dados
comerciais referem-se aos indicadores dedesempenho
do negócio.
116
b. Dimensões: são as características descritivas que fornecem
as perspectivas adicionais a um determinado fato por meio
de seus atributos. As dimensões são armazenadas em tabelas
de Dimensões vinculadas a tabela de Fatos. As dimensões
normalmente utilizadas em uma análise de dados de vendas
(Fatos Vendas) podem ser as dimensões de produto/serviço,
localização e tempo.
c. Atributos: representam os valores das características descritivas
sobre os fatos. Cada tabela de Dimensão contém atributos
que constumam ser utilizados para buscarem, filtrarem e
classificarem fatos.
d. Hierarquias: representam a ordenação em hierarquias
de atributos no interior das dimensões, fornecendo uma
organização vertical adotada para a finalidade de detalhamento
e agregação de dados, no DW, por operações de drill down ou
roll up (também chamado de drill up). As operações permitem
o detalhamento dos atributos, definindo um caminho para
identificar como os dados devem ser dissociados ou agregados.
A Figura 3 mostra o exemplo de hierarquias dos atributos
de localização detalhada por região, estado, cidade e loja;
tempo detalhado por ano, trimestre, mês e semana; e produto
detalhado por tipo, categoria, grupo e subgrupo.
ASSIMILE
A granularidade de dados faz referência ao nível de
detalhamento dos dados de uma tabela. Quanto maior o
nível de detalhe, menor será a granularidade.
117
Hierarquia do atributo
Localização
Cidade
Loja
Hierarquia do atributo
Tempo
Mês
Semana
Hierarquia do atributo
Produto
Grupo
Subgrupo
Figura 3 – Hierarquia de atributos
Fonte: adaptada de Rob e Coronel (2011).
Os DW geralmente são constituídos de muitas tabelas de Fatos que
armazenam grande quantidade de dados históricos relacionadas com
as tabelas de Dimensões, cada uma projetada para responder questões
específicas de suporte a decisões. As tabelas de Fatos e de Dimensões
são relacionadas por chaves estrangeiras, sendo que a chave primária
do lado “1” da tabela de Dimensão, é armazenada como parte da chave
primária do lado “muitos” da tabela de Fatos. Como a tabela de Fatos
está relacionada com várias tabelas de Dimensões, a chave primária
da tabela de Fatos é sempre formada combinando-se as chaves
estrangeiras que apontam para as tabelas de Dimensões, formando
uma chave composta.
A Figura 4 ilustra um exemplo do Esquema Estrela com os
relacionamentos entre as tabelas de Fatos de Vendas e as tabelas de
Dimensões de localização, tempo, loja filial e produto. A chave primária
da tabela de Fatos vendas é composta de loc_ID, tem_ID, loj_ID e pro_
ID. Cada registro da tabela de Fatos vendas representa os produtos
vendidos por uma loja, em uma localização específica e em data
118
Dim Localizacao Dim Loia Fllial
loc_lO lnlllg&r(10) loj_lO lnlllg&r(10)
til toc_Desa-icao van:har(255) ~ til k>LNome van:har(255) ~
[li k>c_Cidade van:har(S0) ~ [li k>LEndeleoo van:har(255) ~
til loc_Estado chal(2) ~ til 1c> LBrick van:har(30) ~
til loc_Regiao van:har(20) ~
- Fatos Veodas
~ /oc_/0 fnreger{fO}
~ tem_lD fnleger(fO}
~ /o}_ID fn1Bger(10}
~ pro_iD fnreger(fO}
fll ven_Quantldade nteger(10)
lll ve11_ ValorTotal d«imal(19, 2)
lil ven_Rentabifidade decimaJ(19, 2)
lil voo_ ValorDesconto decimal(19, 2)
Dim_Tempo Dim_Produto
' tem_lD lnteg&r(10) f pro_lD lnleg&r(10)
til tem_Hora date ~ til pm_Nome van:har(100) ~
ijj tem_Dia dato ~ lil pro_Desa-icao van:har(255) ~
ijj tem_Mes date ~ ijj pro_Tpo van:har(20) ~
til tem_Ano date ~ til pro_Marca van:har(30) ~
Ili pro_PrecoCusto decimal(10, 2) ~
Ili pro_PrecoVenda decimal(10, 2) ~
lil pro_DesaontoMaximo nwneric(2, 2) ~
específica, identificado exclusivamente pela combinação dos valores de
cada uma de suas chaves estrangeiras.
Figura 4 – Esquema Estrela para vendas
Fonte: elaborada pela autora.
Colaço (2004) descreve que o Esquema Estrela é assimétrico, pois
percebe-se nitidamente a tabela de Fatos como dominante do esquema,
e é flexível para suportar a inclusão de novos elementos de dados, bem
como mudanças que ocorram no projeto.
A Figura 5 ilustra um esquema com duas tabelas de Fatos, também
conhecido como uma constelação de fatos, ou seja, um conjunto de
tabelas de Fatos que compartilham algumas tabelas de Dimensões
do mesmo esquema. Na figura, as tabelas de Fatos vendas e compras
compartilham as tabelas de Dimensões de produto e tempo.
119
orn Locallzacao
\ loc_lO lnllger(10)
li! loc_Descncao varchar{255) ~ Dim L""' Miai
1i1 1oc_Cidade van:hat(SO) ~
Fatos Vendas U loj_lD lnllger(10)
li! loc_Estado ch:!1(2) ~ ~ ~,o /nreger/10) li! loLNome varchar(255) ~
E!j 1oc_Regiao varchar(25) ~
"" tem_lD lnreger/10) 5'l loLEnoomoo varchar(255) ~
loj_/D lnleger/10) "' uj loLB<id< varchar(30) ~
pro_lD lnreger(f0)
uj ven_Quanlidado inloger(10)
Din Te~ lil ven_Vatorlotal declrnat(19, 2) ~ 0m Produto
\ Lem_lO lnllger(10) - lil ven_Rentablldade declmal(19, 2) 'i pro_lD lnleger(10)
li! lern_Hora dale ~ 5'l ven_ ValorDescooto decimal(19, 2) 5'l pro_Norne varchar(100) ~
[ll lern_ Ola dale ~ E!j pro_Dcsaicao varchar(255) ~
5'l lem_Mes date ~ [:il pro_T,po varchar(20) ~
uj lom_Ano dato ~ -
Fatos Compras rn pro_Matca varchar(30) ~
~ · tem_lD lnleger/10) 5'l pro_PrecoCusto decimal(10, 2) ~
d/s_/0 lnleger/10) - Ili pro_PrecoVenda decimal(10. 2) ~
pro_lD lnleger/10) til pro_Des00<1toMaxirno numeric(2, 2) ~
uj corn_PrecoPago Din Distribuidora decimat(19, 2)
\ dls_lO lnllge,(10)
~
lil corn_UnidadeComprada in lege,(1 O)
uj dls_RazaoSoclal varchar(255) ~ 5'l corn_DesconloAplcado decinal(4, 2)
fij dls_NomeFantasia varchar(255) ~
5'l dis_EnderecoComplolo varchar(255) ~
li! ... varchar(255)
Figura 5 – Esquema Estrela para vendas e compras
Fonte: elaborada pela autora.
Destacam-se como as principais vantagens do Esquema Estrela:
• A estrutura padronizada e regular do esquema é bastante simples,
permitindo que a modelagem do esquema e as ferramentas
de acesso aos dados disponibilizem funcionalidades intuitivas
que facilitem a interação dos usuários com a manipulação dos
dados, bem como à apresentação e o desempenho das consultas
geradas, para análise das informações (KIMBALL; ROSS, 2013).
• A facilidade e a flexibilidade da inclusão de novos elementos de
dados, a partir do relacionamento da tabela de Fatos com uma
nova tabela de Dimensão, bem como, o acréscimo de novas
colunas às mesmas tabelas de Dimensões (COLAÇO, 2004).
• As consultas ocorrem inicialmente nas tabelas de Dimensões
e depois nas tabelas de Fatos, assegurando a consistência dos
dados por meio de uma estrutura de chaves que garanta o acesso
aos dados com melhor desempenho.
• O fornecimento de um mapeamento direto e intuitivo entre as
entidades de negócios de um modelo de dados para as tabelas
de Fatos e tabelas de Dimensões do esquema, facilitam o
entendimento de usuários finais que não estão adaptados com
estruturas de bancos de dados.
120
Date (2004) aponta como uma desvantagem do Esquema Estrela que
nem sempre os esquemas resultam em projetos físicos legítimos, ou
seja, um projeto que preserve todas as informações e restrições em
um projeto lógico correto, considerando os princípios da modelagem
relacional. Assim, muitas vezes é necessário normalizar as tabelas de
Dimensões. Já Barbieri (2011), destaca como uma desvantagem do
Esquema Estrela, a falta de estruturas previstas para armazenar dados já
dissociados ou agregados.
3. Esquema Floco de Neve (Snow Flake Schema)
O Esquema Floco de Neve (Snow Flake Schema) pode ser considerado
uma extensão do Esquema Estrela. Nesse esquema, as tabelas de
Dimensões visam eliminar a redundância dos atributos descritivos,
organizando-as em uma hierarquia de tabelas de Dimensões
normalizadas, contudo aumenta o número de tabelas de Dimensões,
resultando em consultas mais complexas e desempenho reduzido.
Machado (2013)descreve que o Esquema Floco de Neve é uma
decomposição de uma ou mais dimensões que possuem hierarquias
entre seus elementos, o qual cada uma das “pontas da estrela” passa
a ser o centro de outras estrelas com suas tabelas de Dimensões
normalizadas até a terceira forma normal, definindo relacionamentos
muitos para um entre as tabelas de Dimensões decompostas,
assim formando uma hierarquia por meio desses relacionamentos,
como mostra a Figura 6, a dimensão localização decomposta em
cidade, estado e região, e a dimensão produto decomposta em tipo
de produto.
Elmasri e Navathe (2005) descrevem que o “esquema floco de neve é
uma variação do esquema estrela em que as tabelas dimensões de um
121
Dimensão Tipo Dimensão
de Produto Produto
-~
Dimensão Dimensão Dimensã10
Cidade Localização - Fa1tos .. Fi lial ~
Vendas
/ ' ~ Dimensão
Esta.do
Dimensão Dimensão
Tempo Cl iente
Dimensão
Região
esquema estrela são organizadas em uma hierarquia ao normalizá-
las” (ELMASRI; NAVATHE, p. 725). A Figura 6 ilustra o Esquema
Floco de Neve.
Figura 6 – Esquema Floco de Neve (Snow Flake Schema)
Fonte: adaptada de Machado (2013).
O Esquema Floco de Neve separa as hierarquias das dimensões em
tabelas diferentes, especificando variantes da dimensão principal.
Considera-se que a aplicação da técnica de normalização nas tabelas
de Dimensões aumenta consideravelmente o número de dimensões,
consequentemente diminuindo a performance das consultas dinâmicas.
A Figura 7 mostra uma representação do Esquema Floco de Neve,
ilustrando a dimensão de localização normalizada na terceira forma
normal com as tabelas de dimensões cidade, estado, região e país,
obtendo simplicidade semântica e facilitando a navegação do usuário
final pelas dimensões.
122
Dim_Qdade
f cld_lD ln leger (1 O)
!il cid_Nome varchar(SO} (m
1t'i ost_lD fntOfP)r(10) (m
1
1
2
Dim Estado
\ est_lD lnteger{10)
til est_ Nome varchar{30) ~
[il est_Sigla chat{2) ~
~ reg_lD integer(10) ~
~
1
o
Dim_Re,giao
re,g_lD lnteger (10)
~ re,g_Nomo varchar(20) ~
~ pai_JD in t!Jg€r(1 O) ~
1
o
Dim_Pais
pal_lD lnrager(10)
til pai_Nome varchar{SO)
~ pal_Continente V an::har(25)
0 --- -
~
~
Dim_Localizacao
f loc_lD
!il loc_Desaic:ao
'-i cid_lD
lntager(10)
varchar{255)
intoger(10)
Fatos_Veoda~ Dim_Tempo
t.:--:--,o-c-_J::D:-----=--,:--n-:--18-ger---:(1::0::-)----t,o----1-I
pro_lD
~ Vffll_Quantidade
til ven_VaforTotal
~ ven_Rentabilidade
til ven_ ValorDesconto
lnl8ger(10)
lnteger(10)
lnreger(10)
in teger(1 O)
decimal(19, 2)
decimal{19, 2)
declmal{19, 2)
Figura 6 – Esquema Floco de Neve para Vendas
Fonte: elaborada pela autora.
Kimball e Ross (2013) afirmam que os projetistas devem minimizar a
transformação de um Esquema Estrela em Esquema Floco de Neve
devido ao impacto da complexidade deste tipo de estrutura sobre
o usuário final, considerando que o ganho em termos de espaço de
armazenamento é pouco relevante.
A utilização do Esquema Estrela é extremamente recomendável,
pelos aspectos de ganhos de performance, quando comparado com
o Esquema Floco de Neve que resulta normalmente da normalização
de tabelas de Dimensões. Considera-se que, a redundância no caso da
adoção do Esquema Estrela é amplamente compensada pelas reduções
de operações de junção que são necessários para recuperação de dados
em tempo de execução.
123
4. Considerações Finais
Soluções eficientes e que envolvem questões de análises complexas
dos processos de negócio de uma empresa, requerem uma visão das
informações de diferentes perspectivas para permitir a identificação de
problemas e tendências, bem como, às oportunidades de negócios.
Na modelagem multidimensional de um DW, o contexto das
funcionalidades que determinam os processos de negócio de uma empresa
é especificado em tabelas de Fatos. A tabela de Fatos é a principal tabela
de um esquema dimensional que contém vários fatos correspondentes a
cada uma de suas linhas que armazenam uma ou mais medidas numéricas,
constituindo valores para análise dimensional. A tabela de Fatos relaciona-
se com as tabelas de Dimensões que representam as entidades de negócio
e constituem as estruturas de entrada que realizam os filtros de valores
aplicados na manipulação dos fatos. Kimball e Ross (2013) reforçam que,
quanto maior o tempo e a atenção neste processo melhor será a qualidade
da base de dados de um DW.
A decisão de optar pelo Esquema Estrela ou pelo Esquema Floco de
Neve deve ser tomada levando-se em consideração principalmente
pela complexidade da solução e o volume de dados a ser manipulado,
ou seja, é uma decisão que compete as boas práticas de projetos.
Os esquemas, por meio de seus fatos e dimensões, podem fornecer
informações em diferentes formatos e grau de detalhamento, assim
auxiliando na transformação das informações em conhecimento para o
suporte às decisões.
TEORIA EM PRÁTICA
Tornando como base uma das maiores locadoras de
veículos do país, considere que a locadora tem 143 filiais
localizadas em vários estados brasileiros e 18 filiais em
124
4 países da América Latina. Cada filial disponibiliza o
serviço de aluguel de seus veículos para clientes nacionais
e estrangeiros. A locadora possui uma ampla frota com
veículos de diferentes categorias (ônibus, carros de passeio,
utilitários, etc), variadas marcas e modelos. Os gestores
da locadora pretendem analisar os custos, faturamento
e lucros das filiais, de diferentes períodos das locações,
principalmente de datas festivas, para tomarem decisões
estratégicas que tangem a expansão de novas filiais.
Para isso, represente a modelagem multidimensional, no
formato do Esquema Estrela, contemplando as dimensões
que participarão dos fatos mensuráveis para geração de
consultas dinâmicas, a partir de ferramentas OLAP, que
disponibilizadas no projeto de desenvolvimento do Data
Warehouse da locadora.
VERIFICAÇÃO DE LEITURA
1. Os esquemas de dados utilizados na modelagem
dos Data Warehouses (DW) compreendem a chamada
modelagem multidimensional. A modelagem
multidimensional representa uma abstração dos dados
armazenados, consistindo em um modelo composto por
tabelas de Fatos e de Dimensões que proporcionam uma
visão multidimensional de grande quantidade de dados.
A tabela de Fatos é a principal tabela de um esquema
dimensional que geralmente contém vários fatos que
indicam valores para análise dimensional e as tabelas
de Dimensões representam as características descritivas
que fornecem as perspectivas adicionais aos fatos.
125
Assinale a alternativa correta que descreve as
características das tabelas de Fatos e de Dimensões.
a. A tabela de Fatos representa entidades de negócio e
constituem as estruturas de entrada que servem para
armazenar informações como tempo, produto, cliente,
etc. A tabela de Fatos tem uma relação 1:N com as
tabelas de Dimensões.
b. A tabela de Fatos deve ser entendida como a
tabela que realiza os filtros de valores aplicados na
manipulação dos dados, determinando o contexto de
um assunto de negócio.
c. As tabelas de Dimensões servem para armazenar
medidas numéricas associadas a eventos de negócio.
Possuem como chave-primária uma chave única.
d. As tabelas de Dimensões servem para armazenar
uma ou mais medidas numéricas, que constituem
os valores objetos da análise dimensional.
Possuem como chave-primária normalmente uma
chave composta.
e. As tabelas de Dimensões representam as
características descritivas que fornecem as
perspectivas adicionais a um determinado fato por
meio de seus atributos. As tabelas de Dimensões têm
uma relação 1:N com a tabela de Fatos.
2. Existem algumas abordagens específicas para
modelagem multidimensional, derivadas da aparência
do esquema traçado, a partir do Diagrama de Entidades
e Relacionamentos (DER), relacionando as tabelas de
126
Fatoscom as tabelas de Dimensões. O ___________________
é a abordagem que visa criar esquemas físicos mais
simples e incremental devido à disposição em que
se encontram as tabelas, sendo a tabela de Fatos,
centralizada no esquema, e as tabelas de Dimensões são
relacionandas nas pontas do esquema.
Assinale a alternativa correta que preenche a
lacuna acima:
a. Esquema Cubo.
b. Esquema Estrela.
c. Esquema Floco de Neve.
d. Esquema MER.
e. Esquema Multifocal.
3. O nome do Esquema Estrela foi definido em função da
disposição em que se encontram as tabelas, sendo a
tabela de Fatos, centralizada no esquema, e as tabelas
de Dimensões são relacionadas nas pontas do esquema,
de forma independente entre as dimensões.
Sobre as principais vantagens do Esquema Estrela, julgue
os itens a seguir:
I. A presença de dados altamente redundantes,
considerando a desnormalização das tabelas
dimensionais dos dados, para se obter um melhor
desempenho em tempo de execução.
II. As consultas ocorrem inicialmente na tabela de Fatos
e depois nas tabelas de Dimensões, assegurando a
precisão dos dados por meio de uma estrutura de
chaves que garante o acesso aos dados com melhor
desempenho.
127
III. A estrutura padronizada e regular do esquema é
bastante simples, faciliatando à apresentação, o
desempenho das consultas geradas e a compreensão
até mesmo de usuários finais que não estão adaptados
com estruturas de banco de dados.
IV. A flexibilidade da inclusão de novos elementos de dados,
a partir do relacionamento da tabela de Fatos com uma
nova tabela de Dimensão, bem como, o acréscimo de
novas colunas às mesmas tabelas de Dimensões.
Estão corretos os itens:
a. I – II.
b. II – III.
c. III – IV.
d. I – III – IV.
e. I – II – III – IV.
Referências Bibliográficas
BARBIERI, Carlos. BI – Business Intelligence: modelagem & tecnologia. Rio de
Janeiro: Axcel Books, 2001.
COLAÇO, M. Jr. Projetando sistemas de apoio à decisão baseados em data
warehouse. Rio de Janeiro: Axcel Books do Brasil, 2004.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro:
Campus, 2004.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São
Paulo: Pearson Addison Wesley, 2005.
KIMBALL, R. et al. The data warehouse lifecycle toolkit. New York: John Wiley &
Sons, 1998.
KIMBALL, R.; ROSS, M. The data warehouse toolkit: the complete guide to
dimensional modeling. 3 ed. New York: John Wiley & Sons, 2013.
128
MACHADO, Felipe N. Tecnologia e projeto de data warehouse. 6. ed. São Paulo:
Erica, 2013.
POE, V.; KLAUER, P.; BROBST S. Building a data warehouse for decision support.
New Jersey: Prentice Hall PTR, 1998.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e
administração. 8. ed. São Paulo: Cengage Learning, 2011.
Gabarito
Questão 1 - Resposta E.
Resolução: A modelagem multidimensional representa uma
abstração dos dados armazenados, consistindo em um modelo
composto por tabelas de Fatos e de Dimensões que proporcionam
uma visão multidimensional de grande quantidade de dados
Fatos: e uma coleção de itens de dados, composta de dados de
medidas, representando uma transação ou um evento de negócio.
Um fato é representado por valores numéricos em um esquema e
implementado em tabelas denominadas tabelas de Fatos
Dimensões: são os elementos que participam de um fato, ou seja,
são as possíveis formas de visualizar os dados de forma descritiva e
classificatória, determinando o contexto de um assunto de negócio.
Os elementos que representam uma dimensão são especificados
em um esquema e implementados em tabelas denominadas de
tabelas de Dimensões.
Questão 2 - Resposta B.
Resolução: segundo Kimball (1998), o Esquema Estrela (Star
Schema) é a abordagem que visa criar esquemas físicos mais
simples e incremental. O nome estrela se dá devido à disposição em
que se encontram as tabelas, sendo a tabela de Fatos, centralizada
no esquema, e as tabelas de Dimensões são relacionandas nas
pontas do esquema.
129
Questão 3 - Resposta D.
Resolução: Considerando a abordagem do Esquema Estrela da
modelagem multidimensional, o item II está errado porque as
consultas ocorrem inicialmente nas tabelas de Dimensões e depois
nas tabelas de Fatos, para assegurar a consistência dos dados por
meio de uma estrutura de chaves que garante o acesso aos dados
com melhor desempenho.
.
130
Ferramentas de Dados em um
Data Warehouse
Autora: Iolanda Cláudia Sanches Catarino
Objetivos
• Conhecer e compreender os fundamentos do
Processamento Analítico On-line (OLAP).
• Conhecer e compreender as operações OLAP.
• Conhecer e compreender a classificação das
ferramentas OLAP.
1. Fundamentos sobre o Processamento Analítico
On-line – OLAP
O número de usuários que precisa de análises de dados mais
sofisticadas vem crescendo nas organizações, indo além dos níveis
gerenciais mais altos. A viabilização e extração eficazes de informações
de um ambiente de Data Warehouse (DW) para proporcionar essas
análises é possível, a partir de ferramentas que disponibilizam recursos
avançados para suportar operações sobre o conjunto de dados
multidimensional, gerando consultas dinâmicas com interface intuitiva
para os usuários.
As ferramentas de apoio à decisão estão relacionadas com o conceito
de Business Intelligence (BI) – inteligência aplicada aos negócios –, que
“refere-se ao conjunto de tecnologias que permitem o cruzamento de
informações e suportam a análise dos indicadores de desempenho
de um negócio” (COLAÇO, 2004, p. 26). Pela maior popularidade do
uso das ferramentas de acesso a um DW, destaca-se as ferramentas
Online Analytical Processing (OLAP – Processamento Analítico On-line),
termo criado como tecnologia OLAP em 1993 por Edgar Frank Codd,
matemático britânico que desenvolveu o modelo de banco de dados
relacional.
PARA SABER MAIS
Business Inteligence: de acordo com Barbieri (2001), esse
termo é referente a um “guarda-chuva” conceitual, visto que
se dedica à captura de dados, informações e conhecimentos
que permitam às empresas competirem com maior
eficiência em uma abordagem evolutiva de modelagem de
dados, capazes de promover a estruturação de informações
em depósitos retrospectivos e históricos, permitindo sua
modelagem por ferramentas analíticas.
132
Barbieri (2001) enfatiza que o termo Processamento Analítico On-line
representa a característica de se trabalhar os dados, com operadores
dimensionais, possibilitando uma forma múltipla e combinada
de análise.
O OLAP desempenha análise multidimensional de dados empresariais
e oferece capacidades para cálculos complexos, análises de tendências
e modelagem de dados sofisticados. O OLAP habilita usuários finais
a fazerem análises de dados em múltiplas dimensões com recursos
diversos para visualização das informações, provendo o entendimento
que eles necessitam para melhor tomada de decisão. O OLAP pode ser
um processo simples, fácil, rápido, controlável, de acesso à inteligência
implícita nos dados.
Um processamento OLAP estrutura logicamente dados
multidimensionais na forma de um cubo, o qual os usuários finais
visualizam os dados armazenados como um cubo de dados. O cubo
apresenta várias dimensões que são subconjuntos de atributos. É
interessante destacar que os cubos são estáticos, ou seja, não estão
sujeitos a alterações e devem ser criados antes de sua utilização. No
entanto, eles não podem ser criados por consultas ad hoc. Ao invés
disso, a consulta é realizada em cubos pré-criados com eixos definidos.
Date (2004) explica que o termo OLAP pode ser definido como o
processo interativo de criar, gerenciar, analisar e gerar relatórios sobre
dados. Os dados são percebidos e manipulados como se estivessem
armazenados em um array multidimensional.
O OLAP proporciona acesso aos dados de um determinado negócio,
podendo o usuário obter uma compreensão que lheofereça condições
de melhor planejamento e gerenciamento. O arranjo em cubos do
OLAP permite analisar as múltiplas dimensões dos dados utilizados pela
empresa, em múltiplas combinações, sob ângulos variados, podendo
133
o executivo identificar também tendências e descobrir o que está
acontecendo nos negócios (BISPO, 1998).
As ferramentas que apresentam características OLAP passaram a ser
referenciadas como ferramentas OLAP. A maioria dessas ferramentas
é implementada para ambientes multiusuários em arquitetura Cliente-
Servidor, proporcionando resultados rápidos e consistentes às consultas
interativas executadas pelos usuários. Em um projeto de implementação
de uma ferramenta OLAP, pode haver a necessidade de integração de
dados de diferentes plataformas de bases de dados, com isso, soluções
de conectividade devem ser definidas. Consultas complexas podem
demandar respostas que requeiram flexibilidade e performance que se
tornam possíveis pela modelagem dos dados.
Machado (2013) descreve que as ferramentas OLAP surgiram com os
sistemas de apoio à decisão para fazerem a consulta e análise dos dados
dos DW, sendo as aplicações as quais os usuários têm acesso para
extrair os dados de suas bases e construir os relatórios com recursos
que atendem os gestores.
Por ser uma ferramenta de processamento analítico on-line de
dados, uma aplicação OLAP soluciona vários problemas de análise
e consolidação dos dados, com capacidade de visualização das
informações a partir de diferentes perspectivas para os usuários
estratégicos, utilizando-se de consultas dinâmicas em tempo de
execução do sistema.
A característica mais marcante das modernas ferramentas OLAP é a
capacidade de análise multidimensional. Os dados são processados e
visualizados em uma estrutura multidimensional, sendo especialmente
atrativo para os tomadores de decisões de negócios, sendo que
134
enquanto o DW mantém dados de suporte a decisões integrados,
orientados por assunto, variáveis no tempo e não voláteis, o sistema
OLAP fornece o front end por meio do qual os usuários finais acessam e
analisam esses dados (ROB; CORONEL, 2011).
Adicionalmente, é interessante observar que os sistemas OLAP são
projetados para utilizar tanto os dados operacionais de DW, ou seja,
um sistema OLAP pode acessar os dados armazenados em um DW
ou os dados armazenados em um banco de dados operacional ou até
mesmo ambos, dependendo da implementação. Em qualquer caso, a
análise multidimensional de dados exige algum tipo de representação
de dados nesta mesma dimensão, o que normalmente é fornecido pelo
mecanismo de OLAP (ROB; CORONEL, 2011).
Em contraste com os sistemas Online Transaction Processing (OLTP –
Processamento de Transações On-line), as ferramentas OLAP destacam-
se pelo potencial de recuperação de grande volume de dados e análise
de informações de forma rápida e com diferentes perspectivas.
ASSIMILE
Online Transaction Processing (OLTP - Processamento
de Transações On-line): o termo refere-se aos sistemas
transacionais, que são utilizados no processamento dos
dados de rotina que são gerados diariamente, a partir dos
sistemas informacionais de uma organização.
O Quadro 1 apresenta as principais diferenças entre os processamentos
OLAP e OLTP, segundo Barbieri (2001).
135
Quadro 1 – Diferenças entre OLAP e OLTP
OLAP OLTP
Baseado em dados históricos, con-
solidados e frequentemente totali-
zados.
Baseado em transações de dados
atuais de funções repetitivas.
Operações de agregação e cruza-
mentos de dados sumarizados.
Operações de manipulação de da-
dos individuais, por meio dos co-
mandos de inserção, atualização e
exclusão.
Atualizações quase inexistentes,
apenas novas inserções.
Atualizações em grande número
de registros.
Disponibiliza as informações sob
diferentes perspectivas do negó-
cio.
Organiza os dados orientados aos
processos.
Fonte: elaborado pela autora.
Codd & Codd e Salley (1993) descrevem que uma ferramenta OLAP deve
conter doze critérios, relacionados a seguir:
1. Visão conceitual multidimensional: os dados são modelados
em diversas dimensões, possibilitando extração de dados mais
intuitivos e o cruzamento de todos os tipos de dados para gerar
informações de fácil leitura e análise.
2. Dimensionalidade genérica: a ferramenta deve proporcionar
condições ao usuário para executar manipulações ou cálculos
entre as dimensões. Desta forma, a estrutura básica dos dados e o
formato dos relatórios não devem ser influenciados por qualquer
dimensão de dados.
3. Dimensões e níveis de agregação ilimitados: um modelo analítico
comum pode conter quinze a vinte dimensões de dados.
Paralelamente, os níveis de agregação devem ser ilimitados –
desde a mínima até a máxima granularidade.
136
4. Operações dimensionais: considerando-se um modelo analítico,
e tomando-se duas ou mais células pertencentes a diferentes
dimensões dentro deste modelo para serem usadas na realização
de cálculos.
5. Manipulação de matriz esparsa dinâmica: para qualquer matriz
esparsa de dados, existe um e somente um esquema físico,
o qual provê a máxima eficiência e operacionalidade, para
maximizar o desempenho, baseada na densidade dos dados
armazenados.
6. Arquitetura cliente-servidor: a maioria dos dados é armazenada
em um servidor de rede e são acessados por meio de
computadores pessoais. Portanto, é necessário que a ferramenta
seja capaz de operar em ambiente cliente-servidor para atender
multiusuários.
7. Acessibilidade: a ferramenta tem que traçar seu próprio esquema
lógico para tratar os dados heterogêneos armazenados e assim,
executar qualquer conversão necessária para apresentar ao
usuário uma única e consistente visão dos dados.
8. Transparência: a ferramenta deve atender a todas as solicitações
dos usuários, a partir de planilhas eletrônicas, aplicativos de
suporte à decisão ou outras interfaces. Se a ferramenta está em
uma arquitetura cliente/servidor, então os acessos devem ser
transparentes aos usuários.
9. Manipulação de dados intuitiva: todo o processo de criação de
modelos, manipulação de dados e realização de cálculos deve
acontecer da forma mais intuitiva para os usuários, sem necessitar
de qualquer tipo de auxílio.
10. Desempenho consistente de relatório: mesmo com o aumento
do número de dimensões ou do tamanho do banco de dados,
o usuário não deve perceber uma degradação significativa no
desempenho do fornecimento de informações.
137
11. Flexibilidade nas consultas: a análise e a apresentação dos
dados tornam-se mais simples quando linhas, colunas e
células, que vão ser comparadas visualmente, são organizados
por agrupamentos lógicos para efetuarem qualquer tipo
de consulta.
12. Suporte multiusuário: muitas vezes, vários usuários necessitam
trabalhar simultaneamente com o mesmo modelo analítico ou
criar modelos diferentes a partir dos mesmos dados. Assim,
a ferramenta tem que prover esses acessos simultâneos sem
prejuízo à integridade e segurança dos dados.
2. Operações OLAP
Uma característica importante que deve estar presente em ferramentas
OLAP é a capacidade de efetuar algumas operações. Existem diversos
operadores OLAP que permitem acessar os dados em esquemas
multidimensionais. Cada operação sobre um conjunto de dados
multidimensional retorna uma apresentação ou sumarização diferente
de informações.
Em seguida, são apresentadas as principais operações realizadas com
cubos de dados. As operações do tipo Drill (Drill Down, Drill Up, Drill
Across e Drill Throught), permitem a navegação ao longo dos níveis
hierárquicos de uma dimensão. As operações do tipo Slice and Dice
são operações para realizar a navegação por meio dos dados na
visualização do cubo.
2.1 Drill Down
Esta operação ocorre quando o usuário aumenta o nível de detalhe da
informação, diminuindo a granularidade, ou seja, navega verticalmente,
descendo a hierarquiano sentido mais específico.
138
, ' ~ '
De acordo com Elmasri e Navathe (2011):
Uma exibição Drill-Down fornece uma visão mais detalhada”. Por exemplo,
desagregar “as vendas do país por região e, depois, as vendas regionais
por sub-região e também separando produtos por estilos. (ELMASRI;
NAVATHE, p. 724)
A Figura 1 mostra um exemplo de Drill Down:
Figura 1 – Exemplo de Drill Down
Volume de produção
(em milhar)
Telefone celular Tablet
2017 2018 2017 2018
Região Sul
RS 35 29 18 21
SC 47 38 20 23
Drill Down
Dimensão localização geográfica
Membro RS
Volume de produção Telefone celular Tablet
(em milhar) 2017 2018 2017 2018
RS
Canoas 9 7 5 6
Porto Alegre 12 11 6 8
Fonte: adaptada de Machado (2013).
No exemplo da Figura 1, uma operação de Drill Down acontece sobre a
dimensão localização geográfica. A primeira tabela, localizada no topo
da figura, apresenta o volume de produção por região geográfica e
pelos estados dessa região. Ao realizar um Drill Down, abre-se o nível
139
de detalhe da dimensão localização geográfica, visualizando somente
um estado da região anterior (no exemplo, o RS – Rio Grande do
Sul), entretanto, abrindo os valores para as cidades desse estado (no
exemplo, Canoas e Porto Alegre) (MACHADO, 2013).
2.2 Drill Up ou Roll Up
Esta operação é o oposto do Drill Down e ocorre quando o usuário
aumenta o nível de granularidade, diminuindo o nível de detalhamento
da informação, ou seja, permite ao usuário uma visão mais agregada das
informações.
Elmasri e Navathe (2011) explicam que “uma exibição Roll-Up sobe
na hierarquia, agrupando em unidades maiores ao longo de uma
dimensão” (ELMASRI; NAVATHE, 2011, p. 723). Na concepção de Date
(2004), Drill Up” significa ir de um nível mais baixo de agregação até um
nível mais alto” (DATE, 2004, p. 613). Por exemplo, mover de produtos
individuais para uma categorização maior dos produtos.
A Figura 2 mostra um exemplo de Drill Up. Uma operação de Drill Up
está sendo realizada sobre a dimensão tempo. A primeira tabela,
localizada no topo da figura, apresenta o volume de produção globais
independente de produto na região Sul nos estados do Rio Grande
do Sul e Santa Catarina distribuídos por trimestre do ano de 2018. A
segunda tabela, localizada na parte inferior da figura, apresenta os
mesmos dados somente de um dos trimestres, o primeiro. A operação
de sair da segunda tabela para a primeira é uma Drill Up, pois o
usuário sai de um nível mais baixo de detalhe (um trimestre específico
de um ano) para um nível mais alto (todos os trimestres de um ano)
(MACHADO, 2013).
140
Figura 2 – Exemplo de Drill Up
Volume de produção 2018
(em milhar) 1ª Trimestre 2ª Trimestre 3ª Trimestre 4ª Trimestre
Região Sul
RS 12 12 11 15
SC 15 13 12 21
Drill Up
Dimensão tempo
Volume de produção 1ª Trimestre
(em milhar) Janeiro Fevereiro Março
Região Sul
RS 5 3 4
SC 7 4 4
Fonte: adaptada de Machado (2013).
É importante destacar que, apesar de alguns autores tratarem Drill
Up e Roll Up como sinônimos, Date (2004) argumenta que há uma
diferença sutil entre elas: Roll Up é a operação de criar os agrupamentos
e as agregações desejadas e Drill Up é a operação de acessar essas
agregações.
2.3 Drill Across
Esta operação permite navegar transversalmente no eixo da dimensão,
retirando ou inserindo posições da dimensão, ou seja, ocorre quando
o usuário pula um nível intermediário dentro da mesma dimensão. Por
exemplo, a dimensão tempo é composta por ano, semestre, trimestre,
141
1 r 1 r
mês e dia (MACHADO, 2013). A operação Drill Across é executada quando
o usuário passar de ano direto para trimestre ou mês. A Figura 3
apresenta um exemplo de Drill Across:
Figura 3 – Exemplo de Drill Across
Volume de produção
(em milhar)
Telefone celular Tablet
2017 2018 2017 2018
Região Sul
RS 35 29 18 21
SC 47 38 20 23
Drill Down
Dimensão localização geográfica
Membro RS
Volume de produção Telefone celular Tablet
(em milhar) Janeiro 2017 Janeiro 2018 Janeiro 2017 Janeiro 2018
Região Sul
RS 5 3 2 2
SC 7 4 3 2
Fonte: adaptada de Machado (2013).
No exemplo da Figura 3, há duas tabelas com o volume de produção.
A primeira, localizada no topo da figura, mostra os valores antes de
executar um Drill Across. A segunda, localizada na parte inferior da figura,
mostra os valores após a execução de um Drill Across. Neste exemplo,
foi executado um Drill Across de ano para mês (janeiro). Note que na
primeira tabela, os valores correspondem ao volume de produção por
ano (2017 e 2018). Na segunda tabela, após executar um Drill Across, os
valores correspondem apenas ao volume de produção do mês janeiro
de 2017 e 2018.
142
2.4 Drill Throught
Esta operação ocorre quando o usuário navega de uma informação
contida em uma dimensão para uma outra dimensão. Por exemplo,
quando o usuário está na dimensão de tempo e no próximo passo
começa a analisar a informação por região (MACHADO, 2013).
A Figura 4 mostra um exemplo de Drill Throught. A primeira tabela,
localizada no topo da figura, apresenta a quantidade de produtos
vendidos por região e cidades, distribuídos por ano. A segunda tabela,
localizada na parte inferior da figura, apresenta a quantidade de
produtos vendidos por ano, mas distribuídos por lojas da cidade de
Porto Alegre da região Sul. A operação de sair da primeira tabela para a
segunda é conhecida como Drill Throught, pois o usuário seleciona um
membro (cidade Porto Alegre) dentro de uma dimensão (região) e passa
a analisar uma outra dimensão (loja).
Figura 4 – Exemplo de Drill Throught
Volume de produção Telefone celular Tablet
(em milhar) 2017 2018 2017 2018
RS
Porto Alegre 12 11 6 8
Canoas 9 7 5 6
Caxias do Sul 11 11 5 6
Pelotas 8 7 5 5
Drill Throught
Membro Porto Alegre
Volume de produção Telefone celular Tablet
(em milhar) 2017 2018 2017 2018
Loja 18 2 2 1 1
Loja 19 3 2 1 2
Loja 20 4 5 3 3
Loja 21 3 2 1 2
Fonte: elaborada pela autora.
143
2.5 Slice and Dice
Estas operações ocorrem para realizar navegação por meio dos dados
na visualização de um cubo. Slice and Dice significa a redução do
escopo dos dados em análise, além de mudar a ordem das dimensões,
mudando assim a orientação segundo a qual os dados são visualizados.
Entretanto, Machado (2013) explica que Slice é:
A operação que corta o cubo, mas mantém a mesma perspectiva de
visualização dos dados, [ou seja], fatiar ou realizar Slice é a operação de
visualizar somente a produção de um tipo de produto, por exemplo,
celulares. (MACHADO, 2013, p. 89)
No exemplo e Slice da Figura 5, está sendo realizado um Slice sobre
a dimensão produto. A primeira tabela, localizada no topo da figura,
apresenta o volume de produção de celulares e tablets na região sul
nos dois últimos anos. A segunda tabela, localizada na parte inferior
da figura, apresenta os mesmos dados somente de celulares, ou seja,
apenas uma fatia dos dados. A operação de visualizarmos somente a
produção de um tipo de produto (celulares) é conhecido como Slice.
Figura 5 – Exemplo de Slice
Volume de produção Celulares e tablets
(em milhar) Janeiro Fevereiro Março
Região Sul
RS 12 10 8
SC 16 15 10
Slice
Dimensão produto
Membro Celulares
Volume de Produção Celulares
(em milhar) Janeiro Fevereiro Março
Região Sul
RS 8 5 5
SC 11 9 6
Fonte: elaborada pela autora.
144
~ ' 1 '
A operação Dice é utilizada para limitar o conjunto de valores a ser
mostrado, fixando-se algumas dimensões. Segundo Machado (2013),
Dice é “a mudança de perspectiva da visão”, ou seja, “é a extração de um
‘subcubo’ ou a interseção de vários Slices” (MACHADO, 2013, p. 90).
A Figura 6 mostra um exemplo da operação Dice. A primeira tabela,
localizada no topo da figura, é possível visualizar o volume de produção
no sentido estado, cidade, ano, modelo de produto e produto, ou seja,
cada valor apresentado significa o volume produzido em um estado,em
uma cidade, em um ano, de um modelo de produto e de um produto.
A segunda tabela, localizada na parte inferior da figura, foi alterada a
perspectiva para modelo de produto, produto, ano, estado e cidade,
ou seja, cada valor agora representa a produção de um modelo de
produto e um produto, em um ano, em um estado e em uma cidade. O
objetivo desse tipo de análise é descobrir comportamentos conforme a
perspectiva de análise dos dados. (MACHADO, 2013).
Figura 6 – Exemplo de Dice
Volume de produção Telefone celular Tablet
(em milhar) 2017 2018 2017 2018
RS
Porto Alegre 12 11 6 8
Canoas 9 7 5 6
Dice
Volume de produção
(em milhar)
Modelo CT1
RS
Canoas Porto Alegre
Telefone celular
2017 9 12
2018 7 11
Tablet 2017 5 6
2018 6 8
Fonte: elaborada pela autora.
145
3. Classificação das ferramentas OLAP
As ferramentas OLAP podem ser classificadas de acordo com
a estratégia de armazenamento, sendo chamadas de OLAP
Multidimensional (MOLAP), OLAP Relacional (ROLAP), OLAP Híbrido
e OLAP Web.
O MOLAP refere-se à utilização de banco de dados com características
multidimensionais, permitindo a navegação com níveis de detalhamento
em tempo real, a partir da combinação das dimensões do cubo,
proporcionando análises sofisticadas com ótimo desempenho.
Segundo Machado (2013), em um banco de dados multidimensional, os
cruzamentos de valores são realizados automaticamente, agilizando a
visualização multidimensional das informações sob o ponto de vista de
todas as dimensões. A forma de acesso e de agregação dos dados faz
com que esta ferramenta tenha um excelente desempenho.
O ROLAP refere-se à utilização de banco de dados relacional para
implementar soluções OLAP. Segundo Colaço (2004):
Os sistemas ROLAP permitem análise multidimensional dos dados que
estão armazenados em uma base de dados relacional, podendo ser feito
todo o processamento no servidor da base de dados e depois gerados
os comandos SQL e as tabelas temporárias. De forma inversa podem ser
executados os comandos SQL para recuperação dos dados e posterior
processamento no servidor OLAP. (COLAÇO, 2004, p. 37)
A vantagem desta ferramenta é a utilização de banco de dados
relacional, de arquitetura aberta e padronizada.
O HOLAP representa uma abordagem de uso combinado das
duas estratégias anteriores em que as estruturas relacionais são
utilizadas para os dados com maior granularidade, e as estruturas
multidimensionais são utilizadas para dados com menor granularidade,
ou seja, nos dados agregados.
146
O WOLAP refere-se à utilização da ferramenta OLAP em ambiente
remoto, disparando consultas via um navegador web para o servidor
que, por sua vez retorna o cubo processado para análise do usuário.
A escolha de uma ferramenta OLAP envolve a análise dos recursos
e funcionalidades que a ferramenta implementa, pois diferentes
ferramentas OLAP integram um conjunto de módulos que abrangem
parcial ou totalmente as funcionalidades apresentadas no item anterior.
A seguir, é apresentada uma introdução da ferramenta CASE Microsoft
Analysis Services.
3.1 Microsoft Analysis Services
O Analysis Services é um gerenciador de informações que oferece ao
desenvolvedor e aos usuários estratégicos uma série de recursos
para auxiliarem o processo de análise de dados com uma visão
multidimensional com fácil interação e usabilidade.
O Analysis Services disponibiliza modelos de dados semânticos para
relatórios de negócios compatíveis com diferentes plataformas,
como relatórios do Power BI, Excel, relatórios de serviços e outras
ferramentas de visualização de dados. O Analysis Services está
disponível nas plataformas Azure Analysis Services e SQL Server Analysis
Services (MICROSOFT, 2017).
O Analysis Services não precisa ser utilizado apenas com o SQL Server, é
possível utilizar o Analysis Services com qualquer banco de dados que
possua um driver Open Database Connectivity (ODBC) ou um provider
Object Linking and Embedding for Databases (OLE DB). Assim, destaca-se
com a vantagem competitiva de custo zero.
Outro ponto importante a ser observado é a forma de armazenamento
dos dados. O Analysis Services permite que os dados sejam armazenados
147
em tabelas relacionais (ROLAP), num cubo proprietário multidimensional
(MOLAP) ou na forma híbrida HOLAP.
Para Machado (2013), na opção ROLAP, os dados são lidos diretamente
da fonte de dados. Na opção MOLAP os dados são gravados em um
formato proprietário e na opção HOLAP é oferecido uma combinação
das duas opções anteriores, mas é o próprio Analysis Services que
gerencia quais agregações são armazenadas como MOLAP e quais
serão ROLAP.
De acordo com a Microsoft (2017), o Analysis Services utiliza uma
linguagem criada pela Microsoft, conhecida como Multidimensional
Expressions (MDX), específica para manipulação de bases
multidimensionais. A linguagem MDX foi criada para atender a requisitos
que a SQL não supria. Sendo assim, quando consultam-se os dados
de um cubo dentro do Analysis Manager ou por meio de uma planilha
Excel, é disponibilizado uma fatia do cubo (slice), que é caracterizada
pelos eixos do relatório (linhas e colunas) e a sua paginação, ou seja, são
declarações MDX que estão sendo executadas.
O Microsoft Analysis Services oferece aos usuários um sofisticado
ambiente de análises, com boa performance, recursos avançados de
cálculo e, principalmente, autonomia para os usuários montarem seus
próprios relatórios.
4. Considerações finais
As ferramentas que integram um ambiente de DW, como as
ferramentas OLAP e de Data Mining surgiram para auxiliar o processo de
disseminação das informações, formando a base para os sistemas de
BI, a fim de que seja possível encontrar correlações de dados que antes
eram desconhecidos e transformar a informação em conhecimento.
148
As ferramentas OLAP disponibilizam o recurso para gerar consultas
dinâmicas com ótimo desempenho, permitindo que a partir de uma
resposta o usuário faça outras interações, combinando as dimensões do
cubo com diferentes níveis de detalhamento e agregação.
TEORIA EM PRÁTICA
Tornando como base um Data Mart de vendas por brick
referente ao Data Warehouse (DW) organizacional de uma
indústria farmacêutica que precisa simular as vendas, por
categoria de produtos, realizadas para uma distribuidora,
por brick, sendo que um brick representa uma cidade,
bairro ou CEP de um distrito, com potencial de venda, e
considerando que, um brick pode ser mantido por nenhum
ou por muitos vendedores:
1. Elabore o esquema para compreender o fato – Vendas
por brick, considerando as dimensões: categoria de produto,
brick e distribuidora. A dimensão categoria de produto
representa uma classificação dos produtos por categoria,
por exemplo: genérico, similar, OTC e outros; a dimensão
brick representa as regiões de venda, podendo ser uma
cidade, bairro ou CEP de um distrito; e a tabela dimensão
Distribuidora representa as distribuidoras que atendem as
vendas da empresa.
2. Em uma ferramenta com recursos OLAP implemente
o esquema descrito no item anterior, contemplando
simulações do fato – Vendas por brick.
149
VERIFICAÇÃO DE LEITURA
1. O processo de tomada de decisão envolve grandes
esforços no sentido de coleta de informações, do uso
de métodos, técnicas e ferramentas computacionais,
requerendo muita consciência e habilidade por parte
dos gestores. A viabilização e extração eficaz de
informações de um ambiente de Data Warehouse (DW)
é possível, a partir de ferramentas que disponibilizam
recursos avançados para suportar operações sobre o
conjunto de dados multidimensional.
Assinale a alternativa correta que descreve esse tipo de
ferramenta:
a. Online Transaction Processing (OLTP).
b. Online Analytical Processing (OLAP).
c. Business Intelligence.
d. DataBase Management System (DBMS).
e. Extensible Markup Language (XML).
2. A Tecnologia da Informação tem uma grande
influênciano desenvolvimento das atividades de
uma empresa. Manipular os dados coletados pelos
sistemas e transformá-los em informações é um
grande diferencial para a tomada de decisão, de
forma a agregar inteligência aos negócios. Em
contraste com os sistemas________________________, as
ferramentas ________________________, destacam-se pelo
potencial de recuperação e capacidade de prover análise
multidimensional para o usuário.
150
Assinale a alternativa correta que indica os termos que
preenchem as lacunas acima:
a. Online Transaction Processing (OLTP); Business
Inteligence (BI).
b. Online Analytical Processing (OLAP); Online Transaction
Processing (OLTP).
c. Online Transaction Processing (OLTP); Online Analytical
Processing (OLAP).
d. Online Analytical Processing (OLAP); Business
Inteligence (BI).
e. Business Intelligence; DataBase Management
System (DBMS).
3. As ferramentas que apresentam características OLAP
passaram a ser referenciadas como ferramentas
OLAP. Uma característica importante que deve estar
presente em ferramentas OLAP é a capacidade de
efetuar operações que permitem acessar os dados em
esquemas multidimensionais.
Assinale a alternativa correta que indica
operações OLAP:
a. Drill Down, Drill Up; Slice; Dice.
b. Drill Down, Drill Up, Drill Rolap; Drill Molap.
c. Drill Rolap; Drill Molap; Slice; Dice.
d. Slice; Dice; Roll Up; Molap.
e. Drill Across, Drill Throught; Drill Rolap;
Drill Molap.
151
Referências Bibliográficas
BARBIERI, Carlos. BI – Business Intelligence: modelagem & tecnologia. Rio de
Janeiro: Axcel Books, 2001.
BISPO, Carlos Alberto Ferreira. Uma análise da nova geração de sistemas de
apoio à decisão. 1998. 174 f. Dissertação (Mestrado em Engenharia da Produção) –
Escola de Engenharia de São Carlos, Universidade de São Paulo, São Carlos. 1998.
CODD, Edgar F. & CODD, Sharon B.; SALLEY, Clynch T. Providing OLAP (on-
line analytical processing) to user-analysts: An IT mandate. v. 32. Codd and
Date, 1993.
COLAÇO, M. Jr. Projetando sistemas de apoio à decisão baseados em data
warehouse. Rio de Janeiro: Axcel Books do Brasil, 2004.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro:
Campus, 2004.
ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4. ed. São
Paulo: Pearson Addison Wesley, 2005.
MACHADO, Felipe N. Tecnologia e projeto de data warehouse. 6. ed. São Paulo:
Erica, 2013.
MICROSOFT DEVELOPER NETWORK. O que há de novo no SQL Server 2017
Analysis Services: documentação do produto. Disponível em: <https://docs.
microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-
server-2017>. Acesso em: 30 maio 2019.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e
administração. 8. ed. São Paulo: Cengage Learning, 2011.
Gabarito
Questão 1 - Resposta B.
Resolução: Machado (2013) descreve que as ferramentas OLAP
surgiram com os sistemas de apoio à decisão para fazerem a
consulta e análise dos dados dos DW, sendo as aplicações as quais
os usuários têm acesso para extrair os dados de suas bases e
construir os relatórios com recursos que atendem os gestores.
Segundo Rob e Coronel (2011), a característica mais marcante
das modernas ferramentas OLAP é a capacidade de análise
multidimensional. Os dados são processados e visualizados em
152
https://docs.microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-serv
https://docs.microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-serv
https://docs.microsoft.com/pt-br/sql/analysis-services/what-s-new-in-analysis-services?view=sql-serv
uma estrutura multidimensional, sendo especialmente atrativo para
os tomadores de decisões de negócios, sendo que enquanto o DW
mantém dados de suporte a decisões integrados, orientados por
assunto, variáveis no tempo e não voláteis, o sistema OLAP fornece
o front end por meio do qual os usuários finais acessam e analisam
esses dados.
Questão 2 - Resposta C.
Resolução: Online Transaction Processing (OLTP – Processamento de
Transações On-line): o termo refere-se aos sistemas transacionais,
que são utilizados no processamento dos dados de rotina que são
gerados diariamente, a partir dos sistemas informacionais de uma
organização.
Online Analytical Processing (OLAP – Processamento Analítico Online):
desempenha análise multidimensional de dados empresariais
e oferece capacidades para cálculos complexos, análises de
tendências e modelagem de dados sofisticados. O OLAP habilita
usuários finais a fazerem análises ad hoc de dados em múltiplas
dimensões, provendo, desta forma, o insight e entendimento que
eles necessitam para melhor tomada de decisão.
Questão 3 - Resposta A.
Resolução: Existem diversas operações OLAP que permitem
acessar os dados em esquemas multidimensionais. Cada
operação sobre um conjunto de dados multidimensional retorna
uma apresentação ou sumarização diferente de informações.
As operações do tipo Drill (Drill Down, Drill Up, Drill Across e Drill
Throught), permitem a navegação ao longo dos níveis hierárquicos
de uma dimensão. As operações do tipo Slice and Dice são
operações para realizar a navegação por meio dos dados na
visualização do cubo.
153
Mineração de Dados em Data
Warehouse
Autora: Iolanda Cláudia Sanches Catarino
Objetivos
• Conhecer e compreender o processo de Descoberta
de Conhecimento em Bases de Dados (Knowledge
Discovery in Databases – KDD).
• Conhecer e compreender os fundamentos sobre
mineração de dados (Data Mining);
• Conhecer e compreender técnicas de Data Mining.
1. Processo de Descoberta de Conhecimento em
Bases de Dados
Muitas organizações estão dispondo de tecnologias de análise de dados
para auxiliarem na descoberta de padrões de dados e suas relações. As
ferramentas de mineração de dados (Data Mining) podem ser integradas
aos ambientes de Data Warehouse (DW) ou utilizadas com outros tipos
de armazenamento de dados, para obterem informações e, assim,
gerarem conhecimento sobre as operações realizadas pelos sistemas
transacionais que mantém imensas quantidades de dados armazenados,
ao longo dos anos.
A mineração de dados é somente uma parte do processo de exploração,
descoberta e transformação da informação em conhecimento, fazendo
parte de um processo maior conhecido como Knowledge Discovery in
Databases (KDD – Descoberta de Conhecimento em Bases de Dados),
que passou a ser reconhecido no mercado em 1989 como referência ao
processo de encontrar conhecimento útil em grandes bases de dados,
enquanto a mineração de dados, refere-se à aplicação de algoritmos
para extrair modelos e relações de dados (FAYYAD et al., 1996).
O processo de KDD contempla um conjunto de atividades contínuas
que compartilham o conhecimento descoberto a partir de bases de
dados em cinco etapas: seleção dos dados, pré-processamento dos
dados, transformação dos dados, mineração dos dados e interpretação
dos resultados, como ilustra a Figura 1. Brachman e Anand (1996),
enfatizam que as etapas do processo KDD são interativas e iterativas.
Interativas porque envolvem a cooperação e a habilidade dos usuários
responsáveis pela análise de dados durante a execução do processo,
e a iteração porque pode envolver repetidas seleções de parâmetros
e conjunto de dados, à aplicação das técnicas de mineração de dados
e, posteriormente, à análise e interpretação dos resultados obtidos,
refinando e detalhando os conhecimentos extraídos das bases de dados.
155
~ ô • R~::::1es
Dados
Dados Pré
processados
Dados
Transformados
.------- BBB : □: \-!"7 ;n ~ ~ :L2J 6 CJ: ~------; Conhecimento
Padrões
Figura 1 – Etapas do Processo KDD
Fonte: adaptada de Fayyad et al. (1996, p. 84).
Conforme mostra a Figura 1, na primeira etapa, Seleção de Dados,
considera-se que, partir do entendimento do domínio da aplicação a
ser explorada,identificam-se as bases de dados a serem utilizadas para
a descoberta de conhecimentos, em conformidade com os objetivos a
serem atingidos. Na segunda etapa, Pré-Processamento de Dados, é feito
o agrupamento organizado dos dados de uma ou mais bases de dados,
realiza-se a limpeza dos dados, identificando e resolvendo problemas
de integridade, inconsistências e adaptação dos dados ao formato
desejado. Essa etapa pode despender até 80% do tempo necessário
do processo, em função das dificuldades de integração de dados
heterogêneos, por exemplo, a forma de armazenamento de dados
discretos, como sexo do cliente, que pode ter sido armazenado em uma
base de dados como “M” e “F” e, em outra, como “0” e “1”.
Na terceira etapa do processo KDD, Transformação de Dados, os
dados pré-processados são transformados para serem armazenados
adequadamente em DW, de modo a torná-los compatíveis com o uso
das técnicas de mineração de dados. Na quarta etapa, Mineração de
156
Dados, é considerada a principal atividade do processo KDD, o qual
define-se e aplica-se uma ou mais técnicas (redes neurais, árvores
de decisão, sistemas baseados em regras e programas estatísticos)
adequadas de mineração de dados, em conformidade com o domínio do
problema, ou seja, as técnicas que melhor se adaptam ao contexto do
negócio. A última etapa, Interpretação dos Resultados, consiste na análise
e interpretação das informações com os padrões de dados descobertos,
dessa forma, induz e proporciona a geração de conhecimento aos
analistas de negócio e demais profissionais estratégicos. Não sendo
satisfatório, os resultados esperados, retorna-se a qualquer uma das
etapas anteriores de forma interativa e iterativa, iniciando um novo
processo de descoberta de conhecimento em bases de dados.
Colaço (2004) enfatiza que o processo KDD é interativo e
semiautomático, considerando que a interação com o usuário é
indispensável desde a definição dos dados a serem analisados, até
à análise e interpretação do conhecimento gerado. Além disso, se a
organização já possui banco de dados integrados e/ou DW, precisará
aproveitar as estruturas existentes. Ainda Lemos, Steiner e Nievola
(2005), reforçam que a etapa de mineração de dados é a mais
importante do processo KDD, e no contexto de negócios, é a fase que
apoia os usuários estratégicos a descobrirem oportunidades de mercado
e soluções inteligentes e inovadoras.
2. Fundamentos sobre mineração de dados
(Data Mining)
No cenário competitivo dos negócios, ferramentas de mineração
de dados são utilizadas nos diferentes segmentos do mercado para
sustentar e consolidar estratégias que auxiliem no processo de tomada
de decisão, automatizando a detecção de padrões relevantes de grandes
bases de dados das organizações, a partir da utilização de técnicas
157
estatísticas e de inteligência artificial que extraem informações úteis,
valiosas e previamente desconhecidas, para construir modelos que
predizem comportamentos, tendências desconhecidas dos dados,
correlações das informações, entre outros aspectos mensuráveis que
apoiam as necessidades dos negócios.
Na concepção de Date (2004), Data Mining pode ser descrita como
“análise de dados exploratória. O objetivo é procurar padrões
interessantes nos dados – padrões que possam ser usados para definir a
estratégia do negócio ou para identificar um comportamento incomum”
(DATE, 2004, p. 614).
De acordo com Silberschatz, Korth e Sudarshan (2006), Data Mining
refere-se ao processo de analisar grandes bancos de dados de forma
semiautomática para encontrar regras e padrões úteis a partir dos
dados, lidando com descoberta de conhecimento nos bancos de dados.
Ainda, Laudon & Laudon (2014) enfatizam que o conceito de Data Mining
pode ser definido como o processo de descoberta de novas correlações,
padrões e tendências entre as informações de uma empresa, a partir da
análise de grandes quantidades de dados armazenados em um banco
de dados, usando técnicas de reconhecimento de padrões, estatísticas e
matemáticas. Para Rob e Coronel (2011):
A mineração de dados refere-se às atividades que analisam os dados,
descobrem problemas e oportunidades ocultas em seus relacionamentos,
formam modelos computacionais com base nessas descobertas e, então,
utilizam esses modelos para prever o comportamento do negócio – exigindo
a mínima intervenção do usuário final. (ROB; CORONEL, 2011, p. 580)
A inteligência de mercado exige soluções que agreguem valor aos
negócios que possibilitam o acesso e o processo de apresentação
das informações para sustentar descobertas e análises de dados com
visão sistêmica. Assim, a mineração de dados pode ser adotada como
uma solução para apoiar a tomada de decisões nas diversas áreas e
158
segmentos, como em empresas bancárias e de cartões de crédito que
utilizam a análise baseada em conhecimento para detectar fraudes
nas transações financeiras, para prever eventos e projeções de valores
como retornos de vendas, para identificar padrões de compras dos
clientes e resolver situações que envolvem negociação com clientes,
para aprimorar o desenvolvimento e a aceitação de produtos lançados
ou novos produtos, analisar as perspectivas do mercado de ações, para
avaliar os clientes e precificar as apólices de seguro, para apoiar a gestão
de compliance e muitas outras áreas de negócio.
PARA SABER MAIS
Visão sistêmica: consiste na habilidade em compreender
o todo a partir de uma análise global das partes e da
interação entre estas, ponderando os diversos elementos
que influenciam seu funcionamento, incluindo fatores
internos e externos. A visão sistêmica é formada a partir
do conhecimento do conceito e das características
dos sistemas.
Rob e Coronel (2011) enfatizam que a mineração de dados é proativa,
ou seja, as ferramentas buscam automaticamente identificar anomalias
e possíveis relacionamentos entre os dados, identificando problemas
ainda não identificados pelos usuários estratégicos para, dessa forma,
prover o conhecimento e aplica-lo às necessidades dos negócios,
sendo que a mineração de dados contempla quatro fases básicas,
exemplificadas na Figura 2.
A fase de preparação de dados ilustrada na figura como a primeira
etapa do processo de mineração de dados, refere-se à identificação dos
principais conjuntos de dados e do tratamento de limpeza e integração
159
Sistemas OLTP
Data Warehouse
----:11>1 AnâlN • Claailcaçlode
Dados
Aquisição de
Conhecimento
Prognóstico
Identificar o conjunto de dados
Limpar o conjunto de dados
Integrar o conjunto de dados
Análise de:
Agrupamentos, classificações e grupos de dados
Vínculos ou dependências entre os dados
Padrões, tendências e desvios de dados
Selecão e aplica cão de algoritmos de:
Redés neurais ·
Lógica indutiva
Árvores de decisão
Classificação ou regressão
Previsão
Projeção
desses dados a serem utilizados pela operação de mineração de dados,
considerando que os dados de DW já estão integrados e filtrados, a
partir dos dados operacionais oriundos dos sistemas transacionais.
A fase de análise e classificação de dados ilustrada na figura como a
segunda etapa do processo de mineração de dados, refere-se a etapa de
estudo dos dados para identificar características e padrões comuns com
a aplicação de algoritmos das ferramentas de Data Mining, encontrando,
assim, análises de: agrupamentos, classificações e grupos de dados,
vínculos ou dependências entre os dados, e padrões, tendências e
desvios de dados.
Figura 2 – Fases básicas do processo de mineração de dados
Fonte: adaptada de Rob e Coronel (2011).
A fase de aquisição de conhecimento ilustrada na figura como a terceira
etapa do processo de mineração de dados, refere-se à seleção dos
algoritmos mais comuns de modelagem e aquisição de conhecimentos,
baseados em redes neurais, lógica indutiva, árvores de decisão,
classificação ou regressão, etc., e a definição desses algoritmos com
possívelinteração dos usuários finais.
160
A fase de prognóstico ilustrada na figura como a quarta e última
etapa do processo de mineração de dados, refere-se às descobertas
de mineração de dados para preverem o comportamento futuro e
projetarem resultados de negócios, por exemplo, o provável lançamento
de um produto novo ou de uma campanha de marketing. Contudo
algumas ferramentas de Data Mining não contemplam recursos para
esta fase.
De acordo com Barbieri (2001), as ferramentas Online Analytical
Processing (OLAP – Processamento Analítico On-line) objetivam trabalhar
os dados existentes, buscando consolidações em vários níveis, tratando
fatos em dimensões variadas, enquanto as ferramentas de Data Mining
buscam algo mais que a interpretação dos dados existentes, visam
essencialmente realizar inferências, tentando descobrir possíveis fatos e
correlações não explicitadas nos dados de um DW.
A mineração de dados é comumente classificada pela sua capacidade
em realizar tarefas para diferentes domínios. A literatura indica que
não existe um consenso de denominação quanto à classificação,
funcionalidades, tarefas, métodos ou técnicas de mineração de dados.
Contudo, Fayyad et al. (1996) apresentam os seguintes métodos de
mineração de dados que têm como objetivo a predição ou descrição dos
resultados:
a. Classificação: refere-se à tarefa de classificação, é uma das tarefas
mais importantes e mais populares das análises discriminantes
de bases de dados. Na classificação, o modelo analisa o conjunto
de dados fornecido, associando ou classificando um item a uma
ou a várias categorias pré-definidas, derivando uma regra que
possa ser usada para classificar uma observação, referente a um
conjunto de dados identificados que são categorizados por um
assunto. Aplica-se em diversas áreas da saúde, por exemplo, no
diagnóstico médico, visando classificar os pacientes e tipos de
doenças, na área financeira para avaliação de risco de crédito etc.
161
b. Regressão: refere-se a tarefa similar à classificação, porém
é usada quando os dados são identificados por predição de
valores numéricos, considerados variáveis independentes ou
exploratórias, e não pela categorização dos itens analisados.
Assim, é possível verificar o eventual relacionamento funcional
que possa existir entre duas ou mais variáveis quantitativas.
Observa-se que a diferença básica entre o relacionamento entre
variáveis e o método de classificação é que este a tarefa estimada
lida com resultados discretos, enquanto a de classificação lida
com resultados contínuos. São usados principalmente na área de
vendas e marketing.
c. Agrupamentos (Clusters): refere-se à tarefa de segmentar
um conjunto de dados em grupos diferentes cujos itens são
semelhantes, ou seja, subdivide o conjunto de dados em um
conjunto menor, sendo similar no comportamento dos atributos
de segmentação. A partir da mineração de dados descobre-
se grupos diferentes entre o conjunto de dados selecionado,
diferente do método de classificação em que as classes de
categorias são pré-definidas. São usados em problemas
relacionados ao processo de linha de produção, por exemplo, para
detecção de defeitos de fabricação.
d. Sumarização: refere-se à tarefa de descrever padrões e
tendências que são reveladas por subconjuntos de dados
compactados. Funções mais sofisticadas envolvem técnicas de
apresentação e visualização que facilitam a interpretação dos
resultados, como no formato de histogramas e diagramas de
dispersão. Isso é possível a partir da geração automática de
relatórios que demostram uma descrição compacta para um
subconjunto de dados com características similares, demostrando,
assim, as relações funcionais entre as variáveis definidas para a
162
análise exploratória do subconjunto de dados. São usados em
aplicações de diferentes domínios, por exemplo, identificar o
perfil dos clientes de uma operadora de telefonia que residem
em determinada região e identificar o perfil dos clientes de
e-commerce para direcionar ofertas de produtos.
e. Regras de Associação: refere-se à tarefa de identificar as regras
de associação entre variáveis que ocorrem juntas em conjuntos
de dados para estudar, principalmente, preferências e afinidades,
orientar análises e investigações, visando principalmente definir
oportunidades na área de marketing. Uma regra de associação
é definida como se X então Y, ou X ⇒ Y, onde X e Y são conjuntos
de itens e X ∩ Y = ∅. Por exemplo, um modelo de análise de
associação poderia descobrir que um cliente em 65% das vezes,
ao comprar um produto X, também compra o produto Y. Este
é o exemplo clássico de uma grande rede de supermercados
norte-americana, o Wall Mart, quando descobriu que um número
razoável de homens comprava as fraldas e também as cervejas
na véspera de finais de semana. De acordo com a história, a partir
dessa análise de associação entre os dois produtos, a rede de
supermercados utilizou o novo conhecimento para aproximar as
gôndolas desses produtos, incrementando a venda conjunta das
fraldas e cervejas.
f. Análise de Séries Temporais: refere-se à tarefa similar à regra
de associação com objetivo de aplicar algum tipo de padrão
(tendências, variações sazonais, variações cíclicas e variações
irregulares) no conjunto de dados, para determinar que tipos
de sequências podem ocorrer em um determinado período, ou
seja, sequencial no tempo. Como exemplo, a análise temporal de
ocorrências e frequência de abalos sísmicos em uma determinada
região; na área de vendas, é comum analisar a frequência que
um cliente adquire um produto ou que a partir da compra de um
produto, ele retorna após um período de tempo para comprar um
outro produto relacionado.
163
ASSIMILE
Machine Learning (Aprendizado de máquina): é uma área
da ciência da computação que significa aprendizagem de
máquina ou aprendizado automática, que evoluiu do estudo
de reconhecimento de padrões em dados e da teoria da
aprendizagem computacional em inteligência artificial,
permitindo que sistemas aprendam e tomem decisões com
o mínimo de intervenção humana.
3. Técnicas aplicadas em Data Mining
Um conjunto de técnicas de natureza estatística e de inteligência
artificial evoluíram ao longo das décadas, adaptando-se com as
técnicas de aprendizado de máquina, a partir da década de 1990,
constituindo, assim, as características das ferramentas de Data Mining
(BARBIERI, 2001).
Não existe uma técnica de mineração de dados que possa ser
considerada melhor que outra. O sucesso da aplicação de Data Mining
depende muito da experiência, sensibilidade e expertise do analista
de negócio, o qual terá que identificar qual a melhor ferramenta a ser
utilizada, considerando como e onde os dados estão armazenados,
bem como qual o método será adotado para gerar o conhecimento
pretendido. A seguir, estão descritas algumas técnicas que são adotadas
na implementação dos processos das ferramentas de Data Mining,
em conformidade com as características dos métodos de mineração,
segundo Barbieri (2001).
a. Árvores de Decisão (Decision Tree): árvores de decisão
caracterizam-se pelo método de classificação de dados, sendo
164
conveniente adotar essa técnica quando o objetivo é gerar
regras que possam ser entendidas, explicadas e traduzidas para
a linguagem natural. A árvore de decisão é uma técnica que, a
partir de uma massa de dados, cria-se e organiza-se regras de
classificação e decisão em formato de diagramas de árvores, que
classificam suas observações ou predizem classes baseadas nos
valores dos atributos de um conjunto de dados.
b. Redes neurais: as redes neurais artificiais tentam construir
representações internas de modelos ou padrões detectados
nos dados que envolvem o desenvolvimento de estruturas
matemáticas com habilidade de aprendizado, por meio de
experiências de operações da própria máquina. As redes neurais
utilizam um conjunto de elementosde processamento, também
chamados nós e links, análogos aos neurônios. Os elementos
são interconectados em uma rede que implementa detecções
sofisticadas de padrões e algoritmos de aprendizado de máquina,
construindo modelos de dados. Aplicações de redes neurais estão
sendo adotadas principalmente nos campos da medicina, ciência e
dos negócios.
c. Algoritmos Genéticos: utiliza-se algoritmos genéticos para
encontrar soluções de problemas dinâmicos e complexos que
envolvem centenas ou milhares de variáveis e/ou fórmulas
para identificar as descobertas, gerando possíveis soluções
simultaneamente. As técnicas são baseadas em métodos
inspirados na biologia evolucionária, como herança, mutação,
seleção e cruzamento, capazes de realizar pesquisas adaptativas
e robustas para o domínio explorado, principalmente na área de
análise de imagens e projetos de engenharia.
d. Análise de Aglomerações (Cluster Analysis): a técnica de
análise de aglomeração ou clusterização identifica a existência de
diferentes grupos dentro de um conjunto de dados e, constatada
esta existência, agrupa-se os elementos estudados de acordo
com suas similaridades, podendo refiná-los e definir a priorização
entre eles.
165
e. Análise de Regressão: a técnica de análise de regressão processa
os dados das bases de dados de maneira a determinar um
modelo/equação que represente o relacionamento existente entre
as variáveis em estudo, ajustando uma linha reta numa nuvem de
pontos de dados, qual a reta é a melhor representação de todas
as observações consideradas de tarefas de sumarização, predição
e estimativa. Os resultados de uma só análise podem atender a
mais de um objetivo proposto.
f. Predição com Séries Temporais: a técnica de predição com
séries temporais de tempo, espaço físico ou volume é uma técnica
utilizada principalmente no cálculo de previsão de um conjunto de
observação, dados seus valores ao longo do tempo, utilizando-os
na predição de valores futuros da série em questão. Assim, sendo
necessário armazenar as informações das variáveis ao longo de
um período, permitindo que sejam observadas repetidamente em
ciclos distintos.
As técnicas do Data Mining têm sido frequentemente aplicadas com
sucesso para a solução em diversas áreas, por exemplo:
• Saúde e medicina: identificar tratamentos de sucesso para os
diferentes diagnósticos de doenças; prever qual perfil de pacientes
que apresentam maior probabilidade de desenvolverem doenças;
identificar práticas assertivas que melhoram o atendimento e
otimizem os custos; identificar e prever doenças a partir da análise
de imagens.
• Mercado financeiro: prever as oscilações das ações na bolsa
de valores, decorrentes do cenário econômico nacional ou
internacional; prever e detectar fraudes no uso de cartões de
crédito; prever análises de créditos aos clientes.
• Vendas: identificar padrões de comportamento dos consumidores,
identificar clientes que possam migrar para o concorrente e tentar
retê-los, analisar cestas de mercado, a partir das associações entre
produtos adquiridos, encontrar características dos consumidores
166
em função da região demográfica em que vivem, prever quais
consumidores serão atingidos nas campanhas de marketing.
• Seguros e planos de saúde: detectar procedimentos médicos
requisitados ao mesmo tempo, identificar comportamentos
fraudulentos dos segurados, prever quais consumidores têm
tendência a comprar novas apólices.
• Telecomunicação: classificar clientes de acordo com seu
potencial de compra de serviços; identificar fraudes em ligações
telefônicas.
• Transporte: determinar a distribuição de trajetos e horários
decorrentes das atividades diárias ou sazonais dos passageiros;
analisar padrões de sobrecarga, definir a maneira mais
produtiva com otimização de custos dos itinerários de frotas
de veículos.
Muitas ferramentas modernas de Data Mining oferecem recursos
visuais que mostram os dados multidimensionais em telas
bidimensionais, associando os registros de dados ou conjuntos
de registros de dados a uma série de atributos visuais de fácil
usabilidade e compreensão aos usuários, assim combinando
as complexas demonstrações visuais com controles de seleção
interativa. A Figura 3 mostra algumas interfaces de uma ferramenta
de Data Mining, o software TIBCO Spotfire Desktop, que contempla uma
plataforma para exploração de dados com diferentes representações
e perspectivas para análise dos dados.
As quatro interfaces visuais do software TIBCO Spotfire Desktop,
demonstradas na Figura 3, possuem uma série de recursos para
configurar os atributos quanto à forma, cor, brilho, rotação, tamanho,
posicionamento, reposicionamento e varredura, ilustrando o
resultado por meio de gráficos multidimensionais, facilitando, assim,
a navegação interativa do usuário e as análises e interpretação dos
resultados.
167
►W&WU ·~---~~
::::
-··----
i
1.
1, J' • • '! w ••
' . .
-u1=rr~
~ ~~.-=..-_ _;_. . ~=--· =-·
--·--·--- ·-
:.....:!:.; ll~•n•••••• ,4 • .-1, • J ·-- -·-- ---
:.-:--- ·
~~- ::=..:.. . "j
~r =- - ·
:r .., .. .:.; __ ,:
.. ----~·- ·
-· -· -· · i:::=::.-=-
►-
. ,,,.,_ ·- , ....!:"' __ •J
__ ,.
-·· -·-=-..
!_......,.
,-~-"
,_ .. _
.. .... -
--· ··'-
~ i~~
·-i=: ··~---
·--...
... _.,. ---- --~-
-4 -
]
;;· - .,'! ----- -.....
Figura 3 – Interfaces do Software TIBCO Spotfire Desktop
Fonte: <https://software.com.br/p/tibco-spotfire-desktop>. Acesso em: 18 jun. 2019.
4. Considerações finais
As técnicas estatísticas aplicadas à análise analítica dos dados estão
cada vez mais sofisticadas, auxiliando as organizações na transformação
de dados e informações em conhecimento para, assim, apoiarem a
construção de estratégias inteligentes e, com isso, proporcionarem
inteligência de mercado e inteligência competitiva.
Ferramentas de mineração de dados são integradas aos ambientes de
DW ou a outros tipos de armazenamento para gerarem informações
em conhecimento potencialmente útil. Sua função principal é a extração
168
https://software.com.br/p/tibco-spotfire-desktop
de grande volume de dados com o objetivo de encontrarem padrões e
correlações significativas, estimarem tendências e novas perspectivas
que agreguem satisfatoriamente com contexto do negócio explorado.
TEORIA EM PRÁTICA
Considere o contexto de uma agência financeira que
disponibiliza linha de crédito para seus clientes do tipo
microempreendedores individuais, e para microempresas
que precisam de crédito para investimento e considere
a necessidade da agência adotar uma ferramenta de
mineração de dados para apoiar suas decisões de conceder
ou não o crédito de investimento a esses clientes. De
acordo com os métodos e técnicas de Data Mining, definiu-
se para especificar essa solução o método de classificação e
a técnica de Árvore de Decisão com duas possíveis classes:
“Sim” – adimplente/receber crédito e “Não” – inadimplente/
não receber crédito; e os seguintes atributos: A) existência
de restrições em nome da empresa – valores: 1 = Sim e 2 =
Não; B) tempo de conta com a agência – valores: 1 = de 0 a
12 meses, 2 = de 13 a 24 meses e 3 = mais de 24 meses; C)
Tempo de Atividade – valores: 1 = menos de um ano, 2 = de
1 a 3 anos, 3 = mais de 3 anos.
Assim, represente o diagrama de Árvore de Decisão
com o intuito de facilitar a leitura e compreensão dos
usuários que usarão a aplicação, conforme os atributos
e as duas classes de resultado estipuladas, e de acordo
com as seguintes regras de classificação do tipo
“se-então”:
Regras:
1. Se Restrição = 2 e Tempo de conta ≥ 2 e Tempo de atividade
≥ 2,então Adimplente.
169
2. Se Restrição = 1 e Tempo de conta = 2 e Tempo de atividade=
3,então Adimplente.
3. Se Restrição = 1 e Tempo de conta = 3 e Tempo de atividade
≥ 2,então Adimplente.
VERIFICAÇÃO DE LEITURA
1. As técnicas eferramentas de armazenamento de
dados buscam transformar dados e informação em
conhecimento. A mineração de dados é somente
uma parte do processo de exploração, descoberta
e transformação da informação em conhecimento,
fazendo parte de um processo maior conhecido como
____________________________.
Assinale a alternativa correta que indica o termo que
preenche a lacuna acima:
a. Online Transaction Processing (OLTP).
b. Online Analytical Processing (OLAP).
c. Business Intelligence (BI).
d. DataBase Management System (DBMS).
e. Knowledge Discovery in Databases (KDD).
2. O processo conhecido como Knowledge Discovery in
Databases (KDD – Descoberta de Conhecimento em
Bases de Dados), que passou a ser reconhecido no
mercado em 1989 como referência ao processo de
encontrar conhecimento útil em grandes bases de
dados, é constituído por um conjunto de atividades
170
contínuas que compartilham o conhecimento
descoberto a partir de bases de dados em cinco etapas.
Assinale a alternativa correta que indica as
etapas do KDD:
a. Seleção das bases de dados, processamento dos
dados, migração dos dados para Data Warehouse,
mineração dos dados e validação dos dados.
b. Seleção dos dados, pré-processamento dos dados,
transformação dos dados, mineração dos dados e
interpretação dos resultados.
c. Diagnóstico dos dados, seleção dos dados, análise
dos dados, interpretação dos dados e validação dos
resultados.
d. Levantamento dos requisitos, análise dos dados,
projeto dos dados, implementação dos dados e teste
com os dados.
e. Análise dos dados, projeto das informações,
mineração dos dados, implementação dos algoritmos
e Interpretação dos resultados.
3. A mineração de dados é comumente classificada pela
sua capacidade em realizar tarefas para diferentes
domínios. Fayyad et al. (1996) apresentam os métodos
de mineração de dados que têm como objetivo a
predição ou descrição dos resultados. Considerando
a aplicabilidade dos diferentes métodos, assinale a
alternativa correta que apresenta as características do
método de Classificação.
a. Usa-se quando os dados são identificados por
predição de valores numéricos, consideradas as
variáveis independentes ou exploratórias, e não
171
►.
pela categorização dos itens analisados, sendo
possível verificar o eventual relacionamento funcional
que possa existir entre duas ou mais variáveis
quantitativas.
b. Usa-se para segmentar um conjunto de dados em
grupos diferentes cujos itens são semelhantes,
ou seja, subdivide o conjunto de dados em um
conjunto menor, sendo similar no comportamento
dos atributos de segmentação, descobrindo grupos
diferentes entre o conjunto de dados selecionado.
c. Usa-se para associar um item a uma ou a várias
categorias pré-definidas, derivando uma regra que
possa ser usada para classificar uma observação,
referente a um conjunto de dados identificados que
são categorizados por um assunto.
d. Usa-se para descrever padrões e tendências que são
reveladas por subconjuntos de dados compactados,
a partir de um subconjunto de dados com
características similares, demostrando as relações
funcionais entre as variáveis definidas para a análise
exploratória do subconjunto de dados.
e. Usa-se para aplicar algum tipo de padrão (tendências,
variações sazonais, variações cíclicas e variações
irregulares) no conjunto de dados, para determinar
que tipos de sequências podem ocorrer em um
determinado período, ou seja, sequencial no tempo.
Referências Bibliográficas
BARBIERI, C. BI – Business Intelligence: modelagem & tecnologia. Rio de Janeiro:
Axcel Books, 2001.
172
BRACHMAN, R. J.; ANAND, T. The process of knowledge discovery in databases:
a first sketch. In: FAYYAD, U. M. et al. Advances in Knowledge Discovery in
Databases. Menlo Park: AAAI Press, 1994.
COLAÇO, M. Jr. Projetando sistemas de apoio à decisão baseados em data
warehouse. Rio de Janeiro: Axcel Books do Brasil, 2004.
DATE, C. J. Introdução a sistemas de bancos de dados. 8. ed. Rio de Janeiro:
Campus, 2004.
FAYYAD, U. M. et al. Advances in knowledge discovery and data mining.
California: AAAI Press, 1996.
LAUDON, K. C. & LAUDON, J. P. Sistemas de informação gerenciais. 11. ed. São
Paulo: Pearson Prentice Hall, 2014.
LEMOS, E. P.; Steiner, M. T. A; Nievola, J. C. Análise de crédito bancário por meio de
redes neurais e árvores de decisão: uma aplicação simples de data mining. Revista
de Administração, São Paulo, v. 40, n. 3, p. 225-234, jul./set. 2005.
ROB, P.; CORONEL, C. Sistemas de banco de dados: projeto, implementação e
administração. 8. ed. São Paulo: Cengage Learning, 2011.
SILBERSCHATZ, A.; KORTH, H. F.; SUDARSHAN, S. Sistema de banco de dados. 5. ed.
Rio de Janeiro: Elsevier, 2006.
Gabarito
Questão 1 - Resposta E.
Resolução: a mineração de dados é somente uma parte do
processo de exploração, descoberta e transformação da informação
em conhecimento, fazendo parte de um processo maior conhecido
como Knowledge Discovery in Databases (KDD – Descoberta de
Conhecimento em Bases de Dados), que passou a ser reconhecido
no mercado em 1989 como referência ao processo de encontrar
conhecimento útil em grandes bases de dados, enquanto a
mineração de dados, refere-se à aplicação de algoritmos para
extrair modelos e relações de dados (FAYYAD et al., 1996).
Questão 2 - Resposta B.
Resolução: o processo de KDD é constituído por um conjunto de
atividades contínuas que compartilham o conhecimento descoberto
173
a partir de bases de dados em cinco etapas: seleção dos dados, pré-
processamento dos dados, transformação dos dados, mineração
dos dados e interpretação dos resultados.
Questão 3 - Resposta C.
Resolução: refere-se à tarefa de classificação, e é uma das tarefas
mais importantes e mais populares das análises discriminantes
de bases de dados. Na classificação, o modelo analisa o conjunto
de dados fornecido, associando ou classificando um item a uma
ou a várias categorias pré-definidas, derivando uma regra que
possa ser usada para classificar uma observação, referente a um
conjunto de dados identificados que são categorizados por um
assunto. Aplica-se em diversas áreas da saúde, como no diagnóstico
médico, visando classificar os pacientes e tipos de doenças; na área
financeira para avaliação de risco de crédito, etc.
174
175
Bons estudos!
Apresentação da disciplina
Banco de Dados Transacionais versus Bancos de Dados Analíticos
Conceitos básicos sobre Data Warehouse
Data Marts
Modelagem de dados para um Data Warehouse
Esquema Estrela e Esquema Floco de Neve
Ferramentas de Dados em um Data Warehouse
Mineração de Dados em Data WarehouseMais conteúdos dessa disciplina
Mapa Mental - Mudança Organizacional- exercicios transição de serviços de TI
- Mapa Mental - Banco de Dados
- Avaliacao GRAU B_ Revisao da tentativa
- Avaliacao Grau A_ Revisao da tentativa
- Acerca da geração da informação
- Comprovante de Pix
- 20_questoes_abertas_TGA_FICR
- RESOLUÇÃO - (032 99116 - 4945) - RELATÓRIO DE AULA PRÁTICA PROGRAMAÇÃO E DESENVOLVIMENTO DE BANCO DE DADOS
- RESOLUÇÃO - (032 99116 - 4945) - RELATÓRIO DE AULA PRÁTICA - PROGRAMAÇÃO ORIENTADA A OBJETOS - MYSQL
- Pergunta 5 Qual habilidade é mais enfatizada pela abordagem da sala de aula invertida? a. Memorização de informações. b. Habilidades técnicas desneces
- CESPE - TJ - PA -ANALISTA JUDICIARIO ASSINALE A ALTERNATIVA QUE INDICA DE EXTRAÇÃO E TRANSFORMAÇÃO
- Uma consequência de linguagem biomédica inadequada no manejo da dor lombar é: * a) Redução da catastrofização b) Aumento da autonomia do paciente...
- Escolha uma opção: a. REVOKE TABLE b. CREATE TABLE. c. UPDATE TABLE. d. SELECT TABLE e. INSERT TABLE
- A dimensão do tempo significa a organização dinâmica do processo ao longo do tempo. O ciclo de vida do software é dividido em ciclos. Cada ciclo corre
- Qual é a vazão de chuva que um tubo horizontal de diâmetro de 150mm e declividade de 1,00% consegue transportar. Dado : n = 0,011 Q 2/3 = 0,766 Qpleno
- Qual comando usaríamos para, por meio da linguagem DCL, remover todos os privilégios de um usuário? Questão 1Escolha uma opção: a. REVOKE ALL PRI...
- Qual é a capacidade de escoamento de uma calha de seção quadrada de lado igual a 15 cm é inclinação de 1%. Dado n = 0,011. Q = 12,45 l/s Q = 27,81 l/s
- Qual é a vazão de chuva que um tubo horizontal de diâmetro de 100mm e declividade de 1,40% consegue transportar. Dado : n = 0,011 Q 2/3 = 0,766 Qpleno
- Qual das tecnologias a seguir representa um tipo de conexão utilizado em equipamentos que compõem soluções baseadas no conceito de IoT? Questão 9...
- Qual a máxima capacidade que uma calha de seção semicircular e diâmetro de 100mm, inclinação de 0,8%, pode transportar de água de chuva. Dado : n = 0,
- Qual dos conceitos a seguir é o mais adequado para definir big data? Questão 6Escolha uma opção: a. Big data é a linguagem de pesquisa declarati...
- Questão 01 1 PONTO Uma das formas de se avaliar o espaço físico de um determinado layout é considerar o volume transportado entre as áreas deste espaç
- Avaliação Final (Discursiva) - Individual - Introdução ao Desenvolvimento de Sistemas Web
- 02 AMS Módulos de SW Ed 01
