A área de data staging é a área de trabalho do data warehouse. É o lugar onde se colocam os dados primários, onde se limpa, combina, arquiva e, ao finl, exportam esses dados para um ou mais data marts. O propósito da párea de data staging é preparar os dados para carrega-los em um servidor de apresentação (um SGBD relacional ou software OLAP). Assumimos que a área de data staging não é um serviço de consulta. Em outras palavras, qualquer banco de dados que é usado para consultas assume-se que esteja fisicamente a jusante da área de data staging.

Talvez a gente nem perceba que tenha uma área de data staging. Talvez seus dados façam apenas um pouso rápido e arremeta, sem tocar o solo, entre os sistemas legados e o servidor de apresentação. (Esta é uma metáfora aeronáutica). A gente traz os dados brevemente, designa-se uma chave substituta (surrogate key), verifica-se a consistência dos registros e os enviados ao carregador do SGDB que é o banco de dados de apresentação.

Se os dados legados já estão disponíveis em um banco de dados relacional, então faz sentido executar todos os passos do processamento dentro da moldura relacional, especialmente se o banco de dados relacional fonte e o eventual banco de dados de apresentação de destino são do mesmo fornecedor. Isto faz mais sentido ainda quando o banco de dados fonte e o de destino estiverem na mesma máquina física, ou quando existe um link de alta velocidade entre eles.

Contudo, existem muitas variações deste tema e, em muitos casos, pode não fazer sentido carregar os dados fonte em um banco de dados relacional. No detalhamento das descrições dos passos de processamento veremos que quase todo o processamento consiste de classificações, seguidas de uma leitura seqüencial única que entre uma ou duas tabelas. Este paradigma de processamento simples não precisa do poder de um SGB relacional. De fato, em alguns casos, pode ser um erro grave desviar recursos para carregar dados em um banco de dados relacional quando o que é necessário é processamento seqüencial de arquivos comuns.

Da mesma forma, veremos que os dados primários não estiverem em um formato entidade-relacionamentop (ER) normalizado, em muitos casos não vale a pena carrega-lo em um modelo ER físico simplesmente para verificar os relacionamentos dos dados. Os passos mais importantes de integridade dos dados envolvendo o enquadramento dos dados em relacionamentos um-a-um e um-para-muitos pode ser realizado, novamente, com classificações simples e processamento seqüencial. Mantendo isto em mente, vamos desmembrar os passos de transformação dos dados o máximo possível.

Processamento da Dimensão

Para forçar a integridade referencial quase sempre processamos as dimensões antes de processar os fatos. Tomamos o ponto de vista de que sempre criamos a chave substituta para um registro de dimensão antes de carrega-lo no data mart final. Veremos na seção seguinte que a identificação da chave substituta correta é uma pesquisa seqüencial simples de arquivo.

Um problema significativo de processamento dimensional é decidir o que fazer com uma descrição de dimensão como a de um cliente ou produto que não pe compatível com o que está já armazenado do data warehouse. Se a descrição revisada é tomada como uma legítima e confiável atualização para uma informação prévia, então deve-se usar as técnicas de “slowly changing dimensions”. Se a descrição revisada é meramente uma entrada informal, então os campos alterados são ignorados.

Precisamos reconhecer o que foi alterado nos dados de entrada e gerar a chave de dimensão substituta correta. Toda chave de data warehouse deve ser uma chave substituta porque o DBA deve ter a flexibilidade de reagir a descrições mutantes e a condições anormais nos dados primários. Se a chave real de junção física (physical join key) entre uma tabela de dimensão e a tabela de dados é uma derivaçãop direta de uma chave de produção, mais cedo ou mais tarde o DBA enfrentará uma situação impossível. Chaves de produção podem ser re-usadas ou reformatadas. As vezes o valor de dimensão mesmo pode ser “desconhecido”. A necessidade mais comum para uma chave generalizada existe quando o data warehouse tenta rastrear uma descrição dimensional revisada e a chave de produção não foi alterada.

Decidindo o que mudou

O primeiro passo na preparação de um registro de dimensão é decidir se já possuímos o registro. Os dados primários geralmente terão um valor de chave de produção. Este valor da chave de produção deve ser cruzado com o mesmo campo no registro de dimensão "corrente". Note que na dimensão do data warehouse este é apenas um atributo dimensional comum. O registro de dimensão atual pode ser encontrado rapidamente com um flag atualizável no registro de dimensão que identifica se o registro é ou não é o corrente.

Este cruzamento da chave de produção de entrada, à sua parceria no registro de dimensão corrente pode ser obtido com uma passagem seqüencial simples dos dados primários e os dados da tabela de dimensão, ambos classificados pela chave de produção. Se a informação dimensional de entrada confere com a que já temos, então não é necessária mais nenhuma ação. Se qualquer coisa na informação dimensional de entrada mudou, então devemos aplicar uma alteração na dimensão de tipo 1, tipo 2 ou tipo 3.

Tipo 1: Soprepor. Tomamos a descrição revisada dos dados primários e sobrepomos os conteúdos da tabela de dimensão. Por exemplo, podemos receber um endereço de cliente corrigido. Neste caso, sobreposição é a escolha correta.

Tipo 2: Criação de um registro de dimensão novo. Tomamos a versão anterior do registro de dimensão, se ela existe, e a copiamos, criando um registro de dimensão novo com uma nova chave substituta.

Se não existe uma versão anterior do registro de dimensão, então criamos um completamente novo. Ai, atualizamos este registro com os campos que foram alterados e quaisquer outros campos necessários. Por exemplo, podemos receber um registro de cliente que mostre o estado civil do cliente mudou. Se isto for uma alteração real ao invés de uma correção, então devemos usar este tipo. A nova chave substituta é provavelmente o próximo número inteiro seqüencial que representa o Max (chave de substituição) + 1 para a dimensão em questão. Para acelerar o processamento o valor do eq (chave de substituição) pode ser explicitamente armazenado como Meta Dado ao invés de ser calculado cada vez que seja necessário.

Tipo 3: Desloque o valor alterado para um campo de atributo "antigo". Neste caso, nós antecipamos que um atributo pode sofrer mudanças "soft" que requerem que o usuário se refira a um dos atributos, ao valor antigo ou ao novo. Por exemplo, se uma equipe de vendas é designada a uma região de vendas recentemente nomeada pode ser necessário rastrear a equipe alternadamente na antiga, ou na nova região designada.

Independentemente do tipo de alteração que fizemos ao processar os dados de dimensão de entrada, nossa escolha sempre resultará em um passo de processamento seqüencial de passagem única.

Consolidando a partir de fontes diferentes Dimensões complexas são geralmente derivadas a partir de várias fontes. Pode ser necessário mesclar informações de clientes de várias linhas ou segmentos de negócio e a partir de fontes externas. Normalmente, não existirá uma chave universal que torne fácil esse processo de mesclar. Os dados primários e a tabela de dimensão existente podem ter que ser classificados em ocasiões e campos diferentes para se tentar fazer o cruzamento. Às vezes, o cruzamento pode se basear em critérios pouco precisos; nomes e endereços podem conferir exceto pequenas diferenças de grafia. Nestes casos, um paradigma de processamento seqüencial é mais natural do que uma "equijoin" em um banco de dados relacional. De qualquer forma, cruzamentos pouco precisos não são diretamente suportados em um contexto relacional.

Outra tarefa de cruzamento comum na preparação de dados é buscar textos equivalentes para códigos de produção. Em muitos casos, os textos equivalentes são obtidos informalmente a partir de fontes não produtivas. Novamente, a tarefa de acrescentar a equivalência de textos pode ser feita em uma passagem única, primeiramente classificando-se ambos, os dados primários e a tabela de pesquisa de texto pelo código de produção.

Limpeza de dados

A limpeza de dados pode também envolver a verificação da grafia de um atributo ou a participação de uma tributo em uma lista. Uma vez mais, isto é melhor realizado classificando-se os dados primários e os valores alvos permissíveis e processando-os em uma passagem única de comparação.

Uma conferencia útil da qualidade dos dados, mesmo quando não existia uma lista de participação definida, é simplesmente classificar os dados primários em cada atributo de texto; variações menores em grafia ou pontuação serão destacadas. Uma lista assim classificada pode ser facilmente transformada em uma contagem de freqüência. As grafias com pequena freqüência poderão ser verificadas manualmente, se necessário, e corrigidas.

Processando Nomes e Endereços

Campos de nome e endereço podem ser freqüentemente combinados em um número pequeno de campos genéricos tais como Endereço 1, Endereço 2 e Endereço 3. Os conteúdos desses campos genéricos precisam ser separados em todos os seus elementos constituintes. Uma vez que os campos de nomes e de endereços estejam limpos e formatados conforme um padrão eles poderão ser "decuplicados". O que, à primeira vista, parece ser dois clientes, resulta em um cliente. Talvez um deles tenha uma caixa postal e o outro um endereço completo, mas o restante dos dados claramente revela se tratar do mesmo cliente.

Eu prefiro classificar com um software dedicado de classificação como o SyncSort ao invés de tentar fazer isso em um banco de dados relacional.

Uma forma mais poderosa de eliminar a duplicação é contextualizar pelo domicílio. Neste caso uma unidade econômica consistindo de vários indivíduos é conectada sob um identificador de domicilio único. O caso mais comum seria o marido e a esposa que têm várias contas individuais e conjuntas com várias pequenas diferenças na grafia do nome e dos endereços.

Validando relacionamentos um-para-um e um-para-vários

Se dois atributos em uma dimensão supostamente têm um relacionamento de um para um, você pode verificar isso facilmente, classificando os registros de dimensão por um dos atributos. Uma varredura seqüencial dos dados mostrará se existe alguma violação. Cada valor de atributo na coluna de classificação deve ter exatamente um valor na outra coluna. A verificação deve ser então revertida classificando-se pela segunda coluna, repetindo o processo. Note que não se colocam esses dados em um esquema de entidade-relacionamento para forçar um mapeamento de um para um. Dever-se-ia corrigir quaisquer problemas antes de carregar os dados, o que é o ponto que se discute aqui.

Um relacionamento de uma-para-vários pode similarmente ser verificado classificando-se pelos atributos "vários" e verificando-se que cada valor tem apenas um valor no atributo "um".

Processamento de fatos Os registros de entrada de fatos (fact records) terão chaves de produção, não chaves de data warehouse. A correspondência correta atual entre uma chave de produção e a chave do data warehouse deve ser pesquisada em tempo de carregamento. A pesquisa rápida da chave substituída é facilitada mantendo-se uma tabela de duas colunas que mapeia todas a Ids de produção com relação às chaves substitutas do data warehouse. Se a tabela de pesquisa rápida puder ser mantida em memória durante o processo de substituição de chave, então a tabela fato poderá não requerer a classificação. Se não, o procedimento mais rápido será classificar os registros fatos de chegada, de cada vez, em cada ID de produção e, então, executar a pesquisa da chave substituta em uma única pesquisa seqüencial.

Processamento de Agregados Cada carregamento de registros de fatos requer que agregados sejam calculados ou acumulados. É muito importante manter os agregados em sincronia com os dados base em todo momento. Se os dados base são atualizados e colocados online, mas um atraso ocorre antes que os agregados sejam atualizados, então os agregados deverão ser colocados offline até que fiquem prontos. De contrário, os agregados não refletirão corretamente os dados base. Nesta situação, o DBA tem uma opção entre atrasar toda disponibilização dos dados até que ambos, os dados base e os agregados, estejam prontos ou liberar os dados base revisados em um modo performance degrada enquanto os agregados estão sendo atualizados offline.

A criação de agregados é equivalente à criação de linhas de quebra em um relatório. Se agregados representando totais de produto-categoria são necessários, então os dados de chegada devem ser classificados por produto. Na verdade, várias passagens podem ser necessárias para produzir todas as categorias de agregados. Se os dados da tabela de fatos base têm uma granularidade de produto por loja e por dia, nós poderemos querer produzir os seguintes agregados:

Categoria por loja, por dia
Categoria por região, por dia
Categoria por loja, por mês
Categoria por região, por mês

Se estivermos carregando dados todos os dias, então para cada dia poderemos criar as duas categorias de agregados inteiramente a partir das cargas diárias. Duas classificações dos dados são necessárias: a primeira é por loja/produto com os produtos acumulando em categorias dentro de cada loja; a segunda é por região/produto com produtos acumulando em categorias dentro de cada região.

A primeira classificação pode também ser usada para aumentar o agregado da categoria por loja, por mês pela substituição da chave substituta do dia com a chave substituta do mês apropriado e apresentar este registro à tabela de fatos da categoria por loja, por mês. Por "aumentar", quero dizer que os registros gerados a cada dia causam uma inserção ou uma atualização na tabela de agregados mensais. Não podemos saber se uma inserção ou uma atualização é necessária até que apresentamos o novo registro de agregado à tabela de fatos. Se um registro com a mesma chave já existe, fazemos uma atualização, acrescentando os fatos apropriados àqueles já no registro de destino. Se o registro de mesma chave não está na tabela de fatos, executamos uma inserção. É altamente desejável ter um carregador de SGBD que possa executar essas cargas por lotes (bulk mode). Se um programa seqüencial tem que checar o registro do banco de dados, registro por registro, para decidir se deve executar uma atualização ou uma ou uma inserção, o processamento da carga será bem mais lento.

A questão final: O Data Staging é Relacional? A maioria das atividades de data staging são, na verdade, não relacionais, mas sim, processamentos seqüenciais. Se seus dados de entrada estão em formato de arquivo comum (flat file) deve-se terminar os processos e data staging como arquivos comuns antes de carrega-lo em um banco de dados relacional.

Não se deixe enganar pela habilidade de processar seqüencialmente uma tabela relacional com um cursor relacional e uma linguagem de programação como o PL*SQL da Oracle.

Talvez, tudo que você tenha conseguido seja transformar seu banco de dados relacional em uma espécie de arquivo comum. Isso seria o mesmo que dirigir um tanque para ir à farmácia.

Você se surpreenderá com a velocidade da classificação de arquivos comuns e do processamento seqüencial para o data staging.

A nova geração de fornecedores de extratores como a D2K Inc. Informática Corp., Sagent Technology Inc., e a Vmark Software, todos apresentam paradigmas de processamento seqüencial para o data staging. Confira esses produtos visitando seus sites através dos links do site de Larry Greenfield em pwp.starnetinc.com/larryg/index.html.