Table of Contents

Search

  1. Preface
  2. Introduction
  3. The Design Issues
  4. Standard Population Choices
  5. Parsing, Standardization and Cleaning
  6. Customer Identification Systems
  7. Fraud and Intelligence Systems
  8. Marketing Systems
  9. Simple Search
  10. Composite Keys
  11. Summary

Application and Database Design Guide

Application and Database Design Guide

Key Fields

Key Fields

Using Standard Populations, an application may be set up to index and search on three field types:
  • Person Names
  • Organization Names
  • Addresses
  • Code Fields
  • Geocodes
  • Product Names

Person Names

The Algorithm that builds keys and search ranges for Person Names is invoked by a calling SSANAME3 by passing
FIELD=Person_Name
in the
Controls
parameter of the
get keys
or
get ranges
calls.
The
Person_Name
Algorithm is designed to overcome the error and variation that would be typically found in a person’s full name. This may include salutations and honorifics, special characters, embedded spaces, nicknames, different word orders, use of initials, spelling errors, concatenated words, localized words, foreign words, etc.
An application should pass the full person name to SSA-NAME3 functions. The word order, that is the position of the first name, middle names and family names, should be the normal word order used in your data population. For example, in English speaking countries, the normal word order would be:
First Name + Middle Name(s) + Family Name(s)
Depending on your table design, your application may have to concatenate these separate fields into one field before calling SSA-NAME3.
While SSA-NAME3 includes Search Strategies that overcome word order variations, the word order does have some significance in the quality of Narrow and Typical searches, and when matching using the Purposes "same Household", "same Family" or "same Wide_Household".
The application (or SSA-NAME3) may pass multiple names (such as a married name and a former name) in the one call to SSA-NAME3.
The
Person_Name
algorithm has an Edit-List whose rules may be overridden by the Population Override Manager or Edit RuleWizard.

Organization Names

The Algorithm that builds keys and search ranges for Organization Names is invoked by a calling application by passing
FIELD=Organization_Name
or
FIELD=Organisation_Name
in the
SSANAME3 Controls
parameter of the
get keys
or
get ranges
calls.
The
Organization_Name
algorithm is designed to overcome the error and variation that would be typically found in a business, company, institution or other organization name. The algorithm also caters for multiple names in the one field, and a mixture of Organization and Person names in the data population. The error and variation may include different legal endings, abbreviations, salutations and honorifics, special characters, embedded spaces, nicknames, different word orders, missing and extra words, spelling errors, concatenated words, use of initials, mixed use of numbers and words, foreign words, localization, etc.
This field supports matching on a single name, or a compound name (such as a legal name and its trading style).
The application (or SSA-NAME3) may also pass multiple names (such as a current name and a former name) in the one call to SSA-NAME3.
The
Organization_Name
algorithm has an Edit-List whose rules may be overridden by the Population Override Manager or Edit Rule Wizard.

Addresses

The algorithm that builds keys and search ranges for Addresses is invoked by a calling application by passing
FIELD=Address_Part1
in the
SSA-NAME3 Controls
parameter of the
get keys
or
get ranges
calls.
The
Address_Part1
algorithm is designed to overcome the error and variation that would be typically found in addresses. The error and variation may include the presence of care of information, abbreviations, special characters, embedded spaces, different word orders, spelling errors, concatenated words and numbers, use of initials, mixed use of numbers and words, foreign words, missing words, extra words and sequence variations, etc.
An application should pass the part of address up to, but not including, the locality "last line". The word order, that is the position of the address components, should be the normal word order used in your data population. These should be passed in one field. Depending on your table design, your application may need to concatenate these attributes into one field before calling SSA-NAME3.
For example, in the US, a typical string to pass would comprise of:
Care-of + Building Name + Street Number + Street Name + Street Type + Apartment Details
But not including City, State, Zip, Country.
The application (or SSA-NAME3) may pass multiple addresses (such as a residential address and a postal address) in the one call to SSA-NAME3. See the
API REFERENCE
guide for more details.
The
Address_Part1
algorithm has an Edit-List whose rules may be overridden by the Population Override Manager or Edit Rule Wizard.

Code Fields

The code fields are a group of fields that support numeric or alphanumeric values. The code fields include the following fields:
  • Code
  • Telephone_Number
  • Date
  • CreditCard
  • VIN
  • ISBN10 or ISBN13
The code fields support the following Match Purposes:
  • CC_Owner
  • CC_Issuer
  • VIN_Owner
  • VIN_Manufacturer
  • AuthorISBN
  • PublisherISBN
The code fields are available for all the standard populations except the OFAC population.
Pass
FIELD=<Code Fields>
to SSA-NAME3 in the Controls parameter of the get_keys or get_ranges calls, where
Code Fields
can be one or more of the supported code fields. It invokes the algorithm that builds the keys and search ranges for the code fields. Identity Resolution passes the value to the
KEY-LOGIC
and
SEARCH-LOGIC
Controls parameters.
The algorithms of the code fields overcome any errors or variations that are common across the code entities, such as missing digits, different digit orders, and special characters.
Identity Resolution can pass multiple code fields as one code field in the form of a match purpose to SSA-NAME3.
For example, if you search for a credit card to find the customer name and the credit card issuer, you can use the
CC_Issuer
purpose.
The
Code
field matches any numeric or alphanumeric data. The algorithms of the
Telephone_Number
,
Date
,
VIN
,
ISBN10
or
ISBN13
, and
CreditCard
fields are specific to their processing domain. They carry less overhead than the generic
Code
field. However, the
Code
field algorithm reduces the overhead associated with the creation and maintenance of separate indexes. The application simplifies the search experience by not categorizing the search data.
The Population Override Manager or the Edit Rule Wizard can override the Edit-List rules of the algorithm that uses the
Code
field.

Geocode

Pass
Field=Geocode
to SSA-NAME3 in the Controls parameter of the get_keys or get_ranges call to build keys and search ranges based on the latitude and longitude geographic coordinates. You can pass the Geocode field in the
KEY-LOGIC
and
SEARCH-LOGIC
Controls parameter.
The Geocode field matches the location or creates a search range based on the geographic coordinates that you specify.
You can specify the latitude and longitude geographic coordinates with an optional elevation. Specify the elevation value with its unit after the geographic coordinates. The supported units are feet (ft), kilometer (km), and meter (m). Negative elevation represents depths below the sea level.
For example, -23.399437,-52.090904, 203m
Use one of the following formats to specify the geographic coordinates:
  • -23.399437,-52.090904, 203m
  • 40:26:46.302N 079:56:55.903W 192ft
  • 40°26'47"N 079°58'36"W 0.203km
  • 40d 26' 47" N 079d 58' 36" W 203
  • 40.446195N 79.948862W
  • 40.446195 -79.948862
  • 40° 26.7717, -79° 56.93172
  • N40:26:46.302 W079:56:55.903
  • N40°26'47 W079°58'36"
  • N40d 26' 47" W079d 58' 36"
  • N40.446195 W79.948862
The Population Override Manager or the Edit Rule Wizard can override the Edit-List rules of the algorithm that uses the
Geocode
field. Define a geocode override rule as a character rule, which replaces or removes strings or numbers that include special characters or delimiters.

Product Names

Pass
FIELD=Product_Name
to SSA-NAME3 in the Controls parameter to match the names of products. The
Product_Name
and
Product_Description
fields use word pairs or a bigram to search, match, and handle additional variations between product names and description. The
Model_Number
field is a matching field that compares two strings.
You can use the following optional search fields for a product:
  • Product_Description
  • Model_Number
  • Company_Name
  • ID
  • Code
  • Attribute1
  • Attribute2

0 COMMENTS

We’d like to hear from you!