Conceitos de dados em IBM Master Data Management

Entidades de exploração doméstica

Ao criar um tipo de entidade para ajudá-lo a rastrear e identificar registros de pessoas que compartilham um domicílio, há alguns fatores importantes a serem considerados. Estabelecer seus critérios de dona de casa é um primeiro passo crítico na gestão e formação das famílias. As famílias podem ser definidas por critérios explícitos, critérios expressos ou uma combinação dos dois.

Os critérios explícitos podem incluir qualquer atributo definido em seus tipos de dados. A seguir, são exemplos de critérios explícitos que você pode considerar na sua estratégia de realização de tarefas:

• As partes compartilham o mesmo endereço de um determinado tipo de endereço, como o mesmo endereço residir.
• As partes compartilham um sobrenome.
• Os partidos caem dentro de uma faixa etária definida.
• As partes compartilham um método de contato, como um número de telefone residir.
• Os partidos têm um certo tipo de relação, como uma relação familiar.
• As partes têm funções específicas no contexto de um contrato. Por exemplo, um pai pode ter um papel de representante legal para uma conta de propriedade de uma criança.

Use critérios explícitos para construir domicílios com o algoritmo de correspondência. Para ativar o IBM Master Data Management para construir suas entidades domésticas algoritmicamente, selecione os critérios explícitos escolhidos como os atributos correspondentes para esse tipo de entidade. Para obter informações sobre a configuração do algoritmo de correspondência, consulte Matando seus dados para criar entidades de dados principais.

Critérios expressos inclui outras informações que não fazem parte do modelo de dados. Os critérios expressos podem ter sido comunicados verbalmente por um membro do agregado familiar ou por um agente. A seguir, exemplos de critérios expressos que você pode considerar em sua estratégia de realização de tarefas:

• Os partidos comunicaram que estão dentro do mesmo agregado familiar.
• Um agente coletou informações das famílias durante a configuração inicial de uma conta de cliente.

Para construir uma entidade doméstica com base em critérios expressos, você deve vincular manualmente registros para formar uma entidade. É possível criar vínculos manuais de registros usando o espaço de trabalho de dados mestre para editar as regras de vinculação de um registro. Para obter mais informações, consulte Explorando entidades e registros de dados mestres em IBM Master Data Management.

Determinando Valores de Atributo de uma Entidade

Uma entidade de dados principais pode incluir duas categorias de atributos:

• Atributos cujos valores são compostos a partir de registros de membros de uma entidade
• Atributos cujos valores são armazenados diretamente na entidade, conhecidos como atributos de entidade

Atributos compostos

As entidades derivam muitos de seus valores de atributos dos valores definidos em seus registros de membros. Os valores de atributos de uma entidade são selecionados a partir de seus registros de membros usando um conjunto de regras de composição de atributos É possível definir e personalizar regras de composição de atributos para cada tipo de entidade em suas definições de tipo de dados. Para obter mais informações sobre composição de atributos, consulte Definindo regras de composição de atributos em IBM Master Data Management.

Atributos de entidade

Os atributos de entidade são definidos diretamente na entidade, em vez de serem compostos a partir de seus registros de membros Defina atributos de entidade na definição de tipo de dados para seus tipos de entidade. Para obter informações sobre como modificar tipos de dados, consulte Personalização dos tipos de dados.

• Para alterar o valor de um atributo de entidade, edite a entidade diretamente Editar registros de membros não afeta o valor de um atributo de entidade. Para obter informações sobre como editar uma entidade, consulte Adicionar e editar registros e entidades em IBM Master Data Management.
• Quando uma entidade é criada pela primeira vez pelo algoritmo correspondente, ela não possui nenhum valor de atributo de entidade definido Edite a entidade no espaço de trabalho de dados mestre para fornecer valores para os atributos da entidade.
• Se uma entidade com valores de atributos de entidade preenchidos for excluída como resultado de uma mudança em sua composição, por meio de uma ação manual link ou unlink ou por meio de uma mudança no algoritmo correspondente, seus valores de atributos de entidade serão transferidos para quaisquer entidades sobreviventes.
• Se duas entidades que possuem atributos de entidade forem mescladas (correspondidas ou vinculadas manualmente), então os valores de atributo de entidade do ID da entidade sobrevivente terão precedência.. Se o atributo em questão consistir em uma lista de valores, o sistema mesclará as listas de ambas as entidades. A mesclagem assegura que a lista não contenha nenhum valor duplicado Se as duas listas incluírem o mesmo valor, esse valor aparecerá somente uma vez na lista mesclada.

Atributos definidos pelo usuário

Quando um engenheiro de dados tiver configurado um tipo de entidade para persistir, um administrador de dados poderá editar todos os atributos de uma entidade, mesmo que seus valores tenham sido originalmente derivados dos registros de membros da entidade usando regras de composição de atributos. Quando você modifica o valor de qualquer atributo de nível de entidade, o atributo é marcado com uma tag User Overridden. Uma vez substituído, o valor do atributo é preservado e nunca será atualizado pelo sistema, a menos que a substituição seja explicitamente removida, mesmo que os registros de membros da entidade sejam alterados.

Persistência da entidade

Ao definir tipos de dados, é possível configurar se as exibições compostas de cada tipo de entidade são salvas no banco de dados ou compostas sob demanda a partir de seus registros de membros. Quando um tipo de entidade é configurado para persistir, os atributos compostos de cada entidade são armazenados no banco de dados de forma semelhante à maneira como os atributos de registro são armazenados, o que significa que os dados da entidade são mais estáveis e resilientes.

Quando as entidades são configuradas para persistir, os administradores de dados e os usuários corporativos podem pesquisar diretamente nos dados da entidade, incluindo atributos suplementares, atributos de auditoria e propriedades do sistema, como contagem de registros e ID da entidade. Os usuários podem pesquisar entidades persistentes usando os mecanismos de pesquisa simples ou avançados na interface do explorador de dados mestres.

Além disso, se as entidades estiverem configuradas para persistir, os administradores de dados poderão editar qualquer atributo de uma entidade, mesmo os valores de atributo derivados dos registros de membros da entidade, usando regras de composição de atributos.

Dependendo do volume de dados de entidade em seu sistema, o armazenamento de exibições compostas de entidade no banco de dados pode fazer com que o tamanho do banco de dados aumente significativamente.

Para obter mais informações sobre a definição de tipos de entidades, consulte Personalização dos tipos de dados.

Propriedades do sistema (atributos de auditoria)

As propriedades do sistema no modelo de dados aprimoram sua capacidade de auditar os dados em IBM Master Data Management para ajudar a garantir a conformidade com as regras de governança de dados. As propriedades do sistema são definidas, capturadas e armazenadas pelo sistema e não estão disponíveis para customização ou modificação.

Há propriedades do sistema associadas a vários elementos diferentes do modelo de dados: tipos de registro, tipos de entidade, tipos de atributo, tipos de relacionamento, tipos de hierarquia, tipos de nó e tipos de grupo.

• Tipo de registro propriedades do sistema armazenam informações no nível de registro. Por exemplo:

  • record_last_updated acompanha o tempo em que cada registro foi atualizado pela última vez.
  • record_number armazena um número de identificação gerado pelo sistema para cada registro.

• Entidade tipo propriedades do sistema armazenam informações no nível da entidade. Por exemplo:

  • created_date armazena o horário e a data em que uma entidade foi criada.
  • link_last_updated_date acompanha o horário e a data em que os registros de membros de uma entidade foram alterados pela última vez.
  • last_updated_date armazena o horário e a data em que os atributos complementares de uma entidade foram alterados pela última vez.
  • last_updated_user acompanha o usuário que fez as alterações mais recentes nos atributos complementares de uma entidade.

• Tipo de atributo propriedades do sistema armazenam informações no nível do atributo. Por exemplo, attribute_last_updated acompanha o tempo em que cada atributo foi atualizado pela última vez.

• Relacionamento tipo propriedades do sistema armazenam informações no nível de relacionamento. Por exemplo:

  • relationship_last_updated acompanha o tempo em que cada relacionamento foi atualizado pela última vez.
  • relationship_number armazena um número de identificação gerado pelo sistema para cada relacionamento.

• As propriedades do sistema do tipo hierarquia armazenam informações do sistema no nível da hierarquia. Por exemplo:

  • last_updated_date rastreia a hora em que cada hierarquia foi atualizada pela última vez.
  • hierarchy_number armazena um número de identificação gerado pelo sistema para cada hierarquia.

• As propriedades do sistema do tipo nó armazenam informações do sistema no nível do nó. Por exemplo:

  • last_updated_date rastreia a hora em que cada nó foi atualizado pela última vez.
  • node_number armazena um número de identificação gerado pelo sistema para cada nó.

• As propriedades do sistema de tipo de grupo armazenam informações do sistema no nível do grupo. Por exemplo:

  • last_updated_date rastreia a hora em que cada grupo foi atualizado pela última vez.
  • node_number armazena um número de identificação gerado pelo sistema para cada instância de grupo.

Assista ao vídeo a seguir para ver como visualizar os atributos de auditoria gerados pelo sistema que o IBM Master Data Management cria quando você adiciona ou edita dados de registro.

Tipos de registro

Tipos de registro no modelo de dados definem vários tipos de registros relevantes para os domínios e casos de uso exigidos por sua organização. Cada tipo de registro consiste nas seguintes propriedades ou objetos:

• label é o rótulo para o tipo de registro.
• description é uma descrição curta do tipo de registro.
• entity_types contém os objetos para todos os tipos de entidade que estão incluídos neste tipo de registro. Cada entity_type objeto contém um rótulo e uma descrição.
• attributes é um objeto que contém todos os atributos associados ao tipo de registro. Cada atributo definido contém as seguintes propriedades:
  • label -Um rótulo para o atributo.
  • description -Uma descrição do atributo.
  • attribute_type -O tipo de atributo deste atributo.
  • cardinality -A cardinalidade do atributo (lista ou única). Cardinalidade define quantos valores esse atributo pode ter.
  • indexed -Um campo booleano indicando se o atributo está indexado para suportar pesquisas de texto livre de seu conteúdo.

Tipos de atributo

Os tipos de atributos no modelo de dados definem os tipos de atributos que podem ser associados a um tipo de registro ou tipo de relacionamento. Cada entrada de tipo de atributo consiste nas seguintes propriedades ou objetos:

• label é a etiqueta para o tipo de atributo.
• description é uma descrição curta do tipo de atributo.
• matching_type indica o tipo de função de correspondência para aplicar em todos os atributos desse tipo de atributo.
• fields contém definições de todos os campos que fazem parte deste tipo de atributo. Cada campo consiste em propriedades label, descriptione indexed .

Tipos de Relacionamento

Os tipos de relacionamento no modelo de dados definem os tipos de relacionamentos disponíveis para serem atribuídos nestes dados. Cada tipo de relacionamento definido inclui as seguintes propriedades e objetos:

• label é um rótulo para o tipo de relacionamento.
• description é uma descrição curta do tipo de relacionamento.
• classification especifica a classe do relacionamento. Por exemplo, as relações do tipo hierarquia podem ser classificadas como hierarchy_node_relationship, que é uma relação hierárquica nó a nó, ou hierarchy_node_association_relationship, que é uma relação entre um nó de hierarquia e um objeto associado. Os objetos associados podem ser tipos de registro ou tipos de entidade. Da mesma forma, os relacionamentos de tipo de grupo podem ser classificados como group_association_relationship, que é um relacionamento de grupo para objeto associado.
• label_from_source é o rótulo para o relacionamento, como visto do ponto de vista da fonte. Por exemplo: "Managens".
• label_from_target é o rótulo para o relacionamento, como visto do ponto de vista do alvo. Por exemplo: "Relatórios para".
• cardinality define a cardinalidade do relacionamento (como um-para-muitos ou um-a-um).
• directional indica se os relacionamentos desse tipo são direcionais (diferentes dependendo de qual lado do relacionamento você está visualizando, como um relacionamento médico / paciente) ou bidirecional (o mesmo de ambos os lados do relacionamento, como um relacionamento entre pares).
• attributes é um objeto contendo definições de todos os atributos que fazem parte desse tipo de relacionamento. O objeto attributes tem a mesma estrutura do que um para um atributo de um tipo de registro.
• rules é um objeto que define as regras de origem e destino para esse tipo de relacionamento.
  • O objeto para uma regra fonte contém a lista de tipos de registros e tipos de entidade que podem ser usados como fonte enquanto criam um relacionamento desse tipo.
  • O objeto para uma regra destino contém a lista de tipos de registros e tipos de entidade que podem ser usados como um alvo enquanto criam uma relação desse tipo.

Tipos de hierarquia

Os tipos de hierarquia no modelo de dados definem os tipos de hierarquias disponíveis para serem atribuídas a esses dados. Cada tipo de hierarquia definido inclui as seguintes propriedades e objetos:

• label é um rótulo para o tipo de hierarquia.
• description é uma breve descrição do tipo de hierarquia.
• node_type especifica o tipo de nó usado nesse tipo de hierarquia.
• node_relationship_type especifica o tipo de relação nó a nó usado nesse tipo de hierarquia.
• node_associations especifica a relação entre o nó e os objetos associados nesse tipo de hierarquia. Os objetos associados podem ser tipos de registro ou tipos de entidade.
• attributes é um objeto que contém todos os atributos associados ao tipo de hierarquia. Cada atributo definido contém as seguintes propriedades:
  • label é um rótulo para o atributo.
  • description é uma descrição do atributo.
  • attribute_type é o tipo de atributo desse atributo.
  • cardinality é a cardinalidade do atributo (lista ou único). Cardinalidade define quantos valores esse atributo pode ter.
  • indexed é um campo booleano que indica se o atributo está indexado para suportar pesquisas de texto livre de seu conteúdo.

Tipos de nós

Os tipos de nós no modelo de dados definem os tipos de nós disponíveis para serem atribuídos nesses dados. Cada tipo de nó definido inclui as seguintes propriedades e objetos:

• label é um rótulo para o tipo de nó.
• description é uma breve descrição do tipo de nó.
• classification especifica a classe do nó. Por exemplo, para hierarquias, os nós são classificados como hierarchy_node, o que significa que o nó é usado com tipos de hierarquia.
• attributes é um objeto que contém todos os atributos associados ao tipo de nó. Cada atributo definido contém as seguintes propriedades:
  • label é um rótulo para o atributo.
  • description é uma descrição do atributo.
  • attribute_type é o tipo de atributo desse atributo.
  • cardinality é a cardinalidade do atributo (lista ou único). Cardinalidade define quantos valores esse atributo pode ter.
  • indexed é um campo booleano que indica se o atributo está indexado para suportar pesquisas de texto livre de seu conteúdo.

Tipos de grupos

Os tipos de grupo no modelo de dados definem os tipos de grupos disponíveis para serem atribuídos nesses dados. Cada tipo de grupo definido inclui as seguintes propriedades e objetos:

• label é um rótulo para o tipo de grupo.
• description é uma breve descrição do tipo de grupo.
• group_associations especifica o relacionamento entre os objetos associados e o grupo nesse tipo de grupo. Os objetos associados podem ser tipos de registro.
• attributes é um objeto que contém todos os atributos associados ao tipo de grupo. Cada atributo definido contém as seguintes propriedades:
  • label é um rótulo para o atributo.
  • description é uma descrição do atributo.
  • attribute_type é o tipo de atributo desse atributo.
  • cardinality é a cardinalidade do atributo (lista ou único). Cardinalidade define quantos valores esse atributo pode ter.
  • indexed é um campo booleano que indica se o atributo está indexado para suportar pesquisas de texto livre de seu conteúdo.

Compatibilidade com os identificadores do sistema de origem InfoSphere MDM

IBM InfoSphere O MDM Advanced Edition usa identificadores do sistema de origem para rastrear as informações do sistema de origem de cada registro de parte em seu banco de dados. Ao oferecer suporte a identificadores de sistema de origem, o IBM Master Data Management pode importar registros de um MDM InfoSphere, mantendo os identificadores originais do sistema de origem. Essa estratégia permite que os mesmos sistemas de origem interajam posteriormente diretamente com IBM Master Data Management e utilizem seus próprios identificadores de sistema de origem para recuperar e atualizar registros conforme necessário.

Carregamento em massa de informações do sistema de origem usando a API

Ao carregar em massa registros que contêm informações do sistema de origem em IBM Master Data Management usando a API, você deve lidar com a operação de carregamento em massa de maneira diferente, dependendo se a origem dos dados é IBM InfoSphere MDM Advanced Edition ou o próprio sistema de origem.

• Em IBM InfoSphere MDM Advanced Edition, os registros de partes dos sistemas de origem são consolidados quando o sistema InfoSphere MDM os identifica como representando a mesma entidade por meio de seu processo de correspondência. Esse processo resulta em perfis de partes enriquecidos. Quando você atualiza ou preenche dados de registros de partes do InfoSphere MDM Advanced Edition no IBM Master Data Management, as informações enriquecidas devem substituir quaisquer registros existentes. Para obter esse resultado, você pode usar os métodos da API bulk_load ou ongoing_sync com a estratégia put/replace que substitui o registro inteiro.

• Quando as atualizações se originam de um sistema de origem e precisam ser refletidas em IBM Master Data Management, você deve evitar sobrescrever todo o perfil enriquecido. Em vez disso, somente os atributos alterados recentemente devem ser atualizados. Você pode conseguir isso usando os métodos de API bulk_load ou ongoing_sync com a estratégia patch que atualiza apenas os atributos incluídos na carga útil da solicitação, deixando o restante dos dados enriquecidos intactos.

{
  "attributes": {
    "record_id": "100",
    "record_source": “MDM AE",
    "gender": {
      "value": "Female"
    },
    "source_system_identifier": [
      {
        "source_record_id": "1000",
        "record_source": "Credit"
      },
      {
        "source_record_id": "2000",
        "record_source": "Savings"
      },
	{
        "source_record_id": "3000",
        "record_source": "Mortgage"
      }
    ]
  },
  "system_attributes": {
    "created_date": "1754490798463",
    "created_user": "admin",
    "last_updated_date": "1754552977145",
    "last_updated_user": "admin"
  },
  "type": "record",
  "type_name": "person"
}

{
  "attributes": {
    "gender": {
      "value": "Female"
    },
    "source_system_identifier": [
      {
        "source_record_id": "1000",
        "record_source": "Credit"
      }
    ]
  },
  "system_attributes": {
    "created_date": "1754490798463",
    "created_user": "admin",
    "last_updated_date": "1754552977145",
    "last_updated_user": "admin"
  },
  "type": "record",
  "type_name": "person"
}
Example Relationship Object
Here we can provide Source System Identifiers to create a relationship between two records as source and target respectively.
{
  "relationship_type": "party_relationship",
  "attributes": {
    "relationship_id": "284950703641779361",
    "relationship_last_updated": "1509445180982",
    "relationship_value": {
      "value": "Party 2 accountant is party 1"
    },
    "record_start": {
      "value": "2017-10-03 13:13:37.792"
    },
    "relationship_source": "MDM"
  },
  "target": {
    "attributes": {
      "source_system_identifier": {
        "source_record_id": "2000",
        "record_source": "savings"
      }
    },
    "type": "record",
    "type_name": "person"
  },
  "source": {
    "attributes": {
      "source_system_identifier": {
        "source_record_id": "3000",
        "record_source": "credit"
      }
    },
    "type": "record",
    "type_name": "person"
  }
}