Você está na página 1de 77

Arquitetura de Data Warehouse

Brasília-DF.
Elaboração

Kelli de Faria Cordeiro

Produção

Equipe Técnica de Avaliação, Revisão Linguística e Editoração


Sumário

APRESENTAÇÃO.................................................................................................................................. 5

ORGANIZAÇÃO DO CADERNO DE ESTUDOS E PESQUISA..................................................................... 6

INTRODUÇÃO.................................................................................................................................... 8

UNIDADE I
ARQUITETURA TÉCNICA........................................................................................................................... 9

CAPÍTULO 1
VISÃO GERAL DA ARQUITETURA............................................................................................... 10

CAPÍTULO 2
BACK ROOM.......................................................................................................................... 14

CAPÍTULO 3
FRONT ROOM........................................................................................................................ 18

UNIDADE II
FÁBRICA DE INFORMAÇÕES CORPORATIVAS........................................................................................ 26

CAPÍTULO 1
VISÃO GERAL.......................................................................................................................... 26

CAPÍTULO 2
COMPONENTES DO CIF.......................................................................................................... 29

UNIDADE III
DW 2.0................................................................................................................................................ 40

CAPÍTULO 1
VISÃO GERAL.......................................................................................................................... 41

CAPÍTULO 2
SETORES................................................................................................................................. 45

CAPÍTULO 3
COMPONENTES DO DW 2.0.................................................................................................... 52

UNIDADE IV
DATA MARTS E DW GLOBAIS................................................................................................................. 62

CAPÍTULO 1
DATA MARTS INDEPENDENTES X DEPENDENTES........................................................................ 62
CAPÍTULO 2
ABORDAGENS DE IMPLEMENTAÇÃO........................................................................................ 69

CAPÍTULO 3
DATA WAREHOUSE GLOBAL..................................................................................................... 72

PARA (NÃO) FINALIZAR...................................................................................................................... 75

REFERÊNCIAS................................................................................................................................... 77
Apresentação
Caro aluno

A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se entendem
necessários para o desenvolvimento do estudo com segurança e qualidade. Caracteriza-se pela
atualidade, dinâmica e pertinência de seu conteúdo, bem como pela interatividade e modernidade
de sua estrutura formal, adequadas à metodologia da Educação a Distância – EaD.

Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade dos conhecimentos
a serem oferecidos, possibilitando-lhe ampliar conceitos específicos da área e atuar de forma
competente e conscienciosa, como convém ao profissional que busca a formação continuada para
vencer os desafios que a evolução científico-tecnológica impõe ao mundo contemporâneo.

Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo a facilitar
sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na profissional. Utilize-a
como instrumento para seu sucesso na carreira.

Conselho Editorial

5
Organização do Caderno
de Estudos e Pesquisa
Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em capítulos, de
forma didática, objetiva e coerente. Eles serão abordados por meio de textos básicos, com questões
para reflexão, entre outros recursos editoriais que visam a tornar sua leitura mais agradável. Ao
final, serão indicadas, também, fontes de consulta, para aprofundar os estudos com leituras e
pesquisas complementares.

A seguir, uma breve descrição dos ícones utilizados na organização dos Cadernos de Estudos
e Pesquisa.

Provocação

Textos que buscam instigar o aluno a refletir sobre determinado assunto antes
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor
conteudista.

Para refletir

Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As
reflexões são o ponto de partida para a construção de suas conclusões.

Sugestão de estudo complementar

Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo,


discussões em fóruns ou encontros presenciais quando for o caso.

Praticando

Sugestão de atividades, no decorrer das leituras, com o objetivo didático de fortalecer


o processo de aprendizagem do aluno.

Atenção

Chamadas para alertar detalhes/tópicos importantes que contribuam para a


síntese/conclusão do assunto abordado.

6
Saiba mais

Informações complementares para elucidar a construção das sínteses/conclusões


sobre o assunto abordado.

Sintetizando

Trecho que busca resumir informações relevantes do conteúdo, facilitando o


entendimento pelo aluno sobre trechos mais complexos.

Exercício de fixação

Atividades que buscam reforçar a assimilação e fixação dos períodos que o autor/
conteudista achar mais relevante em relação a aprendizagem de seu módulo (não
há registro de menção).

Avaliação Final

Questionário com 10 questões objetivas, baseadas nos objetivos do curso,


que visam verificar a aprendizagem do curso (há registro de menção). É a única
atividade do curso que vale nota, ou seja, é a atividade que o aluno fará para saber
se pode ou não receber a certificação.

Para (não) finalizar

Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem


ou estimula ponderações complementares sobre o módulo estudado.

7
Introdução
Estamos vivendo a era da informação, na qual o conhecimento determina o sucesso dos mais
variados projetos em diversas áreas, domínios e seguimentos do mercado. Essa era começou há
décadas atrás, com o surgimento dos computadores e o desenvolvimento de sistemas de informação
que passaram a automatizar os processos de negócio dentro das empresas, gerando grandes volumes
de dados, persistindo todas as suas operações ao longo dos anos. A análise histórica desses dados
passou a ser um fator determinante na busca por diferencial competitivo no mercado.

Para transformar o enorme volume de dados disponível dentro das empresas em conhecimento
relevante para a gestão do negócio, é necessária a construção de um ambiente analítico. Este deve ser
composto por elementos que capturem os dados dos diversos sistemas de informação, transformem
e correlacionem uns com os outros agregando valor, e os apresentem em uma interface amigável
para o consumo analítico dos tomadores de decisão.

O ambiente que apoiará a tomada de decisão com inteligência, ou seja, baseado na análise quantitativa
de fatos, é o Data warehouse. Esse ambiente precisa de diversos elementos organizados e agrupados
para implementar o fluxo que os dados deverão seguir para serem transformados em conhecimento.
A organização dos componentes é realizada por meio de uma arquitetura que visa a facilitar a
comunicação entre os membros da equipe e o crescimento do ambiente, melhorando a sua gestão.

“Uma arquitetura:

» fornece planejamento, estrutura e padronização necessários para garantir


integração de vários componentes, projetos e processos ao longo do tempo; e

» estabelece framework, padrões e procedimentos para o Data warehouse


num nível corporativo.”
The Data Warehousing Institute <www.tdwi.org>

Ralph Kimball e Bill Inmon, considerados os inventores do Data warehouse, propuseram


arquiteturas, que evoluíram ao longo do tempo, para que um ambiente analítico possa ser construído
de forma otimizada e personalizada. Veremos cada uma dessas arquiteturas e abordagens que
compõem os fundamentos de um Data warehouse.

Objetivos:
»» Compreender a função de cada um dos componentes de um Data warehouse.

»» Promover a análise crítica sobre o uso e aplicação dos componentes de uma


arquitetura de Data warehouse.

»» Analisar as diferentes abordagens de implementação de um ambiente de Data


warehouse.

8
ARQUITETURA UNIDADE I
TÉCNICA

Imagine uma indústria em que a matéria-prima é o dado. Essa matéria-prima passará


por diversas fases de processamento até chegar ao produto final, o conhecimento.
O responsável por esta indústria deve arquitetar seus componentes para produzir
conhecimento valioso, com qualidade, de forma otimizada.

Nesta unidade, vamos conhecer a Arquitetura Técnica projetada por Ralph Kimball, considerado
um dos pais do Data warehouse (DW), ao lado de Bill Inmon. Descreveremos o fluxo que o dado
segue para ser transformado em conhecimento; os componentes da arquitetura utilizados por este
fluxo; e os elementos de apoio desta arquitetura.

Na era da informação, com a geração de grandes volumes de dados a cada instante,


quais são os componentes de uma arquitetura de informação necessários para
transformação de dado em informação, e de informação em conhecimento relevante
e com qualidade? Como esses componentes devem ser organizados? Deve existir
mais de um caminho para o processamento das informações? Todos os elementos
devem ser implementados juntos ou podem ser construídos gradativamente?

9
CAPÍTULO 1
Visão geral da arquitetura

No universo de Data warehouse e Business Intelligence, uma arquitetura é composta por diversos
elementos que, combinados entre si, visam a transformar dado em conhecimento para o apoio à
tomada de decisão.

O valor da arquitetura
Uma arquitetura possui um grandioso valor no contexto de um projeto de DW. Ela melhora a
comunicação entre os membros da equipe, além de apoiar o planejamento da sua implementação,
para que o DW alcance a maturidade para o qual foi projetado; descreve o fluxo de dados ao longo
do caminho; especifica as ferramentas e técnicas necessárias.

Enquanto requisitos de informação respondem “o que temos que fazer?”, a


arquitetura técnica responde “como vamos fazer isso?” (KIMBALL, 1998).

Os requisitos de negócio determinam o que o DW deve ser e quais são as suas prioridades. Uma boa
arquitetura aumenta a flexibilidade do sistema, facilita a manutenção, o aprendizado por meio da
sua documentação e aumenta a produtividade e reuso.

Back e front room


Ralph Kimball (2008) dividiu os componentes da Arquitetura Técnica em dois grandes grupos,
chamados de Back Room e Front Room. No Back Room, ou bastidores, os dados são tratados e
preparados para serem apresentados pelos componentes do Front Room, ou sala da frente.

Tal divisão e nomenclatura foram concebidas por Kimball quando ele estava em um restaurante o
qual lhe serviu um prato de comida ornamentado que chamou sua atenção. O prato possuía uma
bela aparência, ou seja, uma boa apresentação. Nesta ocasião, Kimball vislumbrou como aquele
prato havia sido preparado, quais foram as matérias-primas utilizadas, quais foram as técnicas e
instrumentos usados nos “bastidores”.

A partir dessa concepção, Kimball propôs a Arquitetura Técnica, ilustrada na figura a seguir, a qual
possui elementos de dois tipos distintos: dados e serviços.

»» Dados: são locais temporários ou permanentes para o dado. Podem ser chamados,
também, de repositório de dados ou banco de dados.

10
ARQUITETURA TÉCNICA │ UNIDADE I

»» Serviços: são funções necessárias para cumprir as tarefas requeridas de um DW,


como, por exemplo, copiar uma tabela de um lugar para outro. Esses serviços podem
ser implementados em pacotes de transformação de dados, chamados de ETL
(Extracting, Tranforming and Loading), ou por aplicações, chamadas de Olap (On
Line Analytical Processing) que visam a proporcionar interfaces amigáveis para a
apresentação dos dados processados e seu respectivo consumo pelos tomadores de
decisão.

Figura 1. Arquitetura Técnica – Visão Geral.

Fonte. Kimball (1998).

Fluxo dos dados


Em um ambiente de Data warehouse, os dados seguem um fluxo que parte dos sistemas de
informação usados como fonte de dados, e chegam até o computador dos usuários para serem
consumidos de forma analítica.

De um ponto de vista mais alto, o dado se move dos sistemas fonte para o Data Staging Area,
chamado de Área de Preparação de Dados, usando as aplicações fornecidas pela camada Data
Staging Services, chamada de Serviços de Preparação de Dados ou ETL.

11
UNIDADE I │ ARQUITETURA TÉCNICA

Figura 2: Fluxo dos Dados no Back room.

Fonte. Kimball (1998).

Este fluxo é guiado pelo metadado mantido no catálogo de metadados. Dados que descrevem as
localizações e definições das fontes de dados e dos alvos, as transformações do dado, temporalidade
e dependência.

Depois da integração e alinhamento do dado na Staging Area, os Data Staging Services são usados
para selecionar, agregar e reestruturar o dado em data sets ou conjunto de dados.

Os data sets são carregados nos servidores de apresentação e unidos via dimensões e fatos, que são
as especificações do Data warehouse Bus.

Todo dado acessado pelo usuário final, seja por uma ferramenta de consulta, por um gerador de
relatório ou por um software de modelagem, pertence a um Data Mart (DM), segundo a abordagem
do Kimball.

Alguns DM terão dados muito granulares e outros terão apenas dados agregados, mas, em qualquer
um dos casos, é essencial separar as questões do Data Staging dos dados de apresentação.

A área de staging não fornece serviços de consulta. Apenas os servidores de apresentação que
fornecem esses serviços.

Os dados dos servidores de apresentação são armazenados e apresentados no formato dimensional.

Figura 3. Fluxo dos dados no Front room.

Fonte: Kimball (1998).

12
ARQUITETURA TÉCNICA │ UNIDADE I

Os usuários ganham acesso ao dado por meio de ferramentas de acesso de desktop, que são
usualmente uma combinação de ações pré-definidas ou personalizadas, criadas via programação.
Essas ferramentas devem usar a vantagem dos serviços de suporte a consulta para ajudar a gerenciar
o logon, localizar o dado apropriado e coletar informação sobre uso e desempenho do sistema.

Algumas ferramentas de front-end são dotadas de serviços de suporte à consulta próprios. Esses
serviços podem ter diversos formatos, desde código do próprio cliente até produtos de DW fornecidos
por um fabricante.

O Servidor de Apresentação é o primeiro local em que o lógico e o físico tendem a se misturar.


Do ponto de vista do usuário, deve haver apenas um local para obter a informação. As linhas
pontilhadas, no Servidor de Apresentação, representam uma única visão lógica. Reparem: até o
momento, apenas fluxo lógico de dados. Os Servidores de Apresentação representam uma camada
de simplificação que permite o acesso a todos os DM pela comunidade de usuários.

Os Servidores de Apresentação podem ser criados de diversas maneiras, a mais comum é agrupar
fisicamente os dados em um único local físico. Se não for possível agrupar fisicamente os dados em
um único local, existem outras abordagens como middleware, servidores de aplicação, gateways,
metadado, tabelas físicas. Qualquer outra combinação pode fornecer uma camada de simplificação
para os usuários.

Características-chave
A Arquitetura Técnica proposta por Kimball (1998) possui duas características chaves: orientação
à metadados, ou “metadata driven”, e uso de camadas de serviços flexíveis. Todos os componentes
de uma arquitetura de DW devem ser descritos em um repositório ou catálogo compartilhado por
todos aqueles que interagem com o ambiente, desde os programadores até os usuários finais.

Por que camadas de aplicação adicionam flexibilidade à arquitetura?

Camadas de software abstraem detalhes de implementação.

Evolução da arquitetura de DW
O plano de uma arquitetura de DW evolui constantemente. Requisitos de negócio mudam, novos
dados são disponibilizados, e novas tecnologias são lançadas. A implementação inicial de uma
arquitetura vai cobrir apenas alguns componentes.

À medida que os produtos, plataformas e projetos são aprimorados ao longo do tempo, a


implementação física evolui e se aproxima do modelo lógico da arquitetura. A arquitetura evolui à
medida que se aprende mais sobre o negócio e sobre a tecnologia.

13
CAPÍTULO 2
Back room

Local em que o processo de preparação dos dados (data staging) é executado, ou seja, nos bastidores.
Nesse local, a preocupação primária dos DBAs (Data Base Administrator) e dos Administradores de
Sistemas, responsáveis pelo no back room, é resolver problemas específicos, como levar os dados
corretos de um local para outro com as transformações apropriadas, no momento apropriado. O
back room é formado por um subconjunto dos componentes da Arquitetura Técnica, conforme
ilustrado na figura a seguir.

Figura 4. Subconjuto dos Componentes da Arquitetura Técnica: Back room (Bastidores).

Fonte. Kimball (1998).

Pode ser um local temporário ou permanente para o dado ao longo do caminho. Os dados coletados
têm uma implicação direta na infraestrutura do DW, é necessário um local para armazená-los. A
maioria dos data store primários são encontrados no back room do DW, especialmente em projetos
de pequeno ou médio porte. Os data stores necessários dependem dos requisitos de negócio e da
complexidade do seu processo de extração e transformação. Descreveremos, a seguir, todos os
componentes do back room.

14
ARQUITETURA TÉCNICA │ UNIDADE I

Sistemas fonte
Os sistemas transacionais da empresa são as fontes mais evidentes de informações relevantes para
o negócio. Por outro lado, fontes de dados externas ao negócio podem ser de grande valia também.
Exemplos: informações demográficas do cliente, lista de clientes alvos, segmento comercial do
cliente, dados de competitividade de vendas.

O processo de preparação de dados é iterativo por natureza. A fonte para um processo de carga pode
ser outro data warehouse ou o próprio data warehouse.

Sistemas legados que podem ser fontes de dados, como: mainframes com arquivos flat contendo
textos. Relatórios gerados por processos batch. Se não for possível fazer engenharia reversa das
transformações de dados, então o próprio relatório será a fonte.

Arquivos flat file são fontes comuns para DW. Normalmente é mais fácil convencer as equipes dos
sistemas fontes a gerar arquivos flat como parte do seu processamento regular do que convencê-los
a dar acesso direto ao banco.

Arquivos do tipo flat file são flats, mas não significa que são simples!

Os modelos de dados dos sistemas fonte podem ser de vários tipos, hierárquicos, desnormalizados e
normalizados. Entender a natureza dos sistemas fonte é uma tarefa crítica na criação da arquitetura
do back room. As ferramentas, conexões e serviços dependem, em parte, de onde o dado vem e de
que forma ele vem. Exemplos clássicos de fontes de dados são: Sistemas ERP (Enterprise Resource
Planning), Reporting Instance e Operational Data Store (ODS).

Sistemas ERP
São sistemas tipicamente compostos de vários módulos que cobrem a maioria das principais áreas
funcionais do negócio, como recursos humanos, produção etc. Para um DW, é um problema!
Normalmente possuem milhares de tabelas e podem estar em outros idiomas, como alemão, por
exemplo. Grande desafio saber quais tabelas são interessantes e como elas se relacionam.

Tipicamente, esses sistemas não apoiam a tomada de decisão, visto que foram projetados para
processamento transacional. Têm que gerenciar muitos processos distribuídos complexos, e
raramente deixam ciclos livres para o suporte a decisão.

15
UNIDADE I │ ARQUITETURA TÉCNICA

As dificuldades do uso dos dados de um ERP são conhecidas pelos fabricantes. Vale
verificar se eles possuem ferramentas e serviços para extração de dados.

Temos que ter cuidado com ERP warehouses prontos oferecidos pelos fornecedores. Não podemos
esquecer-nos dos requisitos particulares do negócio, do projeto e da arquitetura do DW. Além disso,
eles, provavelmente, não são flexíveis o suficiente para armazenar todos os dados de outros sistemas
fonte ou para serem usados com outras ferramentas de consumo de informações.

A vantagem competitiva está na singularidade do negócio, logo não pode ser


padronizada.

Serviços de relatórios
A maioria dos clientes com sistemas transacionais ou sistemas legados acaba criando uma cópia
do banco de dados operacional para servir de ambiente para relatórios.  Isso acontece por que os
sistemas operativos não têm poder computacional suficiente para processamento transacional e
para relatórios.

Os Reporting Instance, ou Serviços de Relatórios, devem ser gerenciados como um componente


do ambiente operacional com níveis de serviços apropriados, com monitoramento, ajustes e
planejamento. É outra fonte de dados do ponto de vista do DW.

Operational Data Store (ODS)

O que é um ODS, afinal?

Em 1996, Bill Inmon, Claudia Imhoff e Greg Battas descreveram um ODS como um “armazém de
dados orientado a assunto, integrado, volátil, com valores de dados correntes contendo apenas
dados corporativos detalhados”.

Primeira interpretação: ambiente de fato operacional, fontes em tempo real para balanços, históricos
e consultas detalhadas. Em muitos casos, servem para relações diretas com clientes (um-para-um).
Uma vez que esses ODS apoiam constantes acessos e atualizações operacionais, eles devem ser
mantidos fora do warehouse.

16
ARQUITETURA TÉCNICA │ UNIDADE I

Segunda interpretação: ambiente para fornecer dados correntes e detalhados para apoiar a decisão.
À medida que o DW amadurece, há uma crescente demanda de análise cada vez mais detalhada,
com uma textura cada vez mais operacional.

De acordo com Kimball (1998), a primeira interpretação é um componente importante do ambiente


operacional, e a segunda é simplesmente uma parte do DW.

Cuidado: estruturas implementadas para atender as necessidades operacionais,


normalmente não atendem as necessidades de suporte à decisão.

Dúvidas sobre onde situar ODS?

Examine o seu propósito.

Se seu propósito é atuar com um papel operacional e em tempo real, seu lugar é no ambiente
operativo. Se seu propósito é prover relatórios e funcionalidades para apoio à tomada de decisão,
ele deve ser integrado no warehouse no nível mais atômico.

Um ODS deve ser construído?

Se a empresa não precisa armazenar todas as transações detalhadamente, visto que o alto nível de
gerência olha apenas resumos de alto nível, então não é necessário um ODS. Se a empresa precisa
saber os detalhes das transações, tanto correntes como históricas, é necessário um ODS.

Data staging area


É a área de construção do DW. É o local em que é feita a maior parte das transformações no dado e
em que é criada a maior parte dos valores agregados ao dado do DW. Local para fazer mapeamentos
entre as diversas fontes de dados, trabalhando com chaves alternativas, chamadas de chaves
surrogadas.

Se você tiver uma Staging Area sólida, servindo às mais variadas transformações, evitará que o
processo de negócio invista em decifrar os sistemas fonte e executem os mesmos cálculos repetidas
vezes por diferentes equipes e sistemas de suporte à decisão.

17
CAPÍTULO 3
Front room

O Front room, ou sala da frente, é a face pública do DW. É o que os usuários de negócio podem
ver. Para muitos usuários, a interface é o DW. Eles não sabem ou não se preocupam com o tempo,
energia e recursos por trás disso.

Importante para os usuários de negócio: respostas!

Porém, os dados para essas respostas são dados complexos.

O objetivo primário do warehouse deve ser tornar a informação o mais acessível possível, para
ajudar as pessoas a obterem a informação que precisam. Para atingir esse objetivo, deve-se construir
uma camada entre o usuário e a informação, para esconder algumas complexidades de acesso para
o usuário. O subconjunto dos componentes da Arquitetura Técnica que formam o Front room está
ilustrado na figura a seguir.

Figura 5. Subconjunto dos componentes da Arquitetura Técnica: Front room.

Fonte. Kimball (1998).

Quem se beneficia com Front room?

18
ARQUITETURA TÉCNICA │ UNIDADE I

Os principais beneficiários com o Front room são:

»» desenvolvedores de aplicações para os usuários finais;

»» avaliadores de ferramentas de mercado para acesso ao dado;

»» gerente de projeto, para interagir eficientemente com os vendedores de ferramentas


e gerenciar as expectativas da comunidade do negócio.

Aplicações de acesso ao dado


O acesso ao dado no Front room é realizado por meio de aplicações que, em alguns casos, podem ter
repositório de dados locais para processamento extra. Algumas dessas aplicações são:

»» Ferramentas de relatórios padronizados: desenvolvidas para acesso aos mainframes.


Usualmente, tiram vantagem de acesso ao warehouse como fonte de dados primária.
Podem ter múltiplos data stores, incluindo banco de dados construídos a partir do
warehouse e dos sistemas operacionais. Também podem ter um “cache” para os
relatórios. Atualmente, diversos fabricantes de software produzem serviços de geração
de relatórios, chamados Reporting Tools, que permitem a criação de relatórios pelos
usuários, o desenvolvimento de relatórios parametrizáveis ou pré-definidos.

»» Ferramentas de acesso: à medida que o dado se move para o Front room e fica mais
próximo do usuário, ele se torna mais difundido, popular. Usuários podem gerar
centenas de consultas e relatórios ad hoc por dia. Essas ferramentas são chamadas de
ferramentas Olap. Normalmente, essas consultas focam alguma questão específica.
Exemplo: investigação de uma anomalia do negócio, ou análise de impacto de uma
promoção de vendas. Algumas ferramentas trabalham com seus próprios servidores
de aplicação, que podem ter um banco de dados para funcionar como “cache” dos
resultados das consultas e relatórios padrões. Essa “cache” pode melhorar o tempo
de resposta. As ferramentas de acesso evoluíram da arquitetura cliente/servidor
para a arquitetura Web. Ou seja, os dados do DW podem ser acessados via browser
de um computador, notebook, e até mesmo de um tablet. Para este último, algumas
ferramentas são construídas de forma a serem acessadas diretamente, sem a
necessidade de browser, fazendo uso de diversas funcionalidades com interface
altamente amigável para análise de indicadores, como os Dashboards.

»» Aplicação de Modelos: dados usados para aplicação de técnicas de processamento


analítico para descoberta do conhecimento. Normalmente, residem em máquinas
separadas com seu próprio data store. Usam os dados do data warehouse para
fazer cálculos, que podem alimentar algum atributo de alguma dimensão. Exemplo:
Nível de crédito.

»» Sistemas downstreaming: à medida que o DW se torna a principal fonte de dados


para análise e relatórios, os sistemas passam a serem projetados tendo o DW como

19
UNIDADE I │ ARQUITETURA TÉCNICA

fonte de dados. O propósito básico desses sistemas é produzir relatórios, mas tendem
a se aproximar dos dados operacionais. Apesar de esses sistemas serem tipicamente
orientados a transações, eles ganham um valor significativo por incluírem algum
dado histórico do DW. Exemplo: média de custos de ligações em um ano.

Outro tipo de aplicação que usa os dados do DW é aquele que apoia a interação com o cliente.
Sistemas de vendas e suporte ao cliente (Call Center). Esses sistemas são construídos com base em
um DW, mas são produzidos em ambientes separados.

Serviço de acesso ao dado


Principais motivadores para a transferência do serviço de acesso ao dado do front-end para uma
camada de aplicação: poder de compra do mercado de DW e demanda por ferramentas baseada na
Web, fazendo com que os fabricantes deixem os suas ferramentas cliente mais leves, movendo as
funcionalidades de compartilhamento para os servidores de aplicação.

O mais indicado é que os serviços de acesso ao dado sejam independentes de ferramentas. Esses
serviços devem ser implementados à medida que os requisitos são definidos. Devem cobrir cinco
principais tipos de atividades:

»» navegação pelo warehouse ou metadados;

»» acesso e segurança;

»» atividade de monitoramento;

»» gerenciamento de query;

»» reporting padrão.

Gerenciamento de consultas

Conjunto de funcionalidades que gerencia a troca entre a formulação da consulta, a execução da


consulta no banco e o retorno do resultado. Dentre seus serviços, estes devem ser executados:
simplificação de conteúdo para mostrar ao usuário só o que será importante para ele e reformulação
da consulta para uma melhor execução.

Existem três principais opções de onde os serviços de consultas podem ser localizados:

»» no desktop do usuário final;

»» no servidor de aplicação;

»» no banco de dados.

Verificar soluções com os fabricantes para definir a melhor localização do


gerenciamento de consultas.

O hardware para armazenamento de dados tem evoluído muito nos últimos anos!

20
ARQUITETURA TÉCNICA │ UNIDADE I

Navegação pelo warehouse

Atividade que usa o catálogo de metadado para apoiar o usuário na busca de informação. Deve ter
uma ligação dinâmica com o catálogo de metadados para mostrar os assuntos (subjects) disponíveis
e seus elementos de dados. Deve ser capaz de recuperar as definições e derivações dos vários
elementos de dados.

Dotar um DW de serviços de navegação nem sempre é a prioridade de um projeto de DW. Normalmente,


as ferramentas de front-end têm sido o início e o final do processo de navegação. À medida que elas
ficam mais sofisticadas, usam metadados para definir subconjuntos de dados e simplificar a visão do
usuário. Podem prover meios para o usuário acessar as descrições das tabelas e colunas.

Acesso e segurança

É recomendado que cada usuário tenha a sua identificação própria. Apesar de dar mais trabalho,
isso ajuda a rastrear o uso do DW e identificar necessidades individuais. Além de identificar os
usuários, é necessário determinar o que eles podem ver. Depende da cultura da empresa. Exemplo:
os gerentes regionais podem ver apenas os dados de vendas da sua região.

Serviços de monitoramento de atividade

Envolve a captura de informação sobre o uso do DW.

Por que monitorar a atividade do DW?

O uso do DW deve ser monitorado para verificar aspectos como:

»» desempenho;

»» suporte ao usuário para verificar se os recém-treinados estão conseguindo fazer o


que querem;

»» marketing para os patrocinadores do projeto de DW;

»» planejamento para o crescimento.

Como todos os serviços das outras camadas da arquitetura, implementar conforme


a demanda!

21
UNIDADE I │ ARQUITETURA TÉCNICA

Serviço de relatórios

Frequentemente, as análises que são desenvolvidas de forma ad hoc se tornam relatórios padrões.
Disponibilizá-los em um ambiente de relatórios passa a ser um requisito. Com isso, os requisitos de
ferramentas de relatórios são:

»» ambiente de desenvolvimento;

»» servidor de execução;

»» parametrizável;

»» execução agendada baseada em eventos ou no tempo.

Serviços de desktop
Apenas alguns serviços residem no desktop dos usuários, mas eles são os mais importantes. São
encontrados nas ferramentas de front-end dos usuários que provêm o acesso ao dado no warehouse.
A qualidade da experiência do usuário com o DW será determinada por como essas ferramentas
atendem a necessidade do usuário.

Ao projetar serviços para os usuários finais, você deve considerar:

»» Diferentes tipos de usuários:

›› os que só manipulam papéis;.


›› os que só pressionam botões;
›› os que elaboram relatórios ad hoc simples;
›› os que fazem consultas complexas.

»» Diferentes necessidades de dados;

»» Diferentes tipos de necessidades;

»» Monitoramento de alto nível:

›› métricas;

»» Acompanhamento do negócio:

›› vendas, produtos, clientes;


›› navegação para o detalhe;

»» Investigação:

›› exceções, novos problemas ou oportunidades.

»» Análises complexas:

›› análises estatísticas.

22
ARQUITETURA TÉCNICA │ UNIDADE I

Existem diferentes ferramentas para atender diferentes necessidades e de acordo com a habilidade
do usuário no uso do computador, conforme sintetizado no quadro a seguir.

Quadro 1. Diferentes formas de acesso ao DW.

Área de atuação Papéis Botões Ad hoc simples Avançados


Email, algum editor de Editores de texto, planilhas
Uso do computador Nenhum. Macros.
texto. eletrônicas e apresentações.
Depende de Relatórios padrão, uso Consultas simples, alteração de Consultas completas e acesso
Uso do DW
outros. de parâmetros default. parâmetros, navegação. direto ao banco.

Fonte. Kimball (1998).

Infraestrutura
Provê a base para todos os elementos da arquitetura técnica do DW. É composta pelo hardware,
rede, equipamentos de segurança etc. Muitos fabricantes determinam a infraestrutura apropriada
para uma determinada implementação, e muitos deles não são necessariamente técnicos.

O arquiteto de DW normalmente não é especialista em infraestrutura.

Melhor estratégia: trabalhar próximo aos especialistas de infraestrutura da empresa.

A plataforma de hardware deve ser adequada ao tamanho do DW e a sua maturidade. Observe a


figura a seguir, que representa o crescimento de um ambiente de DW ao longo de sua evolução e
expansão da sua abrangência.

Figura 6. Crescimento da Infraestrutura da Arquitetura de DW.

Fonte. Kimball (1998).

Se prepare para o crescimento!

23
UNIDADE I │ ARQUITETURA TÉCNICA

A definição da infraestrutura do back room deve considerar alguns fatores, como, por exemplo:

»» tamanho do dado;

»» volatilidade;

»» número de usuários;

»» número de processos de negócio;

»» natureza do uso;

»» recursos financeiros;

A definição da infraestrutura do front room deve considerar alguns fatores, como, por exemplo:

»» configurações dos servidores de aplicação: memória, disco, plataforma;

»» configurações dos desktops: sistema operacional, ferramentas baseadas na web,


memória;

»» fatores de rede e conectividade: largura de banda, acesso remoto, transferência de


arquivos.

Catálogo de metadados

O que são metadados?

É um tópico interessante do mundo DW. Quando não se sabe exatamente o que são metadados e
onde estão, muito tempo é gasto discutindo sobre ele, se preocupando com ele, se sentindo culpado
por não estar fazendo nada sobre ele. Dizer que é “dado sobre dado” não ajuda muito. Com o tempo,
essas questões vão se clareando.

“Qualquer informação que serve para responder quem, o que, quando, onde, por
que e como cada pedaço de informação está documentado em uma organização e
como esse conhecimento pode ser reusado” (THANGARATHINAM, et al., 2004).

Os metadados do back room estão relacionados ao processo, guia a extração, limpeza e carga
dos dados. Já os metadados do front room são mais descritivos, ajudam as funcionalidades das
ferramentas de consulta e de relatórios. Metadados de processo e descritivos possuem sobreposições,
porém é interessante pensar neles separadamente.

24
ARQUITETURA TÉCNICA │ UNIDADE I

Para conhecer mais detalhes sobre a Arquitetura Técnica do Kimball, acesse o site do
seu grupo: http://www.kimballgroup.com/

Preencha as figuras a seguir com os componentes da Arquitetura Técnica do Ralph Kimball.

Preencha o quadro abaixo com as diferentes formas de acesso pelo usuário final de
acordo com a sua habilidade de uso do computador.

Quadro 1. Diferentes formas de acesso ao DW.

Área de atuação Papéis Botões Ad hoc simples Avançados


Editores de texto,
Email, algum
Uso do computador Nenhum. planilhas eletrônicas e Macros.
editor de texto.
apresentações.

Uso do DW

25
FÁBRICA DE
INFORMAÇÕES UNIDADE II
CORPORATIVAS
Sorte a nossa sermos contemporâneos de duas grandes mentes, altamente ativas,
Kimball e Inmon, que trabalham em função de transformar dados corporativos em
conhecimento relevante. Cada um possui uma visão autêntica e particular. Com o
passar do tempo, as discussões polêmicas resultaram em abordagens inteligentes
e complementares.

Nós, analistas de Business Intelligence, somos os maiores beneficiários desse duelo!

Nesta unidade, vamos conhecer o CIF (Corporate Information Factory), ou Fábrica de Informações
Corporativas, proposta por Bill Inmon. Descreveremos todos os componentes desta Arquitetura de
DW, que, em muitos pontos, complementam ou contrapõem a abordagem do Ralph Kimball.

Bill Inmon, criador do CIF, possui uma visão curiosa sobre as informações: elas fazem
parte de um ecossistema.

Tendo em mente os ecossistemas encontrados na natureza, o que você entende por


ecossistema de informação?

CAPÍTULO 1
Visão geral

Ecossistema de informação
Também chamado de Information Ecosystem, é um sistema com diferentes componentes, cada um
servindo a uma comunidade, que trabalham em conjunto para produzir um ambiente de informação
coeso e balanceado. Assim como na natureza, um ecossistema de informação deve ser adaptável,
balanceado e permitir mudanças. O CIF (Corporate Information Factory) é a implementação física
de um ecossistema de informação (INMON, 2000).

As principais características de um CIF são:

»» Genérico na sua estrutura: fácil de percebê-lo em diferentes empresas.

26
FÁBRICA DE INFORMAÇÕES CORPORATIVAS │ UNIDADE II

»» Único para cada empresa: é formatado pelo negócio, cultura, política, economia e
tecnologia de cada empresa.

Fluxo de dados do CIF


O dado entra no CIF de forma detalhada e bruta (raw), como é coletado das aplicações ou sistemas
de informação fontes. Eles são refinados pelas aplicações e, então, passados para os programas
da camada que integra e transforma os dados funcionais em dados corporativos. O dado passa da
camada de integração e transformação para o ODS e para o DW.

O DW pode ser alimentado com dados tanto da camada de integração quanto do ODS. Depois que
o dado passa pelo DW, o dado é acessado, analisado e transformado em informação para diferentes
propósitos.

A arquitetura e o fluxo de dados do CIF são muito similares a uma fábrica comum. O dado bruto
e a matéria-prima entram na fábrica e são imediatamente processados. As linhas de montagem
transformam a matéria-prima em produtos. Diversos produtos são produzidos. Alguns produtos
são completamente acabados e outros servirão de matéria-prima para outras linhas de montagem.

Arquitetura
A arquitetura do CIF é formada pelos seguintes elementos, ilustrados na figura abaixo e descritos
no capítulo a seguir.

»» Mundo externo;

»» Aplicações;

»» Operational Data Store (ODS);

»» Camada de Integração e Transformação;

»» Data warehouse (DW);

»» Data Mart (DM);

»» Internet/Intranet;

»» Metadado;

»» DW de exploração e mineração de dados;

»» Armazém de dados alternativo;

»» Sistemas de Suporte à Decisão;

»» Dados externos.

27
UNIDADE II │ FÁBRICA DE INFORMAÇÕES CORPORATIVAS

Figura 7. Componentes do CIF.

Fonte. (Inmon, 2000).

28
CAPÍTULO 2
Componentes do CIF

Mundo externo
É o início e o fim do CIF, local em que as transações do negócio ocorrem. Sem o comércio do mundo
externo, não haveria um CIF.

Cuidado para não focar na tecnologia e outros aspectos do CIF, e esquecer-se do


mundo externo.

No mundo externo, ou seja, no mundo real, encontramos os produtores de transações. As transações


são registradas por meio de sistemas de informação desenvolvidos e acessados dentro da empresa
ou sistemas de comércio eletrônico disponíveis na Internet, que são aplicações que automatizam
os processos do negócio. As características das informações encontradas nessas aplicações são:
detalhada ou resumida, grande ou pequena, estruturada ou não estruturada.

Além dos produtores de informações, encontramos, também no mundo externo, os consumidores


de informação. São os gestores do negócio responsáveis por tomar decisões no nível operacional,
tático ou estratégico.

Produtores e consumidores de informação fazem parte de um sistema complexo


que se adaptam e evoluem a partir das suas próprias interações.

Consumidores de informação tomam decisões baseadas nestas que podem


influenciar nas novas transações do negócio e, com isso, gerar novas informações
que irão apoiar novas tomadas de decisão, formando um ciclo.

29
UNIDADE II │ FÁBRICA DE INFORMAÇÕES CORPORATIVAS

Figura 8. Mundo Externo.

Fonte: Inmon (2000).

Aplicações
É o componente em que os dados transacionais são produzidos. Historicamente, as aplicações não
são integradas. Depois de construídas e em produção, são difíceis de serem integradas. Por isso a
necessidade de um Data warehouse, para agregar valor às informações produzidas isoladamente
com o cruzamento entre elas. Neste ambiente, tempo de resposta é uma questão importante, visto
que as transações do negócio dependem do seu bom desempenho.

No CIF, o dado deixa a camada de aplicação e entra na camada de integração e transformação.


Selecionar a aplicação que será a fonte de dados é uma decisão importante, representa a melhor
informação, não necessariamente o dado perfeito.

Dados externos
Como outras partes do CIF, as aplicações fazem uso de dados externos e metadados. Apoiam
requisições detalhadas no nível mais granular. Tipicamente é criado e coletado de outras empresas.
Pode ser de qualquer tipo ou volume, estruturado ou não, detalhado ou resumido.

Dados internos podem ser manipulados, alterados, remodelados, mas os dados externos não podem.
As fontes de dados externos estão além do CIF, então use do jeito que está ou não use, exceto quando
há mudança de chaves de identificação.

O metadado do dado externo rastreia o caminho do dado, de onde ele vem, como ele está sendo
usado e para onde o dado está indo.

30
FÁBRICA DE INFORMAÇÕES CORPORATIVAS │ UNIDADE II

Camada de integração e transformação


Diferentemente do DW, ODS e DM que são compostos essencialmente de dados, a Camada de
Integração é composta de programas. Esse conjunto de programas tem como função de capturar,
transformar e mover os dados do ambiente das aplicações para o ODS e DW.

É o local em que os dados das aplicações produzidos de forma isolada são combinados, ou integrados,
e transformados em dados corporativos.

A camada de integração e transformação possui uma interface instável, pois as aplicações estão
constantemente mudando. Por isso, o DW é construído incrementalmente e iterativamente. A figura
a seguir ilustra a complexidade desta camada.
Figura 9. Camada de integração e transformação.

Fonte: Inmon (2000).

As atividades da camada de integração e transformação, muito influenciada pelo modelo de dados,


são:

»» tratamento de chaves;

»» reestruturação do layout dos dados;

»» merge de dados;

»» agregação de dados;

»» resumo de dados.

31
UNIDADE II │ FÁBRICA DE INFORMAÇÕES CORPORATIVAS

ODS
É uma coleção de dados detalhados que satisfazem necessidades coletivas, integradas e operacionais
da empresa. Normalmente, essas necessidades surgem nas seguintes situações:

»» à medida que decisões estratégicas são tomadas com base no DW e DM;

»» à medida que relatórios operacionais integrados são necessários através de múltiplos


sistemas operacionais.

Segundo Inmon (2000), as características do ODS são:

»» orientado a assunto;

»» integrado;

»» volátil;

»» valor corrente; e

»» detalhado.

A diferença do tipo de dado e do processamento faz com que o ODS tenha um ambiente físico
separado do DW.

ODS x DW
»» Orientado a assunto e Integrado: como no DW.

»» Volatilidade:

›› ODS: Volátil. Pode ser atualizado como parte de um processamento normal.

›› DW: Não volátil. Não pode ser atualizado, contém snapshots; um novo snapshot
é criado sempre que uma mudança precisa ser refletida no DW

»» Valor corrente:

›› ODS: normalmente contém dados do dia, da semana e até do mês, mas o dado
envelhece muito rápido.

›› DW: contém grandes volumes de dados históricos, pode ser de 5 a 10 anos

»» Detalhado:

›› ODS: contém apenas dado detalhado;

32
FÁBRICA DE INFORMAÇÕES CORPORATIVAS │ UNIDADE II

›› DW: contém dados detalhados e resumidos.

Classes do ODS
»» Classe I:

›› Existe uma interface síncrona.

›› O tempo decorrido entre a execução da transação na aplicação e seu reflexo no


ODS é muito pequeno (<1s).

›› Nesta classe, o trabalho a ser feito com os dados é muito pouco, pois
simplesmente não há tempo para fazer muito. A transação passa para o ODS
muito rapidamente, e o usuário final nem percebe que o intervalo de tempo entre
a transação operacional e o reflexo no ODS.

»» Classe II:

›› O intervalo de tempo entre a execução da transação e seu reflexo no ODS é de 1


a 2 horas.

›› A camada de Integração e Transformação tem tempo para fazer integrações.

›› O usuário nota uma pequena diferença entre os dados das aplicações operacionais
e o dado do ODS.

»» Classe III:

›› O intervalo de tempo entre a execução da transação e seu reflexo no ODS é de 12


a 24 horas.

›› É um processo batch noturno, podem-se integrar tantos dados quanto se queira.

›› O usuário pode definitivamente notar uma diferença entre os valores de dados


do ambiente operacional, e os dados do ODS.

»» Classe IV:

›› O dado entra no ODS diretamente do DW. Neste caso, o dado é lido e analisado
no DW e as derivações são passadas para o ODS. Derivações típicas passam para
o ODS incluindo segmentos de clientes e seus “scores”.

›› Esta classe é importante por que é nela que o tempo de resposta on-line pode ser
obtido ao acessar dados derivados de um DW.

33
UNIDADE II │ FÁBRICA DE INFORMAÇÕES CORPORATIVAS

Determinando a classe do ODS


Muitas implicações tecnológicas da intranet devem ser consideradas:

»» velocidade da movimentação do dado para o ODS;

»» volume de dados que deve ser movido;

»» volume de dados que deve ser armazenado em locais intermediários durante o


processamento de integração e transformação;

»» a hora do dia em que a movimentação dos dados tem que ocorrer.

Outras considerações:

»» A escolha de qual classe de ODS será criada, deve ser a primeira, e a decisão mais
importante do arquiteto.

»» O custo de desenvolvimento e operação da Classe I é o mais alto.

»» Se integração é primordial, então uma Classe I não é uma boa escolha, por que
quase nenhuma integração pode ser obtida com ela.

»» Por isso, deve haver uma boa justificativa de negócio para a Classe I.

»» Normalmente, as Classes II, III e IV servem a maioria das necessidades de


processamento das empresas.

Virtual Operational Data Store (VODS)


Consultas podem ser criadas sem nenhuma infraestrutura de apoio. Os dados residem nos sistemas
fonte. Só é possível por causa do avanço da tecnologia. Não há necessidade de construir um banco de
dados, DW, DM, nem metadado. Atrativos do VODS: flexibilidade e velocidade extrema na criação
e execução das consultas. Ótimo apenas para alguns tipos de consultas: são executadas apenas uma
vez; e não podem ser executadas em nenhum outro lugar.

O VODS pode obter dados de praticamente qualquer lugar: Sistemas fonte, ETL, Setor Integrado
entre outros. A figura a seguir ilustra o VODS na arquitetura do DW 2.0 proposto por Inmon e
detalhado na Unidade a seguir.

34
FÁBRICA DE INFORMAÇÕES CORPORATIVAS │ UNIDADE II

Figura 10. VODS no DW 2.0.

Fonte: Inmon (2008).

O processamento do VODS é realizado em um servidor de aplicação. É necessário um disco rígido


para armazenar os dados coletados. Uma requisição é enviada pela rede para encontrar os dados
necessários. Assim que são encontrados, os dados são enviados para o servidor de aplicação, pela
rede. Assim que a consulta é liberada, o disco e outros recursos também são liberados.

DW
É uma estrutura arquitetural que apoia o gerenciamento do dado que é orientado a assunto;
integrado; variante no tempo; não volátil e composto tanto de dados detalhados e resumidos.

Orientado a assunto
O DW é organizado de acordo com as principais entidades da organização: clientes, produtos,
vendedores, transações, pedidos, contabilidade, entregas. O DW não é orientado a aplicação ou
funcionalidades. Isso permite a mudança do dado ao longo do tempo sem, fundamentalmente,
afetar sua organização ou estrutura. Questão crucial, dado o grande volume de dados históricos que
são gerenciados em um DW.

Integrado
Refere-se à unificação física e coesa dos dados à medida que ele é armazenado num warehouse.
A integração cobre muitos aspectos do warehouse, incluindo estrutura de dados, codificação e
decodificação de estruturas, definição de dados, layout, relacionamento de dados, convenção de
nomeação.

Integração de dados no DW não é atingida meramente copiando dado do ambiente operacional. Ao


invés disso, à medida que o dado bruto (raw) passa pela camada de Integração e Transformação ele
é alterado para atingir a integração do DW.

35
UNIDADE II │ FÁBRICA DE INFORMAÇÕES CORPORATIVAS

Variante no tempo
Qualquer registro no ambiente de DW é relativo a algum momento no tempo. Uma forma de acomodar
a variação do tempo é por meio da criação de snapshots. Muitas vezes, o DW é considerado como
uma coleção massiva de snapshots. Cada snapshot tem um momento no tempo no qual o registro
está “sem defeito” (accurated). A variação no tempo no DW aparece como um elemento de tempo
na estrutura de chave, podendo ser um dia, um ano ou um mês.

Não volátil
Refere-se ao fato de que atualização (qualquer alteração de um registro) normalmente não ocorre
no DW, salvo exceções. Quando mudanças ocorrem e precisam ser levadas para o DW, as mudanças
são capturadas na forma de snapshots variáveis no tempo. Um novo snapshot é adicionado no DW
para refletir a mudança, ao invés de ocorrer uma atualização.

Composto tanto de dados detalhados e resumidos


»» Detalhados: reflete o nível atômico de transações. Inclui dado que descreve o uso do
produto, atividade contábil, movimento de estoque, vendas etc.

»» Resumidos:

›› Profile Record: exemplo: fornecedor, varejista, seguradora, instituições


financeiras.

›› Public Summary: calculado departalmente, mas tem visibilidade corporativa.


Exemplo: posição contábil da empresa no quadrimestre.

Qual é a diferença entre um ODS e um DW?

Data mart
É uma coleção de dados talhados para as necessidades do processamento de suporte a decisão de
um departamento. Segundo Inmon (2000), é um subconjunto do DW que foi personalizado para
atender as necessidades do departamento, mas pode ser usado por mais de um departamento.

Tipicamente, o dado é desnormalizado, selecionado e resumido quando passa do DW para o DM.


A estrutura do projeto físico do data mart é conhecida como esquema estrela. Organiza o dado
facilitando a sua navegação e visualização.

36
FÁBRICA DE INFORMAÇÕES CORPORATIVAS │ UNIDADE II

Exploration e data mining


Para entender a necessidade do exploration warehouse, considere a situação do administrador do
DW quando se depara com uma imensa consulta, com horas de processamento. Uma solução é criar
um warehouse fisicamente separado do DW, dedicado exclusivamente para o processamento de
exploração.

Exploração x Mineração
»» A exploração é livre para examinar e testar grande faixa de possibilidades. O
explorador busca padrões de dados e formula hipóteses e assertivas sobre o porquê
de o padrão existir.

»» O minerador testa a validade das hipóteses e assertivas. São atividades distintas,


porém altamente inter-relacionadas.

Store alternativo
Permite manter grandes volumes de dados detalhados e históricos no warehouse de forma
eficiente com um custo acessível. À medida que os dados não estão sendo utilizados no DW, eles
são movimentados para um armazém de dados alternativo. Para isso é necessário um serviço de
monitoramento. A figura a seguir ilustra a utilização de um Store alternativo.

Figura 11. Store Alternativo.

Fonte: Inmon (2000).

Inter/intranet
Os componentes do CIF não são “stand alone”, ou seja, não estão isolados. Eles passam dados um
para o outro via uma estrutura de comunicação, inter/intranet. A figura a seguir ilustra a localização
da inter/intranet em uma arquitetura de DW.

37
UNIDADE II │ FÁBRICA DE INFORMAÇÕES CORPORATIVAS

Figura 12. Inter/Intranet.

Fonte: Inmon (2000).

Metadado
Informações sobre o dado necessário para a sua administração e uso. Exemplos:

»» Layout dos dados: Nome-Cliente varchar(45).

»» Conteúdo: existem 150.000 transações X na tabela Y.

»» Índices: tabela X tem índices nas colunas A, B e C.

»» Periodicidade de atualização: a tabela X é atualizada toda terça às 2 horas da manhã.

»» Uso: apenas duas das dez colunas da tabela X foram usadas nos últimos seis meses.

»» Integridade referencial: tabela A se relaciona com B pela chave C.

»» Documentação genérica: a tabela A foi projetada em 1975 como parte do novo


sistema de contabilidade.

Para obter mais informações sobre o CIF, acesse o site do Bill Inmon: http://www.
inmoncif.com

Preencha o quadro abaixo com as características do ODS e do DW.

Característica ODS DW
Volatilidade [sim|não]

Idade do dado [dia|mês|ano]

Tipo de dados [detalhado|resumido]

38
FÁBRICA DE INFORMAÇÕES CORPORATIVAS │ UNIDADE II

Preencha corretamente os itens abaixo:

DW é uma estrutura arquitetural que apoia o gerenciamento do dado que é:

Quais são as diferenças e semelhanças entre a Arquitetura Técnica do Kimball e o CIF


do Inmon?

39
DW 2.0 UNIDADE III

O mundo moderno gera informações a todo instante, não apenas via sistemas
de informação, mas também por e-mails, relatórios e mensagens instantâneas.
Informações valiosas podem ser encontradas no crescente volume desses tipos de
dados, chamados não estruturados ou textuais.

Nesta unidade, vamos conhecer o DW 2.0, também proposto por Bill Inmon, como a segunda
geração de Data warehouse. Descreveremos seus principais aspectos e diferenciais em relação à
primeira geração de DW; os setores e componentes da arquitetura.

Como os dados não estruturados podem complementar as análises sobre os


dados estruturados? Quais são os componentes arquiteturais necessários para essa
exploração conjunta?

40
CAPÍTULO 1
Visão geral

O DW 2.0 é composto por elementos de dados de duas diferentes naturezas: estruturada e não
estruturada, que estão distribuídos ao longo de quatro setores de acordo com a sua idade. O dado
nasce no setor interativo e, à medida que envelhece, passa para o setor seguinte, até chegar ao
setor no qual os dados são arquivados. Os dados permanecem no setor de arquivo muitas vezes por
questões jurídicas. A figura a seguir ilustra os componentes de dados estruturados e não estruturados
do DW 2.0 e seu ciclo de vida. As seções a seguir detalham os principais aspectos e características
desta arquitetura proposta por Bill Inmon.

Figura 13. Visão Geral da Arquitetura do DW 2.0.

Fonte: adaptada de Inmon (2008).

Principais aspectos

Setores
O DW 2.0 possui quatro setores: Setor Interativo, Setor Integrado, Setor Near Line e Setor Arquivo.
Os dados são distribuídos entre os setores de acordo com a sua idade. A idade do dado é definida

41
UNIDADE III │ DW 2.0

de acordo com a probabilidade de acesso ao dado e a necessidade de velocidade de acesso. Dessa


forma, quando o dado é pouco acessado em um setor, este é migrado para o setor seguinte.

Cada um dos setores do DW 2.0 possui tecnologias de armazenamento e processamento diferenciadas.


Os setores com dados mais novos são equipados com tecnologias mais velozes e consequentemente
mais caras. Por isso, apenas o dado com alta frequência de acesso deve permanecer nesses setores.

Mudança dos dados


»» Geralmente os dados passam intactos de um setor para o outro, exceto:

»» quando o dado da aplicação passa para o Setor Integrado, ele deve ser integrado;

»» quando o dado passa para o Setor Arquivo, ele pode ser consideravelmente
transformado.

Volume de dados
»» Os setores do DW 2.0 possuem diferentes volumes de dados e, portanto, possuem
diferentes tecnologias de armazenamento. A figura a seguir ilustra cada um dos
setores e seu respectivo volume de dados.

»» Interativo: poucos dados.

»» Integrado: mais dados.

»» Near Line: muitos dados.

»» Arquivo: grande volume de dados.

Figura 14. Volume de dados.

Fonte: Inmon (2008).

42
DW 2.0 │ UNIDADE III

As tecnologias de armazenamento de dados evoluíram muito nos últimos anos, de


forma que grandes equipamentos de storage foram projetados para contemplar
diferentes tecnologias com diferentes velocidades e gerenciar o seu uso de acordo
com a frequência de acesso aos dados.

Vale conferir o que os grandes fabricantes, como HP, IBM, Oracle, EMC têm de novidade no
momento!

Vantagens da arquitetura do DW 2.0


»» Mantém os dados no nível mais baixo de detalhe.

»» Mantém os dados infinitamente.

»» Alto desempenho no processamento de transações.

»» Relaciona dados estruturados e dados não estruturados.

»» Metadados fortemente acoplados ao ambiente do DW.

»» Trata diferentes tipos de processamento sem sacrificar o tempo de resposta.

»» Trata mudanças no dado através do tempo.

Gerações do DW – primeira x segunda


A primeira geração de Data warehouse e a segunda geração, chamada de DW 2.0 por Inmon,
possuem diferenças significativas de acordo com alguns critérios, conforme descrito a seguir.

Ciclo de vida do dado


As características do dado mudam à medida que envelhecem.

»» No DW 2.0: os dados são divididos em setores baseado na sua idade.

»» Na primeira geração: não havia tal distinção.

Dado não estruturado


Algumas das informações mais valiosas da empresa residem em dados não estruturados. Ex.: e-mail,
planilhas, documentos etc.

»» No DW 2.0: dados não estruturados são tratados.

»» A primeira geração: não reconhece que há dado valioso no ambiente não estruturado.

43
UNIDADE III │ DW 2.0

Metadados
No DW 2.0, metadado faz parte da arquitetura. É a cola que mantém o dado junto por todos os seus
diferentes estados. Na primeira geração: metadado foi omitido como parte da sua infraestrutura.

Quadro 2. Principais características das duas gerações de DW.

DW DW 2.0
Não volátil Setores (Ciclo de Vida)
Histórico Dado não estruturado
Orientado a assunto Metadado

Integrado

Fonte: o próprio autor.

DW 2.0 é uma marca registrada. Ninguém, além dos autores, pode alterar a
arquitetura. Empresas que desenvolvem um DW 2.0 ganham um certificado!

44
CAPÍTULO 2
Setores

Figura 15. Setores do DW 2.0.

Fonte: o próprio autor.

Setor interativo
Local em que ocorre processamento de alto desempenho do DW. Processamento on-line. Quase
o mesmo tempo de resposta do OLTP. Dados passíveis de atualização. Baseado em transações ou
processamento batch. Ex.: análises realizadas às 9h15 da manhã podem ter resultados diferentes
das análises realizadas às 20h. Ocasionalmente, os dados carregados não estão integrados e serão
utilizados pelo Setor Integrado.

»» Poucos dados disponíveis.

»» Poucos dados históricos.

»» Pouca ou quase nenhuma análise estatística.

»» Consultas tendem a ser pequenas.

Assim que o dado passou do “ponto”, ou seja, não é o mais atual, ou não é mais atualizável, ele é
transferido para o Setor Integrado. Dado Atual ou Atualizável é o dado que reflete a última transação,
ainda não chegou ao nível de granularidade mínima, é alterada a cada nova transação. Exemplos:

»» Dado atualizável: total de vendas até o momento.

»» Dado não atualizável: total de vendas do dia.

Os dados desse Setor estão corretos apenas no momento do acesso. Os dados residem em discos
rígidos. O padrão de acesso é randômico.

45
UNIDADE III │ DW 2.0

Setor integrado
Local em que os dados integrados são armazenados. Fontes primárias de dados:

»» Setor interativo:

›› dados que não serão mais atualizados.

»» Ambiente operacional:

›› os dados podem ir direto para o Setor Integrado sem passar pelo Setor Interativo!

A integração dos dados ocorre por meio de um ETL (Extract, Transform and Load). Os dados são
divididos em duas partes, armazenadas fisicamente separadas:

»» Dados correntes integrados:

›› Dado granular, serve de base para a maioria das análises e dos vários processos.

›› Normalmente usado indiretamente, atendendo as necessidades de diferentes


data marts, relatórios, aplicações DSS etc.

›› Ocasionalmente os dados são acessados diretamente para a execução de análises


que não podem ser realizadas em nenhum outro lugar.

»» Dados analíticos ativos:

›› usado para processamento estatístico previamente conhecido;

›› utilizado quando a empresa faz processamento estatístico regularmente.

Os dados do Setor Integrado são integrados! As duas partes (dados correntes integrados e dados
analíticos ativos) devem ser integradas, nem que seja no nível mais baixo, utilizando estruturas de
chaves. Os dados estão reduzidos ao formato granular. Permite que os dados sejam modelados e
remodelados de acordo com as necessidades de diferentes usuários. Com isso, podem ser resumidos,
agregados e reestruturados. A figura a seguir ilustra as diferentes operações que podem ser feitas
com os dados deste setor.

Figura 16. Setor Integrado

Fonte: Inmon (2008).

46
DW 2.0 │ UNIDADE III

Os dados do Setor Integrado possuem alta probabilidade de acesso e são usados como fonte para
diversas aplicações analíticas. O acesso varia de acordo com a idade do dado: dados correntes
integrados: um mês a 36 meses; dados analíticos ativos: faixa de idade randômica.

A atividade no setor deve ser monitorada!

»» Quais tabelas estão sendo acessadas?

»» Quais linhas estão sendo acessadas?

»» Quais colunas estão sendo acessadas?

Com essas respostas, o administrador pode determinar o inverso:

»» Quais tabelas não estão sendo acessadas?

»» Quais linhas não estão sendo acessadas?

»» Quais colunas não estão sendo acessadas?

Essas informações permitem o entendimento das características de uso dos dados. Determina a
probabilidade de acesso e, com isso, quais dados devem migrar para o setor seguinte.

Figura 17. Movimento dos Dados no Setor Integrado via Monitoramento.

Fonte: Inmon (2008).

A probabilidade de acesso ao dado determina qual dado irá ficar e qual dado não irá ficar no Setor
Integrado. Determina qual dado sairá da parte de dados correntes integrados e irá para a parte de
dados analíticos ativos.

A estrutura dos dados desse setor é formada por snapshots de dados. Por isso nenhuma atualização
é realizada, conforme ilustrado na figura a seguir.

47
UNIDADE III │ DW 2.0

Figura 18. Snapshot de dados do Setor Integrado.

Fonte: Inmon (2008).

Diferentemente das consultas do Setor Interativo, as consultas do Setor Integrado tendem a ser
uniformemente grandes. E não há variação de dado ao longo do tempo, ou seja, a análise executada
diretamente no Setor Integrado tem o mesmo resultado pela manhã e pela noite.

Setor near line


Local em que é armazenado o dado com baixa probabilidade de acesso. É alimentado exclusivamente
pelo Setor Integrado. Os dados com baixa probabilidade de acesso e/ou dados velhos são transferidos
para o Setor Near Line. Dispositivos nearline são tipos de equipamentos intermediários que se
situam entre dispositivos on-line, como os discos rígidos que estão disponíveis para acesso imediato, e
dispositivos off-line, como as fitas de backup. O formato dos dados deste setor é mantido para que, caso
seja necessário, o dado possa ser movido de volta ao Setor Integrado de forma rápida e transparente.

Assim que o dado é transferido para o Setor Near Line, metadados são criados. É uma atividade
essencial. Mostra onde estão os diferentes tipos de dados. Permite futura recuperação de dados.
É desejável que se crie, também, índices que dizem qual o conteúdo que está dentro do dado. Sem
metadados, o Setor Near Line se torna uma lata de lixo.

Figura 19. Dados no setor arquivo sem metadados não são úteis.

Fonte: Inmon (2008).

Os metadados devem conter:

»» Itens clássicos:

›› nome da tabela;

›› atributos;

›› características físicas;

48
DW 2.0 │ UNIDADE III

»» Itens não padronizados:

›› data em que o dado foi carregado no setor;

›› data representada pelo dado;

›› quantidade de dados carregados;

›› valores codificados;

›› tabelas de referência utilizadas;

›› fonte de dados.

Existem diversos meios para transferir os dados para o Setor Near Line:

»» Simples: cópia dos dados diretamente. Fácil recarga no setor Integrado.

»» Reestruturado: divide o dado em diferentes tabelas (split table).

Os dois meios podem ser empregados criando dados redundantes, pois o custo de armazenamento
desse setor é baixo.

Regra: os dados desse setor devem ser organizados, no mínimo, pelo nível mais alto
de data, normalmente, ano.

Figura 20. Organização dos dados do Setor Arquivo por Ano.

Fonte: Inmon (2008).

Há um frequente movimento de dados entre o Setor Integrado e o Near Line. O Setor Near Line
torna-se uma extensão do Setor Integrado, sua cache de dados. Deve haver uma consistência no
formato dos dados em nível de registro e de campo.

Figura 21. Movimento dos dados entre os Setores Integrados e Near Line.

Setor Integrado

Setor Near Line


Fonte: Inmon (2008).

49
UNIDADE III │ DW 2.0

Há queda de desempenho na execução da consulta que precisa de dados do Setor


Near Line?

Sim! Porém esse movimento não deve ser frequente, uma vez que o dado foi transferido para o Setor
Near Line por ter baixa probabilidade de acesso. Os dados são armazenados em dispositivos near
line, não em disco!

Os dados são armazenados no formato de snapshots, como no Setor Integrado. Os índices podem
ser criados a qualquer momento, chamados de índices passivos e podem ser criados enquanto
o ambiente Near Line não está sendo usado. Normalmente, o Setor Near Line tem seu próprio
ambiente separado.

Setor arquivo
Local em que é armazenado o dado com probabilidade muito baixa de acesso. Todos os dados do
Setor Arquivo vieram do Setor Near Line. A probabilidade de acesso é quase nula. Em muitos casos,
são armazenados por motivos legais.

Figura 22. Motivo da existência do Setor Arquivo.

Fonte: Inmon (2008).

Os meios de armazenamento desses dados são muito baratos. São armazenados por 10, 20 ou
mais anos. Como a maioria dos dados é relativa ao tempo, os dados são armazenados por ano,
normalmente.

Figura 23. Dados do Setor Arquivo organizados por Ano.

Fonte: Inmon (2008).

50
DW 2.0 │ UNIDADE III

O metadado é um componente muito importante do Setor Arquivo!

O metadado funciona como um guia do conteúdo do Setor Arquivo. Sem os metadados, o Setor
Arquivo torna-se uma via de apenas uma mão. Com os metadados, o ambiente Arquivo pode ser
pesquisado de maneira razoavelmente eficiente. Sem eles, arquivos inteiros terão de ser lidos.
São armazenados como parte do Setor de Arquivo. Os dados e seus metadados não podem estar
armazenados separadamente.

Figura 24. Sem metadados os dados são lidos em uma única direção.

Fonte: Inmon (2008).

Os dados do Setor Arquivo podem alimentar qualquer Setor do DW 2.0: Interativo, Integrado e
Near Line.

Figura 25. Movimento dos dados do Setor Arquivo para outros Setores.

Fonte: Inmon (2008).

51
CAPÍTULO 3
Componentes do DW 2.0

O DW 2.0 possui componentes de duas diferentes naturezas: estruturados, provenientes de banco


de dados, planilhas e flatfiles, e não estruturados, provenientes de arquivos com conteúdo textual
como e-mails e chats. As seções a seguir detalham cada um desses componentes.

Componentes de dados estruturados

Dado de aplicação
Pertence ao Setor Interativo. Local de geração de dados por meio de transações. Requer: tempo de
resposta muito rápido (2/3s) e alta disponibilidade. Normalmente não é integrado. Normalmente
é relacionado a transações. É permitida a atualização de valores de dados, assim como inserção e
criação.

Repare!

Todos os setores possuem os mesmos tipos de componentes, exceto o Setor


Interativo.

Área de dados de assuntos detalhados


É o dado detalhado do ambiente transacional que foi integrado e está organizado por assunto,
como vendas, compras, marketing, contabilidade etc. A maior parte desses dados é oriunda das
transações persistidas nos sistemas de informação que automatizam os processos do negócio. É o
coração do DW. São dados oriundos das aplicações que são integrados para prover conhecimento
novo. Uma vez que esse dado foi capturado para dentro do DW 2.0, ele se torna a base para as
operações de Business Intelligence. O dado deste componente é tão granular que pode ser modelado
e remodelado de diferentes maneiras para atender a diferentes necessidades analíticas.

Essa área acomoda dados financeiros, vendas, marketing, engenharia, recursos humanos, contábil.
Normalmente encontrada no formato relacional, cada registro possui um timestamp, ou seja, possui
um atributo temporal. Este componente é chamado de Fatos e Dimensões por Kimball (1998).

Dado resumido
Também chamada de Snapshot por Kimball (1998), é o dado muito detalhado que foi resumido para
entrar no DW. É gerado por um gerenciador de granularidade. Alguns dados chegam ao DW em um
nível de granularidade muito baixo, por exemplo, dados de clickstream (sequência de clicks em um

52
DW 2.0 │ UNIDADE III

site). Enquanto a maioria dos dados é detalhada no DW 2.0, há um lugar para dados resumidos. É
apropriado quando o resumo é amplamente usado por toda a empresa.

Quando o dado resumido é criado, é sábio incluir as regras de agregação:

»» qual dado foi incluído;

»» qual dado foi excluído;

»» como o cálculo foi feito.

Dado de snapshots contínuos


São séries de registros de dados relacionados, em que um registro é logicamente relacionado a outro.
Não há sobreposição lógica, mas há a possibilidade de gaps de descontinuidades. Os elementos de
dados que estão contidos nessa estrutura são, normalmente, poucos e mudam lentamente.

Dado de snapshots contínuos é o dado que é interligado por uma série de dados from/to. A ligação é
lógica, não física. São úteis quando existem poucas variáveis que demoram a mudar. Pode ser criada
uma definição contínua do dado. Exemplo típico: nome e endereço de cliente. Também chamada de
Slowly Change Dimension por Kimball (1998).

Figura 26. Dado de snapshots contínuos.

From ---- To
From ---- To
From ---- To

Fonte: Inmon (2008).

Dado Profile
É um dado composto que foi coletado de uma variedade de fontes. Registros típicos profiles são de
clientes. É o dado que foi integrado ou amalgamado de diversas fontes. Outras fontes podem ser
resumidas antes de entrar o registro profile. Por exemplo, o registro composto de cliente pode ter
originado de várias fontes:

»» compras do cliente;

»» pagamentos do cliente;

»» navegação da internet do cliente;

»» dados demográficos do cliente.

Tudo pode ser reunido no registro profile do cliente.

53
UNIDADE III │ DW 2.0

Figura 27. Composição de um Dado Profile.

Fonte: Inmon (2008).

Componentes de dados não estruturados

Textual subjects
São as diferentes categorias de informações ao redor do qual o “dado texto” é relacionado. São
aqueles assuntos pelos quais o texto do ambiente não estruturado é organizado. As categorias
podem ser internas ou externas, ou ambas. Podem ser gerados internamente ou externamente pela
criação de taxonomias.

Texto capturado
É o texto capturado de e-mails, documentos, transcrições de conversas telefônicas etc., originados
no ambiente não estruturado que são relevantes para o ambiente de negócio. Não faz sentido colocar
uma massa grande de dados não estruturados dentro do DW 2.0 a menos que sejam importantes
para a representação do negócio no DW 2.0. Por isso o texto não estruturado que encontra o seu
caminho para o DW 2.0 foi previamente editado e limpo para passar para o DW 2.0.

Linkage
É uma ligação de duas vias entre o identificador do texto capturado e a chave do dado da transação
do ambiente estruturado. Típicos links podem ser formados por meio de endereços de e-mail e
números de telefone. O dado textual é mais útil quando está ligado a uma transação clássica ou a
um dado estruturado. É por meio deste componente que as análises sobre os dados estruturados são
enriquecidas com os dados não estruturados, e permite também a navegação entre esses ambientes.

Outros links podem ser formados por meio de nomes e mutações dos nomes. Note que alguns dados
textuais não terão ligações, mas serão relevantes para o negócio da empresa.

Dado master (mestre) ou referência


É o dado que é referenciado por diversos setores e sistemas da empresa, como as siglas e nomes de
produtos e serviços. Quando o dado de referência é aplicado por meio de toda a empresa, ele pode
ser chamado de dado Master.

54
DW 2.0 │ UNIDADE III

Ponteiros textuais simples


São referências que apontam para dados não estruturados com baixa prioridade de interesse, dados
que não pertencem ao ambiente do DW 2.0, porém precisam ser referenciados.

Em certas ocasiões, alguns dados não estruturados são úteis e interessantes, por isso devem ser
contemplados. Existe a possibilidade de encontrar informações valiosas no ambiente de dados
não estruturado. Os dados não estruturados são acessados indiretamente por meio dos ponteiros
textuais, para consultas eventuais sobre algum detalhe do fato que está sendo analisado.

Metadados
São um dos componentes mais importantes, atuando como o sistema nervoso do DW 2.0. Descrevem
o que há dentro do DW 2.0 e como os dados e componentes estão relacionados. Segundo Bill Inmon,
sem os metadados, o dado no DW 2.0 seria uma grande pilha de dados essencialmente inúteis.

Diferentes tipos de metadados são encontrados no DW 2.0:

»» metadados de negócio locais;

»» metadados técnicos locais;

»» metadados corporativos.

Metadado local
Refere-se ao metadado encontrado em um determinado componente:

»» na ferramenta de BI;

»» no diretório do SGBD;

»» em uma planilha;

»» em um relatório;

»» em uma tela;

»» em um dicionário de dados.

Em cada um desses casos, há uma tecnologia ou até mesmo uma única instância de uma tecnologia
em que o metadado está contido. Se o metadado precisa ser adicionado ou modificado, isso é feito
dentro da tecnologia que o contém. Ou seja, o metadado local vive em uma existência totalmente
autocontida. Qualquer unidade de metadado local desconhece a existência de vários outros
metadados com os quais ele precisa se relacionar. Por isso é chamado de “local”.

55
UNIDADE III │ DW 2.0

Dentro dessa categoria de metadados, há o metadado de negócio e o metadado técnico.

»» Metadados de negócio: é o metadado que contém o texto que é significativo e útil


para a pessoa de negócio.

›› Metadados técnicos: é o metadado que contém o texto útil para e de interesse do


técnico.

Como os metadados locais podem ser compartilhados por toda a empresa?

Repositório de metadados corporativos


Há metadados locais permeando toda tecnologia e ferramentas encontradas no DW 2.0. Mas há a
necessidade de integrar os metadados locais. Essa necessidade é suprida pelo estabelecimento de
um grande repositório de metadados corporativo. É uma tecnologia que abrange todos os metadados
locais e que os reúne em um só local. Uma vez em um único local, o repositório permite que os
metadados locais sejam integrados. Note que esse local não é onde o dado é criado ou atualizado,
é onde o dado é enviado ao repositório de diferentes fontes locais. O metadado local e corporativo
reflete uma estrutura maior de metadados, conforme ilustrado na figura a seguir.

Figura 28. Repositório de Metadados Corporativos.

Fonte: Inmon (2008).

Exploration Warehouse (EDW)


Exploração de dados envolve duas atividades distintas e inter-relacionadas: observação e criação
de hipóteses com teste de veracidade. Ambas requerem o uso de técnicas de mineração de dados
que possui em sua base as teorias estatísticas. Essas atividades normalmente fazem uso de grande
volume de dados para a descoberta de padrões nos dados e consequente inferência de tendências.

56
DW 2.0 │ UNIDADE III

A exploração de dados envolve acesso a grande volume de dados que geram


contenções no banco de dados.

Como esse problema pode ser resolvido?

Solução: isolar o processamento estatístico, ou seja, criar um ambiente separado, com dados
oriundos dos diversos setores do DW 2.0, em que os algoritmos de mineração e predição podem ser
executados sem comprometer o desempenho das análises do DW.

Figura 29. Exploração no DW 2.0.

Fonte: Inmon (2008)

Implementação

Como os componentes do DW 2.0 estão interligados?

57
UNIDADE III │ DW 2.0

Figura 30. Interligação entre os componentes do DW 2.0.

Fonte: Inmon (2008).

Como os dados dos diversos componentes do DW 2.0 são acessados?

Mesmo sem interligação os componentes podem ser acessados diretamente!

Figura 31. Acesso aos dados do DW 2.0.

Fonte: adaptada de Inmon (2008).

Os componentes do DW 2.0 devem ser usados conforme a necessidade do negócio!

58
DW 2.0 │ UNIDADE III

Exemplo de aplicação

Questão analítica

Considere:

A empresa WebSales vende produtos pela internet e mantém um canal de comunicação com seus
clientes por meio de e-mails.

A Gerente de Negócios deseja analisar suas vendas e o relacionamento com seus clientes.

»» Como os dados não estruturados contidos nos e-mails podem ajudar nas análises?

»» Qual é a percepção de qualidade dos clientes sobre os nossos produtos e serviços?

Exemplos de dados não estruturados:

Figura 32: Exemplos de dados não estruturados.

Fonte: Inmon (2008).

Modelo de dados

A partir das questões analíticas e das fontes de dados estruturados e não estruturados, o modelo
de dados ilustrado na figura a seguir foi elaborado com elementos de dados da primeira e segunda
geração de DW.

59
UNIDADE III │ DW 2.0

Figura 33. Modelo de Dados dos componentes da primeira e segunda geração do DW.

Fonte: o próprio autor.

Aplicação

Com a base de dados carregada e a aplicação desenvolvida, diversas análises foram feitas, como
ilustrada na figura abaixo e descritas a seguir:

Figura 34. Exemplo de consulta analítica.

Fonte: o próprio autor.

»» As reclamações diminuíram e os elogios aumentaram, isso é bom, mas ainda não


está em um nível aceitável de qualidade.

»» A equipe de WebDesinger melhorou muito o nosso site, a quantidade de solicitações


de informações caiu pela metade!

60
DW 2.0 │ UNIDADE III

Compare as duas figuras a seguir e identifique os componentes em comum nas duas


arquiteturas.

Figura 35. CIF.

Fonte: Inmon (2000).

Figura 36. Arquitetura do DW 2.0.

Fonte: Inmon (2008).

61
DATA MARTS E DW UNIDADE IV
GLOBAIS

Nesta unidade serão descritas e analisadas as diversas formas de implementação de Data Marts
seguido da apresentação conceitual de um DW Global.

Por onde começar a implementação de um Data warehouse?

O que fazer caso já exista diversos Data warehouses espalhados pelas diversas filiais
de uma empresa?

CAPÍTULO 1
Data Marts independentes x
dependentes

Data mart
Segundo Bill Inmon, é uma coleção de fatos (Subject Areas) organizada para apoiar a tomada de
decisão, baseada nas necessidades de um determinado Departamento. Exemplos: Marketing,
Financeiro, Vendas etc. Cada departamento é dono do seu hardware, software, dados e programas
do Data Mart. Consequência: não existe controle ou disciplina para coordenar os dados encontrados
nos diferentes departamentos. Cada departamento possui a sua própria interpretação do que um
data mart deve ser.

Tipicamente, usa um esquema estrela. O nível de granularidade e os dados históricos são definidos
para atender às necessidades do Departamento. Podem ser de dois tipos:

»» Dependentes: fonte é o Data warehouse:

›› Logo: todos possuem a mesma fonte de dados.

›› Possuem estrutura e arquitetura mais consistentes.

»» Independentes: fonte é o Ambiente Transacional (OLTP):

62
DATA MARTS E DW GLOBAIS │ UNIDADE IV

›› Logo: diversas fontes de dados para cada Data Mart.

›› Estrutura e arquitetura heterogêneas.

›› Os problemas e deficiências surgem apenas quando múltiplos Data Marts


Independentes são construídos.

Data marts independentes


São DM construídos diretamente das aplicações transacionais. Podem ser construídos por um
Departamento sem a consideração de outros Departamentos ou sem a consideração de um órgão de
TI centralizado. Não há a necessidade de pensar globalmente.

Representam um subconjunto dos requisitos do sistema de suporte à decisão de uma empresa. Sua
construção é relativamente barata e permite que uma organização tenha em mãos o destino das
informações. Essas são algumas das razões que tornam os DM Independentes populares.

Analisar as consequências da construção de vários DM Independentes!

Figura 37. Data Marts Independentes.

Fonte: Inmon (2008).

Ao construir o primeiro Data Mart, o usuário final fica satisfeito. A análise dos dados é personalizada.
Há uma nova perspectiva sobre o dado.

Os usuários questionam qual é a grande crítica aos DM Independentes. De fato, não existe problema
algum em um único DM Independente.

63
UNIDADE IV │ DATA MARTS E DW GLOBAIS

O primeiro DM é um sucesso!

Figura 38. Primeiro DM.

Fonte: Inmon (2008).

O segundo também é u,m sucesso, mas algumas pessoas notam que as respostas para questões
similares não estão coerentes.

Figura 39. Segundo DM.

Fonte: Inmon (2008).

O terceiro DM Independente é adicionado. Agora, existem três opiniões sobre tudo. Alguns
dados detalhados aparecem toda vez que um novo DM é adicionado, ou seja, aumenta o nível de
redundância dos dados.

64
DATA MARTS E DW GLOBAIS │ UNIDADE IV

Figura 40. Terceiro DM.

Fonte: Inmon (2008)

O quarto DM é adicionado. Mais uma verdade sobre o dado que não pode ser correlacionada com
nenhuma outra opinião. Mais dados detalhados são coletados, mais redundância. Mais programas
de extração, transformação e carga precisam ser construídos e mantidos.

Figura 41. Quarto DM.

Fonte: Inmon (2008).

Agora, o setor de Engenharia também quer um DM. Tudo deve ser construído do zero, pois não há
documentação, nem histórico, nem coordenação para integração.

65
UNIDADE IV │ DATA MARTS E DW GLOBAIS

Figura 42. Quarto DM integrado a Engenharia.

Fonte: Inmon (2008).

O primeiro Data Mart Independente é um sucesso, mas não podemos dizer o mesmo
do terceiro em diante, por causa das inconsistências, redundâncias e retrabalho.

Problemas dos Data Marts independentes:

»» não provêm uma plataforma para reutilização;

»» não provêm a base para reconciliação de dados;

»» não provêm a base para um único conjunto de programas de ETL;

»» requerem que todo DM crie seu próprio conjunto de dados detalhados, ou


seja, redundância.

Qual é a solução para o problema dos DM Independentes?

Data Marts Dependentes. Oposto dos DM Independentes. São construídos a partir dos dados vindos
do DW. Não dependem dos dados do ambiente transacional. Requerem investimento. Necessário
que alguém pense globalmente.

66
DATA MARTS E DW GLOBAIS │ UNIDADE IV

Data marts dependentes


Requer múltiplos usuários para extrair seus requisitos de informação para a criação do DW. Ou seja,
requer planejamento prévio, perspectiva de longo prazo, análise global, cooperação e coordenação
na definição dos requisitos entre os diferentes departamentos da empresa.

Figura 43. DM Dependentes.

Fonte: Inmon (2008).

Figura 44. Visão Global do DW com DM Dependentes.

Fonte: Inmon (2008).

DM Independentes representam uma solução de curto prazo e escopo limitado. DM


Dependentes, por outro lado, requerem uma perspectiva global e de longo prazo.

67
UNIDADE IV │ DATA MARTS E DW GLOBAIS

DM x DW

Data Marts: um substituto para o DW?

De uma perspectiva imediata, é possível obter benefícios de um Data Mart sem o alto custo e
investimento de um DW. Porém, de uma perspectiva de longo prazo, um Data Mart nunca será um
substituto para o DW, segund=o Bill Inmon.

Figura 45. DW e DM no mesmo ambiente.

Fonte: Inmon (2008)

A estrutura do dado encontrado em um Data Mart é modelado para um conjunto particular de


requisitos. Por causa dessas diferenças na estrutura dos dados para cada Data Mart, fazer de um
DM um DW não faz sentido. A estrutura de dados de DM, normalmente, não é reutilizável por meio
da corporação e não está pronta para atender a novos requisitos, mas o dado granular do DW sim.

Observar a evolução da abordagem do Inmon ao longo do tempo!

68
CAPÍTULO 2
Abordagens de implementação

Existem diferentes abordagens de implementação de um Data warehouse:

»» Top-down;

»» Botton-up;

»» Combinada/Híbrida;

»» Federada.

Fatores que influenciam na opção por um tipo de abordagem:

»» infraestrutura de TI;

»» arquitetura;

»» escopo;

»» recursos disponíveis;

»» necessidade de acesso corporativo;

»» ROI;

»» tempo para implementação.

Top-down
Nesta abordagem, primeiro o DW é construído, depois o DM. Requer maior planejamento e trabalho
nas definições conceituais e na seleção das fontes de dados.

»» Vantagens:

›› herança de arquitetura: todos os DM utilizam a arquitetura e os dados do DW;

›› visão do negócio: o DW concentra todas as áreas de negócio da empresa;

›› repositório de metadados corporativo: os mesmos metadados são compartilhados


por toda a empresa;

›› ETL Centralizado: conjunto único de aplicações para extração, limpeza e


integração dos dados.

»» Desvantagens:

›› maior tempo para implementação: primeiros resultados demoram a aparecer;

›› dificuldade para manter o apoio político e financeiro;

›› alto risco;

69
UNIDADE IV │ DATA MARTS E DW GLOBAIS

›› necessidade de administrar as expectativas;

›› necessidade de equipe com bom nível de maturidade: as decisões de projeto


tomadas na fase de concepção afetará o desenvolvimento dos DM futuramente.

Botton-up
Nesta abordagem, a implementação é incremental. O planejamento e o projeto dos DM podem ser
feitos sem uma infraestrutura corporativa. O retorno do investimento é mais rápido.

»» Vantagens:

›› implementação mais rápida;

›› retorno mais rápido;

›› escopo reduzido;

›› foco em um único setor;

›› menor risco;

›› desenvolvimento incremental;

›› equipe aprende e amadurece junto com o projeto.

»» Desvantagens:

›› maior dificuldade para gerenciar múltiplos DM;

›› múltiplas equipes, modelos, infraestrutura, visão de negócio;

›› risco de maior redundância;

›› conter as expectativas;

›› o sucesso do primeiro DM é esperado nos outros DM. Com a mesma equipe,


tempo e recurso;

›› muitas vezes a mesma equipe terá que desenvolver os novos DM e manter os


anteriores.

Combinada/híbrida
Esta abordagem integra a abordagem top-down com a botton-up, ou seja, modelagem com a
visão macro e implementação parcial e incremental. Com isso, se obtém a vantagem da melhor
consistência dos dados.

Planejamento top-down, implementação botton-up.

70
DATA MARTS E DW GLOBAIS │ UNIDADE IV

Imprescindível a Gestão de Metadados!

Abordagem Federada
É a arquitetura de arquiteturas. Recomenda a integração de DW, DM e ETL Heterogêneos (que já
existem na empresa). Objetivo: integrar, o máximo possível, as estruturas analíticas.

Deve-se buscar a criação de uma área de staging comum, para eliminar redundância de alimentação
de dados no ambiente analítico.

“Solução de Contorno!”

Top down x bottom Up


Considere a perspectiva extrema da abordagem top-down:

»» completamente centralizada;

»» um banco de dados “master” deve ser completamente construído antes de qualquer


dado ser resumido ou publicado em um DM.

Considere a perspectiva extrema da abordagem botton-up:

»» um DW Corporativo pode ser construído a partir da junção de DM não relacionados.

Nenhuma das perspectivas extremas da abordagem top-down e botton-up é


recomendada!

O caminho mais viável é o meio termo entre as duas abordagens, em que é necessária uma arquitetura
apropriada que guie o projeto de todas as partes separadas. É o que Kimball chama de Arquitetura
de Barramento (Bus Architecture), na qual as dimensões em comum são compartilhadas entre os
diversos Data Marts.

A única maneira de combinar todos os dados de todos os DM é por meio das dimensões, que devem
ter o mesmo significado. Além disso, um DM pode, sim, conter dados granulares, não só resumidos.

Agilidade e velocidade do Botton-up.

Integração do Top-down.

71
CAPÍTULO 3
Data warehouse Global

O que acontece quando uma empresa precisa de múltiplos data warehouses? Empresas
multinacionais deparam-se com o mesmo problema, precisam de dois tipos de dados:

»» Local: é o dado normalmente encontrado no data warehouse.

»» Global: é o dado que foi retirado do ambiente local e relançado em um modelo


global.

Figura 46. DW Global.

Fonte: Inmon (2008).

O modelo de dados global é criado na matriz. O modelo de dados global reflete apenas o dado que é
necessário globalmente. Normalmente esse modelo é muito pequeno e simples, e é enviado para os
ambientes locais fazerem as extrações de dados.

Figura 47. Envio de modelo global de dados para os ambientes locais.

Fonte: Inmon (2008).

72
DATA MARTS E DW GLOBAIS │ UNIDADE IV

Depois que o modelo global é criado, ele é enviado para cada ambiente local.

Figura 48. Mapeamento do modelo global para os dados locais.

Fonte: Inmon (2008).

Em cada ambiente, o dado local é mapeado ao dado global. Em muitos casos isso significa um
recálculo ou uma reinterpretação do dado local. Depois que o mapeamento local é criado, o próximo
passo é traduzir os mapeamentos locais em tabelas físicas. Um ETL pode ser usado.

Figura 49. Extração dos dados locais.

Fonte: Inmon (2008).

Depois que as tabelas locais são criadas, elas podem então ser enviadas para o data warehouse
global.

73
UNIDADE IV │ DATA MARTS E DW GLOBAIS

Figura 50. Envio dos dados locais para o DW Global.

Fonte: Inmon (2008).

Uma vez criado e populado, há agora um data warehouse global e uma série de data warehouses
locais. E em cada warehouse há uma diferente perspectiva do dado.

Figura 51. Diferentes perspectivas do dado nos diversos DW.

t
Fonte: Inmon (2008).

Quais são as vantagens e desvantagens de Data Marts Dependentes e Independentes?

Qual é a abordagem de implementação mais recomendada?

Como funciona a implementação de um DW Global?

74
Para (Não) Finalizar

Você sabe o que é Big Data?


Carlos Barbieri

Autor do Livro: BI2-Modelagem e Qualidade (2011)

O texto está disponível em: <http://blogdobarbi.blogspot.com.br>

Não sabe direito, mas tem uma ideia sutil do que seja... ah é? O conceito aplica-se para arquivos,
Bancos de dados, Data Marts e Data warehouses com volumes de centenas de terabytes e petabytes
e olhando os números abaixo, você poderá entender o porquê desses novos conceitos:

»» Entre o início da História e o ano de 2003, estimadamente, foram produzidos cerca


de 5 exabytes. Exabytes (sem h) é a unidade que corresponde a 1000 (escala decimal)
ou 1024 (escala binária) petabytes, que por sua vez é 1000 ou 1024 terabytes, que
por sua vez é 1000 ou 1024 gigabytes. A partir daí, você conhece, já tem no seu
pendrive, no seu celular, tablet etc.

»» Acontece que essa mesma quantidade de dados, de 2003 em diante, passou a ser
produzida a cada dois anos. Entendeu o fenômeno? Produção massiva de dados,
criando a cada dois anos a mesma quantidade de dados que foi produzida desde o
início dos tempos. Passadas as escalas de exabytes, chegaremos às escalas nunca
antes imaginadas de zettabytes (nível acima de exabytes) e yottabytes, a última
escala denominada até agora. Nesse momento, algum organismo de definição de
padrões já deve ter o radical para indicar 1000 ou 1024 yottabytes, ou seja, um
número cuja magnitude não temos ideia. Algo assim, como os recursos públicos
desviados por aqui, cujo valor deve ser além dos yottabytes. Talvez seja (id)
yottabytes, que seria uma homenagem singela a nós mesmos.

Sabe o porquê disso? Veja a seguir:

»» A cada minuto, 600 novos “posts” de blogs são colocados na internet.

»» A cada minuto, 34.000 novos tweets são criados no Twitter.

»» A cada minuto, 240.000 mensagens são colocadas no Facebook.

»» O YouTube coloca, em dois meses, o equivalente de conteúdo digital igual ao que foi
produzido pelas grandes redes americanas (ABC,NBC e CBS), desde 1948.

»» O IDC estima que exista hoje um conteúdo de 45GB para cada habitante do planeta,
o que daria 281 bilhões de GB, ou seja, 281 exabytes.

75
PARA NÃO FINALIZAR

»» Por US$600 você compra um HD capaz de armazenar todas as músicas já feitas até
hoje.

»» Em julho de 2011 havia cerca de 5 bilhões de celulares no mundo, sendo a grande


parte tocadores de músicas, gravadores de voz e câmeras fotográficas;

Esse é o conceito de BIG Data: volume, processamento e armazenamento em escalas nunca antes
imaginadas. Você acha que isso vai ou não modificar a nossa forma de pensar a Informática, os
Bancos de dados, as abordagens de BI etc.?

76
REFERÊNCIAS

KIMBALL, R. et al. The Data warehouse Lifecycle Toolkit: Expert Methods for Designing,
Developing, and Deploying Data warehouses. Wiley, 1998.

KIMBALL, R. et al. The Data warehouse Lifecycle Toolkit: Practical Techniques for Building
Data Warehouse and Business Intelligence Systems. Wiley, 2008.

INMON, W. H., IMHOFF, Claudia; SOUSA, Ryan. Corporate Information Factory. Prentice
Hall, 2000.

INMON, W.H.; STRAUSS, D.; NEUSHLOSS, G. DW 2.0. Morgan Kaufmann, 2008.

The Data Warehousing Institute. Disponível em: <http://www.tdwi.org>.

Corporate Information Factory. Disponível em: <http://www.inmoncif.com>.

Kimball Group. Disponível em: <http://www.kimballgroup.com>.

77