Algoritmos de correspondência em IBM Master Data Management
IBM Master Data Management utiliza algoritmos de correspondência para mapear registros de dados para entidades de dados mestre. Os engenheiros de dados podem definir algoritmos de correspondência diferentes para cada tipo de entidade em seus dados. Os algoritmos de correspondência podem, então, analisar os dados para avaliar e comparar registros e, em seguida, coletar registros correspondidos para as entidades.
Há duas razões comuns para executar correspondência em seus dados:
- Para deduplicação de registro e resolução de entidade, o processo de correspondência analisa seus dados para determinar se algum registro duplicado existe em seus dados. Os registros duplicados suspeitos são mesclados em entidades de dados principais para estabelecer uma visualização em 360 graus única e confiável de seus dados.
- Para criar outros tipos de associações de entidades, o processo de correspondência analisa seus dados para coletar registros em entidades que representam diferentes tipos de agrupamentos, como um domicílio.
O processo de correspondência
O mecanismo de correspondência passa por um processo definido para correspondência de registros nas entidades. O processo de correspondência inclui três etapas principais:
Normatização. Durante esta etapa, o algoritmo padroniza o formato dos dados para que eles possam ser processados pelo mecanismo de correspondência.
Criação de bucket. O algoritmo classifica os dados em várias categorias ou "buckets" para que eles possam ser comparados como partes da informação.
Comparação. O algoritmo compara os dados para determinar uma pontuação de comparação final. Em seguida, o algoritmo usa a pontuação de comparação para determinar se os registros são uma correspondência.
Cada uma dessas etapas é definida e configurada pelo algoritmo de correspondência.
Correspondência para criar mais de um tipo de entidade
IBM Master Data Management Os algoritmos de correspondência são determinados pelo tipo de entidade dos dados associados. É possível definir mais de um tipo de entidade para cada tipo de registro no modelo de dados. Para cada tipo de entidade, configure e ajuste o algoritmo de correspondência correspondente para garantir que o IBM Master Data Management crie entidades que atendam aos requisitos da sua organização.
Um registro único pode fazer parte de mais de uma entidade separada. Se suas definições de tipo de dados incluírem mais de um tipo de entidade, você poderá executar diferentes tipos de correspondência no mesmo conjunto de dados. Por exemplo, considere um conjunto de dados que inclui registros de pessoa de toda a sua empresa. Se o tipo de registro Pessoa incluir definições para um tipo de entidade Pessoa e um tipo de entidade Domicílio, então é possível executar o algoritmo de correspondência Pessoa para resolução e deduplicação da entidade e também executar o algoritmo de correspondência Domicílio para criar entidades compostas por registros de pessoas que pertencem ao mesmo domicílio.
Regras de resiliência
Você pode usar a API do IBM Master Data Management para configurar regras de resiliência que limitam a forma como o algoritmo de correspondência responde às alterações nos dados dos registros.
Sem regras de resiliência em vigor, há uma série de possíveis alterações de vinculação de entidades que podem ocorrer quando um registro de dados mestre é adicionado, atualizado ou excluído:
Se um novo registro for adicionado, ele poderá:
- Associar-se a uma entidade existente.
- Faz com que duas ou mais entidades existentes se unam, atuando como um registro de cola.
- Forma uma nova entidade singleton.
Se um registro for atualizado, ele poderá:
- Não pertence mais à sua entidade atual e se torna uma nova entidade singleton.
- Deixar de pertencer à sua entidade atual e passar a integrar outra entidade existente.
- Faz com que sua entidade atual se divida em várias entidades.
- Faz com que outras entidades se juntem à entidade existente, atuando como um registro de cola.
- Não causa alterações na composição da entidade.
Se um registro for excluído, ele poderá:
- Faz com que sua entidade singleton também seja excluída.
- Faz com que sua entidade atual seja dividida.
Ao definir regras de resiliência, os engenheiros de dados podem configurar como o mecanismo de correspondência do IBM Master Data Management responde a cada um desses cenários. O mecanismo de correspondência controla seu comportamento de vinculação para se alinhar com as regras de resiliência que você configurou. Ao configurar as regras de resiliência, você pode limitar as fusões e divisões de entidades, o que significa que você pode ter uma composição de entidades mais estável.
Defina regras de resiliência usando a API ' resiliency_rules. Se uma determinada regra for definida como ' FALSE, o cenário de vinculação de entidade correspondente não concluirá suas alterações usuais de vinculação de entidade.
Para obter o conjunto atual de regras de resiliência, execute o seguinte comando de API:
GET /mdm/v1/resiliency_rules
Para atualizar as regras de resiliência, execute o seguinte comando de API com uma carga útil atualizada:
PUT /mdm/v1/resiliency_rules
{
"link_resiliency_rules": {
"records": {
"person": {
"add": {
"join_existing_entity": "true/false",
"merge_entities": "true/false"
},
"update": {
"record_becoming_singleton": "true/false",
"join_existing_entity": "true/false",
"original_entity_split": "true/false",
"merge_entities": "true/false"
},
"delete": {
"singleton_entity_deletion": "true",
"original_entity_split": "true/false"
}
}
},
"entities": {
}
}
}
Ajustar as pontuações de correspondência com base na frequência
Você pode configurar o algoritmo de correspondência do IBM Master Data Management para ajustar as pontuações de correspondência com base na frequência ou raridade dos tokens correspondentes em seus dados reais. Esse recurso utiliza a distribuição real de tokens em seu conjunto de dados, e não estatísticas populacionais genéricas, para tomar decisões de pontuação mais precisas.
Quando os algoritmos de correspondência tratam todas as correspondências de tokens da mesma forma, a correspondência com o sobrenome “Smith” tem o mesmo peso que a correspondência com “Xylander” Na verdade, a correspondência com um nome muito comum como “Smith” é muito menos distintiva do que a correspondência com um nome raro como “Xylander”
Sem o reconhecimento de frequência, o sistema pode:
- Priorizar as correspondências em tokens comuns. Por exemplo, dois registros com o nome "John Smith" recebem uma pontuação alta, embora "John" e "Smith" sejam nomes extremamente comuns e possam facilmente pertencer a pessoas diferentes.
- Sublinhe as correspondências em tokens raros. Por exemplo, dois registros com o nome “Subbu Sai Reddy” recebem uma pontuação modesta, embora a raridade desses nomes torne muito provável que se refiram à mesma pessoa.
Configuração da correspondência baseada em frequência
Para configurar a correspondência baseada em frequência para qualquer função de comparação em seu algoritmo de correspondência, adicione os seguintes parâmetros às funções comparison do algoritmo de correspondência. Três parâmetros controlam o comportamento da correspondência baseada em frequência:
min_freq_cut_off- Os tokens mais raros do que essa frequência recebem um bônus de pontuação.max_freq_cut_off- Os tokens mais comuns do que essa frequência recebem uma penalidade na pontuação.scaling_coefficient(opcional) - Controla a intensidade do ajuste (valor mais alto = efeito mais forte). O valor padrão é 1.
Para ativar a correspondência baseada na frequência:
Adicione os parâmetros de
min_freq_cut_offconfiguração,max_freq_cut_off, e, opcionalmente,scaling_coefficientaos métodos de comparação relevantes na definição do seu algoritmo.Execute a tarefa de cálculo de frequência utilizando a seguinte API do IBM Master Data Management :
POST /mdm/v1/bulk_freq_calculationA tarefa de cálculo de frequência analisa seus registros existentes e calcula estatísticas de frequência de tokens.
Opcionalmente, visualize os resultados da tarefa de cálculo de frequência executando a seguinte API:
GET /mdm/v1/token_frequenciesA resposta identifica quais tokens são considerados valores atípicos e mostra suas frequências.
Executar correspondência. Após a conclusão da tarefa de cálculo de frequência, os ajustes de pontuação com base na frequência são aplicados automaticamente quando você executa a correspondência.
Observações sobre a correspondência baseada na frequência
Considere as seguintes notas de uso para a correspondência baseada na frequência:
- Uso de memória — As frequências dos tokens são carregadas em um cache na memória dos pods correspondentes para permitir consultas mais rápidas em tempo de execução, o que consome memória do contêiner (aproximadamente 90 bytes por par token-frequência). Para evitar que os pods correspondentes fiquem sem memória, a tarefa de geração de frequências permite definir um limite configurável para o número de tokens atípicos retidos. Ajuste este parâmetro de acordo com o tamanho do seu conjunto de dados e a memória disponível no pod.
- Atualização do cache — Para recalcular as frequências dos tokens e aplicar os valores atualizados, certifique-se de que não ocorram ações de criação, atualização ou exclusão de registros (ou seja, nenhuma correspondência em tempo real) por pelo menos 10 minutos, incluindo o tempo de execução da tarefa. Esse período de espera permite que o cache existente expire e seja recarregado.
Componentes do algoritmo de correspondência
Três tipos principais de componentes definem um algoritmo de correspondência do IBM Master Data Management :
Padronizadores
Como o nome sugere, os padronizadores definem como os dados são padronizados. A padronização permite que o algoritmo de correspondência converta os valores de diferentes atributos em uma representação padronizada que possa ser processada pelo mecanismo de correspondência.
O algoritmo de correspondência usa vários padronizadores. Cada padronizador é adequado para processar tipos de atributos específicos encontrados nos dados de registro.
Os padronizadores são definidos por objetos JSON. A definição de cada objeto JSON do padronizador contém três elementos:
label- um rótulo que identifica este padronizador.inputs- a listainputspossui um elemento, que é um objeto JSON. Esse objeto JSON tem dois elementos:fieldseattributes:fields- a lista de campos a serem usados para padronização.attributes- a lista de atributos a serem usados para padronização.
standardizer_recipe- uma lista de objetos JSON em que cada objeto representa uma etapa a ser executada durante o processo de normatização do padronizador associado. Cada objeto na listastandardizer_recipeconsiste em quatro elementos principais:label- um rótulo que identifica esta etapa na receita do padronizador.method- o método interno usado. Este elemento é apenas para referência e não deve ser editado.inputs-Um único elemento da listainputsdefiniu um nível mais altofields- uma lista dos campos a serem usados para esta etapa. Esse é geralmente um subconjunto de todos os campos definidos na listainputsum nível mais alto. Nem toda etapa precisa processar todos os campos doinputs.set_resource- o nome de um recurso customizável do tiposetusado para esta etapa.map_resource- o nome de um recurso customizável do tipomapusado para esta etapa.
Dependendo do comportamento de uma etapa, pode haver mais elementos de configuração que são necessários no objeto JSON correspondente.
Padronizadores pré-configurados
Os seguintes padronizadores estão prontos para uso em IBM Master Data Management. Os padronizadores pré-configurados também são personalizáveis.
Nome da Pessoa
Este padrão é usado para padronizar valores de atributo Person Name. Ele contém as seguintes receitas, em sequência:
Upper case-Converte os valores de campo de entrada para usar seus equivalentes de uppercase.Map character-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes. Opcionalmente, defina o mapa nos recursos IBM e Master Data Management.Tokenizer-Tokeniza o valor do campo de entrada em vários tokens, com base na lista definida de delimitadores.Parse token- Analisa os valores dos campos de entrada em diferentes tokens, dependendo dos valores predefinidos nos recursos IBM e Master Data Management. Por exemplo, você pode usar esta receita para analisar valores de sufixo, prefixo e de geração em campos apropriados.Length-Descarta tokens que estão fora de um intervalo de comprimento determinado. Os valores mínimo e máximo estão definidos nos recursos IBM e Master Data Management.Stop token-Remove valores de entrada anônimos, conforme configurado.Pick token-Seleciona um subconjunto (ou todos) dos tokens como os dados padronizados para usar em bucketing e comparação.
O padronizador de Nome da Pessoa usa os seguintes recursos de Mapa por padrão:
map_character_general-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes.person_map_name_alignments-analisa valores de sufixo, prefixo e geração em campos apropriados.
O padronizador Nome da Pessoa usa os seguintes recursos do Conjunto por padrão:
person_set_name_aname-Remove os valores de nome de pessoa anônima
Nome da organização normando
Este padrão é usado para padronizar valores de atributos de Nome da Organização. Ele contém as seguintes receitas, em sequência:
Upper case-Converte os valores de campo de entrada para usar seus equivalentes de uppercase.Map character-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes. Opcionalmente, defina o mapa nos recursos IBM e Master Data Management.Stop character-Remove caracteres de entrada indesejados de valores de nomes.Map token-Gera apelidos ou nomes alternativos para a entrada dada e armazena as informações em um novo campo interno separado.Tokenizer-Tokeniza o valor do campo de entrada em vários tokens, com base na lista definida de delimitadores.Stop token-Remove valores de entrada anônimos, conforme configurado.Acronym-Gera um acrônimo para o nome de organização determinado e armazena as informações em um novo campo interno separado. Esse valor de acrônimo é usado durante a comparação para tratar de nomes abreviados.Pick token-Seleciona um subconjunto (ou todos) dos tokens como os dados padronizados para usar em bucketing e comparação.
O padronizador de Nome da Organização usa os seguintes recursos de Mapa por padrão:
map_character_general-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes.org_map_name_cnick_name-Gera apelidos ou nomes alternativos para a entrada fornecida.
O padronizador do Nome da Organização usa os seguintes recursos do Conjunto por padrão:
org_set_name_aname-Remove os valores de nome da organização anônima
Data padrão
Este padrão é usado para padronizar valores de atributos Data. Ele suporta muitos formatos de data diferentes e contém as seguintes receitas, em sequência:
Map character-Converte caracteres slash (/) para dash caracteres (-).Date function-Converte entradas de data em formatos diferentes para um formato padronizado.Stop token-Remove valores de data anônima, conforme configurado.Parse token-Analisar os valores do campo de entrada para tokens diferentes, dependendo de determinadas expressões regulares Por exemplo, você pode usar esta receita para analisar uma entrada de data completa em tokens de dia, mês e ano.Pick token-Seleciona um subconjunto (ou todos) dos tokens como os dados padronizados para usar em bucketing e comparação.
O padronizador de Data usa os seguintes recursos de Mapa por padrão:
map_character_date_separators-Converte barra (/) ou quaisquer outros caracteres separadores em caracteres de traço (-).map_date_tokens_year_month_day-analisa o valor de data de entrada para campos internos, ou seja,birth_year,birth_monthebirth_day, com base em expressões regulares.
O padronizador de Data usa os seguintes recursos do Conjunto por padrão:
set_date_date-Remove os valores de data anônimos
Padronamento de gênero
Este padrão é usado para padronizar valores de atributo Gender. Ele contém as seguintes receitas, em sequência:
Map character-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes. Opcionalmente, defina o mapa nos recursos IBM e Master Data Management.Upper case-Converte os valores de campo de entrada para usar seus equivalentes de uppercase.Stop token-Remove valores de gênero de entrada anônimos, conforme configurado.Map token- Converte os valores dos tokens de entrada em valores equivalentes, conforme configurado nos recursos IBM e Master Data Management.Parse token-Parsa valores de campo processado para um campo interno apropriado.Pick token-Seleciona um subconjunto (ou todos) dos tokens como os dados padronizados para usar em bucketing e comparação.
O padronizador de Gênero usa os seguintes recursos de Mapa por padrão:
map_character_general-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes.map_gender_gender-Mapea diferentes valores de gênero de entrada para valores padrãomap_gender_tokens_gender-Analisar o valor do token de entrada para o campogenderinterno com base na expressão regular
O padronizador de Gênero usa os seguintes recursos do Conjunto por padrão:
set_gender_anon_gender-Remove os valores de gênero de entrada anônimos
Padrão de endereço
Este padrão é usado para padronizar valores de atributo de Endereço. Os endereços podem ter vários formatos diferentes, dependendo dos locales. Essa flexibilidade requer um processamento complexo para converter endereços em uma forma padronizada. O Address standdizer contém as seguintes receitas, em sequência:
Upper case-Converte os valores de campo de entrada para usar seus equivalentes de uppercase.Map character-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes. Opcionalmente, defina o mapa nos recursos IBM e Master Data Management.Map token- Converte os valores dos tokens de entrada em valores equivalentes, conforme configurado nos recursos IBM e Master Data Management. Por exemplo, “Estados Unidos da América ”, “Estados Unidos ” e “EUA” podem todos ser mapeados para “EUA ”. Esse mapeamento é comum para os valores de campo do país e da província / estado. Além disso, caracteres delimitadores configurados no recurso são mapeados para o caractere de espaço.Tokenizer-Tokeniza o valor do campo de entrada em vários tokens, com base na lista definida de delimitadores.Stop token-Remove valores de entrada anônimos, como códigos postais, conforme configurado.Keep token-Permite apenas a lista definida de valores para um determinado campo. Por exemplo, você pode definir uma lista de códigos postais que são permitidos durante a padronização. Valores de entrada que não estão na lista permitida serão removidos.Parse token-analisa os valores do campo de entrada para campos internos apropriados, dependendo de determinadas expressões regulares e valores predefinidos, conforme configurado nos recursos. Você pode usar esta receita para truncar um determinado token para um certo comprimento usando expressões regulares. Você também pode definir diferentes conjuntos de padrões alfanuméricos sob a forma de expressões regulares para permitir apenas certos padrões.Join fields-Junta-se dois ou mais campos juntos para criar um novo valor combinado, atribuído a um campo interno. Por exemplo, os valores de campolatitudeelongitudepodem ser unidos para formar um novo campo interno chamadolat_long.Pick token-Seleciona um subconjunto (ou todos) dos tokens como os dados padronizados para usar em bucketing e comparação.
O padronizador de Endereço usa os seguintes recursos de Mapa por padrão:
map_character_general-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes.map_address_country-Converte os valores do país de entrada em valores equivalentesmap_address_province_state-Converte valores de província e de estado de entrada em valores equivalentesmap_address_delimiter_removal-Caracteres delimitadores de mapas configurados no recurso para o caractere de espaço.map_address_addr_tok-Converte os valores do token de endereço de entrada em valores equivalentesmap_address_tokens_unit_type_and_number-analisa o campo de entradaresidence_numbercom base na expressão regular para campos internos, a saberunit_typeeunit_number.map_address_tokens_street_number_name_direction_type-analisa o campo de entradaaddress_line1com base na expressão regular para campos internos, a saberstreet_number,street_name,directionestreet_type.map_address_tokens_sub_division-analisa o campo de entradaaddress_line2com base na expressão regular no campo internosub_division.map_address_tokens_pobox_type_and_number-analisa o campo de entradaaddress_line3com base na expressão regular para campos internos, a saberpobox_typeepobox.map_address_tokens_city-Analisar o valor de entrada do campocitycom base na expressão regularmap_address_tokens_province-analisa o valor de entrada do campoprovince_statebaseado na expressão regular para o campo internoprovince.map_address_tokens_postal_code-Analisar o valor de entrada do campozip_postal_codecom base na expressão regular para o campo internopostal_code.map_address_tokens_country-analisa o valor de entrada do campocountrycom base na expressão regular.map_address_tokens_latitude-Analisar o valor de entrada do campolatitude_degreescom base na expressão regular para o campo internolatitudemap_address_tokens_longtitude-Analisar o valor de entrada do campolongitude_degreescom base na expressão regular para o campo internolongitude.
O padronizador de Endereço usa os seguintes recursos de Conjunto por padrão:
set_address_postal_code-Remove os valores de entrada anônimos parazip_postal_code
Telefone normalizado
Este padrão é usado para padronizar valores de atributo Phone. Ele contém as seguintes receitas, em sequência:
Stop character-Remove caracteres de entrada indesejados de valores de telefone.Stop token-Remove valores de telefone anônimos, conforme configurado.Phone-Parsa números de telefone de entrada com formatos diferentes de diferentes locales em um formato comum. Esta receita pode ser configurada para remover códigos de área e códigos de país a partir de números de telefone. Ele também pode reter um determinado número de dígitos em um número de telefone padronizado.Parse token-Os parsos processam valores de campo para um campo interno apropriado dependendo de determinadas expressões regulares, conforme configurado nos recursos.Pick token-Seleciona um subconjunto (ou todos) dos tokens como os dados padronizados para usar em bucketing e comparação.
O padronizador de Telefone usa os seguintes recursos de Mapa por padrão:
map_phone_tokens_phone-Analisar valores de telefone para um campo interno com base em expressões regulares
O padronizador de Telefone usa os seguintes recursos de Conjunto por padrão:
set_character_phone-Substitui todos os caracteres que não são alfanuméricos. Permite especificar expressões regulares.set_phone_anon_phone-Remove valores de telefone anônimo.
Padronamento de identificação
Este padrão é usado para padronizar valores de atributo de Identificação. Ele contém as seguintes receitas, em sequência:
Map character-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes. Opcionalmente, defina o mapa nos recursos IBM e Master Data Management.Upper case-Converte os valores de campo de entrada para usar seus equivalentes de uppercase.Stop character-Remove caracteres de entrada indesejados a partir de valores de identificação.Stop token-Remove valores de entrada anônimos, conforme configurado.Map token- Converte os valores dos tokens de entrada em valores equivalentes, conforme configurado nos recursos IBM e Master Data Management.Parse token-Os parsos processam valores de campo para um campo interno apropriado dependendo de determinadas expressões regulares, conforme configurado nos recursos.Pick token-Seleciona um subconjunto (ou todos) dos tokens como os dados padronizados para usar em bucketing e comparação.
O padronizador de Identificação usa os seguintes recursos de Mapa por padrão:
map_character_general-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes.map_identifier_equi_identifier-Converte os valores do token de entrada em valores equivalentesmap_identifier_tokens_identification_number-Os parsos processam valores de campo para um campo interno apropriado dependendo de determinadas expressões regulares, conforme configurado nos recursos.
O padronizador de Identificação usa os seguintes recursos de Conjunto por padrão:
set_character_identification_number-Remove caracteres de entrada não alfanuméricos de valores de identificação Permite especificar expressões regulares.set_identifier_anonymous-Remove os valores de identificação anônimos
Padronamento de e-mail
Este padrão é usado para padronizar valores de atributo Email. Ele contém as seguintes receitas, em sequência:
Map character-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes. Opcionalmente, defina o mapa nos recursos IBM e Master Data Management.Upper case-Converte os valores de campo de entrada para usar seus equivalentes de uppercase.Stop token-Remove valores de entrada anônimos, conforme configurado.Map token- Converte os valores dos tokens de entrada em valores equivalentes, conforme configurado nos recursos IBM e Master Data Management.Parse token-Os parsos processam valores de campo para um campo interno apropriado dependendo de determinadas expressões regulares, conforme configurado nos recursos.Pick token-Seleciona um subconjunto (ou todos) dos tokens como os dados padronizados para usar em bucketing e comparação.
O padronizador de e-mail usa os seguintes recursos de Mapa por padrão:
map_character_general-Converte caracteres de entrada UNICODE para caracteres de alfabeto inglês equivalentes.map_non_phone_equi_non_phone-Converte os valores do token de entrada em valores equivalentesmap_non_phone_tokens_non_phone-Analisar o campo de entradaemail_idcom base na expressão regular para os campos internosemail_local_parteemail_domain
O padronizador de e-mail usa os seguintes recursos de configuração por padrão:
set_non_phone_anon_non_phone-Remove valores de e-mail anônimo.
Tipos de entidade (bucketing)
Dentro de um único algoritmo de correspondência, cada tipo de registro pode ter várias definições de tipo de entidade (objetos JSON entity_type). Por exemplo, em um algoritmo definido para um tipo de registro de pessoa, você pode precisar criar mais de uma definição de tipo de entidade, como entidade de pessoa, entidade de domicílio, entidade de localização, etc.
Cada tipo de entidade pode ser usado para corresponder e vincular registros de diferentes formas. Um tipo de entidade define como os registros são depositados e comparados durante o processo de correspondência.
Cada definição de tipo de entidade (entity_type) no algoritmo correspondente tem vários elementos JSON:
clerical_review_threshold- os registros que possuem uma pontuação de comparação inferior ao limite de revisão administrativo são considerados como não correspondências.auto_link_threshold- os registros que possuem uma pontuação de comparação superior ao limite de link automático são considerados como correspondências fortes o suficiente, que eles são correspondidos automaticamente.bucket_generators- Esta seção contém a definição dos geradores de bucket configurados para um tipo de entidade. Existem dois tipos de geradores de bucket: buckets e grupos de bucket.Baldes envolvem a criação de bucket para apenas um atributo. Cada definição do
bucketinclui quatro elementos:label- um rótulo que identifica o gerador de bucket.maximum_bucket_size- um valor que define o tamanho de buckets grandes. Qualquer hash de bucket com um tamanho de bucket maior do que este valor não é considerado para seleção de candidato durante a correspondência.inputs- para buckets, a listainputspossui apenas um elemento, que é um objeto JSON. Esse objeto JSON tem dois elementos:fieldseattributes:fields- a lista de campos a serem usados para a criação de bucket.attributes- a lista de atributos a serem usados para a criação de bucket.
bucket_recipe- uma lista de receita de bucket define as etapas para que o gerador de bucket seja concluído durante o processo de criação de bucket. Cada listabucket_recipepossui uma série de subelementos:label- um rótulo que identifica o elemento da receita do bucket.method- o método interno usado. Este elemento é apenas para referência e não deve ser editado.inputs-Um único elemento da listainputsdefiniu um nível mais altofields- uma lista dos campos a serem usados para este bucket. Esse é geralmente um subconjunto de todos os campos definidos na listainputsum nível mais alto.min_tokens- o número mínimo de tokens a serem usados quando a receita está formando um hash de bucket.max_tokens- o número máximo de tokens a serem usados em conjunto quando a receita estiver formando um hash de bucket.count- um limite no número de hashes de bucket para um registro único que é gerado fora de um gerador de bucket. Se um registro gerar muitos hashes de bucket, apenas o número de hashes configurado por este elemento será selecionado.bucket_group- o número da sequência para um grupo de buckets que produz um hash de bucket. Etapas ou receitas intermediárias não receberiam um número de sequência.order- especifica se os tokens são classificados em ordem lexicográfica quando vários tokens são combinados para formar um hash de bucket.maximum_bucket_size- um valor que define o tamanho de buckets grandes. Este elemento é o mesmo que o definido no nível do gerador de bucket; tê-lo no nível de receita do bucket também proporciona um controle mais fino sobre buckets individuais grandes.
Grupos de bucket envolvem a criação de bucket para mais de um atributo. Cada definição do
bucket_groupinclui cinco elementos:label- um rótulo que identifica o gerador de bucket.maximum_bucket_size- um valor que define o tamanho de buckets grandes. Qualquer hash de bucket com um tamanho de bucket maior do que este valor não é considerado para seleção de candidato durante a correspondência.inputs- para grupos de bucket, a listainputstem mais de um elemento de objeto JSON. Cada um dos objetos JSON tem dois elementos:fieldseattributes:fields- a lista de campos a serem usados para a criação de bucket.attributes- a lista de atributos a serem usados para a criação de bucket.
bucket_recipe- uma lista de receita de bucket define as etapas para que o gerador de bucket seja concluído durante o processo de criação de bucket. Cada listabucket_recipepossui uma série de subelementos:label- um rótulo que identifica o elemento da receita do bucket.method- o método interno usado. Este elemento é apenas para referência e não deve ser editado.inputs-Um único elemento da listainputsdefiniu um nível mais altofields- uma lista dos campos a serem usados para este bucket. Este é geralmente um subconjunto de todos os campos que são definidos na listainputsum nível mais alto.min_tokens- o número mínimo de tokens a serem usados quando a receita está formando um hash de bucket.max_tokens- o número máximo de tokens a serem usados em conjunto quando a receita estiver formando um hash de bucket.count- um limite no número de hashes de bucket para um registro único que é gerado fora de um gerador de bucket. Se um registro gerar muitos hashes de bucket, apenas o número de hashes configurado por este elemento será selecionado.bucket_group- o número da sequência para um grupo de buckets que produz um hash de bucket. Etapas ou receitas intermediárias não receberiam um número de sequência.order- especifica se os tokens são classificados em ordem lexicográfica quando vários tokens são combinados para formar um hash de bucket.maximum_bucket_size- um valor que define o tamanho de buckets grandes. Este elemento é o mesmo que o definido no nível do gerador de bucket. Ser capaz de defini-lo no nível da receita do bucket proporciona um controle mais fino sobre buckets individuais grandes.set_resource- o nome de um recurso do tiposetusado para uma receita de bucket.map_resource- o nome de um recurso do tipomapusado para uma receita de bucket.output_fields- se esta receita produzir novos campos depois de concluir as funções de criação de bucket nos campos de entrada, este elemento conterá uma lista dos nomes dos campos gerados.
bucket_group_recipe- uma seção de receita de grupo de buckets é usada normalmente para definir buckets que consistem em mais de um atributo. Todo elemento de uma listabucket_group_recipeé um objeto JSON que define a construção para um único grupo de buckets.- A lista
inputsembucket_group_recipetem mais de um elemento, o que significa que ela se refere a mais de um atributo definido na matrizinputsum nível superior. - O elemento
fieldsé uma lista das listas. Toda lista interna de campos está associada à respectiva listaattributes. - As listas
min_tokensemax_tokenspossuem mais de um elemento, com cada elemento correspondente à respectiva listaattributes.
- A lista
Nota:Em algumas definições de receita de bucketing, há uma propriedade denominada
search_only. Por padrão, o seu valor éfalse. Se configurado comotrue, essa propriedade indicará que um depósito ou grupo de depósitos é usado apenas para cenários de procura probabilística e não é usado para cenários de resolução de entidade (correspondência)
compare_methods- definições dos métodos de comparação que são configurados para um tipo de entidade. Cada objeto JSONcompare_methodsconsiste em definições de vários métodoscompare. O algoritmo de correspondência soma as pontuações de cada definição de métodocomparepara obter a pontuação de comparação final. Cada objeto JSON do métodocomparecontém três elementos:label- um rótulo que identifica o métodocompare.methods- uma lista de comparadores que formam um grupo de comparação. Todo elemento dessa matriz representa um comparador, destinado a um tipo de atributo de correspondência. O algoritmo de correspondência considera o máximo das pontuações de todos os comparadores em uma lista domethodscomo a pontuação final a partir deste grupo de comparação. Cada definição de comparador inclui dois elementos:inputs- para comparadores, a listainputspossui apenas um elemento, que é um objeto JSON. Esse objeto JSON tem dois elementos:fieldseattributes:fields- a lista de campos a serem usados para comparação.attributes- a lista de atributos a serem usados para comparação.
compare_recipe- esta lista é usada principalmente para definição das etapas de comparação. Geralmente, há apenas um elemento JSON nesta matriz, representando apenas uma etapa para fazer a comparação. Esta etapa tem cinco elementos:label- um rótulo que identifica a etapa de comparação.method- o método interno usado. Este elemento é apenas para referência e não deve ser editado.inputs-Um único elemento da listainputsdefiniu um nível mais altofields-Os campos a serem usados para essa comparação de todos os campos que são definidos na listainputsum nível superior.comparison_resource- o nome de um recurso de comparação customizável usado para esta etapa de comparação.
weights- cada comparação que é feita por um comparador resulta em uma pontuação de número entre 0 e 10. Esse número é chamado de distância ou medida de dissimilaridade. Uma distância de 0 indica que os valores que estão sendo comparados são exatamente os mesmos. Uma distância de 10 indica que eles são completamente diferentes. Correspondendo aos 11 valores distintos (0 - 10), são definidos 11 pesos para cada comparador. Após calcular a distância, o método de comparação determina o valor de peso correspondente da lista de pesos, resultando na pontuação de comparação total. Os engenheiros de dados podem customizar os pesos conforme necessário, com base na qualidade ou distribuição de dados ou em outros fatores.
record_filter-O elemento de filtro de registro permite que o mecanismo correspondente selecione registros para correspondência com base em seus tipos de entidade. Cada definição de filtro de registro contém um elemento:criteria-Inclui ou exclui registros da consideração de correspondência com base em condições específicas Esse elemento contém um objeto JSON com um par de valores de chaves.A chave do objeto JSON do
criteriaé um nome de atributo Ele pode ser um dos seguintes:- O atributo de sistema
record_source - Um atributo customizado definido pelo usuário de um tipo de atributo simples (sequência).
- O atributo de sistema
O valor do objeto JSON
criteriaé outro objeto JSON que contém um elemento, que pode ser um dos seguintes:allowed-Uma matriz de valores de sequência. Registros que incluem qualquer um desses valores serão considerados durante a correspondência.disallowed-Uma matriz de valores de sequência. Registros que incluem qualquer um destes valores não serão considerados durante a correspondência.
source_level_thresholds-Os limites de nível de origem permitem definir limites de link automático e de revisão clerical em uma base de origem para origem. Os limites de nível de origem substituem os valores do limite global padrão. Cada configuração de limite de nível de origem contém uma coleção de origens com limites padrão opcionais específicos da origem ou uma coleção de pares de limites de origem para origem que permitem definir limites diferentes para cada origem... Para obter mais informações, consulte Configurando limites de correspondência específicos de origem no tópico Ajuste de algoritmo de correspondência avançado
Recursos de bucketing.
As definições de bucketing usam os seguintes recursos de Mapa por padrão:
person_map_name_nickname-Gera apelidos ou nomes alternativos para uma determinada entrada de nome de pessoaorg_map_name_cnick_name-Gera apelidos ou nomes alternativos para uma determinada entrada de nome da organização
As definições de bucketing usam os seguintes recursos do Set por padrão:
person_set_name_bkt_anon-Remove os valores de nome de pessoa anônimaorg_set_name_acname-Remove os valores de nome da organização anônima
Funções de comparação
Funções de comparação, às vezes chamadas de comparadores, são um dos componentes principais do algoritmo de correspondência. As funções de comparação são utilizadas pelo motor correspondente para comparar dados de registro durante o processo de correspondência. Essencialmente, a correspondência de registros envolve a comparação de diferentes tipos de atributos entre dados de registros diferentes.
Para muitos dos tipos de atributos comumente usados nos domínios de pessoas, organizações e locais, o mecanismo de correspondência IBM Master Data Management inclui métodos de comparação pré-configurados.
Em IBM Master Data Management, as funções de comparação utilizam uma abordagem conhecida como vetores de características. Existem várias definições de recursos personalizáveis em IBM Master Data Management que são utilizadas para diferentes funções de comparação. Cada comparação resulta em uma medida de distância (um vetor) que mostra como são desparecidos dois valores de atributos dados.
No algoritmo de correspondência, cada valor de distância discreta é dado um peso que determina o quão fortemente se considera esse valor. O peso combina com a distância para produzir uma pontuação de comparação. O algoritmo de correspondência soma todas as pontuações de comparação juntas para chegar a uma pontuação de comparação final para a comparação geral de registro a recorde.
Sobre os Recursos
Um recurso representa os detalhes de nível fino de uma função de comparação. Diferentes tipos de atributos utilizam diferentes tipos de verificações de similaridade, significando que suas características variam também.
As definições de recurso ditam os tipos de funções internas utilizadas para cada função de comparação. Exemplos de funções internas incluem correspondência exata, distância de edição, apelido, equivalente fonético ou partida inicial.
Recursos de comparação
Cada método de comparação inclui recursos que contêm detalhes de suas operações de comparação internas.
Cada um dos tipos de comparação padrão possui seus recursos próprios Consulte cada tipo comparação para obter detalhes dos recursos associados.
Para comparações em tipos de atributos customizados que possuem um tipo correspondente de generic, o método de comparação genérico inclui os seguintes recursos:
compare_spec_generic-No algoritmo gerado, o formato de nome desse recurso érecordType_entityType_compare_spec_generic
Comparações de nome da pessoa
Campos diferentes dentro de um atributo de nome de pessoa são tratados de forma diferente. Para campos como prefixo, sufixo e valores de geração, a exequibilidade ou não correspondência é verificada. Outros campos como nome dado, sobrenome e nome do meio utilizam principalmente os seguintes recursos:
- Correspondência exata
- Correspondência de apelido
- Distância de edição
- Partida de iniciais
- Correspondência fonética
- Deslocamento de tokens
- Tokens extras
- Valores omissos
O método de comparação de Nome da pessoa inclui os seguintes recursos:
person_compare_spec_name-No algoritmo gerado, o formato de nome desse recurso érecordType_entityType_ compare_spec_namePor exemplo:person_person_entity_compare_spec_name.
Comparações de nome da organização
Para nomes de organização, há tipcally um campo que contém todo o nome do negócio. Esse campo é comparado usando principalmente os seguintes recursos:
- Correspondência exata
- Correspondência de apelido
- Distância de edição
- Partida de iniciais
- Correspondência fonética
- Deslocamento de tokens
- Tokens extras
- Valores omissos
Para nomes de organização, as siglas e apelidos também são comparados para a exatidão.
O método de comparação de nome da organização inclui os seguintes recursos:
org_compare_spec_name-No algoritmo gerado, o formato de nome desse recurso érecordType_entityType_ compare_spec_name
Comparações de data
Para datas, há tipicamente três campos para comparar: dia, mês e ano.
O campo year é comparado usando os seguintes recursos:
- Exatidão
- Distância de edição
- Não correspondência
- Ausente
Os campos day e month são comparados usando os seguintes recursos:
- Exatidão
- Não correspondência
- Ausente
O comparador de data também verifica se os campos day e month foram transpostos devido a diferenças de locale na formatação de data.
O método de comparação de Data inclui os seguintes recursos:
compare_spec_date-No algoritmo gerado, o formato de nome desse recurso érecordType_entityType_ compare_spec_date
Comparações de gênero
O atributo de gênero é comparado usando os seguintes recursos:
- Exatidão
- Não correspondência
O método de comparação de gênero inclui os seguintes recursos:
compare_spec_gender-No algoritmo gerado, o formato de nome desse recurso érecordType_entityType_ compare_spec_gender
Comparações de endereço
Campos diferentes dentro de um atributo de endereço são tratados de forma diferente.
Campos como país, cidade, província / estado, e subdivisão são comparados usando os seguintes recursos:
- Exatidão
- Equivalência
- Distância de edição
- Não correspondência
- Ausente
Os campos de código postal são comparados usando os seguintes recursos:
- Exatidão
- Distância de edição
- Não correspondência
- Ausente
Campos como número de rua, nome da rua, tipo de rua, número da unidade e direção são comparados usando os seguintes recursos:
- Exatidão
- Equivalência
- Partida de iniciais
- Distância de edição
- Não correspondência
- Deslocamento de tokens
- Ausente
O método de comparação de endereço inclui os seguintes recursos:
compare_spec_address-No algoritmo gerado, o formato de nome desse recurso érecordType_entityType_ compare_spec_address
Comparações de telefone
Os atributos de número de telefone são comparados usando os seguintes recursos:
- Correspondência exata
- Distância de edição
- Não correspondência
O método de comparação de telefone inclui os seguintes recursos:
compare_spec_phone-No algoritmo gerado, o formato de nome desse recurso seriarecordType_entityType_ compare_spec_phone
Comparações de identificador
Os atributos de número de identificação são comparados usando os seguintes recursos:
- Correspondência exata
- Distância de edição
- Não correspondência
O método de comparação do identificador inclui os seguintes recursos:
compare_spec_identifier-No algoritmo gerado, o formato de nome desse recurso érecordType_entityType_ compare_spec_identifier
Comparações de e-mail
Os atributos de e-mail consistem em duas partes: o ID exclusivo (antes do símbolo @) e o domínio de e-mail (após o símbolo @). Tanto as partes de ID como de domínio são comparadas, separadamente, usando os seguintes recursos:
- Correspondência exata
- Distância de edição
- Não correspondência
O resultado das duas comparações são combinados de forma ponderada para produzir uma pontuação de comparação geral.
O método de comparação de e-mail inclui os seguintes recursos:
compare_spec_email-No algoritmo gerado, o formato de nome desse recurso érecordType_entityType_ compare_spec_email
Distância de edição
O mecanismo de correspondência do IBM Master Data Management calcula a distância de edição como uma das funções internas durante a comparação e a correspondência de vários atributos. A distância de edição é uma medição do grau de dissimilaridade entre duas sequências de caracteres. Ela é calculada contando o número de mudanças necessárias para transformar uma sequência de caracteres na outra.
Existem diferentes maneiras de definir uma distância de edição usando diferentes conjuntos de operações de sequências de caracteres. Por padrão, IBM Master Data Management utiliza uma função padrão de distância de edição que está disponível publicamente na literatura. Como alternativa, você pode optar por usar uma função especializada de distância de edição IBM Master Data Management.
A função de distância de edição padrão proporciona melhor desempenho do mecanismo de correspondência. Por esta razão, ela é a configuração de comparação padrão para todos os atributos, exceto para o tipo de atributo Telefone.
A função de distância de edição especializada é construída para casos de uso de hiperprecisão. Esta opção leva em consideração erros de digitação ou caracteres de aparência semelhante, como 8 e B, 0 e O, 5 e S ou 1 e I. Quando há uma incompatibilidade em dois valores comparados com base em caracteres com aparência semelhante, a medida de dissimilaridade designada é menor do que o que seria designado por uma função de distância de edição padrão. Como resultado, esses tipos de incompatibilidades não são penalizados tão fortemente pela função especializada.
Importante: a função de distância de edição especializada inclui alguns cálculos complexos. Como resultado, escolher esta opção tem um impacto no desempenho do sistema durante o processo de correspondência.
Para obter informações sobre como personalizar seu algoritmo de correspondência, incluindo o uso da API para customizar a distância de edição, consulte Customizando e fortalecendo seu algoritmo de correspondência.