Bancos de Dados de Documentos na Modelagem Preditiva

A analítica preditiva depende de processamento, análise de dados de diversas origens diferentes, intercalação e processamento que passa por vários estágios em dados utilizáveis. Isso envolve registrar e armazenar dados em diferentes formatos e pode exigir conversão das informações em PMML. A despeito das complexidades e estrutura das informações, e das origens que frequentemente envolvem dados das origens de dados RDBMS tradicionais, outras soluções oferecem algumas vantagens. Podemos usar a faixa recente de bancos de dados NoSQL baseados em documento para ajudar a intercalar as informações em um formato estruturado, enquanto copia a estrutura flexível dos pontos de dados individuais. Muitos ambientes NoSQL também fornecem suporte para consultas do tipo de redução de mapa abrangente e processamento de grandes volumes de dados em um formato de resumo. Neste artigo, examinaremos a transferência, troca e formatação das informações nos ambientes do NoSQL.

Martin Brown, VP of Technical Publications, Desenvolvedor freelance

author photoEscritor profissional por mais de 15 anos, Martin 'MC' Brown é autor e colaborador de mais 26 livros que abordam uma série de tópicos, incluindo o recentemente publicado Getting Started with CouchDB. Sua especialidade abrange diversas linguagens de desenvolvimento e plataformas Perl, Python, Java, JavaScript, Basic, Pascal, Modula-2, C, C++, Rebol, Gawk, Shellscript, Windows, Solaris, Linux, BeOS, Microsoft® WP, Mac OS e mais. Ele foi o Editor de Tecnologias LAMP da revista LinuxWorld e é um colaborador regular da ServerWatch.com, LinuxPlanet, ComputerWorld e IBM developerWorks. Ele conta com uma experiência rica e variada como membro fundador de um ISP líder no Reino Unido, gerente de sistemas e consultor de TI de uma agência de publicidade e grupo de soluções de Internet, especialista técnico de uma rede de ISP intercontinental e designer e programador de banco de dados. Além disso, ele ainda é um confesso consumidor compulsivo de hardware e software de computação. MC é atualmente o VP da Technical Publications and Education for Couchbase e é responsável por toda documentação publicada, programa de treinamento e conteúdo, e pela Couchbase Techzone.



30/Out/2012

Introdução

Hoje, quer você esteja ciente disso, quer não, é difícil escapar da analítica preditiva. É usada em uma variedade ampla de ambientes de dados diferentes das verificações de cartão de crédito, para gerenciamento de estoque, segurança e monitoramento de segurança.

Em cada ponto no processo, a entrada de dados e uma situação são comparadas a um modelo preditivo que inclui os dados necessários para que o sistema seja capaz de fazer um julgamento. Por exemplo, ao monitorar os sensores de um sistema de segurança, o sistema pode ter de comparar as informações do sensor de entrada com um modelo que define se esse é uma situação de aviso ou alarme. Um gato caminhando por um sensor pode acionar a atividade menor, por exemplo, a ativação da gravação do vídeo, mas não o alarme total, que precisa de um registro de fonte de calor maior.

O desafio em cada uma dessas situações é combinar os dados de entrada com as informações de plano de fundo, e fazer um julgamento. O uso dos padrões abertos como PMML é frequentemente crítico, mas você provavelmente desejará combinar a estrutura do PMML com um histórico passado, ou registrar os acionadores de dados de entrada como parte do inteiro ambiente de analítica.

Por exemplo, com uma transação de cartão de crédito, a analítica preditiva é normalmente usada para capturar comportamento não usual, mas é necessário ter um corpo de informações disponíveis que descrevam o que você sabe sobre o comportamento existente dos clientes, onde eles compram, o tamanho típico das transações e o tempo e datas em que eles fazem tais transações.

O armazenamento e processamento dessas informações e materiais de plano de fundo podem ser uma origem primária do problema. A entrada insuficiente e os dados históricos do passado dentro do modelo conduzirão a decisões inválidas, por exemplo, uma transação completamente válida ser declarada como uma possível fraude, causando embaraço para o seu cliente e tempo adicional para trabalhar com eles e resolver o problema.

Mover um nível nos termo dos requisitos, um problema secundário é a velocidade com que você obtém e processa as informações. Os bancos de dados são projetados para manipular a consulta dos dados que é possível armazenar, mas o nível de processamento necessário para obter as informações e convertê-las em um modelo que possa ser usado dentro da sua camada analítica preditiva, também é crítico. Você não deseja manter um cliente esperando mais de alguns segundos enquanto valida uma transação de cartão de crédito. Geralmente, quanto mais rápido isso acontece, melhor. Mais significativamente, será necessário manipular muitos milhões de outras transações dentro do mesmo período.

Com um sistema de alarme ou monitoramento, a diferença entre uma resposta imediata e alguns segundos pode fazer a diferença entre prevenir um crime ou ser capaz de parar a produção e uma alternativa muito mais catastrófica.


Intercalando Dados no NoSQL

Coletar e intercalar informações de plano de fundo tradicionalmente envolvia registrar essas informações em um banco de dados relacional pesadamente estruturado (RDBMS), como o IBM DB2. A primeira etapa para usar um sistema para registrar informações é criar uma estrutura de dados ou esquema adequado. Por exemplo, é possível usar um modelo como o mostrado na Figura 1 para registrar transações de cartão de crédito.

Figura 1. Registrando transações de cartão de crédito
Registrando transações de cartão de crédito

Registrar dados nesse modelo exige que você tenha todas as informações disponíveis, ou ter, no mínimo, as informações principais (cliente, comerciante ou custo) em que basear suas últimas predições.

Mas o que acontece se o nível de dados nesse cenário mudar? Se você examinou sua fatura de cartão de crédito recentemente, especialmente online, observou que há uma quantidade significativa de informações disponíveis sobre sua transação, algumas vezes incluindo detalhes do que você comprou, que tipo de produto foi e onde esteve pessoalmente ou concluiu a transação online ou por telefone.

Embora possamos alterar os detalhes das informações armazenadas em nosso banco de dados DB2 incluindo campos adicionais, pode ser comparativamente caro, especialmente quando podemos preencher isso em uma tabela com milhões ou mesmo bilhões de linhas de informações.

Considere nosso sensor de alarme, o que acontece se as informações de deslocamento básicas —ou seja, o sensor detectar algo—tiverem sido atualizadas com um sensor mais avançado que pode detectar a temperatura do objeto visto? Em seguida, mais tarde, o que acontece se ele for atualizado com o tamanho e temperatura aproximados? Alterar a tabela cada vez que a qualidade ou quantidade de informações muda não é apenas difícil e consome tempo dentro do RDBMS tradicional, também aumenta a complexidade de obter essas informações de retorno novamente.

Por exemplo, para criar os dados de valor inicial e comparação talvez você tenha de combinar um número de consultas SQL diferente, por exemplo: SELECT MIN(amount),MAX(amount) FROM transactions WHERE customerid = XX.

Para obter as quantidades de transação mínima e máxima para o cliente: SELECT UNIQUE(country) FROM transactions WHERE customerid = XX.

Para obter as informações do país sobre o cliente, no caso de eles comprarem regularmente esse destino: SELECT COUNT(tid) FROM transactions WHERE customerid = XX and merchantid = YY.

Para determinar se o cliente usou alguma vez a empresa antes, e finalmente: SELECT MIN(amount),MAX(amount) FROM transactions WHERE merchantid = YY.

A combinação dessas consultas apenas trata superficialmente o tipo de informações que você deseja normalmente coletar. Na realidade, você provavelmente deseja examinar mais profundamente as transações, inclusive transações individuais de mapeamento, sua frequência e seus valores para chegar a uma decisão para desenvolver seu modelo.

Essas mudanças não apenas alteram o banco de dados em si, mas também como as informações são extraídas, recuperadas e processadas durante o estágio de análise, tudo o que leva tempo e agrega complexidade.

Bancos de Dados de Documento

Pode haver diferentes aspectos para o movimento do NoSQL, mas um dos mais críticos é a movimentação para fora da modelagem de dados baseada no esquema tradicional do RDBMS para um estilo baseado em documento sem esquema, mais flexível.

Dentro de um banco de dados de documentos, em vez de definir um esquema estrito, que envolve criar uma definição de tabela e preenchê-la, as informações são armazenadas como um documento. É, portanto, armazenada pela serialização de um objeto (por exemplo, uma instância com base em Java de uma classe de objeto) ou usando um padrão de dados reconhecidos como JavaScript Object Notation (JSON).

O benefício primário do modelo de documento é que a estrutura não deva ser pré-definida. Vamos examinar uma amostra da transação de cartão de crédito, esse tempo é um documento JSON (veja Listagem 1).

Lista 1. Listagem 1. Amostra da transação de cartão de crédito
{
    "country" : "UK",
    "transaction_country" : "UK",
    "amount" : 23.23,
    "customerid" : "3458983734981294",
    "merchant_country" : "UK",
    "type" : "inperson",
    "merchantid" : "49587",
    "datetime" : "2012-08-23T13:54:00"
}

A estrutura dessas informações leva em consideração a criação de um documento que contém uma grande quantidade de informações, muitas dessas são constantes e é esperado que apareçam nesse tipo de documento, mas os campos individuais são opcionais. É possível impor o nível de exigência na camada do aplicativo, em vez de na camada do banco de dados, permitindo que as informações sejam inseridas e rapidamente atualizadas, mesmo que o conteúdo e informações se expandam.

Para usar o exemplo novamente, se a transação incluir informações detalhadas sobre o que foi comprado, ela pode ser incluída na estrutura de documento (consulte Listagem 2).

Lista 2. Listagem 2. Transação com informações mais detalhadas sobre o que foi comprado
{
    "country" : "UK",
    "merchant_country" : "UK",
    "datetime" : "2012-08-23T13:54:00",
    "amount" : 23.23,
    "transaction_country" : "UK",
    "customerid" : "3458983734981294",
    "type" : "inperson",
    "merchantid" : "49587",
    "items" : [
       {
          "amount" : 10.2,
          "description" : "food"
       },
       {
          "amount" : 13.03,
          "descrition" : "DVD"
       }
    ]
}

Outro registro, agora de um comerciante diferente, contém um nível diferente de informações fornecidas por um sistema de transação diferente para o mesmo cliente (consulte a Listagem 3).

Lista 3. Registro contendo diferente nível de informações
{ 
    "country" : "US", 
    "description" : "Electrical goods",
    "datetime" : "2012-07-01T01:54:00",
    "transacttype" : "internet",
    "transaction_country" : "US", 
    "value" : 192.48, 
    "tax" : 34.29, 
    "addresssupplied" : "yes", 
    "checkcode" : "474", 
    "customerid" : "3458983734981294", 
    "merchantid" : "12875" 
}

A despeito das diferenças nos dados de entrada em cada caso, e a diferença no nível de informações fornecida por cada transação e sistema, há alguns elementos comuns que é possível identificar e extrair do banco de dados. Melhor ainda, é possível marcar os registros para indicar uma versão (se for uma progressão de dados), ou usar uma estrutura de tags para destacar o formato.

Por exemplo, examinando cada documento podemos ainda determinar o valor de cada transação individual, embora as informações estejam em um campo de quantidade em um documento e no campo de valor em outro.

Dentro da solução baseada no documento NoSQL, a extração e identificação das informações podem ocorrer no ponto onde as informações são recuperadas do banco de dados, em vez de ter de processar e inserir as informações nos campos adequados no momento que os dados são recebidos. O modelo MapReduce usado pelo banco de dados NoSQL como Couchbase ou Hadoop pode arcar facilmente com as diferenças na estrutura e formato em cada caso.

Em vez disso, ele insere dados usando estruturas de documento diferentes (mas com elementos comuns), levando em consideração diferenças no processamento, quantidade ou qualidade dos dados e mesmo diferenças nos nomes do campo.

Usar o modelo flexível oferecido pela estrutura de documentos fornece benefícios chave, incluindo:

  • Velocidade de inserção

    Muitas alternativas do NoSQL evitam a indexação típica e conformidade ACID nos bancos de dados tradicionais para melhorar a velocidade, especialmente ao incluir informações.

  • Nenhum esquema

    Sem um esquema fixo, não há nenhuma necessidade de desenvolver uma tabela complexa ou formato de banco de dados, ou criar uma estrutura complexa ou consulta para atualizá-lo.

  • Extensível

    Se a sua estrutura mudar, por exemplo, devido ao formato de dados ou mudança de origem, será possível executar essa mudança de saída e manipulá-la dentro do aplicativo. Com dados preditivos, há mudanças frequentes, expansões e melhorias para os dados de origem.

  • Flexível

    Não apenas é possível armazenar os dados e as mudanças feitas neles, mas também armazenar registros compostos e informações que seriam difíceis (ou exigiriam consultas complexas) dentro de um RDBMS tradicional. Depois de desenvolver um modelo preditivo, é possível armazenar o modelo inteiro novamente no banco de dados do NoSQL.

Esses benefícios não devem ser subestimados; a capacidade de armazenar o que quer que se deseje, sem a estrutura rígida e sem ter de mudar ou alterar o formato de tabela à medida que as origens de informações e desenvolvimento dos aplicativos sejam ideais para natureza em constante mudança e expansão de analítica preditiva.

Escalabilidade

Uma dificuldade chave com muitas soluções RDBMS tradicionais é como você arca com um conjunto de dados cada vez mais crescente. Há numerosas estratégias diferentes disponíveis para você, incluindo o ajuste de escala do hardware, usando camadas de cache como Memcached ou IBM solidDB, e usando réplica e outras técnicas para distribuir os dados entre várias máquinas e permitir que os dados de vários hosts sejam atualizados e lidos.

Ao passo que uma ou todas essas soluções sejam completamente viáveis, elas vêm com um gasto adicional substancial no ponto de criação e implementação da solução escolhida. Usando SQL, especialmente se você deseja executar consultas que necessitem de uma junção de qualquer tipo, complica o processo já que você deve ter acesso a mais do que apenas a tabela principal, mas também aos dados das tabelas na junção.

O modelo de documento frequentemente associado ao banco de dados NoSQL elimina alguns elementos desse processo. Partindo do princípio que os dados podem estar autoencerrados na estrutura do documento, a exigência por junções nem sempre é necessária. Além disso, o ID do documento (ou chave) tratando da natureza do sistema leva em consideração dados a serem mais facilmente distribuídos entre vários nós sem ter de arcar com o problema de manter os outros dados da tabela coerentes e disponíveis, ou se preocupar com de onde eles serão acessados.

A maioria das soluções do NoSQL é deliberadamente projetada com tal escalabilidade em mente. É possível usar muitas soluções de dados de grande porte, maiores, como o Hadoop, para ajudar a intercalar as informações principais e criar o modelo preditivo necessário ao tomar decisões. O Hadoop e outros são especificamente projetados para manipular grandes volumes de dados, e podemos fazer uso da funcionalidade MapReduce integrada nesses sistemas para coletar as informações do cluster e criar o modelo de predição que será usado quando uma transação é solicitada.


Processando Dados Brutos dentro do Ambiente NoSQL

Uma das principais vantagens do banco de dados NoSQL é a combinação da flexibilidade em que você armazena as informações (como já vimos), e como essas informações podem ser extraídas, processadas e armazenadas no banco de dados novamente para facilitar e agilizar o uso na próxima vez.

Muitos dos diferentes bancos de dados NoSQL suportam algum tipo de mecanismo de processamento que processa e, muito frequentemente, reduz ou resume essas informações. Por exemplo, o Hadoop foi especialmente projetado para executar operações MapReduce nos dados de origem e converter essas informações em um formato simplificado.

Com as informações do cartão de crédito, uma função MapReduce pode ser criada para processar as transações passadas de um cliente para trabalhar a transação típica, países e outros limites em uma estrutura adequada para executar a análise final. Isso pode levar em conta todos os parâmetros necessários, além de todas as transações passadas (que seriam uma quantidade significativa de informações de um usuário de cartão frequente). O Hadoop é limitado no aspecto que nem sempre é possível consultá-lo diretamente, pelo menos, não no formato mais útil para analítica preditiva.

O Couchbase Server 2.0 também fornece a funcionalidade MapReduce que pode executar o mesmo nível de análise. Com o Couchbase, as informações do MapReduce são armazenadas em um índice, agilizando muito a obtenção das informações novamente quando precisar delas. Em adição, o Couchbase suporta MapReduce incremental. Isso permite alterar (ou expandir) os dados de origem usados para criar o índice MapReduce e atualizar apenas as informações que mudaram.

Por exemplo, é possível criar uma função mapa dentro do Couchbase Server para processar nosso registro de cartão de crédito de amostra usando o código na Listagem 4 abaixo.

Lista 4. Função map no Couchbase Server para Processar Registro de Crédito de Amostra
function(doc) {
    if (doc.value) {
        emit(doc.customerid, doc.value);
    } else {
        emit(doc.customerid, doc.amount);
    }
}

A chamada de função emit() gera uma linha de dados composta de chave (nosso número de cartão de crédito do cliente) e um valor (o tamanho da transação). O valor pode ser maior, ou um array, ou mesmo um hash de dados, significando que poderíamos realmente gerar um modelo preditivo concluído.

A função map é responsável pelo mapeamento dos campos de entrada para os dados de saída, e, portanto, ideal para manipular esses diferentes formatos de registro de entrada. A função map aqui é escrita em JavaScript e é possível fornecer determinações e cálculos complexos dentro da função map.

A saída da função map é processada e armazenada em um índice de acesso rápido. O processo acontecerá apenas uma vez para cada documento no banco de dados. A função reduce também armazena sua saída no índice, facilitando a criação dos dados.

A função reduce é usada para resumir as informações, das somas e contas mais típicas às estruturas mais complexas, como os altos e baixos que podemos associar ao modelo preditivo de cartão de crédito (veja A Listagem 5).

Lista 5. A função reduce .
function(key, values, rereduce) {
    var result = {total: 0, count: 0};
    for(i=0; i < values.length; i++) {
        if (values[i] < result.min) {
            result.min = values[i];
        }
        if (values[i] > result.max) {
            result.max = values[i];
        }
        if(rereduce) {
            result.total = result.total + values[i];
            result.count++;
        } else {
            result.total = result.total + values[i].total;
            result.count = result.count + values[i].count;
        }
    }
    return(result);
}

Observe que a função está retornando um resultado composto, feito de um objeto do JavaScript que contém os campos total, count, min e max. Felizmente, nossa função map() determinou o campo a partir do qual localizar tais informações. A função reduce apenas precisa reduzir isso para um resultado estruturado.

Poderíamos gerar os dados do modelo preditivo final como parte desse processo de redução, e ter um modelo preditivo gerado completamente do banco de dados (e armazenado no índice para acesso rápido). Podemos usar esse modelo imediatamente para executar a análise.


Ciclo de Vida de Dados do NoSQL

É possível ver um exemplo do ciclo de vida de informações que você pode usar com um banco de dados NoSQL na Figura 2.

Figura 2. Ciclo de vida de informações com um banco de dados NoSQL
Ciclo de vida de informações com um banco de dados NoSQL

O modelo é baseado no modelo de transação de cartão de crédito que estivemos examinando por todo este artigo. O sistema confia em dois conjuntos de dados principais:

  • Transações

    Estes são os registros de dados brutos de todas as transações de cartão de crédito históricas. O sistema de predição preenche as informações quando uma transação é aprovada.

  • Modelo de previsão

    Usando o MapReduce, as transações são processadas em uma estrutura única de modelo preditivo. A estrutura preditiva é armazenada dentro do banco de dados NoSQL como um registro único, permitindo que o sistema de predição recupere e use quando uma transação de entrada chega no sistema.

Conjuntos de dados adicionais podem ser incluídos no sistema para fazer uso das outras informações que podem ser combinadas com os dados de transação para ajudar a formar o documento de modo preditivo. Por exemplo, é possível combinar o conhecimento sobre os deslocamentos conhecidos (dos dados da transação).

O processamento das informações de transação brutas cria o modelo preditivo, que é armazenado no banco de dados NoSQL onde o mecanismo de decisão pode usá-lo para a próxima transação.


Modelando Dados de Entradas nos Documentos

Já vimos alguns exemplos acima de como é possível modelar peças diferentes de informações no banco de dados NoSQL. Dependendo do banco de dados NoSQL que você escolheu, o formato exato e estrutura das informações que você deseja armazenar pode diferir.

Os bancos de dados NoSQL mais práticos usam JSON com um formato de armazenamento, que oferece benefícios adicionais de alguns sistemas. Por exemplo, dentro de alguns bancos de dados NoSQL, o uso do JSON permite que você atualize campos individuais dentro do documento, em vez de recuperar e atualizar todo o documento quando uma modificação é necessária.

O JSON também tem outras utilidades, por exemplo, pode facilmente ser lido, formatado e trocado independentemente da plataforma ou linguagem do aplicativo. Isso o torna ideal para trocar informações entre uma faixa de ambientes de aplicativo diferente. Finalmente, é possível usar o JSON como um formato de troca de dados para objetos de aplicativo. Muitos ambientes suportam a conversão de um objeto interno em uma estrutura JSON e no sentido inverso novamente.

Há algumas práticas comuns e recomendadas para modelar seus dados dentro de um documento ou estrutura JSON, especialmente ao armazenar dados para um modelo preditivo:

  • Armazene as informações comuns, usadas facilmente, no alto nível dentro do documento. As quantidades de transação, países e outras informações diretas são armazenadas dentro de um único campo. Isso simplifica acessar e processar.
  • Use os arrays para armazenar coletas de dados que você normalmente processaria na sua totalidade. Por exemplo, se o seu modelo usa especificamente os itens individuais em uma transação cada vez, então armazene essas informações em um array que possa ser facilmente reiterado.
  • Use hashes quando você deseja executar uma verificação rápida para informações em um formato estruturado. Isso acontece porque é possível procurar pela existência de um campo dentro de um hash em apenas uma única linha. Se você armazenar as informações em um array, terá de iterar pelo o array, o que pode consumir tempo.

Usando essas regras básicas, é possível modelar qualquer origem (relativamente) estruturada de dados em um JSON ou documento similar que pode ser armazenado em um banco de dados NoSQL.


Do PMML para o Documento e do Documento para PMML

Se o ambiente de modelagem preditiva escolhido usar o padrão Predictive Model Markup Language (PMML), assegure que a geração do documento dentro dos estágios MapReduce do NoSQL esteja em um formato que seja fácil de converter para PMML. A melhor abordagem não é criar uma estrutura de documento PMML que possa ser lida novamente, mas usar a capacidade de um banco de dados NoSQL para armazenar documentos —ou seja, o modelo preditivo concluído —e use esse como a base dos dados do PMML.

É possível fazer isso de vários modos dentro da camada de processamento do NoSQL:

  • Crie uma estrutura no JSON (ou seu formato de saída escolhido) que corresponde ao formato PMML. É possível gerar partes do dicionário de dados como um array de elementos diferentes dentro do próprio JSON. Converter esse formato para o PMML requer uma camada adicional de conversão, mas também permite que você consuma mais facilmente e reprocesse as informações de origem sem regenerar a estrutura PMML.
  • Crie o PMML ao lado dos dados do JSON. Esse processo é mais longo e consome mais tempo (e pode ser mais propenso a erro), mas tem o benefício de que o modelo PMML já existe no ponto que ele é necessário.
  • Ou use uma combinação dos dois. Gere o formato do JSON do modelo, e armazene isso no banco de dados NoSQL. Em seguida, gere um modelo PMML se ele for necessário e armazene-o no banco de dados NoSQL de modo que possa ser atualizado para a próxima vez que for necessário. Essa solução exige mais espaço dentro do armazenamento de dados NoSQL, mas pode usar o TTL ou expirar funcionalidade do banco de dados NoSQL, se ele for oferecido para excluir automaticamente o modelo PMML, caso não tenha sido usado por algum tempo.

Evidentemente, qualquer solução que seja necessária para regenerar o modelo dos dados de entrada (como no nosso exemplo do cartão de crédito) implicará em recursos adicionais da CPU.


Conclusão

Os bancos de dados NoSQL removem completamente a necessidade de criar um esquema para os dados que você deseja armazenar, e tem uma grande vantagem, quando é necessário consumir informações de uma variedade de origens diferentes, mas fornecerá por fim alguma parte principal das mesmas informações. Neste artigo, você viu como estruturas diferentes que podem ser armazenadas no NoSQL podem armazenar as mesmas informações, mas em diferentes modos, e como é possível usar a capacidade de processamento do banco de dados NoSQL para converter essas estruturas diferentes em um formato padronizado, e depois usar adicionalmente para criar um modelo preditivo.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre
ArticleID=843407
ArticleTitle=Bancos de Dados de Documentos na Modelagem Preditiva
publish-date=10302012