Datenkonzepte in IBMMatch 360 as a Service

Householding-Entitäten

Sehen Sie sich das folgende Video an, um zu erfahren, wie Sie Entitäten verwenden können, um Haushalte innerhalb Ihrer IBMMatch 360 as a Service-Daten zu identifizieren.

Wenn Sie einen Entitätstyp erstellen, der Ihnen hilft, Personendatensätze zu verfolgen und zu identifizieren, die einen gemeinsamen Haushalt bilden, sind einige wichtige Faktoren zu berücksichtigen. Die Festlegung Ihrer Haushaltskriterien ist ein kritischer erster Schritt bei der Verwaltung und Bildung von Haushalten. Haushalte können durch explizite Kriterien, ausgedrückte Kriterien oder eine Kombination aus beiden definiert werden.

Explizite Kriterien können jedes in Ihren Datentypen definierte Attribut enthalten. Im Folgenden finden Sie Beispiele für explizite Kriterien, die Sie in Ihrer Hausverwaltungsstrategie berücksichtigen können:

• Parteien verwenden dieselbe Adresse eines bestimmten Adresstyps, z. B. dieselbe Privatadresse.
• Parteien haben einen gemeinsamen Nachnamen.
• Parteien fallen in einen definierten Altersbereich.
• Parteien nutzen eine Kontaktmethode gemeinsam, z. B. eine private Telefonnummer.
• Parteien haben eine bestimmte Art von Beziehung, wie eine Familienbeziehung.
• Parteien haben bestimmte Rollen im Kontext eines Vertrags. Ein übergeordnetes Element kann beispielsweise die Rolle eines gesetzlichen Repräsentanten für ein Konto haben, das einem untergeordneten Konto gehört.

Verwenden Sie explizite Kriterien, um Haushalte mit dem Abgleichalgorithmus zu erstellen. Um als Dienst zu IBMMatch 360 aktivieren, mit dem Sie Ihre Haushaltsentitäten algorithmisch erstellen können, wählen Sie Ihre ausgewählten expliziten Kriterien als übereinstimmende Attribute für diesen Entitätstyp aus. Informationen zur Konfiguration des Abgleichsalgorithmus finden Sie unter Abgleich Ihrer Daten zum Erstellen von Stammdatenentitäten.

Ausgedrückte Kriterien enthält weitere Informationen, die nicht Teil des Datenmodells sind. Ausgedrückte Kriterien können mündlich von einem Haushaltsmitglied oder einem Agenten kommuniziert worden sein. Die folgenden Beispiele zeigen ausgedrückte Kriterien, die Sie in Ihrer Hauswirtschaftsstrategie berücksichtigen können:

• Die Parteien haben mitgeteilt, dass sie sich im selben Haushalt befinden.
• Ein Agent hat während der Erstkonfiguration eines Kundenkontos Haushaltsdaten erfasst.

Um eine Haushaltsentität auf der Basis ausgedrückter Kriterien zu erstellen, müssen Sie Datensätze manuell verknüpfen, um eine Entität zu bilden. Sie können manuelle Datensatzverknüpfungen erstellen, indem Sie die Verknüpfungsregeln eines Datensatzes im Stammdatenarbeitsbereich bearbeiten. Weitere Informationen finden Sie unter „Exploring master data entities and records in IBMMatch 360 as a Service “.

Attributwerte einer Entität bestimmen

Eine Stammdatenentität kann zwei Kategorien von Attributen enthalten:

• Attribute, deren Werte aus den Mitgliedsdatensätzen einer Entität gebildet werden.
• Attribute, deren Werte direkt in der Entität gespeichert werden, werden als Entitätsattributebezeichnet.

Composited-Attribute

Entitäten leiten viele ihrer Attributwerte aus den in ihren Mitgliedsdatensätzen definierten Werten ab. Die Attributwerte einer Entität werden mithilfe einer Gruppe von Attributzusammensetzungsregeln aus ihren Mitgliedsdatensätzen ausgewählt. Sie können die Regeln für die Attributzusammensetzung für jeden Entitätstyp in Ihren Datentypdefinitionen definieren und anpassen. Weitere Informationen zur Attributzusammensetzung finden Sie unter „Definieren von Regeln für die Attributzusammensetzung in IBMMatch 360 as a Service “.

Entitätsattribute

Entitätsattribute werden direkt in der Entität definiert und nicht aus ihren Mitgliedsdatensätzen zusammengesetzt. Definieren Sie Entitätsattribute in der Datentypdefinition für Ihre Entitätstypen. Informationen zum Ändern von Datentypen finden Sie unter Anpassen Ihrer Datentypen.

• Um den Wert eines Entitätsattributs zu ändern, bearbeiten Sie die Entität direkt. Die Bearbeitung von Memberdatensätzen hat keine Auswirkung auf den Wert eines Entitätsattributs. Informationen zum Bearbeiten einer Entität finden Sie unter Hinzufügen und Bearbeiten von Datensätzen und Entitäten in IBMMatch 360 as a Service.
• Wenn eine Entität zum ersten Mal durch den Abgleichsalgorithmus erstellt wird, sind keine Entitätsattributwerte definiert. Bearbeiten Sie die Entität im Stammdatenarbeitsbereich, um Werte für Entitätsattribute bereitzustellen.
• Wenn eine Entität mit ausgefüllten Entitätsattributwerten als Ergebnis einer Änderung ihrer Zusammensetzung gelöscht wird, entweder durch eine manuelle Aktion link oder unlink oder durch eine Änderung des übereinstimmenden Algorithmus, werden ihre Entitätsattributwerte an alle verbleibenden Entitäten übertragen.
• Wenn zwei Entitäten, die beide über Entitätsattribute verfügen, zusammengeführt (entweder abgeglichen oder manuell verknüpft) werden, haben die Entitätsattributwerte der verbleibenden Entitäts-ID Vorrang. Wenn das betreffende Attribut aus einer Liste von Werten besteht, führt das System die Listen aus beiden Entitäten zusammen. Die Zusammenführung stellt sicher, dass die Liste keine doppelten Werte enthält. Wenn beide Listen denselben Wert enthalten, erscheint dieser Wert nur einmal in der zusammengeführten Liste.

Benutzerdefinierte Attribute

Wenn ein Data Engineer einen Entitätstyp für die Persistenz konfiguriert hat, kann ein Data Steward alle Attribute einer Entität bearbeiten, auch wenn die Werte ursprünglich aus den Mitgliedsdatensätzen der Entität abgeleitet wurden, indem er Regeln für die Attributzusammensetzung verwendet. Wenn Sie den Wert eines beliebigen Attributs auf Entitätsebene ändern, wird das Attribut mit einem User Overridden-Tag markiert. Nach der Überschreibung bleibt der Wert des Attributs erhalten und wird vom System nicht mehr aktualisiert, es sei denn, die Überschreibung wird ausdrücklich aufgehoben, selbst wenn sich die Mitgliedsdatensätze der Entität ändern.

Persistenz von Entitäten

Bei der Definition von Datentypen können Sie festlegen, ob die zusammengesetzten Sichten jedes Entitätstyps in der Datenbank gespeichert oder bei Bedarf aus ihren Mitgliedsdatensätzen zusammengestellt werden. Wenn ein Entitätstyp so konfiguriert ist, dass er bestehen bleibt, werden die zusammengesetzten Attribute jeder Entität in der Datenbank gespeichert, ähnlich wie Datensatzattribute gespeichert werden, was bedeutet, dass die Entitätsdaten stabiler und belastbarer sind.

Wenn Entitäten so konfiguriert sind, dass sie bestehen bleiben, können Datenverwalter und Geschäftsanwender direkt nach Entitätsdaten suchen, einschließlich zusätzlicher Attribute, Audit-Attribute und Systemeigenschaften wie Datensatzanzahl und Entitäts-ID. Benutzer können nach persistierten Entitäten suchen, indem sie die einfachen oder erweiterten Suchmechanismen in der Stammdaten-Explorer-Schnittstelle verwenden.

Wenn Entitäten so konfiguriert sind, dass sie bestehen bleiben, können die Datenverwalter außerdem jedes Attribut einer Entität bearbeiten, auch die Attributwerte, die aus den Mitgliedsdatensätzen der Entität abgeleitet wurden, indem sie Regeln für die Attributkomposition verwenden.

Je nach der Menge der Entitätsdaten in Ihrem System kann die Speicherung von zusammengesetzten Entitätsansichten in der Datenbank zu einer erheblichen Vergrößerung der Datenbank führen.

Weitere Informationen zur Definition von Entitätstypen finden Sie unter Anpassen Ihrer Datentypen.

Systemeigenschaften (Prüfattribute)

Die Systemeigenschaften im Datenmodell verbessern Ihre Möglichkeiten, die Daten in IBMMatch 360 as a Service zu prüfen, um die Einhaltung der Datenverwaltungsregeln sicherzustellen. Systemeigenschaften werden vom System definiert, erfasst und gespeichert und können nicht angepasst oder geändert werden.

Es gibt Systemeigenschaften, die mit mehreren verschiedenen Elementen des Datenmodells verbunden sind: Datensatztypen, Entitätstypen, Attributtypen, Beziehungstypen, Hierarchietypen, Knotentypen und Gruppentypen.

• Satztyp Systemeigenschaften speichern Systeminformationen auf Satzebene. Zum Beispiel:

  • record_last_updated verfolgt die Zeit, zu der jeder Datensatz zuletzt aktualisiert wurde.
  • record_number speichert eine vom System generierte Kennnummer für jeden Datensatz.

• Systemeigenschaften für Entitätstypen speichern Systeminformationen auf Entitätsebene. Zum Beispiel:

  • created_date speichert die Uhrzeit und das Datum der Erstellung einer Entität.
  • link_last_updated_date verfolgt die Uhrzeit und das Datum, an dem die Memberdatensätze einer Entität zuletzt geändert wurden.
  • last_updated_date speichert die Uhrzeit und das Datum, an dem die ergänzenden Attribute einer Entität zuletzt geändert wurden.
  • last_updated_user überwacht den Benutzer, der die letzten Änderungen an den ergänzenden Attributen einer Entität vorgenommen hat.

• Attributtyp Systemeigenschaften speichern Systeminformationen auf Attributebene. Beispielsweise verfolgt attribute_last_updated die Zeit, zu der jedes Attribut zuletzt aktualisiert wurde.

• Systemeigenschaften für Beziehungstypen speichern Systeminformationen auf Beziehungsebene. Zum Beispiel:

  • relationship_last_updated verfolgt die Zeit, zu der jede Beziehung zuletzt aktualisiert wurde.
  • relationship_number speichert eine vom System generierte Identifikationsnummer für jede Beziehung.

• Systemeigenschaften vom Typ Hierarchie speichern Systeminformationen auf der Hierarchieebene. Zum Beispiel:

  • last_updated_date verfolgt die Zeit, zu der jede Hierarchie zuletzt aktualisiert wurde.
  • hierarchy_number speichert eine vom System generierte Identifikationsnummer für jede Hierarchie.

• In den Systemeigenschaften des Knotentyps werden Systeminformationen auf der Ebene des Knotens gespeichert. Zum Beispiel:

  • last_updated_date verfolgt die Zeit, zu der jeder Knoten zuletzt aktualisiert wurde.
  • node_number speichert eine vom System generierte Identifikationsnummer für jeden Knoten.

• Die Systemeigenschaften des Gruppentyps speichern Systeminformationen auf Gruppenebene. Zum Beispiel:

  • last_updated_date verfolgt die Zeit, zu der jede Gruppe zuletzt aktualisiert wurde.
  • node_number speichert eine vom System generierte Identifikationsnummer für jede Gruppeninstanz.

Sehen Sie sich das folgende Video an, um zu erfahren, wie Sie die vom System generierten Audit-Attribute anzeigen können, die IBMMatch 360 as a Service beim Hinzufügen oder Bearbeiten von Datensätzen erstellt.

Datensatztypen

Datensatztypen im Datenmodell definieren verschiedene Typen von Datensätzen, die für die für Ihre Organisation erforderlichen Domänen und Anwendungsfälle relevant sind. Jeder Datensatztyp besteht aus den folgenden Eigenschaften oder Objekten:

• label ist die Bezeichnung für den Datensatztyp.
• description ist eine Kurzbeschreibung des Datensatztyps.
• entity_types enthält die Objekte für alle Entitätstypen, die in diesem Datensatztyp enthalten sind. Jedes entity_type -Objekt enthält eine Bezeichnung, eine Beschreibung und optional einen Entitätstyp (Identität oder Assoziation).
• attributes ist ein Objekt, das alle dem Datensatztyp zugeordneten Attribute enthält. Jedes definierte Attribut enthält die folgenden Eigenschaften:
  • label -Eine Bezeichnung für das Attribut
  • description -Eine Beschreibung des Attributs.
  • attribute_type -Der Attributtyp dieses Attributs.
  • cardinality -Die Kardinalität des Attributs (list oder single). Kardinalität definiert, wie viele Werte dieses Attribut haben kann.
  • indexed -Ein boolesches Feld, das angibt, ob das Attribut indexiert ist, um freie Textsuchen in seinem Inhalt zu unterstützen.

Attributtypen

Attributtypen im Datenmodell definieren die Attributtypen, die einem Datensatz-oder Beziehungstyp zugeordnet werden können. Jeder Attributtypeintrag besteht aus den folgenden Eigenschaften oder Objekten:

• label ist die Bezeichnung für den Attributtyp.
• description ist eine Kurzbeschreibung des Attributtyps.
• matching_type gibt den Typ der Abgleichfunktion an, die auf alle Attribute dieses Attributtyps angewendet werden soll.
• fields enthält Definitionen aller Felder, die Teil dieses Attributtyps sind. Jedes Feld besteht aus label-, description-und indexed -Eigenschaften.

Beziehungstypen

Beziehungstypen im Datenmodell definieren die Beziehungstypen, die in diesen Daten zugeordnet werden können. Jeder definierte Beziehungstyp enthält die folgenden Eigenschaften und Objekte:

• label ist eine Bezeichnung für den Beziehungstyp.
• description ist eine Kurzbeschreibung des Beziehungstyps.
• classification gibt die Klasse der Beziehung an. Beispielsweise können Beziehungen vom Typ Hierarchie entweder als hierarchy_node_relationship klassifiziert werden, d. h. als eine Beziehung von Hierarchieknoten zu Knoten, oder als hierarchy_node_association_relationship, d. h. eine Beziehung zwischen einem Hierarchieknoten und einem zugehörigen Objekt. Zugehörige Objekte können Datensatztypen oder Entitätstypen sein. In ähnlicher Weise können Beziehungen des Typs Gruppe als group_association_relationship klassifiziert werden, was eine Beziehung zwischen Gruppe und zugehörigem Objekt darstellt.
• label_from_source ist die Bezeichnung für die Beziehung, die aus Sicht der Quelle angezeigt wird. Beispiel: "Verwaltet".
• label_from_target ist die Bezeichnung für die Beziehung aus der Sicht des Ziels. Beispiel: "Berichtet an".
• cardinality definiert die Kardinalität der Beziehung (z. B. Eins-zu-viele oder Eins-zu-eins).
• directional gibt an, ob Beziehungen dieses Typs gerichtet sind (unterschiedlich, je nachdem, welche Seite der Beziehung Sie anzeigen, wie z. B. eine Arzt-/Patientenbeziehung) oder bidirektional (von beiden Seiten der Beziehung, wie z. B. eine Peerbeziehung).
• attributes ist ein Objekt, das Definitionen aller Attribute enthält, die Teil dieses Beziehungstyps sind. Das Objekt attributes hat dieselbe Struktur wie das für ein Attribut eines Datensatztyps.
• rules ist ein Objekt, das die Quellen-und Zielregeln für diesen Beziehungstyp definiert.
  • Das Objekt für eine source -Regel enthält die Liste der Datensatztypen und Entitätstypen, die beim Erstellen einer Beziehung dieses Typs als Quelle verwendet werden können.
  • Das Objekt für eine Ziel regel enthält die Liste der Datensatztypen und Entitätstypen, die beim Erstellen einer Beziehung dieses Typs als Ziel verwendet werden können.

Hierarchytypen

Hierarchietypen im Datenmodell definieren die Arten von Hierarchien, die in diesen Daten zugewiesen werden können. Jeder definierte Hierarchietyp umfasst die folgenden Eigenschaften und Objekte:

• label ist eine Bezeichnung für den Hierarchietyp.
• description ist eine kurze Beschreibung des Hierarchietyps.
• node_type gibt den Typ des Knotens an, der in diesem Hierarchietyp verwendet wird.
• node_relationship_type gibt die Art der Knoten-Knoten-Beziehung an, die in diesem Hierarchietyp verwendet wird.
• node_associations gibt die Beziehung zwischen Knoten und assoziierten Objekten in diesem Hierarchietyp an. Zugehörige Objekte können Datensatztypen oder Entitätstypen sein.
• attributes ist ein Objekt, das alle mit dem Hierarchietyp verbundenen Attribute enthält. Jedes definierte Attribut enthält die folgenden Eigenschaften:
  • label ist eine Bezeichnung für das Attribut.
  • description ist eine Beschreibung des Attributs.
  • attribute_type ist der Attributtyp dieses Attributs.
  • cardinality ist die Kardinalität des Attributs (Liste oder einzeln). Kardinalität definiert, wie viele Werte dieses Attribut haben kann.
  • indexed ist ein boolesches Feld, das angibt, ob das Attribut indiziert ist, um Freitextsuchen nach seinem Inhalt zu unterstützen.

Knotentypen

Knotentypen im Datenmodell definieren die verfügbaren Knotentypen, die in diesen Daten zugeordnet werden können. Jeder definierte Knotentyp umfasst die folgenden Eigenschaften und Objekte:

• label ist eine Bezeichnung für den Knotentyp.
• description ist eine kurze Beschreibung des Knotentyps.
• classification gibt die Klasse des Knotens an. Bei Hierarchien werden die Knoten beispielsweise als hierarchy_node klassifiziert, was bedeutet, dass der Knoten mit Hierarchietypen verwendet wird.
• attributes ist ein Objekt, das alle mit dem Knotentyp verbundenen Attribute enthält. Jedes definierte Attribut enthält die folgenden Eigenschaften:
  • label ist eine Bezeichnung für das Attribut.
  • description ist eine Beschreibung des Attributs.
  • attribute_type ist der Attributtyp dieses Attributs.
  • cardinality ist die Kardinalität des Attributs (Liste oder einzeln). Kardinalität definiert, wie viele Werte dieses Attribut haben kann.
  • indexed ist ein boolesches Feld, das angibt, ob das Attribut indiziert ist, um Freitextsuchen nach seinem Inhalt zu unterstützen.

Gruppentypen

Die Gruppentypen im Datenmodell definieren die Arten von Gruppen, die in diesen Daten zugewiesen werden können. Jeder definierte Gruppentyp umfasst die folgenden Eigenschaften und Objekte:

• label ist eine Bezeichnung für den Gruppentyp.
• description ist eine kurze Beschreibung des Gruppentyps.
• group_associations gibt die Beziehung zwischen Gruppe und assoziierten Objekten in diesem Gruppentyp an. Assoziierte Objekte können Datensatztypen sein.
• attributes ist ein Objekt, das alle mit dem Gruppentyp verbundenen Attribute enthält. Jedes definierte Attribut enthält die folgenden Eigenschaften:
  • label ist eine Bezeichnung für das Attribut.
  • description ist eine Beschreibung des Attributs.
  • attribute_type ist der Attributtyp dieses Attributs.
  • cardinality ist die Kardinalität des Attributs (Liste oder einzeln). Kardinalität definiert, wie viele Werte dieses Attribut haben kann.
  • indexed ist ein boolesches Feld, das angibt, ob das Attribut indiziert ist, um Freitextsuchen nach seinem Inhalt zu unterstützen.

Kompatibilität mit InfoSphere MDM-Quellsystem-Kennungen

IBM InfoSphere MDM Advanced Edition verwendet Quellsystem-Identifikatoren, um Quellsystem-Informationen für jeden Teilnehmerdatensatz in seiner Datenbank zu verfolgen. Durch die Unterstützung von Quellsystemkennungen kann als Service Datensätze aus InfoSphereIBMMatch 360 MDM importieren und dabei die ursprünglichen Quellsystemkennungen beibehalten. Diese Strategie ermöglicht es denselben Quellsystemen, später direkt mit IBMMatch 360 as a Service zu interagieren und ihre eigenen Quellsystem-Identifikatoren zu verwenden, um Datensätze nach Bedarf abzurufen und zu aktualisieren.

Massenladen von Quellsysteminformationen mit Hilfe der API

Wenn Sie Datensätze, die Informationen aus dem Quellsystem enthalten, mithilfe der API in IBMMatch 360 as a Service hochladen, müssen Sie den Massenladevorgang unterschiedlich handhaben, je nachdem, ob die Datenquelle MDM Advanced Edition oder das IBMInfoSphere ursprüngliche Quellsystem selbst ist.

• In IBM InfoSphere MDM Advanced Edition werden Parteidatensätze aus Quellsystemen konsolidiert, wenn das InfoSphere MDM-System sie durch seinen Abgleichprozess als dieselbe Entität identifiziert. Dieser Prozess führt zu angereicherten Parteiprofilen. Wenn Sie Daten aus dem Party-Datensatz von InfoSphere MDM Advanced Edition in IBMMatch 360 as a Service aktualisieren oder einfügen, sollten die angereicherten Informationen alle vorhandenen Datensätze überschreiben. Um dieses Ergebnis zu erreichen, können Sie die API-Methoden bulk_load oder ongoing_sync mit der put/replace strategie verwenden, die den gesamten Datensatz ersetzt.

• Wenn Aktualisierungen aus einem Quellsystem stammen und in IBMMatch 360 as a Service berücksichtigt werden müssen, dürfen Sie nicht das gesamte angereicherte Profil überschreiben. Stattdessen sollten nur die kürzlich geänderten Attribute aktualisiert werden. Sie können dies erreichen, indem Sie die API-Methoden bulk_load oder ongoing_sync mit der patch strategie, die nur die in der Nutzlast der Anfrage enthaltenen Attribute aktualisiert und den Rest der angereicherten Daten intakt lässt.

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