Oracle Text (11g)

What's Oracle Text

Oracle Text is a powerful search technology built into Oracle11g Standard and Enterprise Editions. Oracle Text uses standard SQL to index, search, and analyze text stored in structured form inside Oracle database, or in unstructured form in either local file system, or on the Web.

The Text index is in the database – no separate data or index storage required. Text queries are executed in the Oracle process – no separate query processing. The Oracle optimizer is aware of the Text index, so it can choose the best execution plan for any query – gives the best performance for ad hoc queries involving Text and structured criteria.

Oracle Text search functionality includes:

• Boolean operators (AND, OR, NOT, NEAR etc)
• Exact phrase match
• Section searching
• Fuzzy (words that are spelled similarly)
• Stemming (search for mice and find mouse)
• Wildcard
• Thesaurus (synonyms)
• Stopwords
• Case sensitivity
• Search scoring proximity (Searches for words near one another)
• Results ranking
• Keyword highlighting.

The advanced features of Oracle Text include:

• Search for a document by theme
• Get the themes of a document
• Get the gist of a document
• Get the theme gist of a document
• Extend the knowledge base to include terms from a particular industry
• Extend the knowledge base to make new associations between terms

Finally, Oracle Text also provides:

• Classification
• Clustering
• Query refinement

SQL API

Oracle Text’s SQL API makes it simple and intuitive for application developers and DBA’s to create and maintain Text indexes and execute Text searches.

Create a Text index

To create an Oracle Text index, simply use the CREATE INDEX command. Forn example:

CREATE INDEX description_idx ON product_information(product_description) INDEXTYPE IS CTXSYS.CONTEXT; 

Execute Text Searches

Now you can search for information about all products where “monitor” is near “high resolution” in the product description:

SELECT score(1),  product_id,  product_name FROM product_information WHERE CONTAINS(product_description, 'monitorNEARhighresolution', 1) > 0 ORDERBY score(1) DESC; 

Maintain a Text index

As with any full-text retrieval index, changes to the underlying data are applied to the index in batch. To synchronize the text index “index_one” using 2 megabytes of memory, use:

exec ctx_ddl.sync_index(‘index_one’,’2M’);  

The synchronize can be done periodically (every 5 minutes, every hour, etc.) or immediately. Note that the catalog indextype - designed specifically for the short pieces of text typically found in eBusiness catalogs – needs no synchronization. The catalog index is always up-to-date.

Simple Management

Oracle Text management can be done using the Oracle Enterprise Manager.

Creating Indices

Oracle Text provides different index types that are suitable for different purposes. There are four Text index types:

1. Standard index type (context)
2. Catalog index type (ctxcat)
3. Classification index type (ctxrule)
4. XPath index type (ctxxpath)

Different indexing approaches will be covered in more details in later section.

You create a text index as a type of extensible index to Oracle Database using standard SQL. This means that an Oracle Text index operates like an Oracle Database index. It has a name by which it is referenced and can be manipulated with standard SQL statements.

The benefits of a creating an Oracle Text index include fast response time for text queries with the CONTAINS, CATSEARCH, and MATCHES Oracle Text operators. These operators query the CONTEXT, CTXCAT, and CTXRULE index types respectively.

Oracle Text Indexing Process

The Oracle Text indexing process is modeled after a pipeline, where data items retrieved from a data store pass through a series of transformations before their keywords are added to the index. The indexing process is split into multiple phases, which is configurable by the application developer.

The indexing process includes the following phases:

• Data Retrieval: Data is simply fetched from a data store, for example, a Web page, database large object, or local file system, and passed as a stream of data to the next phase.
• Filtering: The filters are responsible for converting data in different file formats to plain text. The other components in the indexing pipeline only process plain text data and don't know about file formats such as Microsoft Word or Excel.
• Sectioning: The sectioner adds metadata about the structure of the original data item.
• Lexing: A stream of characters is split into words based on the language of the item.
• Indexing: In this final phase, the keywords are added to the actual index.

Index Types

CONTEXT Index

CONTEXT index enables users to search document collections, such as Web sites, digital libraries, or document warehouses. The collection is typically static with no significant change in content after the initial indexing run. Documents can be of any size and of different formats, such as HTML, PDF, or Microsoft Word. These documents are stored in a document table.

To query this index, the application uses the SQL CONTAINS operator in the WHERE clause of a SELECT statement.

CTXCAT index

CONTEXT index enables users to search catalog information which consists of inventory type information, such as that of an online book store or auction site. The stored information consists of text information, such as book titles, and related structured information, such as price. The information is usually updated regularly to keep the online catalog up to date with the inventory.

To query this index, the application uses the CATSEARCH operator in the WHERE clause of a SELECT statement. Queries are usually a combination of a text component and a structured component. Results are almost always sorted by a structured component, such as date or price. Good response time is always an important factor with this type of query application.

CTXRULE index

CONTEXT index enables users to classify an incoming stream or a set of documents by comparing to a pre-defined set of rules. When a document matches one or more rules, the application performs some action.

For example, assume there is an incoming stream of news articles. You can define a rule to represent the category of Finance. The rule is essentially one or more queries that select document about the subject of Finance. When a document arrives about a Wall Street earnings forecast and satisfies the rules for this category, the application takes an action, such as tagging the document as Finance or e-mailing one or more users.

To classify an incoming stream of text, use the MATCHES operator in the WHERE clause of a SELECT statement. Before you start, you need to create a table of rules and then create a CTXRULE index.

CTXXPATH Index

CTXXPATH index is provided for improving performance on XPath searches on XML documents. Note that this indextype will be deprecated and is only supported for backward compatibility with older releases of Oracle Database where XMLIndex is not available. If you are building a new application, Oracle recommends that you use the XMLIndex. Although this index type can be helpful for existsNode() queries, it is not required for XML searching. For more information on XML search, see here.

Theme Index

A document theme is a concept that is sufficiently developed in the document. By default in English and French, Oracle Text indexes theme information. Themes can be queried with the ABOUT operator.You can enable and disable theme indexing with the index_themes attribute of the BASIC_LEXER preference type. You can also index theme information in other languages provided you have loaded and compiled a knowledge base for the language.

Document Services

In addition to the search capabilities of Oracle Text, a number of other features are provided to simplify application development:

• Document Format Support - In order to index documents stored in a variety of native formats, such as Word, Excel, PowerPoint, WordPerfect, HTML, and Acrobat/PDF, interMedia supplies a broad variety of "filters" that allow documents stored in their native formats to be indexed.
• Document Viewing and Highlighting - Oracle Text Services can convert any supported document format to either plain text or formatted text (an HTML approximation retaining as much as possible of the original formatting; available for all formats except PDF). Both plain text and HTML versions may be viewed in a standard browser, allowing maximum flexibility in deployment, especially for public Web applications. Both plain text and HTML versions may be viewed with or without highlighting and navigation of the search words or themes. It is also possible to download the original document in its native form for viewing in either the original authoring system (Word, PowerPoint etc.) or in any third-party viewer. For viewing PDF documents, the Acrobat viewer should be used.
• Document Storage - Oracle Text Services supports several document storage options. The most straightforward option is "direct" storage where documents are kept in an Oracle database table. Where this is not possible, documents may be indexed directly from a file system or URL address by simply storing a file pointer or URL in the indexed column.
• Text Manager - Oracle Text supplies an administration tool, integrated with the Oracle. Enterprise Manager, through which all major text maintenance and administration functions may be performed.

Resources

• Overview of Oracle Text in 11g
  
• Oracle Text Application Developer's Guide 11g
  
• Oracle Text Reference
  
• Oracle XML DB Developer's Guide to learn how to perform full-text search over XML data
• Building Full-Text Search Applications with Oracle Text
  
• Oracle Text SQL Statements and Operators
  
• Oracle Text CONTAINS Query Operators
  
• Oracle Text Feature Overview
  
• White paper June 2007
  
• New Features in Oracle Text with Oracle Database 11g Release 1
  
• HOW TO SEARCH ENABLE OUR ORACLE-BACKED WEBSITE WITH ORACLE TEXT
  
• What a Developer Should Know about Oracle Text
  

Oracle ADF BindingContext and BindingContainer

The Oracle ADF binding context is a runtime map (accessible through the EL expression #{data}) of all data controls and page definitions within the application. The binding context does not contain real live instances of these objects. Instead, the map contains references that become data control or binding container objects on demand. The ADF lifecycle creates the binding context from the application module, DataBindings.cpx, and page definition files.

In Oracle ADF, the group of bindings supporting the UI components on a page are described in a page-specific XML file called the page definition file. The ADF Model layer uses this file at runtime to instantiate the page’s bindings. These bindings are held in a request-scoped map called the binding container, accessible during each page request using the EL expression:

  #{bindings}

This expression always evaluates to the binding container for the current page. For example, to access the collectionModel of binding object named MyShoppingCart , you use the EL expression:

  #{bindings.MyShoppingCart.collectionModel}

BindingContext

The binding context lives in the HttpSession for each end user. It holds references to lightweight application module data control objects that manage acquiring an application module instance from the pool during the request (when the data control is accessed) and releasing it to the pool at the end of each request. The data control holds a reference to the ADF session cookie that identifies the user session. The binding context also holds references to binding containers. The binding context might contain many data controls and many binding containers.

There are three options to access the binding context at runtime by Fusion Web Applications:

1. BindingContext.getCurrent()
2. BindingUtils.getBindingContext()
3. JsfUtils.resolveExpression("#{data}")

For option 1 and 2, they are implemented in the same way internally:

  import oracle.adf.model.BindingContext;

  (BindingContext)ADFContext.getCurrent().getSessionScope().get("data");

However, option 3 is different and resolveExpression() is defined to be:

public static Object resolveExpression(String expression) {
FacesContext facesContext = getFacesContext();
Application app = facesContext.getApplication();
ExpressionFactory elFactory = app.getExpressionFactory();
ELContext elContext = facesContext.getELContext();
ValueExpression valueExp =
elFactory.createValueExpression(elContext, expression,
                     Object.class);
return valueExp.getValue(elContext);
}

As you can see it, the third approach is more expensive because it involves extra expression parsing and syntactic validation of the expression.

BindingContext is an object that implements the Map interface and exposes generic methods to access the binding layer. For example, to find a data control, you could use the findDataControl()method on BindingContext

  findDataControl(dc_name)

BindingContainer

To access binding container, you first retrieve binding context as described above; then you use binding context's getCurrentBindingsEntry method to retrieve binding container object:

  import oracle.binding.BindingContainer;

  BindingContainer bc = bindingContext.getCurrentBindingsEntry();

Internally, getCurrentBindingsEntry() is implemented as follows:

  (BindingContainer)ADFContext.getCurrent().getRequestScope().get("bindings");

If you use option 3 as described above, you can retrieve binding container in a more straightforward way (although it's still more expensive):

FacesContext facesContext = FacesContext.getCurrentInstance();
ExpressionFactory exp = facesContext.getApplication().getExpressionFactory();
DCBindingContainer bindingContainer =
(DCBindingContainer)exp.createValueExpression(facesContext.getELContext(),
"#{bindings}",DCBindingContainer.class).getValue(facesContext.getELContext());

Fusion application developers who prefer working with type-safe methods can cast the bindings instance (i.e., BindingContainer) to DCBindingContainer:

DCBindingContainer object exposes more methods than the its super class object BindingContainer. For example, you can access the application module's client interface from this DCBindingContainer by naming an ADF action binding or an ADF iterator binding as shown below:

// 1. Access the binding container
DCBindingContainer bc = (DCBindingContainer)getBindings();
// 2. Find a named action binding
JUCtrlActionBinding action =
(JUCtrlActionBinding)bc.findCtrlBinding("SomeActionBinding");
// 3. Get the data control from the iterator binding (or method binding)
DCDataControl dc = action.getDataControl();
// 4. Access the data control's application module data provider
ApplicationModule am = (ApplicationModule)dc.getDataProvider();
// 5. Cast the AM to call methods on the custom client interface
StoreServiceAM service = (StoreServiceAM)am;
// 6. Call a method on the client interface
service.doSomethingInteresting();

Final Words

In this article, we have demonstrated how bindings can be accessed via Java code. However, this should be done only as appropriate. In other words, use it when attribute or executable binding properties at JDeveloper's designtime are not able to declaratively meet the needs of the application.

References

1. Oracle Fusion Developer Guide by Frank Nimphius and Lynn Munsinger
2. Oracle Fusion Applications Developer's Guide 11g

Oracle ADF Model In Depth

Oracle ADF Model implements the two concepts in JSR-227 that enable decoupling the user interface technology from the business service implementation:

• data controls
  • A data control abstracts the implementation of a business service, allowing the binding layer to access the data from all services in a consistent way.
  • At runtime, the ADF Model layer reads the information describing the data controls and bindings from appropriate XML files and implements the two-way connection between the user interface and the business service.
• declarative bindings
  • Declarative bindings abstract the details of accessing data from data collections in a data control and of invoking its operations.
  • There are 3 basic kinds of declarative binding objects:
    • Iterator bindings -- to allow scrolling and paging through collections of data and drilling-down from summary to detail information
    • Value bindings -- to display data
    • Action bindings -- to invoke built-in or custom operations on data collections of a data control. They are represented as operations in the Data Controls panel.

The following figure shows how bindings connect UI components to data control collections and methods.

In the following sections, we will see what kind of metadata are needed at design time to bind UI components (or widgets) to their associated data collections or methods declaratively and what kind of objects are generated at runtime to support the gluing.

Design Time

When you begin adding content to your page, you typically use the Component Palette and Data Controls panel of JDeveloper. The Component Palette contains all the ADF Faces components needed to declaratively design your page. Once you have the basic layout components placed on the page, you can then drag and drop items from the Data Controls panel to create ADF Model databound UI components.

From the item (i.e., accessor or attribute) dragged over from the Data Controls panel, JDeveloper first compiles a list of compatible BindingsTypes. From this list, JDeveloper can then determine the set of Creators that are applicable to drop on the page. The user is then presented with this list (organized by BindingsType). When the user selects a Creator to use, the Creator builds the databound UI component (by producing a DOM subtree representing what will be inserted into the page).
For example, If you drop the PrincipalName attribute from the Data Controls panel as an Input Text w/Label widget, JDeveloper creates an inputText component. The following code shows the code generated on the JSF page when you drop the PrincipalName attribute as an Input Text w/Label widget. Notice that the value of the component is bound to the inputValue property of the PrincipalName binding.

           shortDesc="#{bindings.PrincipalName.hints.tooltip}" id="it1">

You can change any of these properties to suit your needs. Reference this appendix for the properties of the ADF bindings.

If you build your application using these databound UI components, JDeveloper will create the following metadata files for you:

• Add a page definition file. The page definition file (pageNamePageDef.xml) defines the group of bindings supporting the UI components on a page.
• Create a DataBindings.cpx file and addes an entry for the page. The DataBindings.cpx file acts as the table of contents to the data controls in use in this application.
• Create the adfm.xml file. This file creates a registry for the DataBindings.cpx file, which allows the application to locate it at runtime so that the binding context can be created.

Runtime

At runtime, multiple objects (i.e., binding context, binding containers, and binding objects) are created in memory to hold binding information. The ADF binding context is a runtime map of all data controls and page definitions within the application. The binding context is the one object that lives in the HttpSession for each end user, accessible using the EL expression #{data}.

The group of bindings supporting the UI components on a page are described in a page definition file. The ADF Model layer uses this file at runtime to instantiate the page's bindings. These bindings are held in a request-scoped map called the binding container, accessible during each page request using the EL expression #{bindings}. This expression always evaluates to the binding container for the current page.

• Binding Context
  • The binding context provides the data environment for your application. It contains all of the data controls and binding containers that your application can access.
  • The ADF lifecycle creates the ADF binding context from the application module, DataBindings.cpx, and page definition files. Binding context contains references that become data control or binding container objects on demand.
  • You can look up ApplicationModule from a managed bean using the BindingContext:

    BindingContext bc = BindingContext.getCurrent();
    DCDataControl dc = bc.findDataControl("AppModuleDataControl");
    ApplicationModule am = (ApplicationModule)dc.getDataProvider();

  • You can retrieve a ControlBinding named "producerMethod" via BindingContext in this way:

    DCBindingContainer bc = (DCBindingContainer)BindingContext.getCurrent().getCurrentBindingsEntry();
    JUCtrlActionBinding actionBnd =
    (JUCtrlActionBinding)bc.getControlBinding("producerMethod");

• Binding Containers
  • A binding container holds value bindings and iterator bindings (or binding objects) for a page. It provides runtime access to all the ADF binding objects for a page.

At runtime, a web request for http://yourserver/yourapp/faces/some.jsp arrives from the client to the application server. The ADFBindingFilter (defined in web.xml) object looks for the ADF binding context in the HTTP session, and if it is not yet present, initializes it for the first time. If the appropriate binding container for the page has never been used before during the user's session, it is created. Also, if it is the first time an application module data control is referenced during the request, it acquires an instance of the application module from the application module pool. Then the control is forwarded to the page to be rendered. The UI components on the page access value bindings and iterator bindings in the page's binding container and render the formatted output to appear in the browser. Finally, the user sees the resulting page in the browser.

References

1. Using Oracle ADF Model in a Fusion Web Application
2. Understanding the Fusion Page Lifecycle
3. Oracle Fusion Middleware Online Documentation Library 11g Release (11.1.1.2)
4. Oracle ADF BindingContext and BindingContainer