Apostila Data Warehouse e Data Mart (Estácio) - Pós-Gradução Inteligência de Negócios

Prévia do material em texto

ARQUITETURA DE DATA WAREHOUSE E DATA MART 1 
 
 
Arquitetura de Data 
Warehouse e Data Mart 
 
 
 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 2 
Arquitetura de Data Warehouse e Data Mart 
 
O Data Warehouse surgiu a partir do reconhecimento da importância do valor da 
informação nas organizações. Ele é um ambiente expansível e planejado para a análise 
de dados não voláteis. 
 
Esses dados são logicamente e fisicamente transformados, provenientes de múltiplas 
aplicações, atualizados e mantidos por um longo período de tempo, expressos em 
termos do negócio e resumidos para uma análise eficiente. 
 
Assim, o Data Warehouse é uma plataforma orientada a assunto, com dados 
integrados e qualidade melhorada para apoiar vários SAD (Sistema de Apoio de 
Decisão) e processos empresariais. 
 
Em termos tecnológicos, Data Warehouse é uma combinação de várias tecnologias, 
tendo como primeiro objetivo a integração efetiva de bases de dados operacionais em 
um ambiente que habilita o uso estratégico dos dados. 
 
Essas tecnologias incluem sistemas gerenciadores de banco de dados relacional e 
multidimensional, modelagem de metadados e repositórios, interfaces gráficas para 
usuário etc. 
 
O Data Mart surgiu em função do volume de dados a serem carregados e também da 
facilidade de armazenamento por áreas de interesse. 
 
Por exemplo: os dados da área financeira ficam armazenados em servidor deles, dados 
de marketing em outro servidor e assim por diante. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 3 
Essa é uma saída interessante para quem precisa de bastante performance, por isso 
não sobrecarrega um único servidor, e o custo de desenvolvimento é bem menor, em 
termos de hardware e de entrega para o usuário. 
 
Iremos estudar que os conceitos em utilizar um DW e DM são idênticos, nas 
bibliografias o Data Mart é um subconjunto do Data Warehouse. 
 
Quais são os motivos de utilizarmos o DW e DM? 
 
Existem vários motivos para a construção do Data Warehouse. Pode-se explicar 
através de alguns pontos importantes citados pela IDC (International Data 
Corporation), que são: 
 
• A habilidade em focalizar processos empresariais e efetuar uma análise 
financeira completa destes processos, assim como permitir as 
organizações tomarem decisões baseadas na compreensão do sistema 
como um todo ao invés de fazer estimativas duvidosas fundadas sobre 
dados incompletos; 
 
• A habilidade em racionalizar e automatizar o processo de construção de 
um repositório de informações integradas para uma empresa ao invés de 
desenvolver inúmeros sistemas de apoio à decisão e sua infraestrutura 
correspondente; 
 
• O preço de hardware e software, bem como os custos de armazenamentos 
relacionados ao desenvolvimento, organização (deployment), e 
manutenção de grandes repositórios de dados estão continuamente 
diminuindo; 
 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 4 
• Os benefícios do Data Warehouse podem ser facilmente estendidos à 
tomada de decisões estratégicas, que podem trazer grandes e tangíveis 
benefícios; 
 
• A habilidade em entender e administrar simultaneamente macro e micro 
perspectivas de uma organização, que pode economizar incontáveis horas 
de trabalho manual das organizações e ajudar a evitar enganos 
dispendiosos, que podem ser o resultado de suposições feitas sobre dados 
incompletos ou incorretos; 
 
• Dificuldade em acessar as informações de formas diferentes, o fato de 
várias informações estarem contidas em sistemas diversos, planilhas e 
documentos, e até mesmo em partes do mesmo sistema em que não se 
relacionam, torna extremamente difícil a tarefa de consultar as 
informações de formas distintas e o DW facilita esta atividade. 
 
Quando pensamos em pequenos armazenamentos de dados pensamos em Data Mart. 
Um Data Mart é um pequeno Data Warehouse, ou seja, um subconjunto do DW, que 
fornece suporte à decisão de um pequeno grupo de pessoas. 
 
Algumas organizações são atraídas aos Data Marts não apenas por causa do custo 
mais baixo e um tempo menor de implementação, mas também por causa dos 
correntes avanços tecnológicos. 
 
São eles que fornecem um Sistema de Apoio à Decisão (SAD) customizado para grupos 
pequenos, de tal modo que um sistema centralizado pode não estar apto a fornecer. 
 
Data Marts podem servir como veículo de teste para companhias que desejam explorar 
os benefícios do Data Warehouse. 
 
Características de DW e DM 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 5 
O Data Warehouse é uma tecnologia, um ambiente de Banco de Dados, não um 
produto. Trata-se da construção arquitetônica de um sistema de informação, que 
fornece a seus usuários informações históricas de apoio a decisão, que são de difícil 
acesso ou apresentação quando se utiliza de meios tradicionais de armazenamento de 
dados operacionais. 
 
O Data Warehouse forma assim uma base de dados que permite efetuar um 
tratamento adequado à informação, que pode habilitar a descoberta e exploração de 
tendências empresariais importantes. 
 
Uma organização moderna precisa de Sistemas de Informações eficientes e fáceis de 
utilizar a fim de sobreviver e obter sucesso em um ambiente globalizado e altamente 
competitivo. 
 
Neste contexto, podem-se citar várias razões para construir estes sistemas, que são: 
 
• As decisões precisam ser tomadas rapidamente e corretamente, usando todos 
os dados disponíveis; 
 
• Os usuários de sistemas de informações são especialistas de domínio de 
negócio, não profissionais de computação; 
 
 
• O volume de dados dobra a cada 18 meses, o que afeta o tempo de resposta e 
incontestavelmente a habilidade em compreender seu conteúdo; 
 
• A competição aumenta dia após dia nas áreas de inteligência empresarial, bem 
como o valor agregado de informações. 
 
Existem várias razões tecnológicas para a existência de Data Warehouse: 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 6 
• O Data Warehouse é projetado para resolver a incompatibilidade de sistemas 
de informações transacionais e operacionais. Estas duas classes de sistemas 
são projetados para satisfazer diferentes, frequentemente incompatíveis, 
exigências; 
 
• A infraestrutura TI muda rapidamente, bem como suas capacidades aumentam. 
 
Isso pode ser evidenciado através dos seguintes pontos: 
 
• O preço dos computadores que operam em uma velocidade medida em MIPS 
(Milhões de Instruções por Segundo) continua caindo, enquanto que o poder dos 
microprocessadores dobra a cada 2 anos; 
 
• O preço de armazenamento digital está diminuindo; 
 
• A banda passante das redes está aumentando, enquanto que o preço de banda 
está diminuindo; 
 
• O local de trabalho é crescentemente heterogêneo em termos de hardware e 
software; 
 
 
• Os sistemas legado precisam, e podem, ser integrados com novas aplicações. 
 
Um Data Warehouse envolve assim aspectos tecnológicos, de negócio e de construção 
propriamente dita de uma base de dados analítica. 
 
Características de um Data Warehouse 
 
O elemento primordial envolvendo o Data Warehouse é que os dados armazenados 
para análise do negócio devem ser separados dos dados do sistema operacional. 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 7 
 
Muitas razões para esta separação têm sido levantadas no decorrer dos anos: 
• A performance do sistema de informação; 
• A garantia da qualidade da informação obtida, completa e correta; 
• A não perturbação dos sistemas operacionais através de requisições de 
consultas pesadas etc. 
 
Finalmente, os avanços tecnológicos e as mudanças na natureza dos negócios tornam 
as análises dos dados muito mais complexas e sofisticadas. 
 
O DW ou DM devem ser orientados por assuntos, integrados, variáveis no tempo e 
não voláteis. Essas seriam as principais características de um DW, porém existem 
outras também importantes como a localização, credibilidade dos dados e 
granularidade. Vamos estudar cada uma delas. 
 
Orientação por Assunto 
 
A orientaçãopor assunto é uma característica marcante de um DW, pois toda 
modelagem é voltada em torno dos principais assuntos da empresa. Enquanto todos 
os sistemas transacionais estão voltados para processos e aplicações específicas, os 
DWs objetivam assuntos. 
 
Integração 
 
Esta característica talvez seja a mais importante do DW. É através dela que se 
padroniza uma representação única para os dados de todos os sistemas que formarão 
a base de dados do DW. Por isso, grande parte do trabalho na construção de um DW 
está na análise dos sistemas transacionais e dos dados que eles contêm. 
 
 
 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 8 
Variação no Tempo 
 
Os Data Warehouses são variáveis em relação ao tempo, isso nada mais é do que 
manter o histórico dos dados durante um período de tempo muito superior ao dos 
sistemas transacionais. 
 
Diz respeito ao fato do dado em um data warehouse referir-se a algum momento 
específico, significando que não é atualizável. A cada ocorrência de uma mudança, 
uma nova entrada é criada, para marcar esta mudança. É uma das variáveis mais 
importante do projeto de DW, pois é o tempo que define a periodicidade da carga dos 
dados no DW ou DM. 
 
Não volatilidade 
 
No DW existem somente duas operações, a carga inicial e as consultas dos front-ends 
aos dados. Após serem integrados e transformados, os dados são carregados em bloco 
para o data warehouse, para que estejam disponíveis aos usuários para acesso. 
 
Isso pode ser afirmado porque a maneira como os dados são carregados e tratados é 
completamente diferente dos sistemas transacionais. 
 
Localização 
 
Os dados podem estar fisicamente armazenados de três formas: 
 
• Em um único local centralizado, com banco de dados em um DW integrado; 
• Os distribuídos, em forma de Data Marts, armazenados por áreas de interesse; 
• Armazenados por níveis de detalhes, em que as unidades de dados são mantidas 
no DW. 
 
 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 9 
Credibilidade dos Dados 
 
A credibilidade dos dados é muito importante para o sucesso de qualquer projeto. 
Discrepâncias simples de todo tipo podem causar sérios problemas quando se quer 
extrair dados para suportar decisões estratégicas para o negócio das empresas. 
 
Granularidade 
 
Granularidade nada mais é do que o nível de detalhe ou de resumo dos dados 
existentes em um DW. Quanto maior for o nível de detalhes, menor será o nível de 
granularidade. 
 
O nível de granularidade afeta diretamente o volume de dados armazenados no DW, 
e ao mesmo tempo o tipo de consulta que pode ser respondida, com isso pode afetar 
drasticamente o tempo de resposta para o usuário final. 
 
O balanceamento do nível de granularidade é um dos aspectos mais críticos no 
planejamento de um DW, pois, na maior parte do tempo, há uma grande demanda 
por eficiência no armazenamento e no acesso aos dados, bem como pela possibilidade 
de analisar dados em maior nível de detalhes. 
 
Quando uma organização possui grandes quantidades de dados no DW, faz sentido 
pensar em dois ou mais níveis de granularidade, na parte detalhada dos dados. 
 
Na realidade, a necessidade de existência de mais de um nível de granularidade é tão 
grande, que a opção do projeto que consiste em duplos níveis de granularidade deveria 
ser o padrão para quase todas as empresas. 
 
Com a criação de dois níveis de granularidade no nível detalhado do DW, é possível 
atender a todos os tipos de consultas, pois a maior parte do processamento analítico 
dirige-se aos dados levemente resumidos que são compactos e de fácil acesso. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 10 
Para ocasiões em que um maior nível de detalhe deve ser investigado, existe o nível 
de dados históricos. O acesso aos dados do nível histórico de granularidade é caro, 
incômodo e complexo, mas caso haja necessidade de alcançar esse nível de detalhe, 
lá estará ele. 
 
Projetos Star Schema e SnowFlake 
 
As possibilidades de implementação do Modelo Multidimensional são o Star Schema 
(Modelo Estrela) e Snowflake Schema (Modelo Floco de Neve). 
 
No Modelo Estrela, as tabelas dimensões se relacionam com a tabela fato. Desta forma, 
essas tabelas precisam ter as descrições necessárias para definir uma classe, ou seja, 
as dimensões não são normalizadas. 
 
Então, poderá ter campos com conteúdos repetidos em cada registro, aumentando 
assim o tamanho das tabelas. 
 
O Modelo Estrela possui este nome, pois a sua representação é no formato de uma 
estrela, onde a tabela fato fica no centro e as dimensões ficam ao redor. 
 
No Modelo Floco de Neve, as dimensões relacionam-se com a tabela fato, porém existe 
também relacionamento apenas entre as dimensões. Isso acontece com o objetivo de 
normalizar as dimensões para diminuir o espaço ocupado por essas tabelas. 
 
A técnica snowflaking consiste em normalizar uma dimensão, removendo atributos do 
tipo texto de baixa cardinalidade e colocá-los em dimensões secundárias e depois criar 
um relacionamento entre essas dimensões. 
 
Dessa forma, mais tabelas são usadas para representar as mesmas dimensões, porém 
o espaço ocupado em disco é menor que no modelo estrela. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 11 
O modelo floco de neve é chamado desta maneira pois cada dimensão divide-se em 
várias outras que organizadas se assemelham a um floco de neve. 
 
Este modelo é recomendado quando se quer reduzir o espaço em disco, para contribuir 
para a estabilidade na manutenção de uma dimensão ou quando é um pré-requisito 
de uma ferramenta a ser utilizada. 
 
Não é recomendado quando dificulta a compreensão do modelo por parte do usuário 
final ou quando compromete a performance durante a navegação pelo modelo devido 
à conexão entre as tabelas. 
 
Observa-se que o modelo floco de neve apesar de ocupar menos espaço em disco 
acaba sendo mais complexo devido à quantidade de tabelas, além de tornar a 
navegação mais lenta justamente por precisar acessar um número maior de tabelas 
para realizar as consultas. 
 
Apesar do Star Schema (Modelo Estrela) ocupar mais espaço no banco, ele é mais 
simples e sua navegação pelos softwares mais fácil, sendo assim mais recomendado 
à criação deste modelo. 
 
No Modelo Floco de Neve, o relacionamento estabelecido entre as Dimensões 
demonstra uma Hierarquia e esta técnica Snowflaking possibilita a visualização gráfica 
dessas Hierarquias das Dimensões. 
 
As Hierarquias podem ser classificadas em Balanceadas ou Regular, Desbalanceadas 
ou Parent-Child e Irregular ou Ragged. 
 
Na Hierarquia Balanceada ou Regular, a quantidade de níveis é uniforme. Todas as 
folhas membros da hierarquia têm a mesma distância da raiz. Cada membro da 
hierarquia tem a mesma quantidade de níveis superiores e o processo de extração e 
carga dos dados nesta dimensão é simples. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 12 
Já na Hierarquia Desbalanceada ou Parent-Child, a quantidade de níveis é variável, os 
membros da hierarquia são definidos com seus respectivos níveis superiores e cada 
linha da dimensão possui a sua chave e a chave do membro pai na hierarquia. 
 
Vantagens e Desvantagens do Star Schema e Snow Flake 
 
Iremos estudar as propriedades e algumas vantagens das modelagens Star Schema 
(Modelo Estrela) e Snowflake Schema (Modelo Floco de Neve). 
 
Propriedades do esquema em estrela 
 
Uma única tabela de fatos contendo dados, sem redundância. Uma tabela por 
dimensão. 
 
As chaves primárias, da tabela de fatos, são apenas de uma por dimensão. Cada 
dimensão representa uma única tabela, altamente desnormalizada. 
 
Vantagens 
 
A simetria do desenho e a simplicidade semântica faz com que este modelo 
disponibilize ao utilizador comum toda a informação necessária sobre o funcionamento 
da sua organização, o reduzido número de junções beneficia o desempenho e tudo 
isto faz com que este modelo tenha uma baixa e fácil manutenção. 
 
Desvantagens 
 
Não fornece explicitamente suporte para hierarquiasde atributos e as tabelas 
dimensionais são um problema. 
 
As tabelas de dimensão, por não estarem normalizadas, contém repetição das 
informações. Não são adequadas para uso transacional, pois uma alteração simples 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 13 
(como de o nome de um país) poderia gerar a necessidade de várias alterações no 
banco de dados (para todas as linhas de municípios). 
 
O Esquema Floco de Neve (Snow flake Schema) 
 
O esquema Floco de Neve consiste na tentativa do arquiteto do modelo de normalizar 
as tabelas de dimensão, reproduzindo no Data Warehouse o modelo de dados 
relacional. 
 
A normalização das dimensões tem um efeito negativo na velocidade de saída dos 
resultados e, acima de tudo, apresenta ao utilizador um conjunto complexo de tabelas 
relacionadas entre si de difícil compreensão e utilização. 
 
Por todas essas razões, é um esquema nada aconselhado a ser utilizado para a 
elaboração do Data Warehouse. 
 
A tabela de fatos é composta por dois tipos de atributos, as chaves estrangeiras, que 
a ligam às tabelas de dimensão, e pelos fatos. As chaves estrangeiras, para além de 
estabelecerem regras de integridade referencial com as tabelas de dimensão, servem 
para utilizar os atributos das dimensões para caracterizar as métricas registradas e 
para parametrizar as queries aos dados. 
 
Tipos de Fatos 
 
Existem 3 tipos de fatos: 
• Fatos aditivos - aqueles que podem ser somados relativamente a todas as 
dimensões de um esquema em estrela; 
• Fatos semiaditivos - apenas podem ser somados relativamente a algumas 
dimensões, ou mesmo, a uma única dimensão; 
• Fatos não aditivos - todos aqueles que não podem ser somados de acordo 
com qualquer uma das dimensões. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 14 
 
As tabelas de dimensão contêm a descrição textual do negócio. Em um modelo de 
dimensão bem estruturado as tabelas de dimensão possuem múltiplas colunas ou 
atributos. Estes atributos descrevem as linhas na tabela de dimensão. 
 
As tabelas de dimensão tendem a ser relativamente pequenas no número de linhas 
(muitas vezes pouco mais de 1 milhão de linhas) mas são largas com colunas grandes. 
 
Cada dimensão é definida pela sua única chave primária, que serve como base para 
manter a integridade referencial quando se liga a uma tabela de fatos. 
 
Independentemente se o snowflake resulta da normalização das tabelas de dimensão 
ou de relacionamentos entre as tabelas de dimensão, uma vantagem de um esquema 
do snowflake é que as tabelas de dimensão são mais versáteis. 
 
Por exemplo, se uma dimensão de tempo é normalizada em várias tabelas de dimensão 
— uma tabela de ano, uma tabela de mês e uma tabela de data, em seguida é possível 
ter várias tabelas de fatos que armazenam dados a outro nível de granularidade com 
respeito ao tempo; uma tabela de fatos podem estar relacionados com a tabela de 
data, enquanto outro podia se relacionar a tabela de mês ou o ano. 
 
O esquema Snowflake, por relacionar tabelas de dimensões, se torna bem mais lento. 
Logo, dificultam as implementações de ferramentas de visualizações de dados. Por 
isso, não é muito utilizado nos projetos de DW. 
 
 
Abaixo, veja a representação do Star Schema, Snowflake e Data Warehouse. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 15 
 
 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 16 
Arquitetura do Data Warehouse ou Data Mart 
 
A arquitetura de Data Warehouse é a maneira de representar a estrutura completa de 
dados, comunicação, processamento, e resultados que são apresentados aos usuários 
finais dentro da empresa. 
 
A arquitetura de Data Warehouse é composta por algumas partes interconectadas: 
 
• Base de Dados Operacional / Camada de Base de Dados Externa; 
• Camada de Acesso a Informações; 
• Camada de Acesso aos Dados; 
• Camada de Diretório de Dados (MetaDados); 
• Camada de Gerenciamento de Processos; 
• Camada de Troca de Mensagens entre Aplicações; 
• Camada do Data Warehouse; 
• Camada de Organização dos Dados. 
 
Camada de Acesso a Informações 
 
Esta camada representa as ferramentas que o usuário final utiliza normalmente, em 
seu dia a dia, para saber as informações disponibilizadas para acessarem o DW ou DM. 
Estas ferramentas serão estudadas em uma disciplina mais adiante no curso. 
 
Camada de Acesso aos Dados 
 
A camada de acesso aos dados da arquitetura do Data Warehouse deve permitir que 
a camada de acesso a informações se comunique com a camada operacional. 
 
Camada de Diretório de Dados (MetaDados) 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 17 
Visando prover acesso universal aos dados, é absolutamente necessário manter 
alguma forma de diretório de dados ou repositório de metadados. 
 
Para termos um Data Warehouse completamente funcional, é necessário que a 
empresa possua uma vasta variedade de metadados disponíveis: 
• Dados sobre os relatórios dos usuários finais; 
• Dados sobre as bases de dados operacionais e outros. 
 
Idealmente, usuários finais devem ser capazes de acessar dados do Data Warehouse 
sem precisar saber onde os dados realmente residem ou como estão armazenados. 
 
Camada de Gerenciamento de Processos 
 
Esta camada está envolvida com o agendamento das várias tarefas que devem ser 
realizadas para construir e manter o Data Warehouse e o diretório de informações 
sobre os dados. 
 
Pode-se pensar nesta camada como sendo a controladora de tarefas de alto nível para 
muitos processos que podem ocorrer para deixar o Data Warehouse atualizado. 
 
Camada de Troca de Mensagens entre Aplicações 
 
A troca de mensagens é utilizada para coletar transações ou mensagens e entregá-las 
a certos locais em certo tempo. Ela é o sistema de transporte em um Data Warehouse. 
 
 
 
Dados Operacionais / Dados Externos 
 
Claramente, o objetivo de um Data Warehouse é libertar a informação que está 
bloqueada nas bases de dados operacionais, e misturá-la com informações de outras 
origens de dados, frequentemente externas. 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 18 
 
Cada vez mais, grandes organizações estão adquirindo dados adicionais de bases 
externas. Entre estes dados, encontram-se características demográficas, competitivas, 
econométricas e as diferenças entre os produtos de consumo internos. 
 
Camada do Data Warehouse 
 
O núcleo do Data Warehouse está onde os dados analíticos atuais residem. Em alguns 
casos, alguém pode pensar em um Data Warehouse simplesmente como uma visão 
lógica ou virtual dos dados. Em muitas instâncias, o DW pode envolver mais do que a 
armazenagem dos dados. 
 
Camada de Organização dos Dados 
 
A organização dos dados também pode envolver programas de análise da qualidade 
dos dados, e filtros que identificam padrões e estruturas de dados dentro dos dados 
operacionais. 
 
A escolha da arquitetura é uma decisão gerencial do projeto e está baseada 
(normalmente) nos fatores relativos à infraestrutura atualmente disponível (que se for 
o caso de aquisição do mesmo), ao ambiente de negócios, escopo desejado, além de 
capacitação dos recursos disponibilizados no projeto e funcionários da empresa 
projetos para tal investimento. 
 
Vantagens e desvantagens dessa arquitetura 
 
Vantagens: 
 
• Herança de arquitetura: todos os DM originados de um DW utilizam a 
arquitetura e os dados desse DW, permitindo uma fácil implementação; 
• Visão de empreendimento: o DW concentra todos os negócios da empresa, 
sendo possível extrair dele níveis menores de informações; 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 19 
• Repositório de metadados centralizado e simples: o DW provê de um 
repositório de metadados central para o sistema. Essa centralização permite 
manutenções mais simples do que aquelas realizadas em múltiplos repositórios; 
• Controle e centralização de regras: a arquitetura top down garante a 
existência de um único conjunto de aplicações para extração, limpeza e 
integração dos dados, além de processos centralizadosde manutenção e 
monitoração. 
 
Desvantagens: 
 
• Implementação muito longa: os DWs são, normalmente, desenvolvidos de 
modo iterativo, por áreas de assuntos, como, por exemplo, vendas, finanças e 
recursos humanos. Mesmo assim, são necessários, em média, 15 ou mais meses 
para que a área de assunto entre em produção, dificultando a garantia de apoio 
político e orçamentário; 
• Alta taxa de risco: não existem garantias para o investimento nesse tipo de 
ambiente; 
• Heranças de cruzamentos funcionais: é necessária uma equipe de 
desenvolvedores e usuários finais altamente capacitados para avaliar as 
informações e consultas que garantam à empresa habilidade para sobreviver e 
prosperar na arena de mudanças de competições políticas, geográficas e 
organizacionais; 
• Expectativas relacionadas ao ambiente: a demora do projeto e a falta de 
retorno podem induzir expectativas nos usuários. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 20 
 
 
 
Implementação de Data Warehouse ou Data Mart 
 
Como vimos, a construção do DW tem um tempo maior de projeto do que o DM, pois 
o DW irá atender a empresa no todo. Já o DM irá atender uma área específica e 
podemos desenvolver um DM para cada área, mas com um requisito primordial: que 
estes DM sejam integrados e não soltos sem nenhuma integração. 
 
Os DMs integrados fazem com que todos os dados sejam únicos e não desconectados. 
 
Nesta etapa, temos que escolher em implementar o DM. Aqui entra a implementação 
Bottom Up, teoricamente, por ser mais fácil e menos custosa de ser implementada do 
que a Top Down, sendo muito usada, até pelo retorno rápido de investimento. 
 
Ela permite que o planejamento e a construção dos Data Marts possam ser realizados 
antes mesmo que a infraestrutura do DW seja definida. O propósito desta 
implementação é a construção de DW incremental a partir do desenvolvimento de DM 
independentes. 
 
A seguir a representação da implementação Bottom UP e Top Down: 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 21 
 
 
 
Vantagens e desvantagens da arquitetura Bottom UP 
 
Vantagens: 
 
• Implementação rápida: a construção dos DM é altamente direcionada, 
permitindo um rápido desenvolvimento. Normalmente, pode ser colocado em 
produção em um período de 6 a 9 meses; 
 
• Retorno rápido: a arquitetura baseada em DM com incremento demonstra 
rapidamente seu valor, permitindo uma base para investimentos adicionais com 
um nível mais elevado de confiança; 
 
• Manutenção do enfoque da equipe: a elaboração de DMs permite que os 
principais negócios sejam enfocados inicialmente, sem que haja gastos no 
desenvolvimento de áreas que não são essenciais ao problema; 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 22 
 
• Herança incremental: a estratégia de DMs incrementais obriga a entrega de 
recursos de informação passo a passo, o que permite a equipe crescer e 
aprender, reduzindo os riscos etc. 
 
Desvantagens: 
 
• Perigo de legamarts: um dos maiores perigos da Administração de DW é a 
criação de DMs independentes. Com isso, o advento das ferramentas de drag 
and drop facilitou o desenvolvimento de soluções individuais de acordo com as 
necessidades da empresa, as quais podem não considerar a arquitetura de 
forma global. Desse modo, os DMs independentes transformam-se em DM 
legados ou legamarts; 
 
• Desafio de possuir a visão de empreendimento: durante a construção dos 
DMs incrementais é necessário que se mantenha um rígido controle do negócio, 
como um todo. Esse controle requer um maior trabalho ao extrair e combinar 
as fontes individuais do que utilizar um DW; 
 
• Administrar e coordenar múltiplas equipes e iniciativas: normalmente 
esse tipo de arquitetura emprega o desenvolvimento de DMs em paralelo. No 
entanto, isso pode conduzir a uma rígida administração, tentando coordenar os 
esforços e recursos das múltiplas equipes, especialmente nas áreas de regras e 
semântica empresariais; 
 
• A maldição de sucesso: a arquitetura com DMs incrementais carrega a 
“maldição de sucesso”. Nesses casos, os usuários finais dos DMs encontram-se 
felizes querendo mais informação para seus DMs e, ao mesmo tempo, outros 
usuários de outros DMs aguardam o incremento de seus DMs. Isso conduz a 
equipe de DM a vencer desafios de recurso e de administração. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 23 
Implementação Combinada 
 
Esse tipo de implementação tem como finalidade integrar a arquitetura top-down e a 
bottom-up. Nessa abordagem, efetua-se a modelagem de dados do Data Warehouse 
de visão macro, sendo o passo seguinte a implementação de partes desse modelo. 
 
Essas partes são escolhidas por processos ou atividades da área de interesse e 
constituem os Data Marts. 
 
Podemos dizer então que cada Data Mart pode ser gerado a partir do macromodelo 
de dados do Data Warehouse e integrado ao modelo físico do mesmo Data Warehouse. 
 
A principal vantagem é a garantia da consistência dos dados, que é obtida em virtude 
dos modelos de dados para os Data Marts serem únicos, possibilitando, a partir disso, 
o mapeamento e o controle dos dados. 
 
 
 
Características da Implementação Combinada 
 
Implementação 
• Planejamento Top-Down; 
• Processos de Negócio. 
 
Desenvolvimento Bottom-Up 
• Um Data Mart de cada vez; 
• Cada Data Mart encarado de forma evolutiva; 
• Complexidade do modelo; 
• Volume de dados; 
• Investimentos; 
 
Gestão de Metadados 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 24 
 
Coerência entre os vários Data Marts 
 
Podemos concluir que qualquer implementação dessa arquitetura para ambiente de 
Data Warehouse requer basicamente uma infraestrutura bem definida e centralizada 
para que o desenho dessas soluções seja realizado de acordo com a construção dos 
DMs. 
 
O início da implantação do DW ou DM deve-se começar com o levantamento e definir 
os objetos de negócios e, por conseguinte, as questões gerenciais que os respondem. 
 
Essa etapa é de extrema importância, pois é ela quem irá determinar quais serão os 
dados a serem armazenados no Data Warehouse. Exigirá, também, uma metodologia 
específica e diferente dos sistemas transacionais. 
 
Terminada esta etapa, partiremos então para a segunda fase da implantação que 
consiste em fazer a modelagem dimensional, ou seja, partindo dos objetos gerenciais 
levantados faz-se a modelagem do novo banco gerando os fatos e as dimensões. 
 
Logo em seguida, parte-se para a criação física do modelo, onde as especificidades de 
um SGBD e da ferramenta OLAP escolhidos são levadas em consideração para otimizar 
as futuras consultas ao banco e onde se deve dar preferência os esquemas estrela. 
 
Feito isso, o passo seguinte é a carga dos dados no DW. Para isso é necessário que 
se definam as origens dos mesmos nos sistemas legados, ou seja, identificar em quais 
sistemas e onde estão armazenados. 
 
Nessa etapa, é imprescindível a presença de um analista de sistemas da empresa que 
conheça profundamente os sistemas transacionais, pois isso facilitará muito o trabalho 
de localização e identificação dos dados. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 25 
A próxima etapa é fazer as rotinas de extração dos dados. Essas rotinas podem ser 
desenvolvidas por programadores em qualquer linguagem de programação. 
 
Após a extração resta dar a carga dos dados no banco dimensional criado no segundo 
passo. Essa carga também pode ser feita através de ferramentas de mercado. 
 
Concluída a carga, deve-se fazer uma checagem profunda da consistência dos dados. 
Isso é muito importante, pois está se trabalhando com informações para dar suporte 
à decisão e, qualquer dado errado poderá determinar o fracasso da análise do negócio 
em questão. 
 
 
 
Outro passo importantíssimo na elaboração é a confecção e armazenamento dos 
metadados. Os metadados são os dados de controle do Data Warehouse. 
 
Para fazermos a análise dos dados, temos as ferramentas OLAP, que permitem a 
visualização dos dados da base dimensionale sua análise de acordo com a imaginação 
do executivo. 
 
Com esses softwares, também denominados ferramentas de front-end, o usuário 
poderá analisar as informações que estão contidas no banco multidimensional. 
 
Além dos passos anteriores, os usuários devem ser treinados de forma a aprender 
como manipular as informações existentes, seja na criação das estatísticas, seja na 
criação de gráficos e relatórios. 
 
Existem 7 etapas para a implementação do DW ou DM. Abaixo veremos cada uma: 
 
1. Levantamento das necessidades: devemos antes de tudo fazer o 
levantamento de todas as informações desejadas pelo usuário. Nesse primeiro 
momento, fazemos o cruzamento de Dimensões e Fatos necessários para 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 26 
alcançar os anseios dos gestores. Nesse primeiro momento, trabalhamos em O 
QUÊ o DW terá, e não O COMO. Por isso, não devemos nos preocupar com a 
existência efetiva dos dados e sim com os desejos requisitados; 
 
2. Mapeamento dos dados: nessa etapa, fazemos o mapeamento dos dados, 
identificando a fonte e como chegar até eles. Aqui vemos a viabilidade dos 
desejos elencados na primeira etapa, verificando a existência ou não dos dados 
para o alcance das necessidades solicitadas; 
 
3. Construção da Staging Area: após o mapeamento, construímos a estrutura 
chamada Staging Area, que se trata da área de transição dos dados do DW. 
Nessa área, os dados são copiados e desacoplados dos sistemas de operação 
(OLTP) e recebem o devido tratamento para as futuras cargas nas tabelas de 
Fatos e Dimensões; 
 
4. Construção das Dimensões: construímos nessa etapa a estrutura das 
Dimensões que farão parte do DW. Definimos também a historicidade que os 
dados irão possuir nas Dimensões; 
 
5. Construção do(s) Fato(s): construímos nessa etapa (após a construção das 
Dimensões) a(s) estrutura(s) do(s) Fato(s). Aqui é avaliado e definido a 
granularidade da informação que será armazenada em cada Fato. Avaliamos 
também a expectativa de crescimento e de armazenamento que serão 
utilizados; 
 
6. Definição do processo geral de carga: após concluirmos as etapas 
anteriores, precisamos criar o motor para que tudo seja carregado, atualizado, 
orquestrado e processado de forma automática e ordenada. Por isso, a 
necessidade do processo geral de carga que é o “cérebro” do DW; 
 
7. Criação dos metadados: por fim, precisamos desenvolver toda a 
documentação dos metadados, que incluem o processo de construção e o 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 27 
dicionário de dados. Os metadados fornecem apoio importante para a gestão 
do conhecimento. 
 
Lembrando que o Data Mart é a divisão do DW em subconjuntos de informações 
organizadas por assuntos específicos. Logo, todas essas etapas, com exceção do 
“levantamento das necessidades” (que deve ser realizada, preferencialmente, uma 
única vez), devem ser repetidas a cada novo Data Mart criado. 
 
Segue o fluxo do processo de construção, que pode ser cíclico até que todos os Data 
Marts sejam desenvolvidos: 
 
 
 
É importante respeitar a sequência dessas etapas, pois elas possuem dependência de 
término para início. Ou seja, a etapa sucessora só deve ser iniciada quando a sua 
predecessora for concluída. 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 28 
 
Por fim, com a devida atenção dada a cada uma dessas atividades, além da conclusão 
de cada uma delas com êxito, fará com que as chances de sucesso no projeto de 
construção do DW seja praticamente garantido. 
 
Dessa forma, teremos, efetivamente, um repositório que armazenará as informações 
que auxiliarão a organização na tomada de decisão. 
 
Veja todo o processo de construção do DW: 
 
 
 
 
Conclusão 
 
 
Conforme o que foi visto, podemos observar que, para o sucesso da base de dados 
Data Warehouse, a empresa precisa observar alguns requisitos, como, por exemplo, o 
fato do usuário desta base de dados dever ser ligado aos negócios da organização e 
ter capacidade de análise contextual da empresa, conhecer a ferramenta de acesso às 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 29 
informações para a criação de consultas necessárias a empresa, e ter tempo disponível 
para usar o Data Warehouse. 
 
Uma vez que a necessidade da empresa é identificada, estes usuários devem criar as 
consultas, extrair os dados, analisá-los e orientar a tomada de decisão. 
 
Quando se investe em um Data Warehouse é necessário verificar a disponibilidade dos 
usuários que irão trabalhar com a ferramenta a fim de gerar as vantagens para a 
empresa, pois um dado interpretado ou manipulado de maneira errada pode causar 
prejuízos para a mesma. 
 
A melhor forma de implementação da base de dados Data Warehouse na empresa é 
utilizando a estratégia Botton-Up, pois o custo é menor, além de ser mais fácil e ter 
um retorno de investimento rápido. 
 
Esta estratégia permite que os Data Marts sejam construídos antes que a infraestrutura 
do Data Warehouse seja definida, seu objetivo é a criação de Data Warehouse 
incremental a partir da criação de Data Marts independentes e integrados. 
 
A construção começa com o ETL para os Data Marts. Estes são modelados com base 
em um modelo dimensional. Essa implementação não possui um gerenciador que 
garanta os padrões únicos de metadados e isso se torna um ponto negativo. 
 
Quando a empresa escolhe a estratégia Botton-Up, cria-se então um banco de dados 
para uma área, pois os custos são menores que a implementação de um projeto de 
Data Warehouse completo. Quando os resultados começam a aparecer, então é dada 
sequência ao projeto nas outras áreas resultando em um Data Warehouse. 
 
Algumas vantagens são que a construção de Data Marts direcionados permite um 
rápido desenvolvimento, oferecendo um retorno rápido possibilitando, desta forma, 
uma base para investimentos adicionais com um nível mais elevado de confiança. 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 30 
Por serem elaborados inicialmente Data Marts com foco nos principais negócios da 
empresa, evita-se gastos desnecessários em áreas que não são essenciais ao 
problema. 
 
Outra vantagem é a redução de riscos, já que os Data Marts são criados de forma 
incremental permitindo assim um aprendizado e crescimento da equipe. 
 
Porém, é preciso tomar alguns cuidados na construção desses Data Marts 
independentes para não se tornarem um problema para o projeto, se não considerar 
a arquitetura de forma global quando estiver construindo os Data Marts, eles podem 
transformar-se em Data Marts legados. 
 
Outra questão é que é necessário manter um rígido controle do negócio como um todo 
quando se está construindo os Data Marts incrementais, este controle exige maior 
trabalho para extrair e combinar as fontes individuais do que utilizar um Data 
Warehouse. 
 
Outra desvantagem é que, como os Data Marts são construídos em paralelo, vai ser 
preciso uma rígida administração para coordenar esforços e recursos das diversas 
equipes. 
 
A utilização da base de dados Data Warehouse por si só não é garantia de vantagem 
competitiva para a organização, mas o que fará a diferença é a maneira como esta 
base de dados será utilizada. 
 
A principal vantagem que o Data Warehouse oferece é a consistência dos dados, que 
se dá devido aos modelos de dados para os Data Marts serem únicos, possibilitando, 
assim, o mapeamento e o controle dos dados. Outra questão é a congruência existente 
nas estratégias utilizadas no Data Warehouse e nos negócios. 
 
 
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 31 
Em um mercado altamente competitivo e de forte concorrência, as organizações 
sabem que informação é um recurso valioso. 
 
Porém, a dificuldade de acesso às informações estratégicas, enfrentada pelo alto 
escalão da maioria das organizações, é um paradoxo. O Data Warehouse, quando 
corretamente implementado, permite este acesso de forma satisfatória. 
 
BIBLIOGRAFIA 
 
ADAMSON, Christian. Star Schema. Mc Graw Hill, 2010. 
 
BARBALHO, P. Descubrao Data Warehouse: produtividade e rapidez. SQL Magazine. 
Rio de Janeiro, n. 03, 2003. 
 
BECKER, K; RUIZ, D. D.; SANTOS, K. MF-Retarget: Aggregate Awareness In: Multiple 
Fact Table Schema DataWarehouse. ADBIS Research Communications, p. 41 – 
51, 2002. 
 
BONOMO, Peeter. Arquitetura de Data Warehouse – Parte 1. Disponível em: 
<https://imasters.com.br/artigo/11417/gerencia-de-ti/arquitetura-de-data-
warehouse-parte-01/>. Acesso em: 13 abril 2018. 
 
______. Arquitetura de Data Warehouse – Parte 2. Disponível em: 
<https://imasters.com.br/artigo/11721/gerencia-de-ti/arquitetura-de-data-
warehouse-parte-02/?trace=1519021197&source=single> Acesso em: 13 abril 2018. 
 
FEINBERG, Donald. Data integration technology and architecture: building your 
data circulatory system. São Paulo: Gartner Enterprise Integration Summit, 2008. 
 
 
GONÇALVES, Rodrigo Ribeiro. Integração Integração de Dados na Prática. São 
Paulo: Erica, 2012. 
https://imasters.com.br/artigo/11417/gerencia-de-ti/arquitetura-de-data-warehouse-parte-01/
https://imasters.com.br/artigo/11417/gerencia-de-ti/arquitetura-de-data-warehouse-parte-01/
https://imasters.com.br/artigo/11721/gerencia-de-ti/arquitetura-de-data-warehouse-parte-02/?trace=1519021197&source=single
https://imasters.com.br/artigo/11721/gerencia-de-ti/arquitetura-de-data-warehouse-parte-02/?trace=1519021197&source=single
 
 
ARQUITETURA DE DATA WAREHOUSE E DATA MART 32 
 
INMON, William H.; HACKATHORN, Richard D. Como usar o Data Warehouse. Rio 
de Janeiro: Infobook, 1997. 
 
INMON, W. H. Building the Data Warehouse. Indianapolis: Wiley Publishi, 2012. 
 
KIMBALL, Ralph; ROSS, Margy. The Data Warehouse Toolkit. 2. ed. Rio de Janeiro: 
Ed. Campos, 2008. 
 
MACHADO, Felipe Nery Rodrigues. Tecnologia e Projeto de DW. São Paulo: Ed. 
Erica, 2014. 
 
METHANIAS, Colaço Jr. Projetando Sistemas de Apoio à Decisão Baseados em 
Data Warehouse. Rio de Janeiro: Axcel Books, 2004. 
 
MOREIRA, Eduardo. Modelo Dimensional para Data Warehouse. Disponível em: 
<https://imasters.com.br/artigo/3836/gerencia-de-ti/modelo-dimensional-para-data-
warehouse/?trace=1519021197&source=single>. Acesso em: 13 abril 2014. 
 
PITON, Rafael. Data Warehouse – O que é star schema? Disponível em: 
<https://rafaelpiton.com.br/data-warehouse-star-schema/>. Acesso em: 13 abril 
2018. 
 
RAGHU, R.; JOHANNES, G. Database Management Systems. 2. ed. Chicago: 
McGraw-Hill Higher Education, 2002. 
 
SINGH, S. Harry. Data Warehouse Conceitos, Tecnologias, Implementação e 
Gerenciamento. Makron Books, 2014. 
 
SOUZA, Michel de. BI: Data Marts. Disponível em: 
<https://imasters.com.br/artigo/1612/gerencia-de-ti/bi-data-
arts/?trace=1519021197&source=single>. Acesso em: 13 abril 2018. 
https://imasters.com.br/artigo/3836/gerencia-de-ti/modelo-dimensional-para-data-warehouse/?trace=1519021197&source=single
https://imasters.com.br/artigo/3836/gerencia-de-ti/modelo-dimensional-para-data-warehouse/?trace=1519021197&source=single
https://rafaelpiton.com.br/data-warehouse-star-schema/
https://imasters.com.br/artigo/1612/gerencia-de-ti/bi-data-arts/?trace=1519021197&source=single
https://imasters.com.br/artigo/1612/gerencia-de-ti/bi-data-arts/?trace=1519021197&source=single