Escolar Documentos
Profissional Documentos
Cultura Documentos
Integração
Esta característica talvez seja a mais importante do DW. É através dela que
iremos padronizar uma representação única para os dados de todos os sistemas
que formarão a base de dados do DW. Por isso, grande parte do trabalho na
construção de um DW está na análise dos sistemas transacionais e dos dados
que eles contêm. Esses dados geralmente encontram-se armazenados em vários
padrões de codificação, isso se deve aos inúmeros sistemas existentes nas
empresas, e que eles tenham sido codificados por diferentes analistas. Isso quer
dizer que os mesmos dados podem estar em formatos diferentes. Vejamos agora
um exemplo clássico referentes aos gêneros masculino e feminino.
Num sistema OLTP, o analista convencionou que o sexo seria 1 para
masculino e 0 para feminino, já em outro sistema outro analista usou para guardar
a mesma informação a seguinte definição, M para masculino e F para feminino, e
por fim outro programador achou melhor colocar H para masculino e M para
feminino. Como podemos ver, são as mesmas informações, mas estão em
formatos diferentes, e isso num DW jamais poderá acontecer. Portanto, é por isso
que deverá existir uma integração de dados, convencionando-se uma maneira
uniforme de guardarmos os mesmos, e isso gera bastante trabalho, se forem
poucos sistemas transacionais não causará grandes problemas, mas se tiverem
muitos então as coisas ficam um pouco complicadas e bem mais trabalhosas.
Figura 1
Variação no Tempo
Segundo W.H.Inmon, os Data Warehouses são variáveis em relação ao
tempo, isso nada mais é do que manter o histórico dos dados durante um período
de tempo muito superior ao dos sistemas transacionais.
Num DW é normal mantermos um horizonte de tempo bem superior ao dos
sistemas transacionais, enquanto no OLTP mantemos um histórico curto dos
dados, no DW guardamos esses dados num período maior. Isso é bastante lógico
porque num sistema transacional a finalidade é de fornecer as informações no
momento exato, já no Data Warehouse, o principal objetivo é analisar o
comportamento das mesmas durante um período de tempo maior.
Fundamentados nessa variação, os gerentes tomam as decisões em cima de fatos
e não de intuições.
Seguindo a mesma linha de raciocínio é válido dizer que os dados nos
sistemas transacionais estão sendo atualizados constantemente, cuja exatidão é
válida somente para o momento de acesso. Os dados existentes num DW são
como fotografias que refletem os mesmos num determinado momento do tempo.
Essas fotografias são chamadas de snapshots.
A dimensão tempo, sempre estará presente em qualquer fato de um DW,
isso ocorre porque, como falamos anteriormente, sempre os dados refletirão num
determinado momento de tempo, e, obrigatoriamente, deverá conter uma chave
de tempo para expressar a data em que os dados foram extraídos. Portanto,
podemos dizer que os dados armazenados corretamente no DW não serão mais
atualizados, tendo-se assim uma imagem fiel da época em que foram gerados.
Assim como os dados, é importante frisar que os metadados, também
possuem elementos temporais, porque mantêm um histórico das mudanças nas
regras de negócio da empresa. Os metadados são responsáveis pelas
informações referentes ao caminho do dado dentro do DW.
Não Volatilidade
No DW existem somente duas operações, a carga inicial e as consultas dos
front-ends aos dados. Isso pode ser afirmado porque a maneira como os dados
são carregados e tratados é completamente diferente dos sistemas transacionais.
Enquanto nesses sistemas temos vários controles e updates de registros, no DW
temos somente inserts e selects de dados. Por exemplo, num sistema de
contabilidade podemos fazer alterações nos registros. Já no DW, o que acontece
é somente ler os dados na origem e gravá-los no destino, ou seja, no banco
modelado multidimensional.
Deve-se considerar que os dados sempre passam por filtros antes de
serem inseridos no DW. Com isso, muitos deles jamais saem do ambiente
transacional, e outros são tão resumidos que não se encontram fora do DW. "Em
outras palavras, a maior parte dos dados é física e radicalmente alterada quando
passam a fazer parte do DW. Do ponto de vista de integração, não são mais os
mesmos dados do ambiente operacional. À luz destes fatores, a redundância de
dados entre os dois ambientes raramente ocorre, resultando em menos de 1
por cento de duplicações", essa definição é dada por Inmon.
Localização
Os dados podem estar fisicamente armazenados de três formas:
Num único local, centralizando o banco de dados em um DW integrado,
procurando maximizar o poder de processamento e agilizando a busca dos dados.
Esse tipo de armazenagem é bastante utilizada, porém há o inconveniente do
investimento em hardware para comportar a base de dados muito volumosa, e o
poderio de processamento elevado para atender satisfatoriamente as consultas
simultâneas de muitos usuários.
Os distribuídos são Data Marts, armazenados por áreas de interesse. Por
exemplo, os dados da gerência financeira num servidor, dados de marketing
noutro e dados da contabilidade num terceiro lugar. Essa pode ser uma saída
interessante para quem precisa de bastante performance, pois isso não
sobrecarrega um único servidor, e as consultas serão sempre atendidas em tempo
satisfatório.
Armazenados por níveis de detalhes, em que as unidades de dados são
mantidas no DW. Pode-se armazenar dados altamente resumidos num servidor,
dados resumidos noutro nível de detalhe intermediário no segundo servidor e os
dados mais detalhados (atômicos), num terceiro servidor. Os servidores da
primeira camada podem ser otimizados para suportar um grande número de
acessos e um baixo volume de dados, enquanto alguns servidores nas outras
camadas podem ser adequados para processar grandes volumes de dados, mas
baixo número de acesso.
Para mudar de nível é necessário que ocorra um dos seguintes eventos: os
dados são sintetizados, arquivados ou eliminados.
O processo de sintetização interage no nível mais alto de detalhamento
(dados detalhados atuais) para os níveis seguintes (levemente e altamente
resumidos). Quando termina determinado período de tempo (semana, mês,
trimestre, ano), os dados são indexados por estes períodos e armazenados nos
seus respectivos níveis de detalhamento. Para facilitar o acesso aos dados, estes
devem estar sintetizados e indexados de várias maneiras. Portanto, ao mesmo
tempo que ocorre o agrupamento por datas, também pode ocorrer a sintetização
por grupos e subgrupos.
Cada nível possui um horizonte de tempo definido para a permanência dos
dados. Então o fato de os dados serem transportados para níveis mais elevados
não implica a exclusão do nível anterior. Um processo denominado processo de
envelhecimento ocorre quando este limite é ultrapassado, e portanto os dados
podem ser transferidos para meios de armazenamentos alternativos ou passar de
dados detalhados atuais para dados detalhados antigos.
Granularidade
Os dados altamente resumidos são compactos e devem ser de fácil acesso, pois
fornecem informações estatísticas valiosas para os Sistemas de Informações
Executivas (EIS), enquanto que nos níveis anteriores ficam as informações
destinadas aos Sistemas de Apoio a Decisão (SAD), que trabalham com dados
mais analíticos procurando analisar as informações de forma mais ampla.
- Ralph Kimball
A criação e manutenção dos conceitos corporativos não são tarefas da área de TI,
e sim da alta cúpula da corporação e dos usuários de informações.
No que tange aos Data Marts, Kimball diz que eles não devem ser
departamentais, ou seja, os Data Marts devem ser orientados aos dados, ou
fontes de dados. Exemplificando, se um banco possui uma fonte de dados de
contas correntes e poupança, então um Data Mart de Contas deve ser criado. Este
não será um Data Mart proprietário da área financeira e nem da área de
Marketing, será sim um Data Mart que terá como público todos os usuários de
todos os departamentos que lidam com aquele assunto. Isso seria possível uma
vez que os conceitos corporativos abordados acima já estariam disponíveis e
implantados, dando a toda empresa uma visão única sobre seu negócio.
Ao final da construção dos Data Marts orientados a assuntos, teríamos uma série
de pontos de conexão entre eles, que seriam as tabelas Fato e Dimensão em
conformidade. Desta forma, informações entre os diferentes Data Marts poderiam
ser geradas de maneira íntegra e segura. A este conceito Kimball dá o nome de
Data Warehouse Bus Architecture.
- Bill Inmon
Em diversos "White Papers" de seu site (www.billinmon.com), especificamente em
"Data Marts and the Data Warehouse : Information Architeture for the Millenium",
Inmon discorre sobre a sua CIF (Corporate Information Factory) como infra-
estrutura ideal para ambientar os dados da empresa, desde de seus sistemas
transacionais até a disponibilização de informações gerenciais ao usuário final.
Emanando do Data Warehouse, seriam criados os Data Marts. Uma vez que os
dados da empresa já estão integrados no Data Warehouse, os Data Marts que
atenderiam os diversos departamentos da empresa gerariam dados íntegros e
corporativos.
O Data Warehouse deve corresponder aos anseios dos usuários e não deve ser
fruto da vaidade da área de Tecnologia. Segundo o autor, apesar deste ponto
parecer óbvio, é muito comum encontrar grandes "Elefantes Brancos" que não
atendem às reais necessidades de negócios da empresa mas que elevam o brio
dos técnicos.
Ralph Kimbal é claro quando diz que os Data Marts devem ser orientados a
assuntos e não departamentais. Portanto, todos os usuários da corporação que
estão ligados a um determinado assunto, não importando sua lotação, devem ser
envolvidos na construção do Data Mart. Isto implica um trabalho de integração de
conceitos entre diversos departamentos, até que chegarmos a uma visão
corporativa e única da empresa.
Por esse motivo, o correto seria convencer a alta administração das empresas
sobre a importância de se ter uma visão corporativa de seus processos e dados.
Se pensarmos com calma, não deveríamos nos esforçar para convencê-los disso,
afinal a maior interessada e beneficiada seria a própria empresa e o Data
Warehouse seria apenas um dos frutos da integração.
Business Intelligence
Com o surgimento dos bancos de dados relacionais, dos PC’s e das interfaces
gráficas como o Windows, aliados ao aumento da complexidade dos negócios,
começaram a surgir os primeiros produtos realmente direcionados aos analistas
de negócios, que possibilitavam rapidez e uma maior flexibilidade de análise.
- Data Warehouses
- Planilhas Eletrônicas
- Geradores de Consultas e Relatórios
- EIS
- Data Marts
- Data Mining
- Ferramentas OLAP
Pode-se entender uma visão geral de uma arquitetura BI, através da figura abaixo:
- Operational Data Store (ODS): Também de acordo com Inmon, ODS é uma
base de dados integrada, volátil, de valores correntes, e que contém
somente dados detalhados. Também pode ser entendido como uma visão
integrada do mundo operacional. Normalmente sua construção adota bases
de dados relacionais;
- Data Warehouse (DW): Para Kimball, o DW é a fonte de dados para
consultas na organização, ou nada menos que a união de todos os Data
Marts já constituídos. Pode ser visto também como uma grande base de
dados que apresenta diversos níveis sintéticos dos dados operacionais,
cujo objetivo maior é o de fornecer informação estratégica integrada,
segundo uma visão holística da organização. Normalmente, é construída
sob a forma de fatos (mensuráveis) e as dimensões sob as quais podem
ser analisados (ex: as vendas da companhia na região nordeste foram de
R$-1.000.000,00 no mês de maio/2003; onde o fato é valor das vendas e as
dimensões são a região e o mês);
- Data Mart (DM): Kimball, afirma que os data marts são subconjuntos de um
DW completo. Podemos assim entender DM como pequenos DW, de visão
departamental ou de área interesse ou área assunto bem definida, com o
propósito de fornecer visão estratégica dos dados setorizados;
- Near Line Store (NLS): Inmon conceitua NLS como sendo uma
armazenagem complementar ao DW, a fim de manter dados raramente
acessados;
Caso uma outra linha, também ortodoxa, como a de Kimball, seja adotada, a
organização buscará desenvolver soluções de informação estratégica para cada
área assunto de interesse da organização, atendendo a cada visão de negócio
com sistemas de informações estratégicos, resumidos em Data Marts, priorizando
esta ou aquela visão de negócios na construção. Qual visão de negócios deve ser
privilegiada ? Como descobrir qual visão pode viabilizar os resultados mais
interessantes para a organização ?
Apesar de que esta última visão tende a produzir resultados mais rápidos devido
ao foco em um determinado assunto de negócio, muitas vezes a alta
administração da organização fica privada de informação estratégica para a
condução abrangente e estratégica de seus negócios.
Desta forma, o que se propõe neste artigo é a entrega parcial de resultados, como
em Data Marts propostos por Kimball, mas priorizando a entrega de resultados
que apresentem a informação da camada mais estratégica da organização.
Segundo esta proposta, busca-se produzir resultados que, em primeiro lugar,
forneçam uma visão geral resumida da situação numérica da empresa como um
todo. Não se pode dizer que é um DM, pois o DM é departamental ou de área
assunto específico. Neste caso, o que se tem é uma visão ampla em termos de
negócios (abrangendo a maior parte dos mesmos, os mais representativos), mas
restrita em termos de profundidade, detalhes. O objetivo fundamental é o de
produzir uma visão estratégica dos negócios da organização, que viabilize tomada
de decisão de maior impacto na organização, que defina os rumos da mesma.
- Não se deve utilizar variáveis, cuja qualidade dos dados relativos a elas não
seja confiável. Aliás, em muitas construções BI, o primeiro produto obtido é
que se deve melhorar o nível da qualidade de dados de forma geral ou
específica.
OLAP
Drill Across
O Drill Across ocorre quando o usuário pula um nível intermediário dentro de uma
mesma dimensão. Por exemplo: a dimensão tempo é composta por ano,
semestre, trimestre, mês e dia. O usuário estará executando um Drill Across
quando ele passar de ano direto para semestre ou mês.
Drill Down
Drill Up
O Drill Up é o contrário do Drill Down, ele ocorre quando o usuário aumenta o grau
de granularidade, diminuindo o nível de detalhamento da informação.
Drill Throught
O Slice and Dice é uma das principais características de uma ferramenta OLAP.
Como a ferramenta OLAP recupera o microcubo, surgiu a necessidade de criar um
módulo que convencionou-se de Slice and Dice para ficar responsável por
trabalhar esta informação. Ele serve para modificar a posição de uma informação,
alterar linhas por colunas de maneira a facilitar a compreensão dos usuários e
girar o cubo sempre que tiver necessidade.
Alertas
Ranking
Filtros
Os dados selecionados por uma Query podem ser submetidos a condições para a
leitura na fonte de dados. Os dados já recuperados pelo Usuário podem ser
novamente “filtrados” para facilitar análises diretamente no documento.
Sorts
Os sorts servem para ordenar uma informação. Esta ordenação pode ser
customizada, crescente ou decrescente.
Breaks
Breves Definições:
Fato: Tabela de valores. Nesta tabela temos os valores que serão analisados no
nosso Data Warehouse/Data Mart;
Neste caso acima, temos então uma implementação MOLAP para sua empresa
acessar. Cada aresta representada deste cubo é uma forma diferente de analisar
os dados, a partir de agora em forma de informação já resumida.
Breve Definição:
SP RJ MG Total
Agregações
DATA MART
Algumas organizações são atraídas aos data marts não apenas por causa do
custo mais baixo e um tempo menor de implementação, mas também por causa
dos correntes avanços tecnológicos. São elas que fornecem um SAD customizado
para grupos pequenos de tal modo que um sistema centralizado pode não estar
apto a fornecer. Data marts podem servir como veículo de teste para companhias
que desejam explorar os benefícios do data warehouse.
Há um consenso entre os fornecedores de soluções de data warehouse. A idéia é
começar pequeno mas pensando grande. E é o que está acontecendo. Na maioria
dos casos, as empresas que optam pelo data warehouse iniciam o processo a
partir de uma área específica da empresa para depois ir crescendo aos poucos.
Mesmo nos casos de “Full Warehouse” ou data warehouse completos - como o da
Previdência Social da Holanda e Noruega - o processo costuma ser organizado a
partir dos data marts.
O data warehouse pode ser uma decisão estratégica, mas não pode ser encarado
com imediatismo, ou seja, não é apenas algo que se realiza aos poucos, mas
também é um processo contínuo de atualização e consolidação dos dados
corporativos. Por isso, os investimentos em um sistema desse tipo não devem
nem podem ser feitos de uma única vez, mas de forma gradual ao longo do
tempo.
É preciso ter em mente que as diferenças entre data mart e data warehouse são
apenas com relação ao tamanho e ao escopo do problema a ser resolvido.
Portanto, as definições dos problemas e os requisitos de dados são
essencialmente os mesmos para ambos. Enquanto um data mart trata de
problema departamental ou local, um data warehouse envolve o esforço de toda a
companhia para que o suporte a decisões atue em todos os níveis da
organização. Sabendo-se as diferenças entre escopo e tamanho, o
desenvolvimento de um data warehouse requer tempo, dados e investimentos
gerenciais muito maiores que um data mart.
Por muitos anos, todos os sistemas que extraíam dados de sistemas legados e os
armazenavam de maneira utilizável para suporte à decisão eram chamados data
warehouses. Ao longo dos últimos anos, uma distinção tem sido feita entre os
corporativos data warehouses e os departamentais data marts, mesmo que
geralmente o conceito ainda continue sendo chamado de data warehousing.
- Os data marts têm o escopo mais limitado e são mais identificados com
grupos de necessidades dos usuários, o que se traduz em esforço/time
concentrado.
CRM
Um Data Warehouse bem estruturado pode ser usado como uma poderosa
ferramenta de CRM (Gerenciamento de relacionamento com o Cliente) analítico.
Através do CRM a empresa pode conhecer o perfil de seu cliente, e a partir daí
fazer um trabalho dirigido de fidelidade. Por meio de pesquisas, descobriu-se que
é muito mais lucrativo manter um cliente do que tentar conquistar novos clientes.
Essa diferença de lucratividade fica mais explícita quando um cliente fidelizado é
comparado com cliente perdido pelas empresas que terá de ser reconquistado.
O CRM é dividido em duas frentes, a operacional e a analítica. O CRM
operacional é feito através do contato direto da empresa com o cliente. Call
Centers, malas diretas, internet e outros tipos de canais são utilizados nesse
segmento de CRM. Já o CRM analítico é feito através dos dados contidos nas
bases gerenciais da empresa (Data Warehouse). Enquanto a função do
operacional é manter o contato com o cliente, o analítico preocupa-se em analisar
os dados colhidos por diversas fontes da empresa sobre o cliente.
DATA MINING
REDES NEURAIS
INDUÇÃO DE REGRAS
ÁRVORES DE DECISÃO
VISUALIZAÇÃO
Redes Neurais
Embora seja verdadeiro que as redes neurais apresentem o mais avançado poder
de mineração, muitos analistas de negócio não podem fazer uso delas porque os
resultados finais não podem ser explicados.
A função básica de cada neurônio é: (a) avaliar valores de entrada, (b) calcular o
total para valores de entrada combinados, (c) compara o total com um valor limiar,
(d) determinar o que será a saída. Enquanto a operação de cada neurônio é
razoavelmente simples, procedimentos complexos podem ser criados pela
conexão de um conjunto de neurônios. Tipicamente, as entradas dos neurônios
são ligadas a uma camada intermediária (ou várias camadas intermediárias) que é
então conectada com a camada de saída.
Indução de Regras
Vários algoritmos e índices são colocados para executar esse processo, incluindo
o Gini, o C 4.5 e o CHAID. Na IR, a grande maioria do processo é feito pela
máquina, e uma pequena parte é feita pelo usuário.
Por exemplo, a tradução das regras para dentro de um modelo aproveitável é feita
pelo usuário, ou por uma interface de árvores de decisão. Do ponto de vista do
usuário, o maior problema com as regras é que o programa de DM não faz o
ranking das regras por sua importância. O analista de negócio é então forçado a
encarregar-se de criar um manual de análise para todas as regras relatadas a fim
de determinar aquelas que são mais importantes no modelo de DM, e para os
assuntos de negócio envolvidos. E isso pode ser um processo tedioso.
Árvores de decisão
As árvores de decisão são uma evolução das técnicas que apareceram durante o
desenvolvimento das disciplinas de machine learning. Elas cresceram a partir da
aproximação de uma análise chamada Detecção de Interação Automática,
desenvolvida na Universidade de Michigan. Essa análise trabalha testando
automaticamente todos os valores do dado para identificar aqueles que são
fortemente associados com os itens de saída selecionados para exame. Os
valores que são encontrados com forte associação são os prognósticos chaves ou
fatores explicativos, usualmente chamados de regras sobre o dado. Outro antigo
algoritmo chamado CHAID foi desenvolvido estendendo as capacidades do DIA
sendo um pouco através da adição da fórmula estatística Chi squared.
Mas foi uma professor na Austrália que desenvolveu a tecnologia que permitiu o
aparecimento das árvores de decisão. Muitas pessoas na indústria de DM
consideram Ross Quinlan, da Universidade de Sydney, Austrália, como o “pai das
árvores de decisão”. A contribuição de Quinlan foi um novo algoritmo chamado
ID3, desenvolvido em 1983. O ID3 e suas evoluções (ID4, ID6, C 4.5, See 5) são
muito bem adaptadas para usar em conjunto com as árvores de decisão, na
medida em que eles produzem regras ordenadas pela importância. Essas regras
são, então, usadas para produzir um modelo de árvore de decisão dos fatos que
afetam os itens de saída. Novas fórmulas de árvores de decisão como a Gini, um
índice computacional inventado por Ron Bryman, são também muito bem
adaptadas para as árvores de decisão, e oferecem uma crescente velocidade de
processamento assim como mais amplas habilidades para processar números
concorrentemente com textos.
Visualização
Nos dois casos, a Visualização mapeia o dado sendo minerado de acordo com
dimensões especificadas. Nenhuma análise é executada pelo programa de DM
além de manipulação estatística básica. O usuário, então, interpreta o dado
enquanto olha para o monitor. O analista pode pesquisar a ferramenta depois para
obter diferentes visões ou outras dimensões.
Nem sempre o DM pôde agregar valor aos SAD. De fato, houve no passado (e
ainda há, de certa forma) muitas barreiras para o DM se tornar uma função
essencial dos SAD. As mais importantes têm sido ultrapassadas, mas outras ainda
se mantêm.
Outras que se podem citar são: o desafio de preparar os dados para mineração;
as dificuldades em se obter uma análise custo/benefício bem fundamentada antes
do início do projeto e a preocupação quanto à viabilidade de muitos dos
fornecedores dessas ferramentas.
Altos Custos
O alto custo da maioria das ferramentas faz com que fique difícil a disseminação
das mesmas entre as corporações. Uma simples operação matemática mostra
que um projeto, com o custo de US$ 20.000 por usuário, pode atender não mais
que um seleto grupo de usuários.
Certos fornecedores dessas ferramentas têm introduzido produtos com custo mais
baixo, mas mesmo assim o preço continua limitando o uso em larga escala.
Evidentemente, os custos por usuário precisam ser reduzidos antes que os
benefícios desta tecnologia possam atingir a massa de usuários.
Mas mesmo com essa nova geração de ferramentas que permitem a mineração
em moderados grupos de dados, uma terceira barreira ainda permanece: A
grande maioria das ferramentas ainda continua incompreensível para os usuários
comuns. De fato, muitas ferramentas ainda fazem o seu trabalho em uma “caixa-
preta”, não permitindo que se saiba como alcançaram os seus resultados.
Isso significa que o DM ainda tem que ser feito no contexto da área de sistemas, a
quem os usuários têm que submeter as suas solicitações, esperar por dias ou
semanas enquanto um expert processa os dados, para então receberem e
examinarem a saída sumarizada. Se os resultados não satisfizerem, todo
processo tem que ser recomeçado.
Contudo, o poder dessas ferramentas não chega nem perto daquelas que utilizam
técnicas mais sofisticadas.
A regra 80/20
Os analistas concordam que por dentro de qualquer grande grupo de dados, 80%
da informação podem ser encontrados dentro de 20% dos dados. Essa regra força
a redução do tamanho do grupo de dados a ser analisado. O particionamento dos
grupos de dados pode ser usado para conseguir esse intento, o que significa que
apenas os dados relevantes é que são usados para o DM, concentrando os dados
úteis dentro dos 20% selecionados para análise. Se mesmo os grupos de dados
particionados continuarem grandes, pode-se retirar amostras dos mesmos para se
ter uma idéia do que acontece no todo.
Viabilidade estatística mínima
Uma outra vantagem importante dos dados de negócio é que eles são, quase
sempre, coletados, mantidos e apropriados pelas mesmas pessoas que os usam,
isto é, pelas pessoas de negócio. Em contraste, os dados científicos são
freqüentemente compostos de fontes de dados estratificadas, como, por exemplo,
amostras que são coletadas em pesquisas de campo por algumas pessoas, e que
são mandadas ao centro de operações para ser compiladas por um outro time de
analistas.
Caixa Preta: qualquer tecnologia que não explica os resultados que gera. Os
usuários não podem descobrir como a resposta foi determinada. Isso faz com que
determinadas técnicas de DM sejam inadequadas para determinadas aplicações
de negócio.
CHAID: um algoritmo híbrido que enxerta uma fórmula estatística chi dentro do
AID (heurística), na tentativa de tratar tanto numéricos quanto simbólicos.
Enquanto o CHAID é confiável, ao mesmo tempo é muito lento e limitado quanto
ao seu poder.
C4.5: um algoritmo de DM que foi desenvolvido a partir do ID3, ID4 e ID6. Ele
trabalha bem tanto com valores numéricos como simbólicos.
Fator causal: qualquer elemento de dado que conduz, influencia ou causa outro
elemento. Por exemplo, se limite de crédito do consumidor pode dizer quão
rentável um consumidor pode ser, então ele é um fator causal. Veja fator
discriminante.
Fraldas e Cervejas: uma anedota popular que descreve o poder do DM. A anedota
(de veracidade duvidosa) conta que uma grande rede de supermercados usou o
DM para descobrir que clientes sempre compravam fraldas e cervejas ao mesmo
tempo. Isso encorajou o varejista a colocar os dois itens juntos na prateleira,
incrementando a venda de ambos.
Gini: um moderno algoritmo de índice para árvore de decisão que foi desenvolvido
por Ron Bryman. Ele lida tanto com números quanto com texto, e oferece boa
velocidade de processamento.
ID3: O primeiro algoritmo que foi desenhado para construir árvores de decisão. Foi
inventado por Ross Quinlan, na Universidade de Sydnei, Austrália. O ID3 foi
seguido pelo ID4, ID6 e see5.
Janela ou nível de confiança: uma medida estatística de quão certo alguém pode
estar que determinado resultado é correto. A janela ou nível descreve o quão
próximo o valor está de ser o resultado exato.
See5: A mais recente das séries Quinlan dos algoritmos da árvore de decisão.
5 - Referências Bibliográficas:
Esta etapa é uma das fases mais críticas de um Data Warehouse, pois envolve a
fase de extração dos dados dos sistemas transacionais ou de outras fontes
(planilhas, arquivos textos), a fase de Filtragem que consiste basicamente em
garantir a integridade dos dados e, por fim, a fase de Carga dos Dados no Data
Warehouse.
O processo de carga dos dados passa por três etapas: extração, filtragem e a
carga propriamente dita.
Extração
Podem existir várias fontes de dados diferentes para compor uma informação. Ela
pode ser oriunda de uma planilha excel, enquanto uma outra que serviria para
compor um mesmo fato viria de um arquivo texto.
Quando há vários arquivos de entrada, a escolha das chaves deve ser feitas 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.
Valores padrões devem ser fornecidos. Às 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.
Se a tabela deve receber uma carga incremental ou a carga por cima dos dados.
A carga incremental normalmente é feita para tabelas fatos, e a carga por cima
dos dados é feita em tabelas dimensões, onde o analista terá que deletar os
dados existentes e incluí-los novamente.
METADADOS
Estas informações são úteis tanto para quem mantém e desenvolve o ambiente,
como para os que usufruem dele como fonte de dados gerenciais. Entretanto,
como existem várias ferramentas concorrentes para as várias fases de um projeto,
não existem sistemas que consigam colocar todos os metadados gerados em um
único repositório central. Essa deficiência, e lacuna no mercado de software, faz
com que o desenvolvimento, gerenciamento, manutenção e utilização do Data
Warehouse fiquem comprometidos.
Em empresas que optaram por não adquirir ferramentas de ETL, partindo para o
desenvolvimento de processos de carga proprietários, não existe interface ou
aplicativo que permita o vínculo de metadados aos processos de carga.
Consequentemente, o ambiente de ETL não está documentado e, portanto, torna-
se uma "área cega" do ambiente de Warehouse.
Por incrível que possa parecer, grandes empresas não tem uma visão unificada
sobre seus objetos corporativos. Cada unidade analisa a estrutura organizacional,
o cliente e os produtos de forma diferenciada. Isso ocorre devido às periódicas
mudanças dessas estruturas em razão de forças políticas ou mercadológicas.
Dessa maneira, as relações entre sistemas e unidades organizacionais distintas
fica muito comprometida, acarretando muitas vezes na geração de informações
incorretas para tomada de decisões, uma vez que não existem conceitos
corporativos sobre objetos utilizados por toda corporação.