Académique Documents
Professionnel Documents
Culture Documents
asp
• HOLAP – Neste caso, junta-se uma ferramenta OLAP ao sistema MOLAP, sendo
que os usuários usam essa interface para fazer suas consultas. É um sistema
extremamente completo, contudo é o mais caros de todos, sendo que muitas
vezes a análise custo/benefício mostra a inviabilidade desta opção.
Características
Cliente Servidor
do sistema
1 – Sistema
Operacional
1 – Sistema
2 - Sistema
Operacional
Gerenciador de Banco
Software mínimo 2 – Aplicações de BI
de Dados Relacional
3 – Middleware para
(SGBDR)
conexão com o SGBD
3 – Middleware para
conexão com o SGBD
requisita
3 – A aplicação de BI,
tem habilidades para middleware, enviam o
formatar os resultado dos dados
resultados dos dados para o cliente
retornados do
servidor
Características
Cliente Servidor
do sistema
1 – Sistema 1 – Sistema
Operacional Operacional
Software Mínimo 2 – Aplicação de BI 2 – SGBD
3 – Middleware para 3 – Middleware para
conexão com o SGBD conexão com o SGBD
Note que o software thin client, reside no web server, e o cliente junto com o
servidor é que completam a tarefa. O cliente contém somente um browser e habilita o
usuário a interagir com o web site do servidor, esse por sua vez, contém o software
para fazer a consulta e também a base de dados a ser consultada. Vamos dar um
exemplo de como se dá a interação entre o cliente e o servidor.
1 – Os usuários dessa
tecnologia podem
analisar os
resultados, tanto
quando estiver
conectado na rede,
ou não. É ideal para 1 – Os custos de
usuários de hardware/software e
computadores upgrades nos
Full client
portáteis. softwares de BI, são
2 – Na maioria dos muito maiores do que
casos de utilização, a no thin client.
funcionalidade e a
robustez dessa
tecnologia tem um
desempenho muito
superior ao thin
client.
thin client.
os upgrades, são bem
2 – Os usuários não
inferiores que o full
conseguem utilizar a
client.
aplicação de BI para
2 – A utilização do
analisar os resultados
thin client é mais
sem estarem
simples que o full
conectados no web
client.
site.
Conclusão
Cada sistema tem a sua importância. Para algumas corporações, onde o número de
usuários dos sistemas de BI é pequeno, talvez seja mais interessante o sistema full
client, pois ele tem mais recursos, e possui uma flexibilidade maior. Mas se a empresa
possuir um grande número de usuários que precisam gerar consultas, remotamente
então o sistema de thin client se torna bem mais interessante, cabe aos gerentes de
informática analisarem e decidirem em qual perfil sua empresa se ajusta melhor.
http://www.datawarehouse.inf.br/artigos.asp
Com as informações já modeladas um usuário irá fazer sua analise e pede algumas
informações, elas são trabalhadas das seguintes formas:
É feita a procura na coluna da tabela, as ocorrências do objeto pedido pelo usuário.
Depois de toda a varredura é apresentado ao usuário o seu pedido.
Ocorre também o seguinte:
Após a analise acima descrita, as informações obtidas serão cruzadas com as de
outras dimensões para uma consulta mais completa.
O quadro a seguir mostra como é feita a varredura de todas as informações nas
dimensões:
Ex.:
Ocorrências de produtos que são vendidos em caixa (será marcado em vermelho)
E poderá ver (em amarelo) os produtos que são vendidos em caixa..
http://www.datawarehouse.inf.br/artigos.asp
Pede a informação sobre um produto especifico, ex. Laranja. Da mesma forma serão
vasculhadas todas as informações sobre produtos e será capturada aquela que
somente indica o produto pedido.
E para finalizar essa consulta o usuário irá pedir a informação sobre seu cliente,
Supermercado Super Super, da mesma forma como nas anteriores será capturada
somente a informação pedida.
As tabelas dimensionais são aquelas que irão guardar em sua maioria informações
textuais, as quais ajudam a definir um componente da dimensão do negocio.
Por exemplo, um componente (registro) da dimensão produto representa um
produto especifico com característica singular.
Tipo de
Chave Produto
Venda
01 Laranja Caixa
02 Laranja Saco
03 Maçã Unidade
04 Maçã Caixa
05 Maçã Saco
06 Morango Caixa
... ... ...
Chave Produto
01 Laranja
02 Laranja
03 Maçã
04 Maçã
05 Maçã
06 Morango
... ...
Cada coluna indica um atributo. Esse pode ser utilizado como restrição da seguinte
forma:
O usuário quer saber sobre um determinado produto (atributo) que é laranja.
Dessa forma na dimensão o atributo atua como restrição.
Registro em uma dimensão é a linha da tabela, ele é único não se repetirá, será
composto por um conjunto de atributos.
Ao trabalhar com a modelagem dimensional pode-se cair em uma armadilha,
Atributo de valor textual ou medição numérica?
O atributo textual irá indicar uma característica especifica, por exemplo, nome, tipo,
marca, peso, entre outros.
http://www.datawarehouse.inf.br/artigos.asp
Características
Cliente Servidor
do sistema
1 – Sistema
Operacional
1 – Sistema
2 - Sistema
Operacional
Gerenciador de Banco
Software mínimo 2 – Aplicações de BI
de Dados Relacional
3 – Middleware para
(SGBDR)
conexão com o SGBD
3 – Middleware para
conexão com o SGBD
requisita
3 – A aplicação de BI,
tem habilidades para middleware, enviam o
formatar os resultado dos dados
resultados dos dados para o cliente
retornados do
servidor
Características
Cliente Servidor
do sistema
1 – Sistema 1 – Sistema
Operacional Operacional
Software Mínimo 2 – Aplicação de BI 2 – SGBD
3 – Middleware para 3 – Middleware para
conexão com o SGBD conexão com o SGBD
Note que o software thin client, reside no web server, e o cliente junto com o
servidor é que completam a tarefa. O cliente contém somente um browser e habilita o
usuário a interagir com o web site do servidor, esse por sua vez, contém o software
para fazer a consulta e também a base de dados a ser consultada. Vamos dar um
exemplo de como se dá a interação entre o cliente e o servidor.
1 – Os usuários dessa
tecnologia podem
analisar os
resultados, tanto
quando estiver
conectado na rede,
ou não. É ideal para 1 – Os custos de
usuários de hardware/software e
computadores upgrades nos
Full client
portáteis. softwares de BI, são
2 – Na maioria dos muito maiores do que
casos de utilização, a no thin client.
funcionalidade e a
robustez dessa
tecnologia tem um
desempenho muito
superior ao thin
client.
thin client.
os upgrades, são bem
2 – Os usuários não
inferiores que o full
conseguem utilizar a
client.
aplicação de BI para
2 – A utilização do
analisar os resultados
thin client é mais
sem estarem
simples que o full
conectados no web
client.
site.
Conclusão
Cada sistema tem a sua importância. Para algumas corporações, onde o número de
usuários dos sistemas de BI é pequeno, talvez seja mais interessante o sistema full
client, pois ele tem mais recursos, e possui uma flexibilidade maior. Mas se a empresa
possuir um grande número de usuários que precisam gerar consultas, remotamente
então o sistema de thin client se torna bem mais interessante, cabe aos gerentes de
informática analisarem e decidirem em qual perfil sua empresa se ajusta melhor.
http://www.datawarehouse.inf.br/artigos.asp
Características
Vantagens Gerenciais
http://www.datawarehouse.inf.br/artigos.asp
O EIS além de facilitar o trabalho, com um ambiente fácil e simples, ele também
pode permitir que o usuário altere o nível de detalhamento das informações com a
ajuda de uma ferramenta OLAP. Com o uso integrado desta ferramenta o executivo
poderá transformar as informações que se encontram em forma de tabelas para
gráficos ou vice-versa, como também poderá executar um Drill-Down ou um Drill-Up
para detalhar ou resumir o grau de granularidade da informação.
Vamos a um exemplo. Em um relatório estão contidas todas as informações das
vendas no ano de 1999 de todas as concessionárias do RS, porém o executivo quer
analisar estas informações, também, para cada cidade deste estado. O que ele deverá
fazer? Neste caso, havendo a integração com o OLAP, o usuário poderá executar um
Drill-Down no estado do Rio Grande do Sul, que automaticamente irão aparecer as
informações para cada cidade deste estado.
Por fim, o EIS permite que o usuário faça análise de tendências e comparações entre
diversas informações de forma prática e rápida, sem necessitar de um apoio da área
de informática para conseguir atingir o seu objetivo, isso o torna mais competitivo,
organizado e independente, que é tudo o que eles querem.
http://www.datawarehouse.inf.br/artigos.asp
Esta etapa é uma das fases mais criticas de um Data Warehouse, pois envolve a fase
de movimentação dos dados. A mesma se dá basicamente em três passos, extração,
transformação e carga dos dados, esses são os mais trabalhosos, complexos e também
muito detalhados, embora tenhamos várias ferramentas (falaremos mais abaixo) que
nos auxiliam na execução desse trabalho.
O primeiro passo a ser tomado no processo de ETL é simplesmente a definição das
fontes de dados e fazer a extração deles. As origens deles podem ser várias e também
em diferentes formatos, onde poderemos encontrar desde os sistemas transacionais
das empresas até planilhas, flat files (arquivos textos) , dados que vem do grande
porte e também arquivos do tipo DBF, do antigo Clipper ou Dbase.
Definidas as fontes, partimos para o segundo passo que consiste em transformar e
limpar esses dados. Mas o que afinal de contas o que é isso?
Bem vamos descrever de uma forma bem simples. Quando obtemos os dados de
uma fonte, que na maioria das vezes é desconhecida nossa, e foi concebida ha muito
tempo atrás, os mesmos possuem muito lixo e há muita inconsistência. Por exemplo.
Quando um vendedor de linhas telefônicas for executar uma venda, ou inscrição, ele
está preocupado em vender, e não na qualidade dos dados que está inserindo na base,
então se por acaso o cliente não tiver o número do CPF a mão, ele cadastra um
número qualquer, desde que o sistema aceite, um dos mais utilizados é o 999999999-
99. Agora imagine um diretor de uma companhia telefônica consultar o seu Data
Warehouse (DW) para ver quais são os seus maiores clientes, e aparecer em primeiro
lugar o cliente que tem o CPF 999999999-99 ? Seria no mínimo estranho. Por isso,
nessa fase do DW, fazemos a limpeza desses dados, para haver compatibilidade entre
eles.
Além da limpeza, temos de fazer na maioria das vezes uma transformação, pois os
dados provêm de vários sistemas, e por isso, geralmente uma mesma informação tem
diferentes formatos, por exemplo: Em alguns sistemas a informação sobre o sexo do
cliente pode estar armazenada no seguinte formato : “M” para Masculino e “F” para
Feminino, porém em algum outro sistema está guardado como “H” para Masculino e
“M” para Feminino e assim sucessivamente. Quando levamos esses dados para o DW,
deve-se ter uma padronização deles, ou seja, quando o usuário for consultar o DW, ele
não pode ver informações iguais em formatos diferentes, então quando fazemos o
processo de ETL, transformamos esses dados e deixamos num formato uniforme
sugerido pelo próprio usuário. No DW, teremos somente M e F, fato esse que facilitará
a análise dos dados que serão recuperados pela ferramenta OLAP.
A seguir são apresentados alguns dos fatores que devem ser analisados antes de
começar a fase de extração dos dados:
• Outro fator que deve ser levado em conta é que dificilmente há o modelo de
dados dos sistemas antigos, e se existem não estão documentados;
• Os dados são reformatados. Por exemplo: um campo data do sistema
operacional do tipo DD/MM/AAAA pode ser passado para o outro sistema do
tipo ano e mês como AAAA/MM;
• Quando há vários arquivos de entrada, a escolha das chaves deve ser feita
antes que os arquivos sejam intercalados. Isso significa que se diferentes
estruturas de chaves são usados nos diferentes arquivos de entrada, então
deve-se optar por apenas uma dessas estruturas;
• Os arquivos devem ser gerados obedecendo a mesma ordem das colunas
estipuladas no ambiente de data warehouse;
• Podem haver vários resultados. Dados podem ser produzidos em diferentes
níveis de resumo pelo mesmo programa de criação do data warehouse;
• Valores default devem ser fornecidos. As vezes pode existir um campo no data
warehouse que não possui fonte de dados, então a solução é definir um valor
padrão para estes campos.
Kimball x Inmon
por Susan Gallas
adaptado por Ana Carolina Trevisan
Chaves substitutas também são geradas aqui. Isto é necessário para dimensões
correspondentes. Tanto Kimball quanto Inmon recomendam a extração de uma única
origem de uma só vez. Alguns consultores de warehouse podem ter interpretado a
abordagem de Kimball como sendo de extrair diversas vezes da mesma origem mas eu
não acho que esta foi sua intenção. Isto tudo é feito na área de staging.
Uma vez que os dados foram carregados para a área de staging, o próximo processo
é carregar os data marts. Todas as partes concordam que a estrutura de negócios mais
adequada é o star schema. Para o tratamento dos dados, estes precisam permanecer
na terceira forma normal de maneira que os relacionamentos ocultos sejam
descobertos. O star schema oculta aqueles devido à extensiva desnormalização. O star
schema lembra bem uma planilha do Excel juntamente com a utilização da tabela pivô.
Esta é a melhor estrutura de layers de apresentação.
Em relação ao ODS, a definição de Inmon é um quadro atual, volátil e integrado dos
negócios. Esta é uma estrutura útil para o marketing one-to-one e relacionamento com
o consumidor, além de outras áreas onde apenas as transações mais recentes são
importantes para o processo operacional do negócio. Kimball descreve o ODS como
http://www.datawarehouse.inf.br/artigos.asp
• Extração primária;
• Identificação dos registros modificados;
• Generalização de chaves para dimensões em modificações;
• Transformação em imagens de registro de carga;
• Migração do sistema legado para o sistema DDW;
• Classificação e construção de agregados;
• Generalização de chaves para agregados;
• Carregamento;
• Processamento de exceções;
• Garantia de qualidade e,
• Publicação.
1. EXTRAÇÃO DE DADOS
http://www.datawarehouse.inf.br/artigos.asp
padronizar a entrada de dados, devemos ter atenção para que não sejam
utilizados atributos para cidade como "RJ" para Rio de Janeiro e noutra base de
dados fonte com o mesmo conteúdo "RJ" representando Roberto Justus. Se o
sistema transacional fonte dos dados for o mesmo, muito dificilmente esta
duplicidade poderia ocorrer;
• Diferenças de granularidade: é o caso de um campo que totalize as horas
despendidas para realizar uma determinada tarefa, como reuniões realizadas
num mês que pode ser confundido com outro campo que totalize as horas
gastas com reuniões numa semana, não sendo possível utilizar estes campos
para realizar comparações ou totalizações sem as devidas conversões;
• Diferenças de abstração: no caso do campo de telefone ser armazenado com o
DDD separado dos números normais em uma fonte enquanto que noutra fonte
estarem estes números combinados num só campo.
informação sobre o sexo do cliente pode estar armazenada no seguinte formato : "M"
para Masculino e "F" para Feminino. Porém, em algum outro sistema pode estar
armazenado como "H" para Masculino e "M" para Feminino e assim sucessivamente.
Quando levamos esses dados para o DW, deve-se ter uma padronização deles, ou
seja, quando o usuário for consultar o DW, ele não pode ver informações iguais em
formatos diferentes. Portanto, fazemos o processo de ETL, transformamos esses dados
e deixamos num formato uniforme normalmente sugerido pelo próprio usuário.
Outra situação de transformação de dados, bem comum, enfrentada pelo analista
responsável pela Aquisição de Dados do DW ao examinar um determinado campo de
uma tabela, onde somente são permitidos os valores 1 ou 2, vir uma ocorrência com
um valor 0 (zero) para o atributo. O módulo de transformação deverá mostrar que o
padrão é o valor 1, neste caso, deverá ser substituído de maneira que as regras
definidas no escopo do sistema sejam cumpridas; deve-se transformar estes dados a
fim de que os mesmos obedeçam a um padrão que permitirá futuras comparações sem
que haja a necessidade de executar operações de conversão durante a realização das
consultas, o que possivelmente tornaria o processo de pesquisa extremamente lento e
trabalhoso em alguns casos.
Ralph Kimball sugere, em seu livro Data Warehouse toolkit (1998) que a equipe de
projetistas do DW construa um sistema de extração de dados de produção,
normalmente, leva-se de 3 a 5 meses para construção, que deve ser configurado de
forma a minimizar o tempo de manutenção durante o carregamento. Um meio para
fazer isso é espelhar o DW, conforme mostra a figura 1.
CONCLUSÃO
A etapa de ETL é uma das mais críticas de um projeto de DW, pois uma informação
carregada erroneamente trará conseqüências imprevisíveis nas fases posteriores. O
objetivo desta fase é fazer a integração de informações de fontes múltiplas e
http://www.datawarehouse.inf.br/artigos.asp
complexas.
A utilização de Ferramentas Back End adquiridas ou desenvolvidas, de acordo com a
opção da empresa, agiliza os processos e minimizam os eventuais prejuízos advindos
das experiências do tipo "tentativa e erro", além de reduzir o tempo de realização
desta etapa do DW, que, geralmente, costuma ser subestimado pelos projetistas,
variando entre 7 a 9 meses e, em alguns casos, até 1 ano.
A complexidade de tarefas necessárias para se desenvolver um sistema de extração
de dados e mantê-lo funcionando exige novas funções na área de informática, tais
como: