Additional Information Regarding the Comparison Process
You will have a better understanding on how match candidates are compared by getting a deeper insight about the comparison process.
Multiple Values in an Attribute
It’s important to remember that with the Reltio architecture, an attribute will typically hold multiple values, each sourced from a contributing crosswalk, resulting from one or more merges. Suppose for First Name, Profile A has values of Bill, and William, while Profile B has values of Willy, William, and Will. The comparison process intrinsically is designed to test each value from Profile A against each value of Profile B. In this case that will produce 2x3, 6 possibilities for a positive evaluation of that attribute.
Here is a screenshot taken from the Sources view of a profile, illustrating how the Name field for this organization contains a variety of values, accumulated during many merges.
Comparing only the OV of the Attribute
It is quite possible and likely that within an attribute, only one of the values it contains is deemed to be the operational value (OV). This means when any normal call to retrieve the attribute’s value occurs, just the OV will be returned, rather than the multiple values the attribute is holding. IQVIA is the OV in the example above.
The combinatorial approach (2x3 = 6 in our example above) has its benefits but for
most customers’ needs, it is desirable to restrict comparison to just the
operational value (OV) of the attribute. If this makes sense from a business
perspective, it will often reduce the number of combinations and improve
performance. You can achieve this by including the setting of useOvOnly =
true
in your match group which is recommended. Continuing with our
example, if the OV of Profile A is William, and the OV of Profile
B is Billy, then instead of a 6-way test, there will only be a single
test of William against Billy. That said, whether this test produces a
positive or negative match will depend on the match strategy designed for this match
group. For example, use of the NamesDictionaryCleanser
will cause
William and Billy to be considered nicknames of one another and
will result in a positive match outcome.
useOvOnly
is recommended and is set at the
match group level, thus it applies to the whole rule, meaning it affects all
attributes in the rule.Case Insensitivity During Comparison
The Reltio match engine performs all match evaluations in a case-insensitive manner.
How Comparison Operators rollup to rule level
How does the test for similarity at the attribute level rollup to one directive of the three possible directives at the rule level? That depends on the type of matching you have chosen to use for the match group.
automatic
orsuspect
rulesIn either of these types of rules, each Comparison Operator within the rule will evaluate to
TRUE
orFALSE
. The outcome of the rule is the boolean algebraic sum of the Comparison Operators. For example, if you have a simple rule that indicates a logicalautomatic
‘AND’ of(Fuzzy(First Name, Last Name)
,Exact(AddrLine1)
, then there are three comparisons taking place. In order for the rule to evaluate toTRUE
, all three comparisons must evaluate toTRUE
.relevance_based
ruleWith this type of rule, the directive coming from the rule is based on a score calculated from an algorithm specified by you using
weights
andactionThresholds
within the rule. For more information, see Relevance-Based Matching - Detailed Explanation.