- Triggers
- Object-Relational Extensions
- Extenders
- LOB and Extender Usage
- Enabling Extenders
- Summary
- Additional Resources
This chapter is from the book
This chapter is from the book
This chapter is from the book
Enabling Extenders
A Software Developers Kit (SDK) and a client and server runtime environment are provided with the DB2 extenders installation package. DB2 extender applications can be executed in a server machine that has the extender client runtime code (automatically installed when the server runtime code is installed) and server runtime code. Extender applications can also be run on a client machine with the client runtime code, and you must ensure that a connection can be made to the server.
Extenders are available in DB2 Version 6 client/server environment. OS/390 is the supported server, and clients can be Windows NT, Windows 98, Solaris, AIX, or OS/390.
When storing image, audio, video, or text objects, you do not store the object in the user table but instead use an extender-created character string referred to as a handle that represents the objects, and the handle will be stored in the user table. The object is actually stored in an administrative support table (or file identifier if the content is a file). The attributes and handles are also stored in these administrative tables. The extender then links the handle in the user table to the object and its attributes in the administrative tables.
Text Extenders
Text extenders bring full-text retrieval to SQL queries for searching large text documents intelligently. With the use of text extenders, you can search several thousand large text documents very quickly. You can also search based upon word variations and synonyms. These documents can be stored directly in the database or in a separate file.
Files such as native word-processing documents can be search by keywords, wildcards, phrases, and proximity. IBM has built into these text extenders a high-performance linguistic search technology, giving you multiple options for searching and retrieving documents. These text searches can be integrated with your normal SQL queries. This enables you to integrate into your SELECT statements the ability to perform attribute and full-text searches very easily.
The following example shows how to perform this integration. In this example, we perform a SELECT from a table that also performs a search on a specified document using a text extender called DB2TX.CONTAINS. We are searching the legal cases document to see if the words "malpractice" and "won" appear in the same paragraph for cases occurring after 1990-01-01. LEGCSE_HANDLE refers to the column LEGCSE that contains the text document.
SELECT DOC_NUM, DOC_DATE
FROM LEGAL_CLAIMS
WHERE DOC_DATE > '1990-01-01'
AND DB2TX.CONTAINS
(LEGCSE_HANDLE,
"malpractice"
IN SAME PARAGRAPH AS "won") = 1
Text extenders allow applications to
Search documents of several languages and formats.
Perform wildcard searches using masks.
Perform a search for words that sound like the search input.
Perform fuzzy searches for like words (various spellings).
Perform searches for specific text, synonyms, phrases, and proximity.
Perform free-text searches where the input is a natural language.
Indexing Text Extenders
Scans are just as undesirable in text documents as they are with our DB2 tables. We need to create indexes so that sequential scans of documents are not necessary. By using a text index, you can speed up the searches performed on these documents.
A text index contains important words as well as a list of words known as stop words, such as and and the, which will not be in a text index. This list can be modified, but you would only want to do it once at installation time. When a request is made, the index is searched for the important terms to determine which documents contain those specified terms.
To set up a text index, you first record the text documents that need to be indexed in a log table. This process occurs when a DB2 trigger is fired off during an insert, update, or delete of a column of a text document. Then, when the terms are inserted or updated in the text document, they are added to the index. They are also deleted from the index if they are deleted from the text document.
There are four types of text indexes, and the type must be established before you implement columns that will be using text extenders. Not all search options are available by all index types, so you want to make sure the index will suit your criteria for searching. The four types of indexes are as follows:
Linguistic: In this type of index linguistic processing is performed during the analysis for the text when creating an index. Before a word is inserted into the index, it is reduced to its base form. Queries also use linguistic processing when searching against this index. This index requires the least amount of space, but searches may be longer than those done against a precise index.
Precise: In this index the search terms are exactly as they are in the text document and are case-sensitive. The same processing is used for the query search terms, so they must match exactly. The search can be broadened by using masks. This index provides a more precise search, and the retrieval and indexing is fast, but more space is required for its storage.
Dual: Dual indexes are combinations of linguistic and precise indexes. This allows the user to decide which type of search to use. This index requires the most amount of disk space. It is slower for searching and indexing than the linguistic indexes and is not recommended for a large number of text documents.
Ngram: The Ngram index is used primarily for indexing DBCS documents; it analyzes text by parsing sets of characters. This index type also supports fuzzy searches.
When creating tables that will support the ability to search text using extenders, you must consider a few design options. You can create one text index for all text columns in the table, or you can have several different text indexes—one for each text column. Using separate indexes for each text column offers the most flexibility in terms of support for your searches. It also gives you other options, such as how frequently the index is updated and where it is stored. One common index is easier to maintain, but is less flexible. If your indexes are large, consider storing them on separate disks, especially if you expect to have concurrent access to the indexes.
You can also have multiple indexes on a single text column. You may want to do this if you need the ability to allow different types of searches on a text column. And just like other DB2 indexes, these indexes will need to be reorganized too. If you have a text column that is continually updated, you will need to reorganize it. However, when using these indexes, the text extender automatically reorganizes them in the background. Despite this feature, you still may have to reorganize an index manually every so often, depending on its volatility. This is done with the REORGANIZE INDEX command. Issue the GET INDEX STATUS command to see if an index needs reorganization.
Frequency of Index Updates
When text documents are added, deleted. or changed, their content must be synchronized with the index. This information is automatically stored by triggers in a log table, and the documents will be indexed the next time an index update is executed.
The indexes can be immediately updated via the UPDATE INDEX command, but it is easier to have this performed automatically on a periodic basis. This time-based information is kept in an environment variable called DB2TXUPDATEFREQ, which provides default settings that can be changed during the ENABLE TEXT COLUMN or ENABLE TEXT TABLE commands. For an existing index, you can use the CHANGE INDEX SETTINGS command to change the variable settings.
The variable for determining when indexing should occur is based on the minimum number of queued text documents in the log table, and when this minimum is reached, the index is updated. Because updating indexes is a very resource-intensive and time-consuming task, this frequency should be set carefully.
Catalog View for Text Extenders
There is a catalog view created for each subsystem when you run the ENABLE SERVER. This view is DB2TX.TEXTINDEXES. It has information about the tables and the columns that have been enabled for the text extender. The entries are made during table, column, or external file enablement. If they are disabled, the row is removed. You can view the entries in the catalog view via SQL. In this view you can see such information as how often the indexes are scheduled for updates, whether or not you have a multiple-index table, and the type of index.
Image, Audio, and Video Extenders
The DB2 video extender can store as many as three representative frames per shot. By displaying the frames, you get a quick yet effective view of a video's content. The DB2 video extender provides sample programs that demonstrate how to build and display a video storyboard.
Video storyboards allow you to preview videos before you download and view them. This can save you time and reduce video traffic on the network. When image data is placed into a table using the DB2IMAGE UDFs, many processes are performed for the application automatically. The following code demonstrates using this function.
EXEC SQL INSERT INTO CONSULTANTS VALUES(
:cons_id,
:cons_name,
DB2IMAGE(
CURRENT SERVER,
'/RYC/images/current.bmp'
'ASIS',
MMDB_STORAGE_TYPE_INTERNAL,
:cons_picture_tag);
In this particular example, the DB2IMAGE reads all the attributes about the image (height, width, colors, layers, pixels, and more) from the source image file header, in this case the current.bmp. All the input is of a standard supported format, and all graphic files contain header information about the structure of the content. The function then creates a unique handle for the image and records all the information in the support table for administrative control of the image. This table contains
The handle for the image
A timestamp
The image size in bytes
The comment contained in :cons_picture_tag
The content of the image
The content of the image source file is inserted into the LOB table as a BLOB. There is no conversion done, and the image is stored in its native format. There is a record in the administrative table that contains all the image-specific attributes, such as the number of colors in the image, as well as a thumbnail-sized version of the image.
This example uses the storage type constants. We used MMDB_STORAGE_TYPE_INTERNAL to store the image into a database table as a BLOB. By using the extenders, we could have stored it elsewhere. If you want to store the object and have its content remain in the original file on the server, you can specify the constant MMDB_STORAGE_TYPE_EXTERNAL. Just because you are using LOBs does not mean that they have to be in DB2-managed tables. The administrative support table for image extenders tells where the LOB is actually stored. This does require Open Edition support services on the OS/390. From a performance perspective, there are many considerations as to where the LOB is stored, how it is used, where it is materialized, and so on.
XML Extenders
XML has been added to the list of available extenders. For the next generation B2B e-commerce solutions, XML is the standard for data interchange. With the XML extender for DB2, you will be able to leverage your critical business information in DB2 databases in order to engage in B2B solutions using XML-based interchange formats.
In terms of Web publishing, you can use XML documents stored in DB2 in a single column or as a collection of data items in multiple columns and tables. The text extender in DB2 supports structured documents like XML. The powerful search functions provided can now be applied to a section or a list of sections within a set of XML documents. This can significantly improve the effectiveness of the search. Additionally, specific XML elements or attributes can be automatically extracted into traditional SQL data types to leverage DB2's sophisticated indexing and SQL query capabilities. The DB2 XML extender also supplies a visual administration tool for easy definitions for mapping elements and attributes from an XML document into columns and tables.