test

Working With the Master Index Data Manager

Learning about MIDM Object Profiles

The information about an object in a master index application is stored in an object profile. The profile includes information from all of the source records for that object and also includes a record that contains the best information about the object according to the master index application.

The following topics describe object profiles and their components:

MIDM Object Profile Components

An object profile, also known as an enterprise record, is a set of information that describes characteristics of an individual object in the master index application. An object profile includes information from one or more source systems. The information can be divided up into child objects, which hold additional information about an object, such as address information, telephone information, or alias names.

A profile contains two types of records:

Source Records

Source records are different from the SBR in that each source record contains a system and local ID pair and only contains data from a specific system. The information in the source records of an object profile is used to determine the best values for the SBR in that profile. If an object profile only contains one source record, the SBR will be identical to that source record. However, if an object profile contains multiple source records, the SBR might be identical to one source record but will more likely include a combination of information from all source records. Certain actions against a source record will cause the SBR to be changed, such as updating, deactivating, or merging a source record. Each active object profile must have at least one active source record. If all source records in a profile are deactivated, then the entire profile will also be deactivated.

Single Best Record

The single best record (SBR) for an object profile is made up of a combination of information from all active source records associated with that object profile. The SBR represents the information that is determined by the master index application to be the most reliable and current of all source records in an object profile. The SBR is dynamic and is recalculated each time an update is made to an associated source record, a merge or unmerge affects the object profile, or a source record in the profile is deactivated or reactivated. You can use the overwrite capability of the MIDM to update the SBR directly or you can update a source record and allow the survivor calculator to determine how to update the SBR (for more information, see Survivor Calculator).

You can override the survivor calculator by specifying values for the SBR in two ways. You can use the overwrite capability to update a field, and that field remains locked and cannot be updated by changes to source records until the field is unlocked. You can also link a field in the SBR to the same field in one of the profile's source systems, and that SBR field will always contain the same value as the source system until the link is removed. For more information about the overwrites and linked fields, see Locking Field Values in the SBR.

Survivor Calculator

The survivor calculator determines which information from each source record in an object profile is stored in the SBR for that profile. The calculator uses information defined by the system administrator to calculate the SBR. By default, the survivor calculator uses a weighted strategy for most fields, using the relative reliability assigned to each system in combination with the reliability given to the most recently updated value.

For some fields, such as alias and auxiliary IDs, a union strategy is typically used. This means that all unique alias names and auxiliary IDs from all systems are included in the SBR. For detailed information about the survivor calculator and configuring the survival strategy, see Survivor Strategy Configuration in Understanding Sun Master Index Configuration Options and Defining the Master Index Survivor Calculator in Configuring Sun Master Indexes .

Source Record and SBR Components in a Master Index

In a master index application, each source record and SBR in an object profile contains a set of sub-objects that store different types of information about the object. Generally, a record contains a parent object and several child objects. A record can have only one parent object, but can have multiple child objects and multiple instances of each child object with each instance being identified by a unique field. For example, in a master person index a record can only contain one person name and social security number (contained in the parent object), but could have multiple addresses, telephone numbers, and aliases (contained in child objects). Typically each address must be of a different type, such as a home address, billing address, or mailing address.

Identification Numbers for each Entity in the Master Index

Each object profile in a master index application is assigned a unique identification number in addition to the local IDs assigned by individual systems. Each object has one unique identification number throughout your organization and a unique identification number within each system with which they are registered.

EUID

Every object profile in the master index system is assigned an enterprise-wide unique identification number. This number is the same for that object regardless of the system from which the object information originates. This number is called the enterprise-wide unique identifier (EUID) and is used to cross-reference object profiles in order to accurately identify the objects throughout your organization.

Local ID

A local ID is a unique local identification number that is assigned to an object in each system at which it is registered. These numbers are assigned using a numbering system unique to each local system, and are used internally by the systems to identify each object. A master index application uses an object’s EUID to cross-reference its local IDs in different systems. Note that the name of the Local ID field is configurable and might be different for your implementation.

Auxiliary ID

An auxiliary ID is an identification code that does not necessarily uniquely identify a single object within the database, but might identify a group of objects. For example, if a family shares the same account or insurance policy, every family member would have the same identification code for that account or policy.