DQM White Paper 12 20 04-2

Oracle Trading
Community Architecture
Understanding the Concepts of
Data Quality Management
An Oracle White Paper
December 2004

Table of Contents
Executive Overview..................................................4
Introduction................................................................5
The Need for Clean TCA Data....................................5
Data Quality management (DQM)........................6
Overview.....................................................................6
How DQM Works........................................................6
Transformation Functions..............................................7
Word Replacement Lists................................................8
Match Rules..............................................................10
Match Rule Types.......................................................10
Defining Match Rules..................................................11
DQM In the E-Business Suite and Customer Hub
Solution.....................................................................17
Smart Search............................................................17
Duplicate Prevention...................................................17
Duplicate Identification...............................................17
Conclusion................................................................19
Appendix A................................................................20
DQM Examples.........................................................20
Smart Search Example................................................20
Duplicate Prevention Example......................................25
Duplicate Identification Example...................................31
What To Do With Duplicates.....................................33
Appendix B................................................................34
Definitions and Terminology.....................................34
Appendix C................................................................36
E-Business Suite Applications That Have Registered Merge
Routines with Party Merge..............................................36
Appendix D................................................................38
E-Business Suite Applications Referenced by Customer Account
Merge.........................................................................38
Oracle Trading Community Architecture Data Quality Management Understanding the Concepts Page 2

Executive Overview
This document is intended to provide the reader with an
overview of the functionality and usage of the Oracle Data
Quality Management (DQM) engine, which is designed to help
a deploying company identify duplicate records within a
customer registry.
The primary audience for this document includes individuals
within a deploying company who are responsible for
information quality and consultants who are implementing
DQM on behalf of a deploying company.
This white paper serves as a high level guide for understanding
DQM and how it is used. For more information regarding DQM
refer to the following documents available on OracleMetaLink:
Oracle Trading Community Architecture Administration

& Reference Guides
Oracle Data Librarian User & Implementation Guides
Please refer to Appendix B at the end of this paper for a list of

Definitions and Terminology mentioned throughout the
document.
Introduction
A
trading
community
consists
of
the
organizations, people and
places
with
which
a
company does or intends to
do
Thebusiness.
Oracle Customer Data
Hub is a packaged solution
that allows a deploying
company to create a single,
enterprise-wide
customer
database by consolidating
customer
information
residing
in
different
heterogeneous systems.
The Data Quality Management (DQM) tool is a flexible

duplicate identification engine that is bundled with the Oracle
Trading Community Architecture (TCA). TCA stores
information and relationships about a companys trading
community, and is the core data model used by all E-Business
Suite applications as well as the Oracle Customer Data Hub
solution.
The features of the DQM engine can be used with other TCA
data quality tools to not only identify duplicate records, but
also resolve them by merging the duplicate parties and
accounts while properly maintaining all associated
transactions.
The Need for Clean TCA Data

An accurate representation of the trading community is
essential to the success of any company. With duplicated and
fragmented data, companies are susceptible to poor customer
interactions, low customer satisfaction rates and low customer
retention rates. In todays increasingly competitive business
environment, gaining, and more importantly retaining
customers is priority number one.
Data Quality management (DQM)

Overview
DQM is a highly configurable duplicate identification engine.
The flexibility of the DQM engine allows a deploying company
to create their own definitions of what constitutes a duplicate
record. Alternate definitions can be used to support specific
business functions. These definitions are called Match Rules,
which can be leveraged to:
-
enhance TCA registry search screens
prevent duplicate records from entering the TCA

registry
identify existing duplicate records within the TCA

registry
How DQM Works

At the core of the DQM search engine is the ability to identify
similar records where the data is misspelled or inconsistent.
Many traditional search engines only have the ability to
identify exact records. For example, imagine that the
following parties exist in a TCA registry:
The Input Value is the

value that the DQM engine
uses to search the TCA
registry to find matching
records.
Business World
Business Wurld
Bisness World
Using a traditional searching method a user tries to find a

record called Business World, which becomes the input
value:
TCA Registry
Input Value
Business World
busines world
Business Wurld
Matching
Records
None
Bisness World
Figure 1: Traditional Search Engine
As you can see, no records were returned from this search

because none of the records in the TCA registry matched the
input value exactly. However the data in the TCA registry

shows that there are other Business Worlds, which happen to
be misspelled. The DQM engine was designed to find these
misspelled records by searching for similar records instead
of exact records. To do this DQM uses Transformation
Functions.
Transformation Functions
Staging
Tables
store
transformed TCA registry
data solely for the purpose
of
identifying
duplicate
records.
A Routine is a procedure
that transforms a data
element in a certain way.
Routines are called upon by
Transformation Functions.
Transformation Functions take data stored within specified

attributes of the TCA registry and alters it for the purpose of
identifying duplicates. The transformed data is stored in
Staging Tables and is solely used internally by the DQM engine
to identify matching records. Transformed data is helpful
when trying to identify similar records with words that are
aliased, inconsistent or misspelled. DQM comes with several
seeded transformation functions, plus the flexibility to create
custom transformation functions to address unique
requirements.
Two of the basic seeded transformation functions, EXACT
and CLEANSE, are listed below. The Routines column
shows the routines that are called to transform the data. A
transformation function can contain one to many routines. For
a complete list of all seeded transformation functions please
refer to the document Oracle Trading Community
Architecture Reference Guide available on OracleMetaLink.
Transformation
Function
EXACT
Routines
Capitalize all letters
Remove non-alphanumeric
characters
Reduce all white space to a single
white space
CLEANSE
Capitalize all letters

Remove non-alphanumeric
characters
Reduce all white space to a single
white space
Remove double letters
Remove all vowels, except leading
vowels
Remember in Figure 1 on Page 5, no matches were found when

searching for Business World because the search engine
used could only identify exact matches. Now lets see how
the DQM search engine would handle this same scenario using
transformation functions to find similar matches instead of

exact matches.
In Figure 2 below, notice how the TCA registry data is
transformed and placed into a staging table for the purpose of
identifying duplicates. In this example the transformation
functions used are EXACT and CLEANSE.
First, the input value is transformed. Then it is evaluated
against the data in the staging table to look for duplicate
records. Because the data has been transformed, the DQM
search engine finds three matching records and returns them
to the user.
TCA Registry
Input Value
Business World
busines world
Business Wurld
Bisness World
TCA Registry
Matching Records
busines world
Business Wurld
Bisness World
Staging Table
Transformed
Input Value
BSNS WRLD
BSNS WRLD
BSNS WRLD
BSNS WRLD
Staging Table
Matching Records
BSNS WRLD
BSNS WRLD
BSNS WRLD
Figure 2: DQM Search Engine
Figure 2 shows that by using the DQM search engine, the

common misspellings of Business World were neutralized by
applying two basic transformation functions.
It is important to remember that the actual data in the TCA
Registry is not being physically changed by the transformation
functions. It is only being copied and then transformed into a
temporary Staging Table for the purpose of identifying

duplicate records.
In addition to calling routines, transformation functions also
can call Word Replacement Lists to help alter and standardize
the data.
Word Replacement Lists
Word Replacement Lists (WRL) standardize words or remove

noise words to improve the likelihood of finding duplicates.
They are especially helpful with nicknames and abbreviations.
Similar to routines, WRLs can be called upon by transformation
functions.
DQM comes seeded with a number of Word Replacement Lists
relating to street types, US state names, person names, and
organization names. Below are samples from the seeded
Person Name and Organization Name Word Replacement
Lists to demonstrate how words can be standardized for the
purpose of matching.
Person Name WRL

TCA
Standardiz
Bill
Bill
Organization Name WRL

TCA
Standardize
Inc
Inc.
Billy
Bill
Incorp.
Inc.
William
Bill
Incorporated
Inc.
To give an example of how WRLs can be used to identify

duplicate records, Figure 3 below shows the application of the
Organization Name WRL.
First, the input value is transformed using a WRL. Then it is
evaluated against the data in the staging table to look for
matching records. Because the data has been transformed
using the WRL, the DQM engine finds three duplicate records
and returns them to the user.
TCA Registry
Input Value
Business Incorp
Business Inc
Business Incorp.
Business Incorporated
TCA Registry
Matching Records
Business Inc
Business Incorp.
Business Incorporated
Staging Table
Transformed
Input Value
Business Inc.
Business Inc.
Business Inc.
Business Inc.
Staging Table
Matching Records
Business Inc.
Business Inc.
Business Inc.
Figure 3: Using Word Replacement Lists to identify

duplicate records
Seeded Word Replacement Lists are provided for American

English and can be updated or new lists can be created.
Additionally, deploying companies can use the existing
architecture to create word replacement lists for any language
around the world. Both single and double byte character sets
are supported.
Using Transformation Functions and Word Replacement Lists
to alter Attributes for the purpose of finding matching records
is how the DQM engine works. However, a key differentiator
of the DQM tool is that the user has the flexibility to define
what they consider to be a duplicate. To do this, selected
Attributes, Transformation Functions and Word Replacement
Lists are packaged together to create Match Rules.
Match Rules
Match Rules represent the different definitions of what
constitutes a duplicate record, and are used by the DQM
engine to identify similar records in the TCA registry. A
deploying company can create any number of match rules to be
used at different times for different purposes. A number of
match rules are seeded to provide a foundation for using the
DQM engine, however users can additionally choose to create
their own match rules based on specific requirements.
Match Rule Types
There are three types of match rules: Search, Bulk and

Expanded.
Search Match Rules
Search Match Rules are used by DQM to enhance party
search screens or to prevent duplicate records from
entering the TCA registry through party creation screens.
These match rules take user data input and search the TCA
registry for potential duplicates.
interMedia Indexes are
built using inverted indexes,
a structure that differs from
normal indexes and allows
the use of a contains
query.
Search Match Rules are comprehensive in their search

because they use interMedia Indexing, which is a type of
indexing that supports the use of a contains query. This
allows Business World to be found as a potential duplicate
for World of Business.
Bulk Match Rules
Bulk Match Rules are mainly used by DQM to prevent
duplicate records from entering the TCA registry through
bulk data import, but can also be used to identify existing
duplicates within the TCA registry. When used to prevent
duplicates from entering through bulk import, these match
rules take each imported record one at a time and search
the TCA registry for potential duplicates.
Bulk Match Rules are less comprehensive than Expanded
Match Rules but provide improved performance. This is
because they use B-Tree Indexing rather than interMedia

Indexing.
Expanded Match Rules
Expanded Match Rules are used by DQM to identify existing
duplicate records within the TCA registry. These match
rules take an existing record as the input and search the
remainder of the TCA registry looking for potential
duplicates.
Expanded Match Rules are as comprehensive as Search
Match Rules because they also use interMedia Indexing.
Defining Match Rules
The Work Unit consists of

all records from the Staging
Tables with attribute values
that match the transformed
acquisition attribute values
of the input record.
The
work unit saves time and
resources
because
this
relevant subset of records,
not
the
entire
staging
tables, can be compared
against the input record for
scoring.
To effectively define match rules it is helpful to understand how

they are used. The DQM engine uses match rules in a two-step
process consisting of an Acquisition phase and a Scoring
phase. The Acquisition phase takes an input value and
searches the TCA registry for similar records. These
matching records form a subset called the Work Unit. The
Scoring phase then evaluates the records in the Work Unit to
determine which records are closer matches to the input value
than others. Match rules provide the DQM engine with the
information necessary to execute both of these phases.
Figure 4 shows the main components involved in setting up
each phase. Notice that the Acquisition Phase setup is
required, but the Scoring Phase setup is optional.
Match Rule
Acquisition Phase
(Required)
Scoring Phase
(Optional)
Select Attributes
Select Attributes
Select Transformation Functions
Select Transformation Functions

Set Weightings
Set Scores
Set Thresholds
Figure 4: DQM Engine Phases with Associated Match

Rule Setups
There are seven steps to follow when creating a match rule.

The steps remain basically the same no matter which of the
three types of match rules is being created, however the
strategy behind creating the match rule may change.
Next, we will go through the seven steps of creating a match
rule. While describing the seven steps, we will create a match
rule of type Search called DUPLICATE SEARCH.
Step 1: Choose Match Rule Type
The type of match rule being created needs to be selected. The
three types of match rules that can be created are: Search,
Expanded and Bulk.
The DUPLICATE SEARCH match rule type will be Search.
Step 2: Choose Attributes
Next, determine which attributes are important when
searching for similar records. The attributes selected here will
be the basis for identifying duplicates.
For the DUPLICATE SEARCH match rule the following
attributes are selected:
Attribute
Organization
Name
URL
Phone Number
Street Address
City
Step 3: Choose Attribute Usages
The next step is to determine how the DQM engine will use
each chosen attribute. Recall that the DQM process of
identifying duplicates consists of an acquisition and scoring
phase, therefore each of the chosen attributes can be used in
the acquisition phase, scoring phase or both. As a general
rule, the use of Acquisition and Scoring will be selected for
all chosen attributes.
For the DUPLICATE SEARCH match rule the chosen

attributes will have these uses:
Attribute
Use
Organization
Name
Acquisition and
Scoring
URL
Acquisition and
Scoring
Phone Number
Acquisition and
Scoring
Street Address
Acquisition and
Scoring
City
Acquisition and
Scoring
Step 4: Assign Transformation Functions to Attributes

Remembering that transformation functions are helpful when
trying to identify duplicate records, the next step is to decide
which transformation functions should be used for each
attribute in this match rule. Each attribute/use combination
must have at least one transformation function.
There will be four different transformation functions used in
this match rule. They are:
EXACT Defined on Page 6
CLEANSE Defined on Page 6
WR(ORG)+CLEANSE Combines the CLEANSE

transformation function with the Organization word
replacement list
WR(ADD)+CLEANSE Combines the CLEANSE

transformation function with the Address word
replacement list.

transformation functions will be selected for each
Attribute/Use combination. Notice that for the attribute
Organization Name for the Scoring use, two transformation
functions have been selected:
Attribute
Use
Transformation
Organization
Name
Acquisitio
n
WR(ORG) +
CLEANSE
Scoring
WR(ORG) + EXACT
WR(ORG) +
CLEANSE
URL
Phone Number
Street Address
City
Acquisitio
n
EXACT
Scoring
EXACT
Acquisitio
n
EXACT
Scoring
EXACT
Acquisitio
n
WR(ADD) +
CLEANSE
Scoring
WR(ADD) +
CLEANSE
Acquisitio
n
CLEANSE
Scoring
CLEANSE
At this point the required acquisition phase setup is complete.

If any of the selected attributes are selected for the use of
scoring, then additional setup steps need to be completed.
Weightings and Scores need to be assigned and a Match
Threshold needs to be set.
Step 5: Assign Weightings
In addition to assigning the transformation functions,
weightings must be given to each scoring transformation
function. Weightings can further control the matching process
by giving only a percentage of the total points (Step 6: Assign
Scores) that will be assigned to the attribute. For example, a
weighting of 100% would likely be given to an EXACT
transformation function, while maybe only 75% would be given
to a CLEANSE transformation function. This means that we
want to give more points to an attribute that matches exactly,
than if it only matched after the attribute values had been
cleansed.

weightings have been assigned to each of the scoring
transformation functions:
Attribute
Use
Transformation
Organization
Name
Acquisitio
n
WR(ORG) +
CLEANSE
Scoring
WR(ORG) + EXACT
100%
WR(ORG) +
CLEANSE
75%
URL
Phone Number
Street Address
City
A Score is a number given

to an attribute in a match
rule that identifies the
importance
of
that
attribute when identifying
matching records.
The
higher the score the more
helpful that attribute is in
the duplicate identification
process.
Acquisitio
n
EXACT
Scoring
EXACT
Acquisitio
n
EXACT
Scoring
EXACT
Acquisitio
n
WR(ADD) +
CLEANSE
Scoring
WR(ADD) +
CLEANSE
Acquisitio
n
CLEANSE
Scoring
CLEANSE
Weigh
t
100%
100%
100%
100%
Step 6: Assign Scores

A Score must to be assigned to each attribute used in the
scoring phase. These scores will be used to determine how
close of a match each record in the work unit is when
compared to the input record. Scoring Attributes that provide
the most influence when determining a duplicate record should
be given the highest scores, while generic scoring attributes
are given the lowest scores.
When assigning scores, distribute 100 points across your
selected scoring attributes. Distributing scores out of 100
points is not required, however it is recommended. Based on
this logic, the following Scores have been assigned to each of
the scoring attributes for the DUPLICATE SEARCH match
rule:
Attribute
Use
Scor
e
Organization
Name
Scoring
20
URL
Scoring
30
Phone Number
Scoring
25
Street Address
Scoring
15
City
Scoring
10
TOTAL POSSIBLE SCORE

The Matching Score is
determined
by
adding
together the scores derived
from each attribute from the
work
unit
record
that
matches the same attribute
from the input value.
The Match Threshold is a

value
used
in
DQM
matching to control which
records will be brought
back as potential duplicates.
Only records with a total
score that equals or exceeds
the match threshold are
selected as a match to the
input record.
100
The purpose of assigning scores is to determine a Matching

Score for each record in the work unit during the scoring
phase. The Matching Score is determined by adding together
the scores for each attribute that matches the input record.
The Matching Score will be used to determine how close of a
match that particular record is to the input record.
Step 7: Set Thresholds
The final step is to set the Match Threshold. The value of the
Match Threshold will determine which records from the work
unit are returned to the user as potential duplicates. If a
record in the work unit falls below the Match Threshold, it is
not returned as a potential duplicate. If a record in the work
unit is equal to or greater than the Match Threshold, it is
returned as a potential duplicate.
Comparing the records in the work unit against the Match
Threshold will change depending on if DQM is being used for
Smart Search, Duplicate Prevention or Duplicate Identification.
For Smart Search and Duplicate Prevention the Threshold
Score needs to be calculated. For Duplicate Identification the
Matching Score can be compared directly to the Match
Threshold.
To calculate the Threshold Score use the equation below:
Threshold Score = (Matching Score / Total Possible Score) *
100
The Total Possible Score

is the maximum score that a
record in the work unit can
receive. This number will
vary based on the number of
attributes passed to the
DQM engine via the input
data.
To determine the Total Possible Score, add up the scores, as

defined in the match rule, for each attribute passed by the
input data. This value will change based on the number of
attributes used in the input data.
For Example:
If Organization Name and Phone Number were passed as
the input value then the Total Possible Score will be 45.
However, if Phone Number, Street Address, and City
were passed as the input value then the Total Possible Score
would be 50.
Important Note: If running a System Duplicate Identification
Batch, the Threshold Score does not need to be calculated.
The Matching Score can be compared directly to the Match
Threshold to determine if the record will be returned or not.
For the DUPLICATE SEARCH match rule the Match
Threshold will be set to 70.
It is important to remember that there is a great deal of
strategy involved when creating match rules. A deploying
company will select different attributes, scores and thresholds
depending on its business requirements, what its definition of a
matching record is and how comprehensive the match rule
needs to be.
DQM In the E-Business Suite and Customer Hub Solution

The application of the DQM search engine can be categorized
into three different areas.
1. Smart Search
2. Duplicate Prevention
3. Duplicate Identification
Smart Search
Smart Search integrates with various E-Business Suite

applications to enable a deploying company to enhance party
search screens using match rules of type Search. This
improved method of searching the TCA registry applies DQM
logic to return a list of similar records, catching records that
are misspelled and/or aliased. In addition, the search fields
exposed to the user can be configured based on the match rule
definition.
Duplicate Prevention
Duplicate Prevention enables a deploying company to

discourage duplicate records from entering the TCA registry.
Match rules of type Search are used to prevent users from
entering duplicate records through party creation screens
while match rules of type Bulk are used to prevent duplicate
records from entering the TCA registry through bulk data
import.
Figure 5 below shows that with the DQM engine applied, there
is a barrier that prevents duplicate records from entering the
TCA Registry while allowing non-duplicate records to be
created.
DUPLICATE
PREVENTION
Bulk
Import
Duplicates
Party
Creation
TCA REGISTRY
Figure 5: DQM Prevents Duplicate Records from

Entering the TCA Registry
Duplicate Identification
Duplicate Identification allows the deploying company to

identify existing duplicate records within the TCA registry
using either match rules of type Extended or Bulk.
Duplicate Identification searches are run in batch mode and
the results are returned in duplicate sets that can be evaluated
and resolved as necessary.
As seen from the three aforementioned areas of application,

the DQM engine provides the power to combat duplicate
records in multiple ways. Figure 6 below shows a
comprehensive graphic of all applications of the DQM search
engine, demonstrating the complete DQM solution for
SMART
SEARCH
DUPLICATE
PREVENTION
Bulk
Import
Duplicates
DUPLICATE
IDENTIFICATI
ON
Party
Creation
TCA REGISTRY
managing duplicate records within the TCA customer registry.

Figure 6: Three Applications of the DQM Engine
Conclusion
The issue of information quality has become a significant
obstacle in establishing a single view of customer information
and gaining accurate, reliable data for decision making. The
Oracle Data Quality Management engine will help arm a
deploying company with the tools necessary to achieve a single
view of its customers by enabling the identification and
prevention of duplicate records in the TCA registry. Realizing
that no two companies face exactly the same data quality
issues, the flexibility of the DQM engine allows a custom
solution for each deploying company.
DQM is one piece of TCAs comprehensive data quality solution
which was created to facilitate the sustained commitment to
managing your data quality over time and adjusting processes
to the ongoing changes in your business environment. Within
the Oracle E-Business Suite, you can build meaningful and
powerful rules to search for registry information, find matches,
identify duplicates, merge them and proactively prevent the
entry of duplicates at the front end. By providing you with
flexible and powerful Data Quality Management tools, you as
the deploying company will have a better answer to the
question Who is my customer? This not only facilitates
important strategic decisions, but empowers you to more
confidently meet the challenges of safeguarding the integrity of
your trading community data one of the most vital resources
necessary for succeeding in todays competitive global
economy.
Within the deploying organization there is typically a single
person or a team of people responsible for managing data
quality. Oracle refers to this role as the Data Librarian. To
facilitate this job role the Customer Data Librarian (CDL)
application has been created, which combines the duplicate
identification (DQM) and duplicate resolution (Party Merge)
tools into a user-friendly html interface created specifically for
individuals and teams responsible for an organizations
information quality.
Appendix A
DQM Examples
This section will give an example of the application of the DQM
engine in the following three areas:
1) Smart Search
Where the DQM engine is leveraged by E-Business Suite
applications to enhance TCA registry search screens
2) Duplicate Prevention
Where the DQM engine is leveraged by E-Business Suite
applications to prevent duplicates from entering the
TCA registry through party creation screens
3) Duplicate Identification
Where the DQM engine is used to identify existing
duplicate records in the TCA registry using System
Duplicate Identification Batches
Smart Search Example
In the following example the DUPLICATE SEARCH match

rule will be used. Refer back to the section titled: Defining
Match Rules (Page 11) for a definition of this match rule. This
example represents a real situation where the DQM engine is
used by an E-Business Suite application to enhance a party
search screen. In this scenario a user tries to search for an
existing party called Business World.
Assume the following two records already exist in the TCA
registry. Record #1 is misspelled, while record #2 is simply
another Business World in a different city.
EXISTING TCA DATA
#1
#2
Org Name
URL
Street
City
Bisness
www.bw.co
Address
1977
Main
San
World
Business
m
www.bw.co
Street
22
Roosevelt
Jose
Detroit
World
Blvd
Input Data
A user tries to search for an organization party and enters the
information below:
INPUT DATA
Org Name
URL
Street
City
Business
www.bw.co
Address
1977
Main
San
World
Street
Jose
Transformed Input Data

The DQM engine must first transform the input data provided
by the user. Each attribute of the input data is transformed
using the superset of transformation functions defined in the
match rule. Recall that the transformation functions for the
match rule DUPLICATE SEARCH are as follows:
Attribute
Use
Transformation
Organization
Acquisitio
WR(ORG) +
Name
n
Scoring
CLEANSE + EXACT
WR(ORG)
URL
Acquisitio
EXACT
n
Scoring
EXACT
Acquisitio
EXACT
n
Scoring
EXACT
Acquisitio
WR(ADD) +
n
Scoring
CLEANSE +
WR(ADD)
Acquisitio
CLEANSE
CLEANSE
n
Scoring
CLEANSE
Phone Number
Street Address
City
Using the superset of these transformation functions, the

transformed input data looks like this:
TRANSFORMED INPUT DATA
Org Name
URL
Street Address
City
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
BUSINESS
WWW.BW.COM
1977 MN ST
SN JS
WORLD
WR(ORG)+CLEANSE
BSNS WRLD
In the Acquisition Phase

the DQM engine acquires a
subset of matching records
based on the acquisition
attributes selected in the
match rule. This subset is
called the Work Unit.
Acquisition Phase
In the Acquisition Phase, the DQM engine compares the
transformed input data to the transformed TCA data (Staging
Tables) to find matching records. The DQM engine only uses
those attributes and transformation functions that are defined
in the selected match rule for use in the Acquisition Phase.
Based on the definition of the match rule DUPLICATE
SEARCH, the table below shows the transformed input data
that will be used for the Acquisition Phase. It also shows the
transformed TCA data, records #1 and #2, with which the
input data will be matched against.
Matching values are outlined with black boxes.
Org Name
URL
Street Address
City
WR(ORG)+CLEANSE
EXACT
WR(ORG)+CLEANSE
CLEANSE
BSNS WRLD
WWW.BW.COM
1977 MN ST
SN JS
TRANSFORMED TCA DATA (Staging Table)
#1
Org Name
URL
Street Address
City
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
BISNESS WORLD
WWW.BW.COM
1977 MN ST
SN JS
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
BUSINESS
WWW.BW.COM
22 RSVLT BLVD
DTRT
WR(ORG)+CLEANSE
BSNS WRLD
#2
WORLD
WR(ORG)+CLEANSE
BSNS
SinceWRLD
both records #1 and #2 had attributes that matched the
input data, they are returned to the Work Unit for evaluation
during the Scoring Phase.
Scoring Phase
In the scoring phase, each record identified for the Work Unit
by the Acquisition Phase is evaluated and receives a Matching
Score. To calculate the Matching Score the DQM engine only
uses the attributes and transformation functions that are
defined in the selected match rule for use in the Scoring Phase.
With that in mind, the table below shows the records in the
Work Unit being evaluated against the input data with the end
result being a Matching Score.
Org Name
URL
Street Address
City
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
BUSINESS
WWW.BW.COM
1977 MN ST
SN JS
WORLD
WR(ORG)+CLEANSE
BSNS WRLD
Work Unit
Org Name (20)
URL (30)
Street Address
City (10)
(15)
#1
WR(ORG)
EXACT(100%)
WR(ORG)
CLEANSE(10
+EXACT(100%)
WWW.BW.COM
+CLEANSE(100%)
0%)
1977 MN ST
SN JS
BISNESS WORLD
Matchin
WR(ORG)
+CLEANSE(75%)
Score
70
#2
WR(ORG)
EXACT(100%)
WR(ORG)
CLEANSE(10
+EXACT(100%)
WWW.BW.COM
+CLEANSE(100%)
0%)
22 RSVLT BLVD
DTRT
BUSINESS
WORLD
Recall that the Matching Score is determined by adding

together the scores for each attribute that matches the input
data on one of the transformation functions defined in the
match rule. Below shows how the Matching Scores in the table
above were determined.
The Matching Score for record #1 is:
Org Name (20 x .75)* + URL (30) + Street Address (15) +
City (10) = 70
Org Name (20) + URL (30) = 50
* The score given to Org Name for the first record is only 75% because
the attribute matched on the WR(ORG)+CLEANSED transformation
function. This was determined when the weightings were set in the match
rule.
Apply Match Threshold

Next, in order to determine if these records will be returned to
the user as potential duplicates, the Threshold Score needs to
be calculated and compared to the threshold set in the Match
Rule. Recall that to calculate the Threshold Score, the
#1
following equations is used:
Threshold Score = (Matching Score / Total Possible Score) x
100
The Matching Score has already been calculated in the Scoring
Phase so the only value left to be determined is the Total
Possible Score. To determine the Total Possible Score, add up
the scores, as defined in the match rule, for each attribute that
is passed a value by the input data. Recall that the scores were
defined as the following:
Attribute
Use
Scor
e
Organization
Scorin
Name
20
50
URL
Scorin
30
g
Phone Number
Scorin
25
g
Street Address
Scorin
15
g
City
Scorin
10
Since the user input Org Name, URL, Street Address and City
the Total Possible Score is the sum of the scores defined for
each of these attributes. In this example the Total Possible
Score is:
Org Name (20) + URL (30) + Street Address (15) + City
(10) = 75
Now that the Matching Score and the Total Possible Score are
known, the Threshold Score can be calculated. It is as follows
for each of the records:
The Threshold Score for record #1 is:
(70 / 75) * 100 = 93.3
(50 / 75) * 100 = 66.7
Finally, the DQM engine will only return those records that
meet or exceed the Match Threshold, which as you recall, is
70. So in this example only record #1 meets or exceeds the
Match Threshold.
Results
The user tried to search for the following record:
USER ENTERED DATA
Org Name
URL
Street
City
Business
www.bw.co
1977 Main
San
World
Street
Jose
Using the DUPLICATE SEARCH match rule, the DQM engine

returned only record #1, to the user:
MATCHING RECORDS
Org Name
URL
Street
Address
City
THRESHOL
D SCORE
#1
Bisness
www.bw.co
1977 Main
San
World
Street
Jose
93.3
Next Steps
At this point the user can:
Continue their process with the DQM engines

suggested party
Duplicate Prevention Example
In the following example the DUPLICATE SEARCH match

rule will again be used. Refer back to the section titled:
Defining Match Rules (Page 11) for a definition of this match
rule. This example represents a real situation where the DQM
engine is used by an E-Business Suite application to prevent a
duplicate record from entering the TCA registry through a
party creation screen.
In this scenario a user tries to create a new party called Vision
Corporation through a party create screen, but before the
party is created, the DQM engine uses the DUPLICATE
SEARCH match rule to search the TCA registry for matching
records and return a list of potential duplicates to the user.
Assume the following four records already exist in the TCA
registry.
EXISTING TCA DATA
#1
#2
#3
#4
Org Name
Phone
Street Address
City
Vision Corp
503.554.256
12344 Hammond
Portlan
Corp Corp.
Vission
8
503-553-
Blvd. Shine Road

1552
d
Portlan
Viasion
2669 554(503)
1234 Hammond
d
Portlan
Corporation
Visin
2568
503.332.326
Boulevard
1956
Brookside Dr.
d
Portlan
Corporation
Input Data
A user tries to create an organization party and enters the
information below. The user accidentally types Visin instead
of the properly spelled Vision:
INPUT DATA
Org Name
Phone
Street Address
City
Visin
503-554-
1234 Hammond
Portlan
Corporation
2568
Blvd.
Transformed Input Data

The DQM engine must first transform the input data provided
by the user. Each attribute of the input data is transformed
using the superset of transformation functions defined in the
match rule. Recall that the transformation functions for the
match rule DUPLICATE SEARCH are as follows:
Attribute
Use
Transformation
Organization
Acquisitio
WR(ORG) +
Name
n
Scoring
CLEANSE
WR(ORG) + EXACT
URL
Acquisitio
EXACT
Phone Number
Street Address
City
Scoring
EXACT
Acquisitio
EXACT
n
Scoring
EXACT
Acquisitio
WR(ADD) +
n
Scoring
CLEANSE +
WR(ADD)
Acquisitio
CLEANSE
CLEANSE
n
Scoring
CLEANSE
Using the superset of these transformation functions, the

transformed input data looks like this:
INPUT DATA
Org Name
Phone
Street Address
City
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
VISIN CORP
5035542
1234 HMND BLVD
PRTLND
568
WR(ORG)+CLEANSE
VSN CORP
Acquisition Phase
In the Acquisition Phase, the DQM engine compares the
transformed input data to the transformed TCA data (Staging
Tables) to find matching records. The DQM engine only uses
those attributes and transformation functions that are defined
in the selected match rule for use in the Acquisition Phase.
Based on the definition of the match rule DUPLICATE
SEARCH, the table below shows the transformed input data
that will be used for the Acquisition Phase. It also shows the
transformed TCA data, records #1, #2, #3, and #4, with which
the input data will be matched against.
Matching values are outlined with black boxes.
Org Name
Phone
Street Address
City
WR(ORG)+CLEANSE
EXACT
WR(ORG)+CLEANSE
CLEANSE
VSN CORP
503554256
1234 HMND BLVD
PRTLND
8
TRANSFORMED TCA DATA (Staging Table)
#1
Org Name
Phone
Street Address
City
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
VISION CORP
503554256
12344 HMND BLVD
PRTLND
WR(ORG)+CLEANSE
VSN CORP
#2
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
VISSION CORP
503553266
1552 SHN RD
PRTLND
WR(ORG)+CLEANSE
VSN CORP
#3
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
VIASION CORP
503554256
1234 HMND BLVD
PRTLND
WR(ORG)+CLEANSE
VSN CORP
#4
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
VISIN CORP
503332326
1956 BRKSD DR
PRTLND
WR(ORG)+CLEANSE
VSN CORP
Since records #1, #2, #3, and #4 had attributes that matched
the input data, they are returned to the Work Unit for
evaluation during the Scoring Phase.
Scoring Phase
In the scoring phase, each record identified for the Work Unit
by the Acquisition Phase is evaluated and receives a Matching
Score. To calculate the Matching Score the DQM engine only
uses the attributes and transformation functions that are
defined in the selected match rule for use in the Scoring Phase.
With that in mind, the table below shows the records in the
Work Unit being evaluated against the input data with the end
result being a Matching Score.
Org Name
Phone
Street Address
City
WR(ORG)+EXACT
EXACT
WR(ORG)+CLEANSE
CLEANSE
VISIN CORP
503554256
1234 HMND BLVD
PRTLND
WR(ORG)+CLEANSE
VSN CORP
Work Unit
Org Name (20)
#1
Phone
Street Address
City (10)
Matchin
Score
(25)
(15)
WR(ORG)
EXACT(100%)
WR(ORG)
CLEANSE(10
+EXACT(100%)
503554256
+CLEANSE(100%)
0%)
VISION CORP
12344 HMND BLVD
PRTLND
WR(ORG)
+CLEANSE(75%)
50
#2
WR(ORG)
EXACT(100%)
WR(ORG)
CLEANSE(10
+EXACT(100%)
503553266
+CLEANSE(100%)
0%)
VISSION CORP
1552 SHN RD
PRTLND
+CLEANSE(75%)
WR(ORG)
EXACT(100%)
WR(ORG)
CLEANSE(10
+EXACT(100%)
503554256
+CLEANSE(100%)
0%)
VIASION CORP
1234 HMND BLVD
PRTLND
+CLEANSE(75%)
WR(ORG)
EXACT(100%)
WR(ORG)
CLEANSE(10
+EXACT(100%)
503332326
+CLEANSE(100%)
0%)
VISIN CORP
1956 BRKSD DR
PRTLND
25
WR(ORG)
#3
65
WR(ORG)
#4
WR(ORG)
+CLEANSE(75%)
Recall that the Matching Score is determined by adding

together the scores for each attribute that matches the input
data on one of the transformation functions defined in the
match rule. Below shows how the Matching Scores in the table
above were determined.
Org Name (20 x .75)* + Phone (25) + City (10) = 50
Org Name (20 x .75)* + City (10) = 25
Org Name (20 x .75)* + Phone (25) + Street Address (15) +
City (10) = 65
Org Name (20) + City (10) = 30
* The score given to Org Name for the records #1, #2, and #3 is only
75% because the attribute matched on the WR(ORG)+CLEANSED
transformation function. This was determined when the weightings were
set in the match rule.
Apply Match Threshold

Next, in order to determine if these records will be returned to
the user as potential duplicates, the Threshold Score needs to
be calculated and compared to the threshold set in the Match
Rule. Recall that to calculate the Threshold Score, the
following equation is used:
Threshold Score = (Matching Score / Total Possible Score) x
100
30
The Matching Score has already been calculated in the Scoring

Phase so the only value left to be determined is the Total
Possible Score. To determine the Total Possible Score, add up
the scores, as defined in the match rule, for each attribute that
is passed a value by the input data. Recall that the scores were
defined as the following:
Attribute
Use
Scor
e
Organization
Scorin
Name
URL
Scorin
20
30
g
Phone Number
Scorin
25
g
Street Address
Scorin
15
g
City
Scorin
10
Since the user input Org Name, Phone, Street Address and City
the Total Possible Score is the sum of the scores defined for
each of these attributes. In this example the Total Possible
Score is:
Org Name (20) + Phone (25) + Street Address (15) + City
(10) = 70
Now that the Matching Score and the Total Possible Score are
known, the Threshold Score can be calculated. It is as follows
for each of the records:
(50 / 70) * 100 = 71.4
(25 / 70) * 100 = 35.7
(65 / 70) * 100 = 92.9
(30 / 70) * 100 = 42.9
Finally, the DQM engine will only return those records that
meet or exceed the Match Threshold, which as you recall, is
70. So in this example records #1 and #3 meet or exceed the
Match Threshold.
Results
The user tried to create the following record:
USER ENTERED DATA
Org Name
Phone
Street Address
City
Visin
503-554-
1234 Hammond
Portlan
Corporation
2568
Blvd. match rule, thedDQM engine
Using the DUPLICATE
SEARCH
returned the following list of records to the user as potential

duplicates:
POTENTIAL DUPLICATES
Org Name
Phone #
Street Address
City
THRESHOL
D SCORE
#3
Viasion
(503) 554-
1234 Hammond
Portlan
#1
Corporation
2568
Boulevard
Vision Corp
503.554.256
12344 Hammond
Portlan
Blvd.
Next Steps
At this point the user can exercise one of two options:
Continue creating the new party
Select one of the DQM engines suggested parties and

update the existing record
92.9
71.4
Duplicate Identification Example
Duplicate Identification is the process of searching the TCA

registry for existing duplicate records. A System Duplicate
Identification Batch(SDIB) is submitted, and returned are sets
of duplicate records. Since match rules of type Search
cannot be used for Duplicate Identification, the DUPLICATE
SEARCH match rule created previously in this document
cannot be used. Instead, a match rule of type Expanded with
a name of DUPLICATE IDENTIFICATION will be used. For
simplicity, the details of this match rule will not be exposed.
However, assume that it functions similar to the DUPLICATE
SEARCH match rule.
System Duplicate Identification Batch
To execute the Duplicate Identification process, an SDIB needs
to be submitted to search the TCA registry for existing
duplicate parties. To create the SDIB, select either a match
rule of type Expanded or Bulk and submit. In this case the
DUPLICATE IDENTIFICATION expanded type match rule will
be used.
The Input Record is the
record that the DQM engine
is trying to find duplicates
for. In Smart Search and
Duplicate Prevention the
Input Record comes from a
user, however in Duplicate
Identification
it
is
determined randomly from
the TCA registry or subset
of the TCA registry.
Input Record
Unlike the Smart Search and Duplicate Prevention methods,
Duplicate Identification does not have a user input. Therefore,
for the input record the DQM engine randomly selects a party
from the TCA registry and evaluates the rest of the registry for
duplicates. During the SDIB creation process the user has the
option to limit the duplicate identification process to a subset
of the TCA registry. This matching process continues until all
parties in the TCA registry, or subset, have been evaluated.
Acquisition and Scoring Phases

The acquisition and scoring phases work the same as in the
Smart Search and Duplicate Prevention methods with one
exception. When comparing records in the work unit to the
Match Threshold, the DQM engine uses the Matching Score
instead of calculation the Threshold Score. Refer back to Step
7 in the section Defining Match Rules for a description of
this process.
Results
Below is a sample of a few duplicate sets that DQM would
return after running an SDIB with the expanded match rule
DUPLICATE IDENTIFICATION:
MASTER RECORD
POSSIBLE DUPLICATES
Gorman Manufacturing
gormmun mfg.
Gorman
Manufacturing
MASTER RECORD
Business World
POSSIBLE DUPLICATES
Bisniss Wurld
Business world
bussines worlld
Next Steps
At this point the user can exercise one of two options:
Determine that the parties are not duplicates and do

nothing
Create a merge request to have the duplicate parties

merged
What To Do With Duplicates

After duplicate records have been identified by the DQM
engine, what next? Listed below are a few things that a user
can choose to do:
1) Create a Relationship
The user may find that the potential duplicates are not
exact duplicates, but that they are related records. In
this case, a relationship can be created to reflect the
connection the two parties have.
Party Merge is used to
consolidate
duplicate
records into one master
record.
All transactional
data associated with the
duplicate party is re-pointed
to the master party.
Account Merge is used to
consolidate accounts from
either the same party or
different parties. Like party
merge,
all
transactional
data associated with the
merged account is repointed to the master
account.
2) Merge Parties
If records are found to be duplicate, the parties can be
merged using the Party Merge functionality.
3) Merge Accounts
If two duplicate accounts are identified they can be
merged using the Account Merge functionality.
4) Create a Merge Request

If DQM finds duplicate records but the user does not
have the ability to merge, he/she can submit a Merge
Request which will notify the Data Librarian that the
records should be merged.
Appendix B
Definitions and Terminology
In order to minimize confusion that can arise due to differences
in interpretation of terminology, the following definitions are
provided for terms that are used throughout this document.
Account refers to the details of the deploying companys

selling relationship with a particular Party.
Account Merge refers to the process of resolving

duplicate customer account records. Account Merge is used
to merge transactions from a source customer account to a
target customer account. Customer Account Merge only
merges the customer accounts and related transactions. It
does not merge any TCA registry level information. You
must separately run Party Merge in order to merge the TCA
registry level information about the party if it is
appropriate.
Acquisition Attributes are used for selecting the initial,

most relevant subset of records for matching, forming what
is called the Work Unit.
Attribute refers to a column in a TCA registry.

Attributes are used by DQM to construct match rules and
identify potential duplicates.
Customer is used to represent a party with whom the

deploying company has a selling relationship, regardless of
whether anything has actually been purchased or serviced.
Data Librarian refers to the employee or consultant for

the deploying company who is responsible for identification
and resolution of duplicate or incomplete party or customer
account information in their implementation of the Oracle
E-Business Suite. This role could be filled by a single
person or a team of people.
Deploying Company refers to the Oracle customer that

has, or will, install, implement, and run all or part of The
Oracle E-Business Suite or Customer Data Hub solution.
Duplicate is a record that a user has deemed a

duplicate. In this case the duplicate record should be
merged using Party Merge and if necessary Account Merge.
Implementer refers to either an internal or external

employee working for the deploying company to implement
any or all of the E-Business Suite or Customer Data Hub

solution.
Match Rules are used to determine if two parties are the

same and should be considered as a match. For example,
you might want to setup a match rule that says: If the
party name, state and primary phone number exactly
match, then the records should be returned as a match.
Merge refers to an operation in which one entity (the

merge-from entity) is mapped to another entity of the same
type (the merge-to entity), then any child entities of the
merge-from entity are transferred, copied, or merged to the
merge-to entity. The merge-from entity is inactivated or
deleted at the option of the user. Example: merging one
party with another.
Party is an entity in the Trading Community Model that

can enter into business relationships. A party is a person,
organization (branch, subsidiary, legal entity, holding
company, etc) or relationship (this is a relationship between
two parties).
Party Merge refers to the process of resolving duplicate

TCA registry records. With the Party Merge feature you
can consolidate duplicate parties, integrate an acquired
party into another party, or consolidate duplicate party sites
or contacts of a party in the TCA party registry. The related
child entities that get merged or transferred include party
relationships, contact information, party profiles, customer
accounts, and information obtained from third-party
sources.
Potential Duplicate is a record that might be a

duplicate, but the user needs to make the final
determination if it is in fact a duplicate.
Scoring Attributes are used to calculate a score for

each record in the Work Unit.
System Duplicate Identification Batch is a process

that can be run by the deploying company based upon the
match rules that they have defined as relevant to their
organization. This process evaluates the records in the TCA
registry to determine which are potential duplicates of each
other. Commonly used by Data Librarians to cleanse the
customer database by identifying existing duplicate
records.
Thresholds are cutoffs that are used to exclude records

that dont have high enough scores to be considered as
potential duplicates. For example, you might want to set up
a threshold that states: if the total match score is less than
50, do not show the record as a potential duplicate.
Transformation Function transforms or changes

attributes into different representations for the purposes of
identifying potential duplicate records. They are helpful in
instances where words are aliased or misspelled.
Transformation Functions can call upon Word Replacement
Lists.
Word Replacement Lists are word mappings that are

treated as equivalents for matching. They help to
standardize data where nicknames or abbreviations may
have been used. They are optionally used by
Transformation Functions. For example, you might want to
map Robert, Rob, Robbie, Bob and Bobbie as all equivalent
to one another for the purposes of matching.
Appendix C
An advantage to The Oracle solution for data quality is the
ability to not only identify duplicate parties, but also merge
them based an intimate knowledge of the Trading Community
Architecture data model. This knowledge allows the solution to
accurately combine all associated transactions and
relationships tied to any of the duplicates based on registered
routines created directly by the experts in each of the EBusiness application teams. The following is a dated list of the
Oracle E-Business Suite Applications that have registered
special routines to ensure that all associated data is merged
properly and data integrity is maintained at the highest level.
E-Business Suite Applications That Have Registered Merge Routines
with Party Merge
as of 9/2003
ACTIVITY BASED MANAGEMENT

ADVANCED PRICING
ADVANCED SERVICE ONLINE
APPLICATIONS OBJECT LIBRARY
COLLECTIONS
COMPLEX MAINTENANCE, REPAIR AND OVERHAUL
CONTRACT FOR RIGHTS
CONTRACTS CORE
CRM FOUNDATION
CRM FOUNDATION INTERACTION HISTORY
CRM FOUNDATION RESOURCE MANAGER
CRM FOUNDATION TASKS AND NOTES
CRM FOUNDATION TERRITORIES
CRM FOUNDATION USER MANAGEMENT
CUSTOMER CARE
GRANTS PROPOSAL
HUMAN RESOURCES
INSTALLED BASE
ISTORE
LEASE MANAGEMENT
MARKETING
MOBILE
OFFERS
ORDER CAPTURE
ORDER MANAGEMENT
PARTNERS ONLINE
PARTNER RELATIONSHIP MANAGEMENT (PREVIOUSLY PARTNERS ONLINE)
PROJECTS
PROJECT CONTRACTS
PROPOSALS
RECEIVABLES
SALES
SERVICE
SERVICE CONTRACTS
SHIPPING
SOURCING
SPARES MANAGEMENT
TCA (TRADING COMMUNITY ARCHITECHTURE)
XML GATEWAY
Appendix D
An advantage to The Oracle solution for data quality is the
ability to merge customer accounts based an intimate
knowledge of the Trading Community Architecture data model.
This knowledge allows the solution to accurately combine all
associated transactions and relationships tied to any of the
duplicate accounts based on registered routines created
directly by the experts in each of the E-Business application
teams. The following is a dated list of the Oracle E-Business
Suite Applications that have registered special routines to
ensure that all associated data is merged properly and data
integrity is maintained at the highest level.
E-Business Suite Applications Referenced by Customer Account Merge
as of 9/2003
ADVANCED PRICING
COLLECTIONS
CONTRACTS CORE
CRM FOUNDATION INTERACTION HISTORY
CRM FOUNDATION TASK
CUSTOMER CARE
FEDERAL FINANCIALS
FINANCIALS LATIN AMERICA LOCALIZATION
GLOBAL ACCOUNTING ENGINE
GLOBAL FINANCIAL FINANCIALS COMMON COUNTRY
GRANTS ACCOUNTING
INSTALLED BASE
INVENTORY
ISTORE
MARKETING
MASTER SCHEDULE AND PLANNING
MULTI-CURRENCY CREDIT CHECKING
ORDER CAPTURE
ORDER MANAGEMENT
PROJECTS
PROPERTY MANAGER
PUBLIC SECTOR
PURCHASING
RELEASE MANAGEMENT
SALES COMPENSATION
PAYABLES
PROVISIONING
RECEIVABLES
SERVICE
SERVICE CONTRACTS
SHIPPING EXECUTION
SPARES MANAGEMENT
TCA (TRADING COMMUNITY ARCHITECTURE)
TRAINING ADMINISTRATION
Oracle Trading Community Architecture Best Practices

Data Quality Management - Understanding the Concepts
April 2004
Contributing Authors: Matt Stitz, Alan Adams
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.
Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
www.oracle.com
This document is provided for information purposes only and the contents hereof are subject to change without notice. This document is not warranted to be error-free, nor
subject to any other warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or fitness for a
particular purpose. We specifically disclaim any liability with respect to this document and no contractual obligations are formed either directly or indirectly by this document.
This document may not be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without our prior written permission.
Oracle is a registered trademark of Oracle Corporation. Various
product and service names referenced herein may be trademarks
of Oracle Corporation. All other product and service names
mentioned may be trademarks of their respective owners.
Copyright 2004 Oracle Corporation
All rights reserved.

DQM White Paper 12 20 04-2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DQM White Paper 12 20 04-2

Uploaded by

Copyright:

Available Formats

Oracle Trading

Understanding the Concepts of

Understanding the Concepts of

Oracle Trading Community Architecture Administration

Oracle Data Librarian User & Implementation Guides

Please refer to Appendix B at the end of this paper for a list of

The Data Quality Management (DQM) tool is a flexible

The Need for Clean TCA Data

Data Quality management (DQM)

enhance TCA registry search screens

prevent duplicate records from entering the TCA

identify existing duplicate records within the TCA

How DQM Works

The Input Value is the

Using a traditional searching method a user tries to find a

Figure 1: Traditional Search Engine

As you can see, no records were returned from this search

input value exactly. However the data in the TCA registry

Transformation Functions take data stored within specified

Capitalize all letters

Remember in Figure 1 on Page 5, no matches were found when

transformation functions to find similar matches instead of

Figure 2: DQM Search Engine

Figure 2 shows that by using the DQM search engine, the

temporary Staging Table for the purpose of identifying

Word Replacement Lists (WRL) standardize words or remove

Person Name WRL

Organization Name WRL

To give an example of how WRLs can be used to identify

Figure 3: Using Word Replacement Lists to identify

Seeded Word Replacement Lists are provided for American

There are three types of match rules: Search, Bulk and

Search Match Rules are comprehensive in their search

because they use B-Tree Indexing rather than interMedia

Defining Match Rules

The Work Unit consists of

To effectively define match rules it is helpful to understand how

Select Transformation Functions

Select Transformation Functions

Figure 4: DQM Engine Phases with Associated Match

There are seven steps to follow when creating a match rule.

For the DUPLICATE SEARCH match rule the chosen

Step 4: Assign Transformation Functions to Attributes

EXACT Defined on Page 6

CLEANSE Defined on Page 6

WR(ORG)+CLEANSE Combines the CLEANSE

WR(ADD)+CLEANSE Combines the CLEANSE

For the DUPLICATE SEARCH match rule the following

At this point the required acquisition phase setup is complete.

For the DUPLICATE SEARCH match rule the following

A Score is a number given

Step 6: Assign Scores

TOTAL POSSIBLE SCORE

The Match Threshold is a

The purpose of assigning scores is to determine a Matching

The Total Possible Score

To determine the Total Possible Score, add up the scores, as

DQM In the E-Business Suite and Customer Hub Solution

Smart Search integrates with various E-Business Suite

Duplicate Prevention enables a deploying company to

Figure 5: DQM Prevents Duplicate Records from

Duplicate Identification allows the deploying company to

As seen from the three aforementioned areas of application,