Resumimos aqui as técnicas e algoritmos mais usados:

“Market Basket Analysis” (MBA)

A análise do cabaz de compras permite inferir regras a partir de grupos de itens ou produtos que surgem numa transacção (ou compra) do ponto-de-venda.

Sendo as transacções anónimas, esta técnica serve para analisar produtos juntamente com a localização geográfica e a partir daí promover investimentos em determinados produtos em zonas diferentes. Se as transacções não forem anónimas e soubermos a identificação dos clientes, então podemos traçar perfis para promoções directas e personalizadas.

“Memory-Based Reasoning” (MBR)

Uso das instâncias conhecidas como modelo para aferir e fazer previsões de instâncias desconhecidas. Ou seja, para determinarmos se vale a pena investigar mais num “alvo”, recolhemos informação sobre os seus “vizinhos” similares e consoante o “estado” dos vizinhos tomamos uma decisão. A fiabilidade da opção dependerá da distância a que estiverem os “alvos vizinhos”.

Pode ser utilizado com quase todos os tipos de dados, o que é uma grande vantagem desta técnica e também apreende novas classificações apenas com a introdução de novas instâncias na base de dados.

“Cluster Detection” (CD)

Detecção de grupos de registos similares. Esta técnica permite construir modelos para a pesquisa de registos que são similares.

Esta é uma forma indirecta de fazer Data Mining, pois a pesquisa de informação para agregar registos similares é uma primeira fase para entender que tipos de dados é que temos.

“Link Analysis” (LA)

Análise de relações entre os vários registos da base de dados com o objectivo de construir modelos baseados nos padrões existentes nessas relações. Sendo uma ferramenta de Data Mining directa, não é muito eficiente para a pesquisa em Bases de Dados relacionais.

“Decision Trees and Rule Induction” (DTRI)

Aferência de regras e árvores de decisão. Esta técnica de Data Mining directa consiste na criação e treino de subconjuntos disjuntos de informação para os quais é aferida uma regra num ou mais campos do registo (record).

Tem a vantagem de ser bastante explícita e de se poder usar Structured Query Language (SQL) como linguagem de pesquisa, pois a lógica das regras é bastante simples.

“Artificial Neural Networks” (ANN)

As redes neuronais são uma das técnicas mais conhecidas e usadas em Data Mining. Utilizam um modelo idêntico ao dos neurónios e as suas ligações (sinapses) no cérebro humano como suporte para aumentarem o seu volume de dados. Apreendem a partir do “treino” sobre esses dados, generalizando padrões e aplicando-os, internamente, para classificação e previsão de resultados.

É uma técnica excelente, muito vantajosa, mas que tem dois aspectos negativos: o primeiro é a complexidade dos modelos gerados. O segundo é o problema de exigir que o formato dos dados seja imutável; para diferentes representações dos dados surgem resultados diferentes, portanto existe um trabalho importante a fazer na preparação dos dados.

“Genetic Algorithms” (GA)

É uma técnica que utiliza o “algoritmo” natural, ou seja, os mecanismos de selecção que a natureza utiliza para a evolução das espécies.

Tem como ponto forte o seu modo de funcionamento estatístico, o qual utiliza a selecção, o cruzamento de dois indivíduos e a mutação para seleccionar as possíveis soluções que prevalecerão para uma próxima geração até convergir na solução óptima (difícil de atingir mas podemos aproximarmo-nos o suficiente).

É uma excelente técnica de optimização para ser utilizada em complemento às técnicas de MBR ou de Redes Neuronais.

Como o Datawarehouse possui Bases de Dados bem organizadas e consolidadas, as ferramentas de Data Mining ganharam grande importância e utilidade. Essa técnica, orientada para a extracção de dados, oferece uma poderosa alternativa para as empresas descobrirem novas oportunidades de negócio e acima de tudo, traçarem novas estratégias para o futuro.

O objectivo da análise de dados é descobrir, previamente, características dos dados, sejam relações, dependências ou tendências desconhecidas. Tais descobertas tornam-se parte da estrutura de informação que constituem a base das tomadas de decisão. Uma típica ferramenta de análise de dados ajuda os utilizadores finais na definição do problema, na selecção de dados e a iniciar uma correcta análise para a criação da informação, que ajudará a resolver problemas descobertos. Noutras palavras, o utilizador final reage a um estímulo externo e à descoberta do problema por ele mesmo.

A premissa do Data Mining é uma argumentação activa, isto é, em vez do utilizador definir o problema, seleccionar os dados e as ferramentas para analisar tais dados, as ferramentas de Data Mining pesquisam automaticamente os mesmos à procura de anomalias e possíveis relações, identificando assim problemas que não tinham sido detectados pelo utilizador. Noutras palavras, as ferramentas de Data Mining analisam os dados, descobrem problemas ou oportunidades escondidas nos relacionamentos dos mesmos e diagnosticam o comportamento dos negócios, requerendo a mínima intervenção do utilizador, dedicando-se este somente à procura de informação e à descoberta de mais vantagens competitivas.

• Carregamento. Num processo de ETL, devemos definir em primeiro lugar as origens das fontes de dados e fazer a extracção dos mesmos. As origens podem ser várias e provenientes de diferentes formatos, onde poderemos encontrar desde os sistemas transaccionais das empresas (por exemplo: SAP, BPCS, etc.) até arquivos de texto e arquivos DBF (”dBase”) ou Microsoft Access.

• Limpeza. Definidas as fontes, partimos para o segundo passo que consiste em transformar e limpar esses dados. A limpeza é necessária, porque os dados normalmente provêm, muitas vezes, de uma fonte desconhecida, concebida há muito tempo, contendo muito lixo e inconsistências. Por exemplo: se a empresa vender cartões de crédito (Citibank ou outras), o vendedor está mais preocupado em vender o produto (cartão) do que na qualidade de dados que está a inserir. Se o cliente não facultar o número do telefone na altura da compra, o vendedor introduzirá um número qualquer para agilizar a venda. Se for feita uma consulta posterior, levando-se em conta o número do telefone dos clientes, no mínimo informações como: número 99999999-99 poderão aparecer. Por isso, nessa fase do Datawarehouse, faz-se a limpeza desses dados, para haver compatibilidade entre eles.

• Transformação. Uma vez que os dados pode ter origem em sistemas diferentes, às vezes é necessário padronizar os 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 pode estar guardado como “H” para Masculino e “M” para Feminino e assim sucessivamente. Quando levamos esses dados para o Datawarehouse, deve-se ter uma padronização deles, ou seja, quando o utilizador for consultar o Datawarehouse, 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 utilizador. No Datawarehouse, teremos somente M e F, facto esse que facilitará a análise dos dados que serão recuperados pela ferramenta OLAP.

Apesar de existirem ferramentas de ETL como o “Data Stage” (Ardent/Informix), o DTS (Microsoft) e o “Sagent” (da própria Sagent), às vezes é necessário criar rotinas de carga para atender determinadas situações que poderão ocorrer. Todos têm as suas características e cada um poderá ser utilizado dependendo do caso de cada empresa. O mais importante é que uma ferramenta de ETL tem grande valia, principalmente se os sistemas OLTP (transaccionais) são muitos, pois elas são uma poderosa fonte de geração de metadados e podem contribuir muito para a produtividade da equipa.

Num projecto de Datawarehouse, deve-se gerar documentação sobre o levantamento de dados, da base de dados, relatórios a serem gerados, origem dos dados que alimentam o Datawarehouse, processos de extracção, tratamento e rotinas de carga dos dados, além de, possivelmente, regras de negócio da empresa e todas as suas mudanças.

Segundo Inmon, os metadados englobam o Datawarehouse e mantém as informações sobre o que está onde. O autor ainda define quais as informações que os metadados devem manter:

• A estrutura dos dados segundo a visão do programador;
• A estrutura dos dados segundo a visão dos analista de SAD;
• A fonte de dados que alimenta o Datawarehouse;
• A transformação sofrida pelos dados no momento da sua migração para o Datawarehouse;
• O modelo de dados;
• O relacionamento entre o modelo de dados e o Datawarehouse;
• O histórico das extracções de dados;
• Os dados referentes aos relatórios que são gerados pelas ferramentas OLAP, assim como os que são gerados nas camadas semânticas.

Os metadados podem surgir de vários locais durante o decorrer dos projectos. Desde o material que tem origem nas reuniões com os utilizadores até à documentação dos sistemas operacionais. Aliás, as reuniões tornam-se, muitas vezes, uma fonte preciosa de informações, pois muitos dados levantados não estão (e não estariam) documentados em nenhum outro local. Nesta fase, deve-se definir, inclusive, as regras para validação dos dados após carregamento no Datawarehouse.

Como pudemos ver, o volume de metadados gerados é muito grande. Existem hoje algumas ferramentas que fazem única e exclusivamente a gestão dos metadados. Elas têm algumas características peculiares. Essas ferramentas conseguem mapear as informações em todas as etapas de desenvolvimento dos projectos, desde a conceptual até à de visualização dos dados em ferramentas OLAP/EIS.

Uma regra de boa implementação de um projecto de Datawarehouse diz que devemos sempre ter muita atenção aos metadados, pois são eles que servirão de guia por entre as brumas das tabelas, relatórios e dados quando estivermos perdidos.

Com o aparecimento do Data Mart ou Warehouse departamental, a abordagem descentralizada passou a ser uma das opções da arquitectura Datawarehouse. Os Data Marts podem surgir de duas maneiras. A primeira é “top-down” e a segunda é “bottom-up”.

• “Top-down”: quando a empresa cria um  Datawarehouse e depois parte para a segmentação, ou seja, divide o Datawarehouse em áreas menores formando assim pequenos bancos de dados orientados por assuntos departamentalizados.

• “Bottom-up”: quando a situação é inversa. A empresa por desconhecer a tecnologia, cria uma Base de Dados somente para uma área. Com isso os custos são menores do que num projecto de Datawarehouse completo. A partir da visualização dos primeiros resultados parte-se para outra área e assim sucessivamente até estar criado um verdadeiro Datawarehouse.

A tecnologia usada tanto no Datawarehouse como no Data Mart é a mesma, as variações que ocorrem são mínimas, quer em tipo de dados quer na complexidade da carga. A principal diferença é a de que os Data Marts são voltados somente para uma determinada área e o Datawarehouse é voltado para os assuntos de toda a empresa. Cabe portanto a cada empresa avaliar a sua procura e optar pela melhor solução.

• Performance de carregamento - os Datawarehouses requerem um carregamento com incremento de novos dados numa base periódica, dentro de janelas de tempo estreitas; o desempenho do processo de carga deve ser medido em centenas de milhões de linhas de registo e “gigabytes” por hora e não deve, artificialmente, constranger o volume de dados requeridos pelo negócio;

Processamento de carga - existem alguns passos que devem ser levados em linha de conta para carregar dados novos ou actualizados no Datawarehouse, incluindo conversões de dados, filtragem, reformatação, confirmação de integridade, armazenamento físico, indexação e actualização de dados. Estes passos devem ser executados como uma única unidade de trabalho.

Os sistemas da “Red Brick” estabeleceram um critério para um sistema de administração de Base de Dados relacional (RDBMS) satisfatório para Datawarehouse e documentaram 10 exigências especializadas para um RDBMS se qualificar como um servidor relacional de Datawarehouse. Este critério é ilustrado no próximo ponto.

De acordo com a “Red Brick”, as exigências para um Datawarehouse RDBMS começam com o carregamento e preparação dos dados para “queries” e análises. Se o “desenhador/consultor” desconhece o critério nesta fase o resto do sistema será inexacto, incerto e indisponível.

Os dados dentro do actual Warehouse têm uma estrutura distinta com ênfase em níveis diferentes de resumo.

Os dados correntes detalhados são importantes porque:

• reflectem os mais recentes acontecimentos que normalmente são os mais interessantes;

• são volumosos porque são armazenados ao mais baixo nível de granularidade;

• São quase sempre armazenados em unidades de disco de acesso rápido.

Os dados detalhados mais antigos são arquivados e, não sendo frequentemente utilizados, são armazenados num nível detalhado consistente com os dados correntes detalhados.

Os dados resumidos são dados seleccionados do mais baixo nível de detalhe encontrado e, geralmente, são armazenados em unidades de disco.

Os dados altamente resumidos são compactos, facilmente acessíveis e podem ser encontrados até mesmo fora do Warehouse.

Uma Base de Dados que é construída para processamento de transacções on-line, OLTP, geralmente é considerada inadequada para um Datawarehouse, pois foi projectada com um conjunto diferente de necessidades e com a sua capacidade processual maximizada.

O Datawarehouse é interessante no processamento de “queries” e não na referida execução de transacções.

Os servidores de Datawarehouse têm uma finalidade diferente da dos sistemas de OLTP, pois permitem responder a questões de análise empresariais em vez de “agregações” simples como “qual o saldo actual da conta para este cliente?” Questões típicas de Datawarehouse incluem tais coisas como “Que linha de produto vende melhor e como é que isso corresponde a dados demográficos?”

O Datawarehouse recupera assim dados de uma variedade de bases de dados operacionais heterogéneas. Os dados são transformados e são entregues ao “Warehouse/Store” (armazém)de dados baseado num modelo seleccionado (ou definição traçada). A transformação dos dados e a movimentação dos processos são executados sempre que é requerida uma actualização para os dados do Datawarehouse, devendo existir alguma forma de automatização para administrar e executar estas funções.

A limpeza dos dados é um aspecto importante para a criação de um Datawarehouse eficiente, naquilo que é a remoção de certos aspectos dos dados operacionais, como a informação de transacção de baixo nível que permite baixar os tempos das consultas.

A fase de limpeza tem que ser tão dinâmica quanto possível, para acomodar todos os tipos de “queries”, até mesmo aqueles que podem requerer informação de baixo nível. Os dados devem ser extraídos das fontes de produção em intervalos regulares e devem ser agrupados centralmente, mas o processo de limpeza tem que remover a duplicação e reconciliar diferenças entre os vários estilos de colecção de dados.

Uma vez limpos os dados, eles são então transferidos para o Datawarehouse que tipicamente ou é uma grande Base de Dados de alto desempenho SMP (”Symmetrical Multi Processing”) ou MPP (”Massive Parallel Processing”).

O poder de análise dos números é outro aspecto importante do Datawarehouse, devido à complexidade envolvida no processamento de “queries ad-hoc” e por causa das vastas quantidades de dados que a organização quer usar no Warehouse. Um Datawarehouse pode ser utilizado de modos diferentes, como por exemplo, uma “loja central” na qual as “queries” são executadas ou como um “mercado de dados”.

A aproximação da loja central, geralmente, usa uma estrutura de dados muito simples com muito pequenas suposições sobre as relações entre os dados, enquanto que os mercados usam frequentemente Bases de Dados multidimensionais que podem acelerar o processamento de “queries”.

Uma aproximação ao Datawarehouse é o “Paradigma da Sandwich” de Parsaye, avançado pelo Dr. Kamran Parsaye, CEO da Hermosa Beach, CA. Este paradigma ou filosofia encoraja a aceitação da probabilidade de que a primeira repetição de um esforço de Datawarehouse requererá uma revisão considerável. Desta forma e para evitar estas revisões caras e demoradas o “Paradigma da Sandwich” defende a seguinte aproximação:

• Trabalho dos dados para determinar que formatos e dados são necessários para apoiar uma aplicação de Data Mining;

• Construção de um protótipo de mini Datawarehouse, com a maioria das características imaginadas para o produto final;

• Revisão das estratégias;

• Construção do “Warehouse”(armazém) final.