Skip Navigation Links | |
Exit Print View | |
Understanding Oracle Java CAPS Master Index Configuration Options (Repository) Java CAPS Documentation |
Understanding Oracle Java CAPS Master Index Configuration Options (Repository)
About Oracle Java CAPS Master Index (Repository)
Oracle Java CAPS Master Index Configuration
Features of Oracle Java CAPS Master Index
Configuration Overview for Oracle Java CAPS Master Index (Repository)
About the Configuration Files for Oracle Java CAPS Master Index (Repository)
Master Index Object Definition File
Master Index Candidate Select File
Master Index Field Validation File
Master Index Enterprise Data Manager File
Match and Standardization Engine Configuration Files
Using the Editors for Oracle Java CAPS Master Index (Repository)
Configuration Editor - Repository
Master Index Object Definition Configuration (Repository)
Master Index Object Definition Components (Repository)
Master Index Object Definition Objects
Master Index Object Definition Fields
Master Index Object Definition Relationships
The Master Index Object Definition File (Repository)
Modifying the Master Index Object Definition
Candidate Select Configuration (Repository)
Query Builder Components (Repository)
Basic Queries in a Master Index (Repository)
Blocking Queries in a Master Index (Repository)
Phonetic Queries in a Master Index (Repository)
The Candidate Select File (Repository)
Modifying the Candidate Select File
Candidate Select File Description
Range Search Processing (Repository)
Blocking Query Range Searching
Blocking Query Offset and Constant Combinations
Threshold Configuration (Repository)
Manager Service Components (Repository)
The Threshold File (Repository)
Match Field Configuration (Repository)
Matching Service Components (Repository)
Match and Standardization Engines
Block Picker and Pass Controller
Sample Standardization and Matching Sequence (Repository)
The Match Field File (Repository)
Modifying the Match Field File
Best Record Configuration (Repository)
The Survivor Calculator and the SBR (Repository)
Update Manager Components (Repository)
Survivor Helper Default Strategy
Survivor Helper Weighted Strategy
Survivor Helper Union Strategy
Weighted Calculator SourceSystem Strategy
Weighted Calculator SystemAgreement Strategy
Weighted Calculator MostRecentModified Strategy
Update Manager Update Policies
Update Manager Update Policy Flag
The Best Record File (Repository)
Modifying the Best Record File
Field Validation Configuration (Repository)
The Field Validation File (Repository)
Modifying the Field Validation File
Field Validation File Structure
Enterprise Data Manager Configuration
The Enterprise Data Manager File Structure
Modifying the Enterprise Data Manager File
Enterprise Data Manager File Description
The properties for the objects you will store in the master index database are defined in the Object Definition file. This file defines the parent and child objects to be indexed and the fields contained in each object, including key properties for each field, such as the field size, unique record identifiers, and whether certain fields are required or can be updated. After you define the master index framework and create the configuration files, you can modify the object structure that you defined.
The Object Definition is used as a basis for most of the master index application components. The information you specify for this file defines the dynamic Java API and the database structure for the primary tables that store object information in the master index application.
The following topics describe the Object Definition file, which defines the object structure.
The object definition includes three primary components that together define the structure of the data in the master index application, the database structure, and the method OTD. Most configuration files in the master index application rely on the objects and fields defined in the Object Definition. For example, the fields you specify for the match string, queries, standardization, and the survivor calculator must all be defined in the Object Definition.
The following topics describe each component of the object definition:
In a master index application, information is stored in objects. Each object in the data structure represents a different type of information. For example, if you are indexing businesses, you might have one object type to store general information about the business (such as the business name and type), one to store address information, and one to store contact information. When indexing personal information, you might have one object type to store general information about the person (such as their name, date of birth, and gender), one to store address information, and one to store telephone information. The object structure can have several objects, but only one primary object (called the parent object). This object is the parent to all other objects defined in the Object Definition. The object structure can have multiple child objects or no child objects at all.
Generally, a record in the master index application has information in one parent object and multiple child objects. A record can also have multiple instances of each child object. For example, in the person index example above, a record for a single person would have one name, one date of birth, and one gender, all three stored in the parent object. However, the same record might have several different addresses, each of which is stored in a separate Address object.
Each object in the object structure contains fields that store the data elements of the object. You can specify properties for each field in the object structure, such as a length, name, data type, formatting rules, and so on. The fields you define in the object structure also determine the structure of the method OTD and the database tables. You can also specify certain properties for each field that determine how the database columns are defined, including the length, name, and required data type.
In the Object Definition, you must specify the parent and child objects. The object structure must contain one parent object. All remaining objects defined in the structure must be specified as child objects to that parent object.
The object structure is defined in the Object Definition file in XML format. The information entered into the default configuration file is based on the objects and fields you defined in the wizard. Depending on how completely you defined the object structure in the wizard, this file should not require customization.
The following topics provide information about working with the Object Definition file:
When you use the wizard to define the object structure, all the configuration files for the master index application are automatically generated based on the information you provide. You can modify the Object Definition file at any time prior to deploying the associated project, but you must regenerate the application and redeploy the project after doing so. If you modify the object structure using the configuration editor, the remaining configuration files are updated accordingly to keep them synchronized. If you update object structure by modifying the file directly, you also need to update the remaining configuration files. For example, if you modify the file directly and you delete a field from the object structure that also appears on the EDM, appears in the SBR, and is defined for standardization and matching, you must remove the field from the Enterprise Data Manager file, the Best Record file, and the Match Field file. Any changes made to the file without regenerating the project will not take effect.
The possible modifications to this file are restricted by the schema definition, so be sure to validate the file after making any changes.
Table 1 lists each element in the Object Definition file and provides a description of each element along with any requirements or constraints for each element.
Table 1 Object Definition File Structure
|
Following is a short sample illustrating the elements in the Object Definition file. The DOB field shows usage of the minimum-value element, the SSN field shows usage of the pattern element, and the AddressType field illustrates the code-module element. The AddressType field also has the key-type set to true, meaning that each record can only contain one address of each address type.
<name>Person</name> <database>oracle</database> <dateformat>MM/dd/yyyy</dateformat> <nodes> <tag>Person</tag> <fields> <field-name>LastName</field-name> <field-type>string</field-type> <size>40</size> <updateable>true</updateable> <required>true</required> <key-type>false</key-type> </fields> <fields> <field-name>FirstName</field-name> <field-type>string</field-type> <size>40</size> <updateable>true</updateable> <required>true</required> <key-type>false</key-type> </fields> <fields> <field-name>DOB</field-name> <field-type>date</field-type> <updateable>true</updateable> <required>true</required> <minimum-value>1900-01-01</minimum-value> <key-type>false</key-type> </fields> <fields> <field-name>SSN</field-name> <field-type>string</field-type> <size>16</size> <updateable>true</updateable> <required>false</required> <pattern>[0-9]{9}</pattern> <key-type>false</key-type> </fields> </nodes> <nodes> <tag>Address</tag> <fields> <field-name>AddressType</field-name> <field-type>string</field-type> <size>8</size> <updateable>true</updateable> <required>true</required> <code-module>ADDRTYPE</code-module> <key-type>true</key-type> </fields> ... </nodes> <nodes> <tag>Phone</tag> ... </nodes> <relationships> <name>Person</name> <children>Address</children> <children>Phone</children> </relationships>