Conceptos de datos en IBMMatch 360 como servicio

Match 360IBM como servicio crea entidades de datos maestros mediante la ejecución de un algoritmo de coincidencia en registros proporcionados por uno o varios activos de datos. Las entidades y los registros se definen y componen basándose en los tipos de datos personalizables IBMMatch 360 como servicio del modelo de datos. Match 360IBM como servicio utiliza identificadores del sistema de origen para rastrear el origen de los datos registrados.

Contenido de este tema:

Registros y entidades

El modelo de datos IBM Match 360

Identificadores del sistema fuente

Registros y entidades

Cada entidad es un objeto de datos maestros que proporciona una vista de 360 grados de una persona, organización u otra entidad. Uno o más registros de datos pueden contribuir a una sola entidad.

  • Un registro es un conjunto de información demográfica que representa un único punto de vista de una persona u organización, tomado de un único origen de datos. Si la misma persona u organización aparece en varios orígenes de datos, el algoritmo de comparación enlazará cada uno de los registros juntos como una sola entidad. Los registros están formados por atributos y valores de campo que describen la persona u organización.

  • Una entidad de datos maestros es una composición de registros que IBMMatch 360 como Servicio determina que deben coincidir entre sí. Sus definiciones de tipos de datos pueden definir dos categorías de entidad: identidad o asociación. Cada entidad incluye uno o varios registros de miembro que el algoritmo de coincidencia ha enlazado. Match 360IBM como servicio determina de forma inteligente el conjunto más probable de atributos y valores de campo que describen correctamente la entidad representada, y los muestra en la vista del espacio de trabajo de datos maestros.

Uno o varios registros de miembro pueden contribuir a una vista de entidad. Los registros de miembro que forman una entidad pueden cambiar si el algoritmo coincidente se vuelve a ejecutar con valores diferentes, como por ejemplo con un umbral de enlace automático diferente o un conjunto diferente de selecciones de atributos coincidentes.

Una entidad puede estar compuesta de un solo registro. Cuando esto sucede, la entidad se conoce como singleton.

Cada entidad se crea alrededor de un registro central. El registro más antiguo de una entidad se considera el registro central. Los registros de centro son la base de la entidad y no se pueden desenlazar o mover a una entidad diferente.

Cada registro que contribuye a una entidad se representa como un borde de gráfico entre los registros y la entidad, según lo determine el proceso de coincidencia. Cuando vuelva a ejecutar el algoritmo de coincidencia, se actualizarán los bordes que representan los enlaces.

Entidades de mantenimiento

Vea el siguiente vídeo para saber cómo utilizar entidades para identificar hogares dentro de sus datos IBMMatch 360 de como servicio.

Este vídeo proporciona un método visual para aprender los conceptos y tareas de esta documentación.

Cuando cree un tipo de entidad para ayudarle a rastrear e identificar registros de personas que comparten un hogar, hay algunos factores importantes que debe tener en cuenta. El establecimiento de sus criterios de hogar es un primer paso fundamental en la gestión y formación de los hogares. Los hogares pueden definirse mediante criterios explícitos, criterios expresados o una combinación de los dos.

Los criterios explícitos pueden incluir cualquier atributo definido en sus tipos de datos. Los siguientes son ejemplos de criterios explícitos que puede tener en cuenta en la estrategia de mantenimiento:

  • Las partes comparten la misma dirección de un tipo de dirección determinado, como por ejemplo la misma dirección inicial.
  • Las partes comparten un apellido.
  • Las partes se encuentran dentro de un rango de edad definido.
  • Las partes comparten un método de contacto, como un número de teléfono particular.
  • Las partes tienen cierto tipo de relación, como una relación familiar.
  • Las partes tienen roles específicos en el contexto de un contrato. Por ejemplo, un padre puede tener un rol de representante legal para una cuenta propiedad de un hijo.

Utilice criterios explícitos para crear hogares con el algoritmo de coincidencia. Para habilitar IBMMatch 360 como servicio para crear entidades domésticas de forma algorítmica, seleccione los criterios explícitos elegidos como atributos coincidentes para este tipo de entidad. Para obtener información sobre cómo configurar el algoritmo de coincidencia, consulte Coincidencia de datos para crear entidades de datos maestros.

Criterios expresados incluye otra información que no forma parte del modelo de datos. Los criterios expresados pueden haber sido comunicados verbalmente por un miembro de la familia o un agente. Los siguientes son ejemplos de criterios expresados que puede tener en cuenta en la estrategia de mantenimiento:

  • Las partes han comunicado que están dentro del mismo hogar.
  • Un agente ha recopilado información de unidad familiar durante la configuración inicial de una cuenta de cliente.

Para crear una entidad de unidad familiar basada en criterios expresados, debe enlazar manualmente los registros para formar una entidad. Puede crear enlaces manuales de registros utilizando el área de trabajo de datos maestros para editar las reglas de enlace de un registro. Para obtener más información, consulte Exploración de entidades y registros de datos maestros en IBMMatch 360 como servicio.

Determinación de los valores de atributo de una entidad

Una entidad de datos maestros puede incluir dos categorías de atributos:

  • Atributos cuyos valores se componen a partir de los registros de miembros de una entidad.
  • Atributos cuyos valores se almacenan directamente en la entidad, conocidos como atributos de entidad.
Atributos compuestos
Las entidades derivan muchos de sus valores de atributo de los valores definidos en sus registros de miembro. Los valores de atributo de una entidad se seleccionan de sus registros de miembros utilizando un conjunto de reglas de composición de atributos. Puede definir y personalizar las reglas de composición de atributos para cada tipo de entidad en sus definiciones de tipos de datos. Para obtener más información sobre la composición de atributos, consulte Definición de reglas de composición de atributos en IBMMatch 360 como servicio.
Atributos de entidad
Los atributos de entidad se definen directamente en la entidad, en lugar de estar compuestos a partir de sus registros de miembro. Defina los atributos de entidad en la definición del tipo de datos para sus tipos de entidad. Para obtener información sobre la modificación de los tipos de datos, consulte Personalización de los tipos de datos.
  • Para cambiar el valor de un atributo de entidad, edite la entidad directamente. La edición de registros de miembro no afecta al valor de un atributo de entidad. Para obtener información sobre cómo editar una entidad, consulte Añadir y editar registros y entidades en IBMMatch 360 como servicio.
  • Cuando una entidad se crea por primera vez mediante el algoritmo de coincidencia, no tiene ningún valor de atributo de entidad definido. Edite la entidad en el área de trabajo de datos maestros para proporcionar valores a los atributos de la entidad.
  • Si una entidad con valores de atributo de entidad rellenados se suprime como resultado de un cambio en su composición, ya sea a través de una acción link o unlink manual o a través de un cambio en el algoritmo coincidente, sus valores de atributo de entidad se transfieren a cualquier entidad superviviente.
  • Si se fusionan dos entidades que tienen ambos atributos de entidad (coincidentes o enlazados manualmente), los valores de atributo de entidad del ID de entidad superviviente tienen prioridad. Si el atributo en cuestión consta de una lista de valores, el sistema fusiona las listas de ambas entidades. La fusión garantiza que la lista no contenga valores duplicados. Si las dos listas incluyen el mismo valor, ese valor sólo aparece una vez en la lista fusionada.
Atributos definidos por el usuario
Cuando un ingeniero de datos ha configurado un tipo de entidad para que persista, un administrador de datos puede editar todos los atributos de una entidad, incluso si sus valores se derivaron originalmente de los registros de miembros de la entidad mediante el uso de reglas de composición de atributos. Cuando se modifica el valor de cualquier atributo a nivel de entidad, el atributo se marca con una etiqueta User Overridden. Una vez anulado, el valor del atributo se conserva y nunca será actualizado por el sistema a menos que se elimine explícitamente la anulación, incluso si cambian los registros de miembros de la entidad.

Persistencia de entidades

Al definir los tipos de datos, puede configurar si las vistas compuestas de cada tipo de entidad se guardan en la base de datos o se componen bajo demanda a partir de sus registros miembros. Cuando un tipo de entidad está configurado para persistir, los atributos compuestos de cada entidad se almacenan en la base de datos de forma similar a como se almacenan los atributos de los registros, lo que significa que los datos de la entidad son más estables y resistentes.

Cuando las entidades están configuradas para persistir, los administradores de datos y los usuarios empresariales pueden buscar directamente en los datos de la entidad, incluidos los atributos complementarios, los atributos de auditoría y las propiedades del sistema, como el recuento de registros y el ID de la entidad. Los usuarios pueden buscar entidades persistentes utilizando los mecanismos de búsqueda simple o avanzada de la interfaz del explorador de datos maestros.

Además, si las entidades están configuradas para persistir, entonces los administradores de datos pueden editar cualquier atributo de una entidad, incluso aquellos valores de atributos que se derivan de los registros de miembros de la entidad mediante el uso de reglas de composición de atributos.

Dependiendo del volumen de datos de entidad en su sistema, almacenar vistas compuestas de entidad en la base de datos puede hacer que el tamaño de la base de datos aumente significativamente.

Para obtener más información sobre la definición de tipos de entidad, consulte Personalización de los tipos de datos.

El IBMMatch 360 como modelo de datos como servicio

Las definiciones de tipos de datos, también conocidas como modelo de datos, describen los metadatos asociados a los datos que se cargan en IBMMatch 360 como servicio.

El modelo de datos contiene propiedades y reglas que se utilizan en IBMMatch 360 como servicio para identificar y categorizar la información presente en los datos. El modelo de datos consta de distintos tipos de metadatos:

Puede definir sus propios tipos de registro, tipos de atributo, tipos de relación, etc., para adaptarlos a los requisitos del modelo de datos de su organización. Las propiedades del sistema generalmente no se pueden personalizar.

Propiedades del sistema (atributos de auditoría)

Las propiedades del sistema en el modelo de datos mejoran su capacidad para auditar los datos en IBMMatch 360 como servicio para ayudar a garantizar el cumplimiento de las normas de gobernanza de datos. El sistema define, captura y almacena las propiedades del sistema y no están disponibles para su personalización o modificación.

Existen propiedades del sistema asociadas a distintos elementos del modelo de datos: tipos de registro, tipos de entidad, tipos de atributo, tipos de relación, tipos de jerarquía, tipos de nodo y tipos de grupo.

  • Las propiedades del sistema Tipo de registro almacenan información del sistema a nivel de registro. Por ejemplo:

    • record_last_updated realiza un seguimiento de la hora en que se actualizó por última vez cada registro.
    • record_number almacena un número de identificación generado por el sistema para cada registro.

  • Las propiedades del sistema Tipo de entidad almacenan información del sistema a nivel de entidad. Por ejemplo:

    • created_date almacena la hora y la fecha en que se ha creado una entidad.
    • link_last_updated_date realiza un seguimiento de la fecha y hora en que se modificaron por última vez los registros de miembros de una entidad.
    • last_updated_date almacena la hora y la fecha en que se modificaron por última vez los atributos suplementarios de una entidad.
    • last_updated_user realiza un seguimiento del usuario que ha realizado los cambios más recientes en los atributos suplementarios de una entidad.

  • Las propiedades del sistema Tipo de atributo almacenan información del sistema a nivel de atributo. Por ejemplo, attribute_last_updated realiza un seguimiento de la hora en que se actualizó por última vez cada atributo.

  • Las propiedades del sistema Tipo de relación almacenan información del sistema en el nivel de relación. Por ejemplo:

    • relationship_last_updated realiza un seguimiento de la hora en que se actualizó por última vez cada relación.
    • relationship_number almacena un número de identificación generado por el sistema para cada relación.

  • Las propiedades del sistema de tipo jerárquico almacenan información del sistema a nivel jerárquico. Por ejemplo:

    • last_updated_date rastrea la hora de la última actualización de cada jerarquía.
    • hierarchy_number almacena un número de identificación generado por el sistema para cada jerarquía.

  • Las propiedades del sistema de tipo nodo almacenan información del sistema a nivel de nodo. Por ejemplo:

    • last_updated_date registra la hora de la última actualización de cada nodo.
    • node_number almacena un número de identificación generado por el sistema para cada nodo.

  • Las propiedades del sistema de tipo grupo almacenan información del sistema a nivel de grupo. Por ejemplo:

    • last_updated_date rastrea la hora de la última actualización de cada grupo.
    • node_number almacena un número de identificación generado por el sistema para cada instancia de grupo.

Vea el siguiente vídeo para saber cómo ver los atributos de auditoría generados por el sistema que IBMMatch 360 como servicio crea cuando se añaden o editan datos de registro.

Este vídeo proporciona un método visual para aprender los conceptos y tareas de esta documentación.

Tipos de registros

Los tipos de registro del modelo de datos definen varios tipos de registros relevantes para los dominios y los casos de uso que necesita su organización. Cada tipo de registro consta de las propiedades u objetos siguientes:

  • label es la etiqueta del tipo de registro.
  • description es una descripción breve del tipo de registro.
  • entity_types contiene los objetos para todos los tipos de entidad que se incluyen en este tipo de registro. Cada objeto entity_type contiene una etiqueta, una descripción y, opcionalmente, un tipo de entidad (identidad o asociación).
  • attributes es un objeto que contiene todos los atributos asociados al tipo de registro. Cada atributo definido contiene las propiedades siguientes:
    • label -Una etiqueta para el atributo.
    • description -Una descripción del atributo.
    • attribute_type : el tipo de atributo de este atributo.
    • cardinality -La cardinalidad del atributo (lista o única). La cardinalidad define cuántos valores puede tener este atributo.
    • indexed -Un campo booleano que indica si el atributo se indexa para dar soporte a búsquedas de texto libre de su contenido.

Tipos de atributo

Los tipos de atributo del modelo de datos definen los tipos de atributos que se pueden asociar con un tipo de registro o tipo de relación. Cada entrada de tipo de atributo consta de las propiedades u objetos siguientes:

  • label es la etiqueta del tipo de atributo.
  • description es una breve descripción del tipo de atributo.
  • matching_type indica el tipo de función coincidente a aplicar en todos los atributos de este tipo de atributo.
  • fields contiene definiciones de todos los campos que forman parte de este tipo de atributo. Cada campo consta de las propiedades label, descriptiony indexed .

Tipos de relaciones

Los tipos de relación en el modelo de datos definen los tipos de relaciones disponibles que se asignarán en estos datos. Cada tipo de relación definido incluye las siguientes propiedades y objetos:

  • label es una etiqueta para el tipo de relación.
  • description es una breve descripción del tipo de relación.
  • classification especifica la clase de la relación. Por ejemplo, las relaciones de tipo jerárquico pueden clasificarse como hierarchy_node_relationship, que es una relación jerárquica de nodo a nodo, o hierarchy_node_association_relationship, que es una relación entre un nodo jerárquico y un objeto asociado. Los objetos asociados pueden ser tipos de registro o tipos de entidad. Del mismo modo, las relaciones de tipo grupo pueden clasificarse como group_association_relationship, que es una relación de grupo a objeto asociado.
  • label_from_source es la etiqueta de la relación, tal como se visualiza desde el punto de vista del origen. Por ejemplo: "Gestiona".
  • label_from_target es la etiqueta de la relación, tal como se visualiza desde el punto de vista del destino. Por ejemplo: "Informes a".
  • cardinality define la cardinalidad de la relación (por ejemplo, de uno a muchos o de uno a uno).
  • directional indica si las relaciones de este tipo son direccionales (diferentes en función del lado de la relación que esté visualizando, como por ejemplo una relación médico-paciente) o bidireccionales (las mismas de ambos lados de la relación, como por ejemplo una relación de igual).
  • attributes es un objeto que contiene definiciones de todos los atributos que forman parte de este tipo de relación. El objeto attributes tiene la misma estructura que el de un atributo de un tipo de registro.
  • rules es un objeto que define las reglas de origen y destino para este tipo de relación.
    • El objeto para una regla de origen contiene la lista de tipos de registro y tipos de entidad que se pueden utilizar como origen al crear una relación de este tipo.
    • El objeto para una regla de destino contiene la lista de tipos de registro y tipos de entidad que se pueden utilizar como destino al crear una relación de este tipo.

Tipos de jerarquía

Los tipos de jerarquía en el modelo de datos definen los tipos de jerarquías disponibles para ser asignadas en estos datos. Cada tipo de jerarquía definido incluye las siguientes propiedades y objetos:

  • label es una etiqueta para el tipo de jerarquía.
  • description es una breve descripción del tipo de jerarquía.
  • node_type especifica el tipo de nodo utilizado en este tipo de jerarquía.
  • node_relationship_type especifica el tipo de relación nodo a nodo utilizado en este tipo de jerarquía.
  • node_associations especifica la relación nodo-objetos asociados en este tipo de jerarquía. Los objetos asociados pueden ser tipos de registro o tipos de entidad.
  • attributes es un objeto que contiene todos los atributos asociados al tipo de jerarquía. Cada atributo definido contiene las propiedades siguientes:
    • label es una etiqueta para el atributo.
    • description es una descripción del atributo.
    • attribute_type es el tipo de atributo de este atributo.
    • cardinality es la cardinalidad del atributo (lista o único). La cardinalidad define cuántos valores puede tener este atributo.
    • indexed es un campo booleano que indica si el atributo está indexado para permitir búsquedas de texto libre en su contenido.

Tipos de nodo

Los tipos de nodo en el modelo de datos definen los tipos de nodo disponibles para ser asignados en estos datos. Cada tipo de nodo definido incluye las siguientes propiedades y objetos:

  • label es una etiqueta para el tipo de nodo.
  • description es una breve descripción del tipo de nodo.
  • classification especifica la clase del nodo. Por ejemplo, para las jerarquías los nodos se clasifican como hierarchy_node, lo que significa que el nodo se utiliza con tipos de jerarquía.
  • attributes es un objeto que contiene todos los atributos asociados al tipo de nodo. Cada atributo definido contiene las propiedades siguientes:
    • label es una etiqueta para el atributo.
    • description es una descripción del atributo.
    • attribute_type es el tipo de atributo de este atributo.
    • cardinality es la cardinalidad del atributo (lista o único). La cardinalidad define cuántos valores puede tener este atributo.
    • indexed es un campo booleano que indica si el atributo está indexado para permitir búsquedas de texto libre en su contenido.

Tipos de grupo

Los tipos de grupo en el modelo de datos definen los tipos de grupos disponibles para ser asignados en estos datos. Cada tipo de grupo definido incluye las siguientes propiedades y objetos:

  • label es una etiqueta para el tipo de grupo.
  • description es una breve descripción del tipo de grupo.
  • group_associations especifica la relación grupo-objetos asociados en este tipo de grupo. Los objetos asociados pueden ser tipos de registro.
  • attributes es un objeto que contiene todos los atributos asociados al tipo de grupo. Cada atributo definido contiene las propiedades siguientes:
    • label es una etiqueta para el atributo.
    • description es una descripción del atributo.
    • attribute_type es el tipo de atributo de este atributo.
    • cardinality es la cardinalidad del atributo (lista o único). La cardinalidad define cuántos valores puede tener este atributo.
    • indexed es un campo booleano que indica si el atributo está indexado para permitir búsquedas de texto libre en su contenido.

Identificadores del sistema fuente

Cuando IBMMatch 360 como servicio compara registros para formar entidades, estas pueden seguir almacenando los identificadores del sistema de origen de cada uno de sus registros miembros, de modo que los valores de los datos sean rastreables hasta sus registros y fuentes originales. Esta capacidad es crucial para mantener el linaje de los datos, y también mejora la integración con los datos de los sistemas MDM existentes, como IBM InfoSphere Master Data Management.

Match 360IBM como servicio puede incorporar datos de múltiples sistemas de origen, cada uno con su propio esquema de identificación y formato de datos. Cuando esta función está activada, IBMMatch 360 como servicio mantiene los identificadores del sistema de origen de los sistemas originales al componer entidades de datos maestros.

A cada registro cargado en IBMMatch 360 como servicio se le asigna un atributo del sistema denominado source_system_identifier. Este atributo incluye dos campos:

  • source_record_id es el identificador único del registro en el sistema fuente de origen.
  • record_source es el nombre del sistema de origen.

Match 360IBM como servicio utiliza el source_system_identifier atributo para hacer referencia y gestionar registros basándose en sus identificadores originales del sistema de origen.

Al formar una entidad de datos maestros a partir de sus registros miembros, IBMMatch 360 como servicio recopila dinámicamente los identificadores del sistema de origen. Los identificadores no se almacenan dentro de entidades persistentes en la base de datos.

Compatibilidad con los identificadores del sistema fuente de MDM InfoSphere

IBM InfoSphere MDM Advanced Edition utiliza identificadores del sistema fuente para rastrear la información del sistema fuente para cada registro de parte en su base de datos. Al admitir identificadores del sistema de origen, IBMMatch 360 como servicio puede importar registros desde InfoSphere MDM conservando los identificadores originales del sistema de origen. Esta estrategia permite que los mismos sistemas de origen interactúen posteriormente directamente con IBMMatch 360 como servicio y utilicen sus propios identificadores de sistema de origen para recuperar y actualizar registros según sea necesario.

Carga masiva de información del sistema fuente mediante la API

Cuando se cargan registros en bloque que contienen información del sistema de origen en IBMMatch 360 as a Service mediante la API, la operación de carga en bloque debe gestionarse de forma diferente dependiendo de si el origen de los datos es IBMInfoSphere MDM Advanced Edition o el propio sistema de origen.

  • En IBM InfoSphere MDM Advanced Edition, los registros de partes de los sistemas de origen se consolidan cuando el sistema InfoSphere MDM los identifica como representantes de la misma entidad a través de su proceso de correspondencia. Este proceso da lugar a perfiles de partido enriquecidos. Cuando actualice o introduzca datos de registros de partes desde InfoSphere MDM Advanced Edition en IBMMatch 360 as a Service, la información enriquecida debería sobrescribir cualquier registro existente. Para conseguir este resultado, puede utilizar los métodos de la API bulk_load o ongoing_sync con la estrategia put/replace que sustituye todo el registro.

  • Cuando las actualizaciones se originan en un sistema fuente y deben reflejarse en IBMMatch 360 as a Service, debe evitar sobrescribir todo el perfil enriquecido. En su lugar, sólo deben actualizarse los atributos modificados recientemente. Puede conseguirlo utilizando los métodos de la API bulk_load o ongoing_sync con la estrategia patch que sólo actualiza los atributos incluidos en la carga útil de la solicitud, dejando intactos el resto de los datos enriquecidos.

Ejemplo de objeto de registro JSON cuando se carga desde un sistema MDM InfoSphere

Cuando se carga un objeto de registro que contiene información del sistema fuente desde InfoSphere MDM Advanced Edition, el objeto de registro es similar al siguiente JSON de ejemplo. Los atributos record_id y record_source están presentes en la sección attributes .

{
  "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"
}

Ejemplo de objeto de registro JSON cuando se carga desde un sistema fuente

Cuando se carga un objeto de registro que contiene información del sistema fuente directamente desde un sistema fuente de origen, el objeto de registro es similar al siguiente ejemplo JSON. En comparación con el ejemplo MDM de InfoSphere, record_id y record_source no están presentes en la sección attributes . Este registro se ha cargado directamente desde Credit Source System aprovechando el valor del atributo source_system_identifier . En este caso, también se conserva otra información del registro source_system_identifier .

{
  "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"
  }
}

Para obtener más información sobre el uso de la API para cargar datos de registros, incluidos los identificadores del sistema de origen, consulte la documentación de referencia IBMMatch 360 de la API de como servicio como servicio.

Más información