Types of entities

When you define a new entity type in your data model, you must decide what this entity's purpose is:

• Identity entities link records that all appear to represent the same real-world person, organization, or object. They share a common identity. For example, a Business Partners entity can be used to match organization records within your data that represent the same real-world company.

• Association entities link records that should be associated for another reason, such as a shared address, employer, or purchasing decision. One common example of an association entity type is a household. You can create a Households entity type that matches members of a given household into a single entity. By using householding entities, you can track and analyze behavior and activity on a per-household basis.

Householding entities

Watch the following video to see how to use association entities to identify households within your IBM Match 360 data.

When you create an association entity type to help you track and identify person records who share a household, there are some important factors to consider. Establishing your householding criteria is a critical first step in managing and forming households. Households can be defined by explicit criteria, expressed criteria, or a combination of the two.

Explicit criteria can include any attribute in your data model. The following are examples of explicit criteria that you might consider in your householding strategy:

• Parties share the same address of a given address type, such as the same home address.
• Parties share a last name.
• Parties fall within a defined age range.
• Parties share a contact method, such as a home phone number.
• Parties have a certain type of relationship, like a family relationship.
• Parties have specific roles in the context of a contract. For example, a parent might have a legal representative role for an account owned by a child.

Use explicit criteria to build households with the matching algorithm. To enable IBM Match 360 to build your household entities algorithmically, select your selected explicit criteria as the matching attributes for this entity type. For information about configuring the matching algorithm, see Matching your data to create master data entities.

Expressed criteria includes other information that is not part of the data model. Expressed criteria might have been verbally communicated by a household member or an agent. The following are examples of expressed criteria that you can consider in your householding strategy:

• Parties have communicated that they are within the same household.
• An agent has collected household information during the initial setup of a customer account.

To build a household entity based on expressed criteria, you must manually link records to form an entity. You can create manual record links by using the master data workspace to edit a record's linkage rules. For more information, see Exploring master data entities and records in IBM Match 360 with Watson.

Determining an entity's attribute values

A master data entity can include two categories of attributes:

• Attributes whose values are composited from an entity's member records.
• Attributes whose values are stored directly in the entity, known as entity attributes.

Composited attributes

Entities derive many of their attribute values from the values defined in their member records. An entity's attribute values get selected from its member records by using a set of attribute composition rules. You can define and customize attribute composition rules for each entity type in your data model. For more information about attribute composition, see Defining attribute composition rules in IBM Match 360. :

Entity attributes

Entity attributes are defined directly in the entity, as opposed to being composited from its member records. Define entity attributes in the data model of your entity types. For information about modifying the data model, see Customizing your data model.

• To change the value of an entity attribute, edit the entity directly. Editing member records does not affect the value of an entity attribute. For information about editing an entity, see Adding and editing records and entities in IBM Match 360.
• When an entity is first created by the matching algorithm, it does not have any entity attribute values defined. Edit the entity in the master data workspace to provide values for entity attributes.
• If an entity with populated entity attribute values gets deleted as a result of a change in its composition, either through a manual link or unlink action or through a change to the matching algorithm, then its entity attribute values are transferred to any surviving entities.
• If two entities that both have entity attributes are merged (either matched or manually linked), then the entity attribute values of the surviving entity ID take precedence. If the attribute in question consists of a list of values, then the system merges the lists from both entities. The merge ensures that the list does not contain any duplicate values. If the two lists both include the same value, then that value appears only once in the merged list.

Entity persistence

When defining the data model, you can configure whether the composite views of each entity type are saved in the database or composed on demand from their member records. When an entity type is configured to persist, the composited attributes of each entity get stored in the database similar to the way that record attributes are stored, meaning that entity data is more stable and resilient.

When entities are configured to persist, data stewards and business users can directly search on entity data, including supplementary attributes, audit attributes, and system properties such as record count and entity ID. Users can search for persisted entities by using the simple or advanced search mechanisms in the master data explorer interface.

Depending on the volume of entities in your master data, storing entity composite views in the database can cause the size of the database to increase significantly.

For more information about defining entity types, see Customizing the data model.

System properties (audit attributes)

System properties in the data model enhance your ability to audit the data in IBM Match 360 to help ensure compliance with data governance rules. System properties are defined, captured, and stored by the system and are not available for customization or modification. There are system properties associated with four different elements of the data model: record types, entity types, attribute types, and relationship types.

• Record type system properties store system information at the record level. For example:

  • record_last_updated tracks the time each record was last updated.
  • record_number stores a system-generated identifying number for each record.

• Entity type system properties store system information at the entity level. For example:

  • created_date stores the time and date when an entity was created.
  • link_last_updated_date tracks the time and date when the member records of an entity were last changed.
  • last_updated_date stores the time and date when an entity's supplementary attributes were last changed.
  • last_updated_user tracks the user who made the most recent changes to an entity's supplementary attributes.

• Attribute type system properties store system information at the attribute level. For example, attribute_last_updated tracks the time each attribute was last updated.

• Relationship type system properties store system information at the relationship level. For example:

  • relationship_last_updated tracks the time each relationship was last updated.
  • relationship_number stores a system-generated identifying number for each relationship.

Watch the following video to see how to view the system-generated audit attributes that IBM Match 360 creates when you add or edit record data.

Record types

Record types in the data model define various types of records relevant to the domains and use cases required by your organization. Each record type consists of the following properties or objects:

• label is the label for the record type.
• description is a short description of the record type.
• entity_types contains the objects for all of the entity types that are included in this record type. Each entity_type object contains a label, desciption, and optionally a type of entity (identity or association).
• attributes is an object that contains all the attributes associated with the record type. Each defined attribute contains the following properties:
  • label - A label for the attribute.
  • description - A description of the attribute.
  • attribute_type - The attribute type of this attribute.
  • cardinality - The cardinality of the attribute (list or single). Cardinality defines how many values this attribute can have.
  • indexed - A Boolean field indicating whether the attribute is indexed to support free text searches of its contents.

Attribute types

Attribute types in the data model define the types of attributes that can be associated with a record type or relationship type. Each attribute type entry consists of the following properties or objects:

• label is the label for the attribute type.
• description is a short description of the attribute type.
• matching_types indicates the type of matching function to apply on all the attributes of this attribute type.
• fields contains definitions of all the fields that are part of this attribute type. Each field consists of label, description, and indexed properties.

Relationship types

Relationship types in the data model define the types of relationships available to be assigned in this data. Each defined relationship type includes the following properties and objects:

• label is a label for the relationship type.
• description is a short description of the relationship type.
• label_from_source is the label for the relationship, as viewed from the source's point of view. For example: "Manages".
• label_from_target is the label for the relationship, as viewed from the target's point of view. For example: "Reports to".
• cardinality defines the cardinality of the relationship (such as one-to-many or one-to-one).
• directional indicates whether relationships of this type are directional (different depending on which side of the relationship you are viewing, such as an doctor/patient relationship) or bidirectional (the same from both sides of the relationship, such as a peer relationship).
• attributes is an object containing definitions of all of the attributes that are part of this relationship type. The attributes object has the same structure as the one for an attribute of a record type.
• rules is an object that defines the source and target rules for this relationship type.
  • The object for a source rule contains the list of record types and entity types that can be used as a source while creating a relationship of this type.
  • The object for a target rule contains the list of record types and entity types that can be used as a target while creating a relationship of this type.