The Search framework

The Search framework is a lightweight framework designed as an InfoSphere® MDM common service.

Interfaces and classes, which constitute the search framework, can be classified into two main categories: SQL definition classes and SQL execution classes.

SQL definition classes

The SQL definition classes and interfaces define the structure of a search SQL statement.
Using these classes, the clients can create new search SQL statements, fetch SQL statements, and pass these to the framework's execution classes to perform the search. The following list shows the classes that are included in this category.
  • SearchSql: Represents the SQL to be executed for the search transaction. This SQL can either be selected from a library of pre-written SQL statements or dynamically constructed using the search input class. In addition to the SQL statement, it also captures the input and output for the SQL statement. The input is represented by an ordered collection of CriterionElement objects while the output is captured by an instance of an implementation of IResultSetProcessor, which is initialized with an ordered list of fields returned by the SQL statement.
  • SearchField: Defines a search related field. It can be a field used in the search criteria or a field included in the search results. The attributes of this class include name and type of the search field.
  • ComparisonOperator: Represents a comparison operator, which is applied to a search field in the SQL. Examples include "=" or "LIKE". Since there is a known finite list of operators, the class provides instances of each of these operators and is not extensible and cannot be instantiated by any other class.
  • CriterionElement: Represents an individual criterion element. Each element is composed of a field name as well as the comparison operator for that field. If the same field can be provided multiple times as search criteria (for example, CategoryName in searchProductInstance), an additional sequence number can be provided to uniquely identify each criterion. If the same field can be provided multiple times as search criteria (for example, CategoryName in searchProductInstance), an additional sequence number can be provided to uniquely identify each criterion. Finally, criterion elements are discriminated whether they are supplementary, or not.
  • ISearchInput: Defines the interface to be implemented by any search input class. A search input class wraps the existing SearchBObj class. One search input class is needed for each SearchBObj class. The interface provides methods to extract and standardize input parameters.
  • SearchInput: SearchInput is abstract class that implements the ISearchInput interface and provides some common implementation logic for search input concrete classes. The SearchInput classes map the attributes of their respective search business object to the corresponding search field. These classes also implement logic to provide values for the supplementary search fields. A hierarchy similar to the one used for the search business object classes is used to model these search input classes. As a general rule, there should be one search input class for each search business object class. Each search business object results in exactly one search result set business object. The same is true of search input and the corresponding search result set processor class.

SQL execution classes

The SQL execution classes provide services to execute a search SQL statement and process its results. The following list shows the classes that are included in this category.
  • ISearch: Specifies an interface that defines the search component interface to provide different search related services, including fetching pre-written SQL statements, finding a matching pre-written SQL, and executing a search SQL.
  • SearchComponent: Specifies a concrete implementation of the ISearch interface.
  • IResultSetProcessor: Specifies an interface that defines the contract that should be implemented by any search result processor classes.
The implementing class processes the results of a search query. These classes are initialized with an ordered list of fields returned by the search query. This list is then used by the class to extract the data from the query results and set the data in the corresponding search result business object class. Given that the search result business objects do not inherit from other search result business objects, the search result processor classes do not follow the inheritance structure either. As a general rule, there should be one search result processor class for each search result business object.
Note: Query and SQLInput classes are not part of the search framework but are used by the framework for executing SQL statements.

Search framework classes

The search framework class diagram shows the main classes and their associations that make up the search framework:
Class diagram showing the search framework, including the main classes and their associations

Stored SQL statements

These SQL statements are fetched and cached in the application. The following diagram shows the tables and their relationships, which contain the SQL statements.
Tables containing the SQL statements and their relationships
The following provides a brief description of these tables:
  • searchsql: Contains pre-written SQL statements.
  • searchcriterion: Contains an ordered list of criterion fields for the given pre-written SQL.
  • searchresultfield: Contains an ordered list of search result fields for the given pre-written SQL.
  • sqlstatement: Contains the actual SQL statement that will be executed.
  • cdcompoptp: Contains the available comparison operators.
  • cdsrchfld: A code table which represents individual search fields that take part in the search transactions. These can be search input (criterion) or output (result) fields. If a search field is mapped directly to an attribute of a business object (search or search result), it will be defined using the foreign key (application, group and element) to the v_element table. All other search fields will be defined using the srch_fld_name column. Each search field has a type as defined by the cdelementtp table.
  • cdelementtp: Defines all available search field types.
  • v_element: An existing table which defines all attributes of the business objects.