CBR 照会
コンテンツ・ベース・リトリーブ (CBR) 照会には、SQL ステートメントの WHERE 節の一部として全文検索関数呼び出しが含まれています。この全文検索関数を使用して、オブジェクトのコンテンツとプロパティー内のテキストを検索することができます。
全文検索関数を指定するには、CONTAINS 関数を使用します。どの検索でも、大/小文字は区別されません。検索は、IBM® Content Search Services 照会構文または XPath ベースの構文で表現する必要があります。
CONTAINS 関数呼び出しの検索結果は、IBM Content Search Services の構成の影響を受けます。詳細については、「検索結果」を参照してください。
CBR 照会の実行時間は長引く場合があります。照会の実行時間を制限するには、その照会にタイムアウト値を設定します。タイムアウト値は、継続可能な照会で照会結果の 1 ページをフェッチするために許される最大時間です。フェッチが許容される最大時間を超えた場合、Content Engine はその照会の実行を停止し、エラーを返します。デフォルトのタイムアウトは 1 つだけでは十分ではない可能性があります。アプリケーションを作成する際に、ユーザーがタイムアウトを設定することができます。
以下の例では、CBR 照会の検索関数呼び出しとその他の主な構文エレメントを示します。
SELECT d.This, c.Rank FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.*,'lion AND tiger')
AND d.Date >= 20101201T000000Z AND d.Date < 20101231T235959Z
ORDER BY c.Rank
OPTIONS (FULLTEXTROWLIMIT 500)
CBR 照会構文には、以下の主なエレメントがあります。
- コンテンツ検索テーブルの結合 - 照会では、ContentSearch テーブルを他の照会で参照されるテーブルに結合する必要があります。他のテーブルの場合と同様、ContentSearch もクラスです。詳細については、「ContentSearch テーブルの結合」を参照してください。
- 全文検索関数 - 照会には、CONTAINS 検索関数に対する呼び出しを 1 つ含める必要があります。なお、日付範囲は、データベース全体 (CONTAINS 節の前) ではなく、CBR 索引データ (CONTAINS 節の後) に適用した方が効率的です。詳細については、「CONTAINS 関数」を参照してください。
- 汎用コンテンツ検索テーブル列の使用 (オプション) - 照会では、オプションで ContentSearch プロパティーを列として参照できます。特に、Rank プロパティーでは、結果の関連性に基づいて照会結果の順序付けをすることができます。照会結果を関連性により順序付けする方法について詳しくは、「照会結果のランキング」を参照してください。その他の ContentSearch プロパティーについては、「ContentSearch プロパティー」を参照してください。
- 照会結果の行の制限 (オプション) - 照会では、CONTAINS 関数呼び出しが返す行の数をオプションで制限できます。詳細については、FullTextRowLimit を参照してください。
検索結果
IBM Content Search Services の索引には、オブジェクトのテキストが 1 つの論理エンティティーとして保管されます。そのため、全文検索では検索条件に一致する索引付きオブジェクトごとに 1 行が返されます。オブジェクトが検索条件に一致する回数は、返される行の数には影響しません。例えば、オブジェクトのコンテンツとプロパティー内のテキストには lion という単語が複数存在する可能性があります。lion を検索すると、そのオブジェクトについて 1 行だけが返されます。
Content Engine は、全文検索で返された行を ContentSearch テーブルに入れます。その後このテーブルは、照会内の他のテーブルと結合されます。詳細については、「ContentSearch テーブルの結合」を参照してください。
CONTAINS 関数呼び出しの結果に影響を与える要因には以下のものがあります。
- CBR 対応のクラスおよびプロパティー
CBR 対応クラスに属しているオブジェクトのテキストのみが索引付けされ、検索可能です。クラスを CBR 対応にするには、関連の ClassDefinition の isCBREnabled プロパティー値を true に設定します。例えば、Document オブジェクトのコンテンツ内のテキストを検索するには、DocumentClassDefinition オブジェクトの isCBREnabled プロパティーを true に設定します。
オブジェクト・プロパティー内のテキストを検索するためには、そのプロパティーも CBR 対応でなければなりません。プロパティーを CBR 対応にするには、関連の PropertyDefinition オブジェクトの isCBREnabled プロパティー値を true に設定します。プロパティーを CBR 対応にしても、クラスを同時に CBR 対応にしない場合は、機能上の効果はありません。プロパティー内のテキストを検索するには、そのプロパティーが属しているクラスも CBR 対応にする必要があります。
クラスまたはプロパティーを CBR 対応にしても、関連クラスが再索引付けされていなければ何も効果はありません。Administration Console for Content Platform Engine を使用してクラスを再索引付けし、クラスおよびプロパティーの状況を CBR 対応に設定する方法については、「オブジェクト・テキストを CBR 照会可能として設定する (Setting object text as CBR-queryable)」を参照してください。
- 単語のステム
全文検索では、単語検索語だけではなく、単語のステムの結果も返されます。 例えば、単語「tests」または「testing」を検索すると、「test」の結果も返されます。 この動作は、1 つ以上の小文字を含んだ用語にのみ適用されます。単語のステム検索が行われないようにするには、 すべて大文字の用語を使用してください (例えば、「TESTS」)。
- シノニム
全文検索では、明示的に指定された用語についての結果だけでなく、その用語のシノニムについての結果も返されます。例えば、 「ibm」と「International Business Machines」をシノニムとして定義したとします。 「ibm」を検索すると、「International Business Machines」という句が含まれたテキストが入ったオブジェクトも返されます。 シノニムの定義について詳しくは、「シノニムの設定」を参照してください。この動作は、1 つ以上の小文字を含む用語に適用されます。シノニム検索が行われないようにするには、「IBM」などのように、すべて大文字の検索用語を使用してください。
- ストップワード
一般に、 ストップワードとは、「a」や「the」のような、検索結果が不要な単語です。 この動作は、1 つ以上の小文字を含む用語にのみ適用されます。ストップワードが無視されないようにするには、「THE」などのように、すべて大文字の検索用語を使用してください。全文検索では、検索式の一部として指定される可能性のあるストップワードはすべて無視されます。ただし、ストップワードが以下のような場合は例外です。
- 句の一部。例: the cat
- ワイルドカード式の一部。例: the* cat
- すべて大文字。例: THE cat
- ストップワードのみで構成される場合。例: the
removeStopwordsFromBooleanQuery 構成ツール・パラメーターは、ブール検索式のストップワードが無視されるかどうかを制御します。removeStopwordsFromBooleanQuery パラメーターが true に設定されている場合、ブール検索式のストップワードは無視されます。それ以外の場合、ストップワードは照会の一部として使用されます。 例えば、removeStopwordsFromBooleanQuery が true に設定されている場合、「the AND cat」句を含む検索式では、the が無視され、単語「cat」を含むすべてのドキュメントが照会で返されます。ただし、removeStopwordsFromBooleanQuery パラメーターが false に設定されている場合、単語「the」と単語「cat」の両方を含むドキュメントのみが照会で返されます。デフォルト値は false です。
ストップワードの定義方法については、「ストップワードを照会から除外する (Omitting stop words from queries)」を参照してください。 構成ツール・パラメーターについては、構成ツール・パラメーターを参照してください。
- 除外される XML ノード
他のテキストの場合と同様、索引付きの XML ドキュメント・テキストのみが検索可能です。検索結果を出力したくない XML ノードを選択して、索引付けから除外することができます。詳細については、「XML ノードを索引から除外する (Omitting XML nodes from indexes)」を参照してください。
ContentSearch テーブルの結合
CBR 照会を実行する場合、Content Engine は、完全 SQL ステートメントによって表される照会とは別個に全文検索を実行します。全文検索は、ステートメント内で lion AND tiger のように表現します。これらの検索式は、IBM Content Search Services に直接渡され、返された検索結果は一時データベース・テーブルにコピーされます。その後、照会は標準的なリレーショナル照会として実行されます。
照会内で参照される他のテーブル (Document など) と同様に、一時テーブルもオブジェクトのクラスを表します。テーブル内の各行は、クラスの個別のインスタンスを表します。この一時テーブルは、ContentSearch クラスとして参照でき、照会内の他のテーブルと結合できます。許可される検索関数呼び出しは 1 つだけなので、1 つの SQL ステートメントについて 1 つだけ、ContentSearch 結合が許可されます。ContentSearch プロパティーについては、「ContentSearch プロパティー」を参照してください。 プロパティーは、照会内では列として参照できます。ContentSearch は内部クラスであり、したがって、このクラスのオブジェクトはインスタンス化できません。
以下の例は、全文検索での内部結合を示しています。
SELECT … FROM Document D INNER JOIN ContentSearch CS ON D.This=CS.QueriedObject
WHERE CONTAINS(*,'text') AND D.Creator = 'Frank'
この照会は、最初に CONTAINS(*, 'text') 節を評価して、そのデータを一時テーブルに書き込むことによって実行されます。次に、照会の残りの部分が実行されます。
SELECT … FROM Document D INNER JOIN ContentSearch CS ON D.This=CS.QueriedObject
WHERE CS.QueriedObject IS NOT NULL AND D.Creator = 'Frank'
CONTAINS 節が CS.QueriedObject IS NOT NULL に置き換えられることに注意してください。
上の例では、CONTAINS 節が AND 演算子とともに使用されています。OR 演算子を使用すると、内部結合 (実質的な AND) が存在するため、紛らわしい結果が生成されます。そのため、INNER JOIN を使用する場合は AND 演算子が必要で、OR 演算子は許可されていません。
以下の外部結合の例では、外部結合によって最初に CONTAINS 節が実行され、全文検索の結果を保持するデータベースの一時表の作成後に照会が実行されます。
SELECT … FROM Document D LEFT OUTER JOIN ContentSearch CS ON D.This=CS.QueriedObject
WHERE CONTAINS(*,'text') OR D.Creator = 'Frank'
外部結合を使用している場合は、ContentSearch クラスのみを条件付きで結合することができます。以下の照会の例では、右外部結合を使用することはできません。右外部結合を使用すると、照会結果で ContentSearch のデータしか返されない可能性がありますが、これは許可されていないためです。CONTAINS 節をその他の条件と組み合わせる場合は、外部結合で OR 演算子も使用する必要があります。AND 演算子の使用は許可されていません。
SELECT … FROM Document D LEFT OUTER JOIN ContentSearch CS ON D.This=CS.QueriedObject
WHERE CS.QueriedObject IS NOT NULL OR D.Creator = 'Frank'
CONTAINS 関数
CONTAINS 関数は、オブジェクト・コンテンツおよびプロパティーの中のテキストを検索する場合に使用します。この関数は、照会用の SQL ステートメントの WHERE 節から呼び出す必要があります。1 つの SQL ステートメントについて、最大 1 つの関数呼び出しを実行できます。
CONTAINS 関数には以下の文法があります。
CONTAINS(<property_spec>, <string_literal>[,<dialect>])
以下の関数呼び出しの例では、IBM Content Search Services 構文をいくつか示します。
CONTAINS(d.*, 'lion NOT tiger')
CONTAINS(d.*, 'lion* tiger')
CONTAINS(d.*, 'lion tiger~0.8')
CONTAINS(d.*, '@xmlxp:''/zoo/mammal[ .contains("lion")]''')
CONTAINS(d.*,'lion AND tiger') AND d.Date >= 20101201T000000Z AND d.Date < 20101231T235959Z
CONTAINS のパラメーターr: <property_spec>
CONTAINS の <property_spec> パラメーターで、検索されるオブジェクトのクラスおよび各オブジェクトの検索のスコープを指定します。単一プロパティーの検索か、すべてのプロパティーとオブジェクトのコンテンツの検索か、いずれかを選択できます。指定された検索スコープの機能的な有効性は、関連のクラスおよびプロパティーが CBR 対応かどうかによって異なります。詳細については、「検索結果」を参照してください。
特定のプロパティーを検索するには、以下の例に示すように、プロパティー名を指定します。
SELECT d.This FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.DocumentTitle,'lion')
すべてのプロパティーに加えてオブジェクト・コンテンツも検索するには、以下の例に示すようにアスタリスクを使用します。
SELECT d.This FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.*,'lion')
CONTAINS のパラメーター: <string_literal>
CONTAINS の <string_literal> パラメーターで、全文検索式を受け入れます。検索式は IBM Content Search Services に送信され、CBR 照会の実行時に処理されます。検索式の構文は、これ以降の各セクションで説明する構文に準拠している必要があります。XML ドキュメントの検索には XPath ベースの構文も使用できます。この構文については、「XML 検索」を参照してください。XML 検索は、フィールド検索およびテキスト検索と組み合わせることができます。
CONTAINS 検索式は、以下の例に示すように単一引用符で囲みます。
SELECT d.This FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.*,'DocumentTitle:zoo AND lion')
用語と句の照会
照会には、用語と演算子を含めることができます。用語とは、「database」などの 1 つの単語のことです。句とは、「computer software」 などのように、引用符で囲まれている単語の集まりのことです。句は、完全に一致する表現として検索されます。
以下の表では、句 (完全一致) と引用符のない検索語について、処理の違いを示します。
検索照会 | 引用符のない用語 | 完全一致 (句) |
---|---|---|
見出し語化 | 行われる | 行われない |
ストップワード | 削除される | 削除されない |
シノニム | 拡張される | 拡張されない |
ブール演算子 | サポートされる | サポートされない (検索語として解釈される) |
演算子:「-」および「%」 | サポートされる | サポートされない (検索語として解釈される) |
ワイルドカード文字:「*」および「?」 | サポートされる | サポートされる |
ブール検索
ブール演算子では、論理演算子を使用して用語を組み合わせることができます。ブール演算子として、 AND、&&、OR、| |、NOT、および「-」がサポートされます。
ブール演算子には、以下の制約事項が適用されます。
- AND、&&、OR、||、NOT の各ブール演算子の前と後に空白文字を付加する必要があります。
- ブール演算子はすべて大文字 (AND、OR、NOT) で指定する必要があります。そうしないと、検索語として処理され、演算子としては無視されます。
- NOT 演算子の代わりに感嘆符 (!) を使用することはできません。
- すべての用語が自動的に照会に組み込まれるため、正符号 (+) はサポートされません。正符号を使用しても無視されます。
用語または句の前に NOT 演算子または負符号 (-) を付加すると、ドキュメントにその用語または句が含まれていない場合のみ一致となります。これらの演算子は同義であり、ドキュメントを除外するためのフィルターとして機能し、正の結果を返す照会に関連付ける必要があります。例えば以下の照会では、computer という用語を含み、hardware という用語は含まれていないドキュメントが返されます。
computer NOT hardware
computer –hardware
括弧を使用して、照会内のブール・ロジックを制御することができます。例えば以下の照会では、WebSphere または Lotus のいずれかの用語と website という用語が含まれているドキュメントが検出されます。
(WebSphere OR Lotus) AND website
以下の表に、ブール演算子による検索照会の例を示します。
検索照会 | 結果 |
---|---|
database AND disk database && disk |
database という用語と disk という用語の両方が含まれているドキュメントが検出されるように、検索対象を絞り込みます。 |
database OR "log file" database || "log file" |
database という用語または log file という句のいずれかが含まれているドキュメントが検出されるように、検索対象を広げます。 |
database NOT "log file" database - "log file" |
database という用語が含まれ、log file という句は含まれていないドキュメントを検索します。 |
database OR "data base" NOT "log file" |
database という用語または data base という句が含まれ、log file という句は含まれていないドキュメントを検索します。 |
フィールド・データ
IBM Content Search Services は、フィールドの索引処理と、フィールド内の文字列ベースのデータの検索をサポートします。検索を実行する際に、オプションで検索対象のフィールドを指定できます。
フィールド名は、<property_spec> パラメーターによって直接的または間接的に指定された索引付きオブジェクト・プロパティーのシンボル名に対応している必要があります。対応するプロパティーが CBR 対応であることも必要です。xmlxp 式では、フィールド検索を使用することはできません。
フィールドを指定しなかった場合、IBM Content Search Services は、ドキュメント全体のテキスト・コンテンツで照会テキストを検索します。XML ドキュメントの場合、IBM Content Search Services は、照会テキストをエレメント内でのみ検索します。
検索対象のフィールドを指定するには、フィールド名を入力し、その後にコロン (:) を付加します。次に、検索する用語または句を指定します。例えば、「DocumentTitle」という CBR 対応プロパティーのシンボル名の値は、以下の照会で検索することができます。
DocumentTitle:"Budget Proposal"
1 つのフィールドで複数の節をグループ化するには、小括弧を使用します。例えば、次の照会では、tutorial という単語と「computer software」という句の両方を含むタイトルが検索されます。
DocumentTitle:(tutorial "computer software")
検索語を小括弧で囲むことにより、ブール演算子を使用する検索でフィールドを使用することもできます。例えば以下の照会では、apple という単語が含まれていないタイトルが検索されます。
DocumentTitle:(-apple)
DocumentTitle:(-apple banana)
以下の照会では、apple または banana という単語が含まれるタイトルが検索されます。
DocumentTitle:(apple OR banana)
以下の照会では、apple という単語が含まれ、banana という単語は含まれていないタイトルが検索されます。
DocumentTitle:(apple AND NOT banana)
また、フィールド・データを近接検索とファジー検索で使用することもできます。
特殊文字
照会構文における特殊文字にはさまざまな機能があります。例えば疑問符 (?) は、ワイルドカード文字として使用できます。特殊文字は CONTAINS <string_literal> パラメーターで指定して、必要に応じてエスケープしてください。多くの場合、特殊文字をエスケープするには、文字の前に円記号 (¥) を付けます。 次に例を示します。
- 文字列「where?」を検索するには、「where¥?」を使用します。.
- 文字列「c:¥temp」を検索するには、「c¥:¥¥temp」を使用します。
単一引用符をエスケープするには、単一引用符をもう 1 つ使用します。 次に例を示します。
- 文字列「owner's name」を検索するには、「owner''s name」と指定します。
以下の表に示す特殊文字は、エスケープする必要があります。
特殊文字 | エスケープしなかった場合の動作 |
---|---|
アスタリスク (*) | ワイルドカード文字として使用されます。 |
アットマーク (@) | アットマークを照会の先頭文字として使用すると、構文エラーが生成されます。xmlxp 式では、アットマークは属性を参照するために使用されます。 |
大括弧 ([]) | xmlxp 式で、エレメントと属性の内容を検索するために使用されます。 |
中括弧 ({}) | 構文エラーが生成されます。 |
円記号 (¥) | |
キャレット (^) | 用語の重み付け (ランキング調整) に使用されます。 |
コロン (:) | フィールドの内容を検索するために使用されます。 |
等号 (=) | 構文エラーが生成されます。 |
感嘆符 (!) | 感嘆符を照会の先頭文字として使用すると、構文エラーが生成されます。 |
スラッシュ (/) | xmlxp 式で、エレメント・パスの区切り文字として使用されます。 |
より大記号 (>) | xmlxp 式で、属性値の比較に使用されます。それ以外の場合は、構文エラーが生成されます。 |
より小記号 (<) | xmlxp 式で、属性値の比較に使用されます。それ以外の場合は、構文エラーが生成されます。 |
負符号 (-) | 負符号を用語の先頭文字として使用すると、その用語が含まれていないドキュメントだけが返されます。 |
小括弧 | グループ化に使用されます。 |
パーセント記号 (%) | 検索語がオプションであることを指定します。 |
正符号 (+) | |
疑問符 (?) | ワイルドカード文字として使用されます。 |
セミコロン (;) | |
単一引用符 (') | xmlxp 式を含めるために使用されます。単一引用符をエスケープするには、円記号の代わりに単一引用符をもう 1 つ使用します。 |
波形記号 (~) | 近接検索とファジー検索で使用されます。 |
縦棒 (|) |
照会構文の中で意味を持たない特殊文字をエスケープする必要はありませんが、エスケープした方が安全です。以下の例は、エスケープする必要のない特殊文字を示しています。
- コンマ (,)
- ドル記号 ($)
- ピリオド (.): xmlxp 式を組み込んでエレメントの内容を検索するために使用されます。
- ポンド記号 (#)
- 下線 (_)
特殊文字は、以下の基準に従って照会されます。
- 特殊文字が単語と隣接している場合、その特殊文字と単語が同じ順序で含まれているドキュメントが返されます。例えば、30$ で照会すると、30$ という表現を含むドキュメントが検出されますが、$30 という表現を含むドキュメントは検出されません。
- 特殊文字が単語に隣接しない場合は、その文字が個別の用語として照会されます。例えば、30 $ (区切りスペースあり) で照会すると、30$、$30、30、および $ を含むドキュメントが検出されます。
- ストップワードと見なされる単語が照会内の特殊文字に隣接している場合、その単語は削除されません。詳しくは、「ストップワード」を参照してください。
- 単語が照会内の特殊文字と隣接する場合、その単語はそのまま分類されます。例えば、英語で cats&dogs を照会すると、cat&dog を含むドキュメントが検出されます。
- 特殊文字で 2 つの単語を区切った場合、一連のトークンはシーケンスとして検索されます。例えば jack_jones を検索すると、jack_jones を含むドキュメントが検出され、jack_and_jones を含むドキュメントは検出されません。
ワイルドカード検索式での特殊文字の使用については、「ワイルドカード検索」を参照してください。
索引付けおよび特殊文字
IBM Content Search Services は、トークン化と言語の処理中に、特殊文字を句読点として識別して索引処理を行います。特殊文字は、トークンの区切り文字になります。例えば、「jack_jones」は「jack」、「_」、「jones」の 3 つの別個のトークンとしてトークン化されます。E メール、URL、ファイル・パスは、トークンに細分化されます。 次に例を示します。
- Jack_jones@ibm.com は、jack _ jones @ ibm . com としてトークン化されます。
- http://www.ibm.com は、http :// www . ibm . com としてトークン化されます。
特殊文字によって、ファイル内のトークンの位置が占有されることはありません。例えば jack_jones は、jack と同じトークンの位置に下線付きで索引処理されます。また、スペースが含まれている場合も、トークンの位置が特殊文字によって占有されることはありません。例えば「jack _ jones」は、jack_jones と同様に索引処理されます。
トークンの位置は、完全一致の句検索と近接検索で使用されます。例えば、あるドキュメントに jack_jones という表現が含まれている場合に、「jack jones」という完全一致の句を検索すると、そのドキュメントが検出されます。
一連の特殊文字を個別に索引付けすると、順不同で検索されます。例えば、「#$」を検索すると、「$#」を含むドキュメントも検出されます。
中国語、日本語、韓国語における特殊文字
中国語、日本語、韓国語 (CJK) で特殊文字を含む文字のシーケンスを検索するには、照会式で特殊文字を指定する必要があります。照会式で特殊文字を省略すると、その文字シーケンスは検出されない場合があります。CJK 以外の言語では、照会式で特殊文字が省略されていても、その文字シーケンスは必ず検出されます。例えば、索引付きドキュメントに john_smith が含まれている場合、john_smith または 「john smith」 (下線なしの完全一致) を検索することができます。また、どちらの照会でも、john_smith を含むドキュメントが返されます。
ワイルドカード検索
IBM Content Search Services は、用語、フィールド・データ、句でのワイルドカード検索をサポートします。ワイルドカード文字は、用語の前、中、または後に置くことができます。1 文字のワイルドカード検索を実行するには、疑問符 (?) を使用します。例えば、以下の用語で照会すると、mare、mere、mire、および more という用語が含まれたドキュメントが検出されます。
m?re
以下の句で照会すると、「uri requirements」と「url requirements」を含むドキュメントが検出されます。
"ur? requirements"
ワイルドカード検索式で特殊文字を使用することができます。例えば ja*_ を検索すると、jack_jones を含むドキュメントが検出されます。ただし、ワイルドカード文字を使用して特殊文字を検出することはできません。例えば「ca*s」を検索すると、cats、categories、cas などを含むドキュメントが検出され、ca_s を含むドキュメントは検出されません。
用語の先頭に 1 文字のワイルドカード文字を指定するには、二重引用符で囲む必要があります。 次に例を示します。
"?more"
複数文字のワイルドカード検索を実行するには、アスタリスク (*) を使用します。複数文字のワイルドカード検索では、0 (ゼロ) 文字以上の文字を検索できます。例えば、以下の用語で照会すると、tech で始まる DocumentTitle プロパティー値を持つドキュメントがすべて検出されます。
DocumentTitle:tech*
以下の句で照会すると、「maintenance contacts」と「maintenance contracts」が含まれた DocumentTitle プロパティー値を持つドキュメントが検出されます。
DocumentTitle:"maintenance cont*"
ワイルドカード文字を XML エレメントおよび XML 属性の値として使用できます。 ただし、ワイルドカード文字を XML エレメントおよび XML 属性の名前内に使用することはできません。 詳しくは、「XML 検索」を参照してください。
注: 複数文字のワイルドカード (*) を検索語の先頭に使用すると、一致する用語が多数検出された場合に、照会のパフォーマンスが低下する可能性があります。返される用語の数については、上限を設定することができます。この制限 (デフォルトでは、10,000 用語) を超えるとエラーが返されます。この制限を変更するには、構成ツールを使用して、queryExpansionLimit パラメーターに新しい値を指定します。詳しくは、「構成ツールの使用法 (Configuration tool usage)」を参照してください。
オプション用語の指定
% 記号を使用して、検索語がオプションであることを指定できます。例えば、以下の照会では、cat という単語が含まれるドキュメントがすべて返され、さらにオプションで dog という単語が含まれるドキュメントがすべて返されます。この照会では、dog という単語も含まれているドキュメントのスコアの方が高くなります。
cat %dog
オプションの演算子が機能するのは、式に複数の検索語が指定されている場合だけです。オプションとしてマークが付けられた用語が 1 つのみ照会に指定されている場合、指定された用語が含まれているドキュメントが照会で検出されます。つまり、式または 1 組の小括弧内に用語が 1 つしか指定されていない場合、オプションの演算子は無視されます。例えば、以下のそれぞれの照会は、検索結果とスコアの両方について同じになります。
%dog
%(dog)
(%dog)
dog
式内のすべての検索語がオプションである場合、指定された用語が 1 つ以上含まれているドキュメントが照会で検出されます。これは、OR 照会と同等です。例えば、以下のそれぞれの照会は、検索結果とスコアについて同じで、cat または dog といういずれかの単語が含まれているドキュメントを返します。
%cat %dog
%cat OR %dog
cat OR dog
以下の照会では、dog および horse という単語にオプションのマークが付いていますが、1 組の小括弧内に指定されているのはこれらの用語だけであるため、ドキュメントが返されるためには、そのドキュメント内で少なくともどちらかの用語が検出される必要があります。例えば、以下のそれぞれの照会は同等です。返される各ドキュメントには、cat という単語が含まれている必要があり、さらに dog または horse のいずれか (あるいは両方) の単語が含まれている必要があります。
cat (%dog %horse)
cat (%dog OR %horse)
cat (dog OR horse)
近接検索
近接検索では、指定された語数以内に用語が含まれているドキュメントが検出されます。近接検索を実行するには、用語を引用符で囲み、用語の後に波形記号 (~) と正の整数を指定します。例えば以下の照会では、連続する 7 語内に IBM と WebSphere が含まれているドキュメントが検索されます。
"IBM WebSphere"~7
- 見出し語化は行われません。
- ストップワードは削除されません。
- シノニムは拡張されません。
- ブール演算子はサポートされていません。
- ワイルドカード文字はサポートされています。
近接検索の対象となるのは、句ではなく個々の用語です。センテンスの区切りの後に続く単語は、前のセンテンス内の単語と隣接しているとは見なされません。センテンスの区切りの後に続く単語は、直前のセンテンスの最後の単語から位置が 10 だけ離れていると見なされます。センテンスの区切りは、後にスペースが続くピリオド (.)、疑問符 (?)、または感嘆符 (!) で識別されます。例えば ibm.com のピリオドは、センテンスの区切りではありません。通常、句読点の位置は、その前の文字と同じ位置になります (句読点単独で位置を占有することはありません)。
フィールド・データで近接検索を使用することができます。例えば以下の照会では、連続する 2 語内に apple と banana という単語が含まれている DocumentTitle プロパティー値が検索されます。
DocumentTitle:("apple banana"~2)
重みづけ検索 (用語のランキング調整)
検索語の後にランキング調整値を付けると、指定された用語を含むドキュメントが、検索結果においてどのようにランクされるかに影響します。キャレット記号 (^) と数字 (ランキング調整係数) を検索対象用語の末尾に付けます。例えば、次のように照会すると、用語 IBM および Germany を含むドキュメントが検索され、さらに 5 という係数によって、検索結果におけるこれらのドキュメントの関連性が大きくなります。
IBM Germany^5.0
フィールド・データを使用した用語のランキング調整
fruit:apple^5.0
fruit:(apple banana^5.0)
ファジー検索
ファジー検索照会では、照会用語と同じ文字シーケンスだけでなく、類似する文字シーケンスも検索されます。ファジー検索を実行するには、用語の末尾に波形記号 (~) を付けます。例えば以下の照会では、analytics、analyze、analysis などの用語を含むドキュメントが検出されます。
analytics~
オプション・パラメーターを追加して、必要な類似度を指定することができます。0 以上で 1 より小さい値を指定します。値の先頭には、例えば 0.8 のように、0 と小数点を付ける必要があります。値が 1 に近くなるほど、一致する用語の類似度が高くなります。このパラメーターを指定しなかった場合のデフォルトは 0.5 です。
analytics~0.8
ファジー検索構文は用語単位で指定できますが、句単位では指定できません。照会で複数の単語にファジー検索を適用するには、それぞれの用語にファジー検索係数を適用する必要があります。例えば以下の照会では、summer と time に類似する用語を含むドキュメントが検出されます。
summer~0.7 time~0.7
検索語を二重引用符で囲むことにより、フィールド・データでファジー検索を使用することができます。例えば以下の照会では、apple という単語と類似する単語を含む DocumentTitle プロパティー値が検索されます。
DocumentTitle:"apple"~0.3
DocumentTitle:"apple"~
- 特殊文字は、ファジー検索照会ではサポートされていません。
- ファジー検索照会の用語については、言語処理 (見出し語化、シノニム拡張、ストップワードの削除) は実行されません。そのため、ファジー検索照会では、シノニムに類似する用語は検出されません。
- ワイルドカード文字がファジー検索用語に含まれている場合、ワイルドカード検索だけが実行されます。
XML 検索
CONTAINS <string_literal> パラメーターを使用すると、XML ファイルのエレメントと属性値で用語を検索するための XPath ベースの式が許可されます。
XML 検索では、以下の検索機能がサポートされています。
- ブール演算子
- 完全一致
- ファジー検索
- 見出し語化
- 近接検索
- ストップワード
- シノニム
- ワイルドカード文字
- テキスト検索
- フィールド検索
検索式は IBM Content Search Services に送信され、CBR 照会の実行時に処理されます。IBM Content Search Services には、以下に説明するように、XPath 仕様のサブセットのみが実装されています。
フィールド値の範囲を指定することもできます。範囲を定義するには、上限と下限を指定して、その範囲が包括的 (大括弧を使用) か排他的 (中括弧を使用) かを指定します。ソート順は字句順になります。例えば、2 は 10 よりも大きいと見なされます。
XPath ベースの検索には以下の制約事項が適用されます。
- 1 つのコンテンツ・エレメントを持つ Document オブジェクトおよび Annotation オブジェクトのみを検索できます。
- コンテンツ・エレメントのコンテンツ・タイプは、「text/xml」または「application/xml」でなければなりません。
- パス検索の一部として、XML ノードを 1 つだけ指定できます。
- XML ドキュメントに対して推定される XML エンコードは UTF-8 です。その他のエンコードの場合は、XML ドキュメントの XML エンコードを明示的に指定してください。
照会内の他のすべての文字列リテラルの場合と同様に、検索式を単一引用符で囲んでください。単一引用符は、検索式の XPath 構文の一部としても使用する必要があります。 このトピックの検索式の例では、XPath で必要な単一引用符を、エスケープ文字を使用せずに示しています。XPath ベースの検索式を CONTAINS 関数に渡す場合は、2 個の連続する単一引用符を使用して、XPath で必要な単一引用符をエスケープしてください。以下の例では、検索式 @xmlxp:'/zoo/mammal[. contains("lion")]' が CONTAINS 関数に渡されます。
SELECT d.This FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.*, '@xmlxp:''/zoo/mammal[. contains("lion")]''')
この例のように、スラッシュを使用して、パスの XML エレメントを区切ります。パスを指定した後に、ピリオドが中に含まれた大括弧を使用して、XML エレメントのコンテンツを検索します。
定義により、XML エレメントと属性の名前では大/小文字が区別されます。ただし、エレメントと属性の値では大/小文字は区別されません。
XML 照会でのエレメント・パスの指定
以下の照会構文を使用することにより、XML 照会でエレメント・パスを指定できます。
/tag[. contains("word")]
- 定義: 最上位エレメントで単語を検索します。
- 例: @xmlxp:’/email[. contains("contract")]’
- 結果: 最上位の <email> エレメントに contract という単語が含まれているドキュメントが返されます。
/tag1/tag2[. contains("word")]
- 定義: 最上位エレメントの最初の子エレメントで単語を検索します。
- 例: @xmlxp:’/email/Subject[. contains("contract")]’
- 結果: 最上位の <email> の直下にある <Subject> エレメントに contract という単語が含まれているドキュメントが返されます。
//tag[. contains("word")]
- 定義: 任意のレベルのエレメントで単語を検索します。
- 例: @xmlxp:’//Recipient[. contains("John")]’
- 結果: 任意のレベルの <Recipient> エレメントに John という単語が含まれているドキュメントが返されます。
/tag1//tag2[. contains("word")]
- 定義: 任意のレベルのエレメントの指定された子エレメントで単語を検索します。
- 例: @xmlxp:’/Email//To[. contains("John")]’
- 結果: 任意のレベルのルート <Email> エレメントの下にある <To> エレメントに John という単語が含まれているドキュメントが返されます。
/*/tag[. contains("word")]
- 定義: 指定されていないルート・エレメントの指定された子エレメントで単語を検索します。
- 例: @xmlxp:’/*/To[. contains("John")]’
- 結果: 任意のルート・エレメントの下にある <To> エレメントに John という単語が含まれているドキュメントが返されます。
/tag1/*/tag2[. contains("word")]
- 定義: 指定されたルート・エレメントの直下にある指定されていないエレメントの指定された子エレメントで単語を検索します。
- 例: @xmlxp:’/Email/*/To[. contains("John")]’
- 結果: ルート <Email> エレメントの下にある任意のエレメントの下の <To> エレメントに John という単語が含まれているドキュメントが返されます。
エレメントと属性の内容の検索
以下のように xmlxp 式でピリオド (.) を使用することにより、XML ドキュメントのエレメントの内容を検索できます。
/tag[.contains ("word")]
以下の例のように、さまざまなレベルのエレメント・パスで検索式を組み合わせることができます。
/book[. contains ("whale")]/name[. contains("Moby")]
XML ドキュメントの属性の内容を検索するには、以下のように、xmlxp 式で @attribute_name を使用します。
/tag[@attribute contains ("word")]
以下の照会式は、エレメントと属性の両方の内容の検索に適用されます。属性値を検索するには、ピリオド (.) を、大括弧で囲まれた @attribute_name に置き換えます。
- /tag[.contains("word")]: 1 つの用語を検索します。
- /tag[.contains("word1 word2")]: 同じエレメントで複数の用語を検索します。
- /tag[.contains("""word1 word2""")]: 完全一致の句を検索します。
- /tag[.contains("word1 %word2")]: 同じエレメントで複数の用語とオプションの用語を検索します。
- /tag[.excludes("value")]: 指定された単語が含まれていないエレメントを検索します。
- /tag[.contains("word~")]: ファジー検索: 指定された用語と類似する用語を検索します。
- /tag[.contains("""word1 word2""~4")]: 近接検索: 指定された単語数の範囲内にある 2 つの用語を検索します。
ブール演算子を使用する式の例
- /tag[.contains("word1 AND word2")]
- /tag[.contains("word1 OR word2")]
- /tag[.contains("word1 NOT word2")]
ワイルドカード文字を使用する式の例
- /tag[.contains("word*")]
- /tag[.contains("word?")]
- /tag[.contains("word1*word2")]
- /tag[.contains("word1?word2")]
- /tag[.contains("*word")]
- /tag[.contains("?word")]
ワイルドカード文字について詳しくは、「ワイルドカード文字」を参照してください。
代替の構文構造
xmlxp 式の大括弧でエレメント・パスを囲むことができます。例えば、以下の照会は同義で、同じ結果が返されます。
@xmlxp:’/doc/email[recipients contains ("John")]’
@xmlxp:’/doc/email/recipients[.contains ("John")]’
この構文を使用して、同じ xmlxp 式でさまざまなサブパスに対する制約を表現することができます。次に例を示します。
@xmlxp:’/doc/email[recipients/to contains ("John") AND sender contains ("Jack")]’
属性値とエレメント値の数値比較
以下の構文を使用して、属性の数値を比較することができます。
/tag[@attribute operator numeric_value]
サポートされている演算子は次のとおりです: > < >= <= =!=
数値は、正の整数 (15 など)、負の整数 (-15 など)、10 進小数 (15.1 など)、浮動小数 (1.510000e+1 など) として指定できます。例えば、以下の照会は同義です。
@xmlxp:’/book/name[@price > 15]’
@xmlxp:’/book/name[@price > 15.0]’
@xmlxp:’/book/name[@price > 1.500000e+1]’
日時の比較
Date エレメント、DateTime エレメント、属性値を検索することができます。Date と DateTime の値を比較する場合、次の演算子がサポートされています: > < >= <= = !=
Date と DateTime の値は、以下の ISO 8601 形式で指定されている場合に検索することができます。
- Date: yyyy-MM-dd
- DateTime: yyyy-MM-ddTHH:mm:ss.SSSSSSSS。「T」は、オプションの時刻の区切り文字です。この区切り文字は、1 つ以上の空白文字で置き換えることができます。ミリ秒 (0 桁から 8 桁) はオプションです。
サポートされる日時形式について詳しくは、http://www.w3.org/TR/xmlschema-2/#dateTime を参照してください。
以下の例は、有効な Date と DateTime の値を示しています。
2011-07-04
2011-07-04 16:41:06
2011-07-04T16:41:06
2011-07-04T16:41:06.123
- エレメントまたは属性には、Date または DateTime の値だけが含まれている必要があります。空白文字以外の余分な文字を含めることはできません。
- Date または DateTime の値を含むエレメントは、下層エレメントを持つことができません。
以下の例は、XML ドキュメントのコンテキストにおける Date と DateTime の値を示しています。
- <elementName>2011-07-04 16:41:06</elementName>
- <elementName attributeName="2011-07-04"></elementName>
検索時には、Date または DateTime の値が正しいデータ型として認識されるように、xs:date() または xs:dateTime() の関数呼び出しで Date または DateTime の値を囲む必要があります。
XML ドキュメントの XML DateTime データ型は、((’+’ | ’-’)hh ’:’ mm) | ’Z’ の形式でタイム・ゾーン値を指定できます。ただし、DateTime の索引処理時には、IBM Content Search Services サーバーによって索引処理中にタイム・ゾーンの値が切り捨てられます。タイム・ゾーンは、照会の xs:date() 値または xs:dateTime() 値で指定することはできません。したがって、Date データ型または DateTime データ型が関係する XML 検索では、タイム・ゾーンは考慮されません。
時刻エレメントの「24:00:00」は、その日の最後の瞬間と翌日の最初の瞬間の間の値として処理されます。
以下の例は、xmlxp 用語の Date と DateTime の比較を示しています。
- @xmlxp:’/Book[@publishDate > xs:date(“2010-01-01?)]’: 最上位タグは Book です。Book は、日付 2010-01-01 よりも大きな属性 publishDate を持っています。
- @xmlxp:’/Book[purchaseTime > xs:dateTime(“2009-05-20T13:00:00?)]’: 最上位タグは Book です。Book は、2009-05-20T13:00:00.000000 よりも大きな DateTime 式である直接の子 purchaseTime を持っています。
照会のブール式
以下のブール演算子を使用して、xmlxp の制約 (AND、OR、XOR) が指定された複雑な照会式を作成することができます。例えば以下の照会には、AND ブール演算子と OR ブール演算子が指定されています。
@xmlxp:’//BBB[.contains("E")]’ AND @xmlxp:’/AAA/BBB[@id = "2"]’ OR @xmlxp:’/AAA/BBB[@id = "2"]’
ブール演算子を @xmlxp 制約の値で使用することもできます。
以下の構文例は、ブール演算子を検索語とともに使用する方法を示しています。
- @xmlxp:’//body[.contains("word1 AND word2")]’: 両方の単語が <body> エレメントで検出された場合に結果を返します。
- @xmlxp:’//body[.contains("word1 word2")]’: 両方の単語が <body> エレメントで検出された場合に結果を返します。 この構文は、AND を使用した場合と同じ結果になります。
- @xmlxp:’//body[.contains("word1 OR word2")]’: いずれかの単語が <body> エレメントで検出された場合に結果を返します。
- @xmlxp:’//body[.contains("word1 NOT word2")]’: <body> エレメントで word1 が検出されたが、word2 は検出されなかった場合に結果を返します。
- @xmlxp:’/tag1[tag2 contains ("word2") AND tag3 contains ("word3")]’: word2 が <tag2> エレメントで検出され、word3 が <tag3> エレメントで検出され、さらに両方の単語が /tag1 エレメント・パスで検出された場合に結果を返します。
エレメントまたは属性の検索
エレメントや属性が存在するかどうかは、エレメントや属性の値を指定しなくても確認することができます。
例えば以下の照会では、<email> エレメントが <doc> エレメントの直下で検出された場合に結果が返されます。
@xmlxp:’/doc/email’
以下の照会では、id 属性を持つ <email> エレメントが <doc> エレメントの直下で検出された場合に結果が返されます。
@xmlxp:’/doc/email/@id’
検索における名前空間の使用
検索時に XML の名前空間を参照することができます。XML ドキュメントの名前空間は、例えば XML ドキュメントと別のソースとの間などで名前の競合を防止するために、エレメント名と属性名のスコープを限定する手段です。名前空間について詳しくは、http://www.w3.org/TR/xml-names を参照してください。
例えば、XML ドキュメントで http://example.com/ns/abc などの明示的な名前空間を定義して xmlxp 照会で参照するには、以下のような形式で XML を指定します。
<?xml version=’1.0’?>
<doc xmlns:ns1="http://example.com/ns/abc">
<ns1:p>word</ns1:p>
</doc>
対応する xmlxp 照会は以下のように作成されます。
@xmlxp:’declare namespace ns1 = "http://example.com/ns/abc";
/doc/ns1:p[. contains ("word")]’
デフォルトの名前空間
XML ドキュメントで http://example.com/ns/abc などのデフォルトの名前空間を定義して xmlxp 照会で参照するには、以下の XML を指定します。
<?xml version=’1.0’?>
<doc xmlns="http://example.com/ns/abc">
<p>word</p>
</doc>
対応する xmlxp 照会は以下のように作成されます。
@xmlxp:’declare default element namespace "http://example.com/ns/abc";
/doc/p[. contains ("word")]’
属性の名前空間
属性も名前空間を持つことができます。以下の例では、エレメントと属性の両方がそれぞれ異なる名前空間を持っています。
<dog xmlns:an="http://example.org/animals" xmlns:sz="http://example.org/sizes">
<an:breed sz:size="Medium">Mutt</an:breed>
</dog>
以下の xmlxp 照会では、属性名に名前空間が使用されています。
@xmlxp:’declare namespace sz = "http://example.org/sizes";
/dog/breed[@sz:size contains("Medium")]’
以下の xmlxp 照会では、属性とエレメントの両方で名前空間が使用されています。
@xmlxp:’declare namespace an = "http://example.org/animals";
declare namespace sz = "http://example.org/sizes";
/dog/an:breed[. contains ("Mutt") and @sz:size contains("Medium")]
XML 検索とフィールド検索の組み合わせ
xmlxp 構文を、メタデータ・フィールドに対する検索と組み合わせることができます。例えば、以下の検索では、Paul という受信者に送信され、CBR 対応の DocumentTitle プロパティーに「IBM」という値が指定された E メールが検出されます。
@xmlxp:’//recipients/to[.contains("Paul")]’ DocumentTitle: IBM
以下の例に示すように、ブール演算子を組み込むこともできます。
@xmlxp:’//recipients/to[.contains("Paul")]’ AND DocumentTitle: IBM
@xmlxp:’//recipients/to[.contains("Paul")]’ OR DocumentTitle: IBM
@xmlxp:’//recipients/to[.contains("Paul")]’ AND NOT DocumentTitle: IBM
XML 検索とテキスト検索の組み合わせ
xmlxp 構文を通常のテキスト検索と組み合わせることができます。例えば以下の検索では、Paul という受信者に送信され、important という単語が含まれている E メールが検出されます。
@xmlxp:’//recipients/to[.contains("Paul")]’ important
XML 検索と近接検索の組み合わせ
以下の構文に従い、xmlxp 構文を近接検索と組み合わせることができます。
SELECT d.This FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.*, '@xmlxp:''/email1/body1[.contains("""body email""~2")]''')
例えば以下の検索では、連続する 2 語内に「sun」と「sand」が含まれている E メールの件名が検出されます。
SELECT d.This FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.*, '@xmlxp:''/icc_document/icc_email/icc_subject[.contains("""sun sand""~2")]''')
CONTAINS のパラメーター: <dialect>
CONTAINS の <dialect> パラメーターは、検索の構文を識別するオプション・パラメーターです。
以下のいずれかの引数をこのパラメーターに渡してください。
- Lucene (IBM Content Search Services の場合)
以下の例に、IBM Content Search Services 構文を指定する検索関数呼び出しを使用した照会を示します。
SELECT d.This FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.*, 'lion' , 'Lucene')
<dialect> パラメーターはオプションです。デフォルトでは、オブジェクト・ストアの CBRSearchType プロパティーにより、CBR 照会の検索を実行するContent Search Engineが決まります。意図されているContent Search Engineにより、照会の推定検索構文が決まります。<dialect> パラメーターは逆の働きをします。検索構文を明示的に識別した場合は、その識別により、検索を実行するContent Search Engineを決定する CBRSearchType プロパティー値が上書きされます。CBR 照会を正常に実行するには、意図されている Content Search Engineを使用可能にする必要があります。
フルテキスト結合
CONTAINS 節を使用すると、そのたびに、(内部の) ContentSearch クラスに対して結合が実行されます。
全文検索を指定して照会を実行すると、最初に全文検索が実行され、次に、ContentSearch クラス名で参照されるデータベースの一時テーブルに、全文検索からのデータがコピーされます。結合が必要なのは、このためです。その後、検索ステートメントの残りの部分がリポジトリーに対して実行され、この一時テーブルに結合して全文検索データにアクセスすることになります。
ContentSearch クラスへの結合は、1 つの照会ステートメントにつき、1 回しか許可されません。これは、CONTAINS 節は 1 つしか許可されないためです。
以下の例は、全文検索での内部結合を示しています。
SELECT … FROM Document D INNER JOIN ContentSearch CS ON D.This=CS.QueriedObject
WHERE CONTAINS(*,'text') AND D.Creator = 'Frank'
この照会は、最初に CONTAINS(*, 'text') 節を評価して、そのデータを一時テーブルに書き込むことによって実行されます。次に、照会の残りの部分が実行されます。
SELECT … FROM Document D INNER JOIN ContentSearch CS ON D.This=CS.QueriedObject
WHERE CS.QueriedObject IS NOT NULL AND D.Creator = 'Frank'
CONTAINS 節が CS.QueriedObject IS NOT NULL に置き換えられることに注意してください。
上の例では、CONTAINS 節が AND 演算子とともに使用されています。OR 演算子では、内部結合が存在するため、紛らわしい結果が生成されます (事実上の AND)。そのため、INNER JOIN を使用する場合は AND 演算子が必要で、OR 演算子は許可されていません。
外部結合の例を以下に示します。
SELECT … FROM Document D LEFT OUTER JOIN ContentSearch CS ON D.This=CS.QueriedObject
WHERE CONTAINS(*,'text') OR D.Creator = 'Frank'
外部結合では、最初に CONTAINS 節が実行され、全文検索の結果を保持するデータベースの一時テーブルの作成後に次の照会が実行されます。
SELECT … FROM Document D LEFT OUTER JOIN ContentSearch CS ON D.This=CS.QueriedObject
WHERE CS.QueriedObject IS NOT NULL OR D.Creator = 'Frank'
外部結合を使用している場合は、ContentSearch クラスのみを条件付きで結合することができます。上記の照会では、右外部結合を使用することができません。右外部結合を使用すると、ContentSearch のデータしか返されない可能性がありますが、これは許可されないためです。CONTAINS 節をその他の条件と組み合わせるときは、外部結合で OR 演算子も使用する必要があります。ここでは、AND 演算子の使用は許可されません。
ContentSummary 照会
全文 (CBR) 照会を作成する場合は、ContentSummary 列を参照しないようにしてください。このテキスト列を取得する場合、検索実行時間が長くなることがあります。
FullTextRowLimit
FullTextRowLimit では、照会の残りの部分を実行する前に CBR 照会が返す行数を指定します。以下の例に、FULLTEXTROWLIMIT オプションの値の指定方法を示します。
SELECT d.This, c.Rank FROM Document d
INNER JOIN ContentSearch c ON d.This = c.QueriedObject
WHERE CONTAINS(d.*,'lion AND tiger')
ORDER BY c.Rank
OPTIONS (FULLTEXTROWLIMIT 500)
コンテンツ・エレメントの数に関係なく、オブジェクトごとに 1 行ずつ存在します。 「全文検索結合」で説明したように、全文検索索引からのデータが一時テーブルにコピーされ、オブジェクト・ストア・データベースの残りの部分にそのテーブルが結合されて、照会が実行されます。
照会には、全文検索索引の何千もの行に一致する CONTAINS 節が含まれる場合があります。ただし、ユーザーは、照会の残りの部分を実行する前に、これらのすべての行を取り出して、一時データベース・テーブルに格納する必要がない場合があります。その場合は、FullTextRowLimit に設定する値を小さくすることにより、一致項目のサブセットをより迅速に表示することができます。
FullTextRowLimit の設定値は、小さくなりすぎないようにしてください。例えば、照会に「WHERE color = 'red' and CONTAINS(*, 'blue')」という WHERE 節が含まれているものとします。この照会では、「CONTAINS(*, 'blue')」に一致する行は 1000 個ありますが、「color = 'red'」および「CONTAINS(*, 'blue')」に一致する行は 10 個しかありません。FullTextRowLimit に 500 を設定すると、全文検索索引から 500 行のみ取り出され、それが一時テーブルに書き込まれます。ただし、これらの 500 行は、データベース内の「color = 'red'」も持つ行と同じではない可能性があります。そのため、照会の結果として、10 個の行がすべて見つかるとは限りません。
FullTextRowLimit の値を指定しない場合は、(GCD に保管された) ObjectStore.FullTextRowDefault プロパティーの値が使用されます。
FullTextRowLimit の値が指定されていて、この値が ObjectStore.FullTextRowMax の値より大きい場合は、ObjectStore.FullTextRowMax の値が代わりに使用されます。FullTextRowMax プロパティーが ObjectStore クラスに存在したため、システム管理者は、照会の処理時間が長くなりすぎることを防止できます。システム管理者によって変更されない限り、デフォルトでは、ObjectStore.FullTextRowMax プロパティーは 10,000 に設定されます。
FullTextRowLimit および最適化された照会
全文検索照会は、以下の特性が該当する場合に最適化されます。
- 照会が継続可能である。
- 照会が ContentSearch.Rank 値の降順で並べ替えられているか、または照会が並べ替えられていない (ORDER BY 節を含まない)。
- 照会に DISTINCT 節が含まれていない。
- 照会で ContentSearch クラスを含めるために INNER JOIN が使用されている。
- 照会がオブジェクト・ストアでのマージ済みスコープ検索に使用されない。
全文検索照会を最適化すると、特定のインスタンスでより迅速に結果を戻すことができます。また、FullTextRowLimit 値に達することも、タイムアウト・エラーやメモリー不足条件になることもなく、ユーザーはより多くの行を取得することもできます。
全文検索照会を最適化した場合、最初のページの要求が生成されると、サーバーは、FullTextRowLimit で指定された数の行を全文検索エンジンから取得します。次に、それをデータベースの一時テーブルに保管して、照会の関係部分を実行します。ただし、検索された行数が、現在のページを埋めるのに不十分である場合、サーバーは、次の一連の行を全文検索エンジンから取得して、十分な行数が検索されるまでこのプロセスを繰り返します。2 番目以降の行セットを全文検索エンジンから取り出したとき、サーバーは、取得した行数のパーセンテージを保持し、その行数が、ユーザーに返される結果データで実際に使用されます。そのため、FullTextRowLimit は使用されなくなり、代わりに、以前使用したパーセンテージに基づいた行数が取得されます。
全文検索照会を最適化するために 2 番目以降のページが要求されると、サーバーは、全文検索エンジンから次の一連の行も取得します。したがって、このタイプの照会を使用すると、コンテンツ検索に一致した行を、行数の制限なく参照することができます。
最適化は、すべてのタイプの照会に適しているわけではありません。ContentSearch.Rank を降順で並べ替えると、照会の関係部分の処理速度が低下します。また、呼び出し側が、データを降順で返されないようにする場合があります。
継続可能な照会は、最適化されていない場合、FullTextRowLimit の値で指定された行数を超えると継続されません。照会が最適化されていない場合、FullTextRowLimit を超えると、サーバーは、後続ページに対する全文検索でヒットした次の行セットを取得できません。代わりに、サーバーは、行数に FullTextRowLimit 値を使用して、処理対象のページごとに同じ行数を取得します。
FullTextRowLimit および最適化されていない照会
継続可能でない照会は、FullTextRowLimit で指定された数の行を全文検索エンジンから 1 セットだけ取り出します。この場合、FullTextRowLimit の値は、慎重に選択する必要があります。
FullTextRowLimit で指定された数を超える一致項目が全文検索索引に存在する場合、最適化されていない照会は、照会に一致する行数のサブセットを戻す場合があります。この状態が発生すると、サーバーは、CBR_FULLTEXTROWLIMIT_EXCEEDED 例外をスローし、一致項目のすべてが返されたわけではないことをクライアントに通知します。この例外がスローされるのは、最後の行が検出された後に、呼び出し側が照会で返された行を繰り返したときです。
FullTextRowLimit の値が指定されていない場合は、グローバル構成データ (GCD) データベースに格納されている ObjectStore.FullTextRowDefault プロパティーの値が使用されます。
FullTextRowLimit の値が指定されたが、この値が ObjectStore.FullTextRowMax プロパティーの値より大きい場合は、代わりに ObjectStore.FullTextRowMax の値が使用されます。FullTextRowMax プロパティーを使用すると、システム管理者は、照会の処理時間が長くなりすぎることを防止できます。FullTextRowMax プロパティーが設定されていない場合、そのデフォルトは 10,000 です。
照会結果のランキング
Rank プロパティーを照会の ORDER BY 節で使用して、返されるオブジェクトを照会の関連性によって順序付けします。Rank プロパティーは、ContentSearch クラスに属しています。
以下の全文検索の例では、検索結果を関連性の降順に順序付けします。
SELECT d.This, c.Rank
FROM Document d INNER JOIN ContentSearch c
ON d.This = c.QueriedObject
WHERE CONTAINS(d.DocumentTitle, 'lion tiger^5')
ORDER BY c.Rank DESCENDING
この例では、DocumentTitle プロパティーが各オブジェクトについて検索するテキストです。検索語は lion および tiger です。(^5 は tiger のランキング調整係数を示します。) 返されるオブジェクトの Rank プロパティー値は、検索するテキストと、以下の要因に従った条件に基づいて計算されます。
- 用語のインスタンス頻度 - 用語のインスタンス頻度は、オブジェクトの検索されるテキスト内での用語インスタンスの数です。用語インスタンスの多いオブジェクトほど、受け取るランキングが一般に高くなります。 この例では、DocumentTitle プロパティー内で lion および tiger のインスタンスが多いオブジェクトの方が、高い Rank プロパティー値を受け取ることになります。
- 用語の逆一致オブジェクト頻度 - 用語の逆一致オブジェクト頻度は、検索されるテキスト内に特定用語があるオブジェクトの数の逆数です。まれな用語が含まれているオブジェクトほど、受け取るランキングが一般に高くなります。この例では、すべての検索対象オブジェクトの DocumentTitle プロパティーに含まれている lion のインスタンスが tiger よりも少ないと仮定します。その場合、DocumentTitle 内に 1 つ以上の lion のインスタンスが含まれているオブジェクトの方が、傾向として Rank プロパティー値が高くなります。
- 用語存在率 - 用語存在率は、検索対象テキストに含まれている特定用語の数です。多くの用語が含まれているオブジェクトほど、受け取るランキングが一般に高くなります。この例では、DocumentTitle プロパティーに lion と tiger の両方が含まれているオブジェクトが、傾向として Rank プロパティー値が高くなります。どちらかの用語だけが含まれているオブジェクトは、傾向として Rank プロパティー値が低くなります。
- 用語のランキング調整 - 用語のランキング調整は、検索式に指定された他の用語との関係における用語の重要度です。検索されるテキスト内にランキング調整された用語が含まれているオブジェクトほど、受け取るランキングが一般に高くなります。この例では、指定されているランキング調整係数は tiger が 5 で lion が 1 です。この場合、DocumentTitle プロパティー内に tiger が含まれているオブジェクトの方が、lion が含まれているオブジェクトよりも、傾向として Rank プロパティー値が高くなります。ランキング調整係数は正の数値でなければなりませんが、0.2 などの 1 未満の数値でもかまいません。
- フィールド長の逆数 - フィールド長の逆数は、フィールド内の単語数の逆数です。検索されるフィールドに含まれている単語数が少ないオブジェクトほど、受け取るランキングが一般に高くなります。この例では、DocumentTitle プロパティーに含まれている単語が少ないオブジェクトの方が、傾向として Rank プロパティー値が高くなります。フィールド という用語は、IBM Content Search Services のフィールドを指しています。 オブジェクト・プロパティーはそれぞれがフィールドであり、オブジェクトのコンテンツはすべてのオブジェクト・テキストが含まれているデフォルト・フィールドの一部です。
CBR 照会の最適化
この機能は、コンテンツ・ベース・リトリーブ (CBR) 検索とデータベース (DB) のリレーショナル検索の両方を組み合わせた検索の実行方法を指定します。デフォルトでは、Content Engine は常に CBR 検索を最初に実行して、次に DB 検索を実行します。この CBR 優先のアプローチは、全文のヒット件数が少ない場合に最も効率的です。ただし、全文のヒット件数が多く、データベースのヒット件数が全文のヒット件数よりも少ない場合は、処理効率が低下します。
組み合わせ検索の実行方法を制御するには、CBRQueryOptimization プロパティーをオブジェクト・ストアで設定します。デフォルトの CBR 優先のオプションの代わりに、このプロパティーを動的切り替えオプションに設定することができます。動的切り替えモードの場合、Content Engine は、CBR 検索を最初に実行するか、あるいは DB 検索を最初に実行するかを動的に決定して、これらのタイプの検索のパフォーマンスを最適化します。
動的切り替えモードの場合、Content Engine は、CBR ヒットの推定件数に基づいて、CBR 優先から DB 優先に切り替えます。この推定件数は、CBRQueryDynamicThreshold プロパティーで設定されたしきい値と比較されます。全文の推定ヒット件数が CBRQueryDynamicThreshold の値以下である場合、CBR 検索が最初に実行されます (CBR 優先検索)。全文の推定ヒット件数が CBRQueryDynamicThreshold の値よりも大きい場合、データベース検索が最初に実行されます (DB 優先検索)。
動的切り替え操作は、ランクの順序付け要求など、さまざまな検索オプションの影響を受けます。オブジェクト・ストアの CBRQueryRankOverride プロパティーは、ランクの順序に対する CBR 検索要求にサーバーが応答する方法を決定しますが、このプロパティーがサーバーのパフォーマンスに影響を与える可能性があります。
サーバーが常に組み合わせ検索を DB 優先検索として処理する CBRQueryOptimization オプションはありません (ただし、照会ユーザーは、SQL オーバーライド・オプションを指定して、強制的に DB 優先検索を実行するできます)。ただし、以下のようにオブジェクト・ストア・プロパティーの組み合わせを設定することにより、DB 優先検索用にサーバーを構成することができます。
- CBRQueryOptimization: DYNAMIC_SWITCHING (1)
- CBRQueryDynamicThreshold: 0 (ゼロ)
- CBRQueryRankOverride: ENABLED (1)
CBR とデータベースの組み合わせ検索用にサーバーをどのように構成する場合でも、パフォーマンスを最大限に高めるための最適な方法に従ってください。動的切り替えモード (最適化されたモード) の使用を検討する場合、このモードで実行する場合の制限事項に注意してください。また、一部の検索については、このモードで最適化することはできません (「サポートされない検索」を参照)。
SQL 照会のオーバーライド
以下の SQL 照会オプションを使用して、オブジェクト・ストアの CBRQueryOptimization 設定をオーバーライドすることができます。
- CBR_CONTENT_FIRST。CBR 検索が最初に実行されます (CBR 優先)。この設定は、動的切り替えをオーバーライドします (オブジェクト・ストアで構成されている場合)。
- CBR_DB_FIRST。データベース検索が最初に実行されます (DB 優先)。この設定は、動的切り替えまたは CBR 優先をオーバーライドします (オブジェクト・ストアで構成されている場合)。
- CBR_DYNAMIC_THRESHOLDN。「N」は、0 (ゼロ) から Integer.Max_Value までの整数です。
検索は、しきい値 N が指定された動的切り替えを使用して実行されます。
DB 優先検索を効率的に実行するには、いくつかの対策が必要になります。詳しくは、「最適な方法」を参照してください。
以下の例では、検索は DB 優先検索として実行され、オブジェクト・ストアで構成されている値がオーバーライドされます。
SELECT d.Id, d.DocumentTitle FROM Document d
WHERE d.DocumentTitle LIKE 'Specification FaultTree%'
AND CONTAINS(d.*, 'Tennesee AND Contract')
OPTIONS (CBR_DB_FIRST)
最適な方法
- DB 優先検索を効率的に実行するには、索引付きプロパティーに対してデータベース基準を設定します。DB 優先検索で高いパフォーマンスを得るには、WHERE 節の 1 つ以上のプロパティーでデータベース索引を指定する必要があります。そうしないと、検索のデータベースのみの部分で、照会が非効率的に実行されます。
- ヒット件数が比較的少数になるように、データベース基準に対する制限条件を指定します。データベースのヒット件数が比較的少ない場合に、DB 優先検索が最も効率的に機能します。例えば、索引付けされたデータベース・プロパティー基準により、データベースのヒット件数がクライアントの検索ページ・サイズ (例えば 200) より少なくなるように制限されていて、CBR のヒット件数が数万件を超えることが予想される場合、DB 優先検索を実行すると、検索パフォーマンスの向上に役立ちます。
- CBR のヒットが多数のコレクションに分散されていて、CBR の合計ヒット件数をコレクション数で除算した数値が小さすぎる場合、動的な推定件数の精度が落ちる可能性があります。以下の表に、複数のコレクションを使用する場合に正確な推定を行うための最小しきい値を示します。CBR の合計ヒット数がこの表のしきい値よりも十分に大きい場合、動的な件数の推定は最も有効に機能します。
コレクション数 推奨最小しきい値 1 600 10 6 K 20 12 K 50 30 K 100 60 K 200 120 K 500 300 K
動的切り替え: 制限事項
動的切り替えモードは、全文のヒット件数が多すぎることに起因する非効率的なパフォーマンスを防ぐことができますが、その一方で、このモードでの実行には以下の制限事項があります。
- 一部の検索では、動的な推定件数の精度があまり高くない場合があり、通常は単なる概算値になります。コレクション内に 200 K 以上のアイテムが存在し、CBR のヒット件数がしきい値よりも十分に大きい場合に、動的な件数の推定が最も有効に機能し、長時間実行される CBR 優先検索が抑止されます。例えば、コレクションが 1 つだけ存在し、しきい値が 10,000 で、CBR のヒット件数が 20,000 以上である場合、動的切り替えによって DB 優先が選択される可能性が高くなります。CBR ヒットが 15,000 しかない場合は、推定が不正確になる可能性があるため、一部の検索が CBR 優先のままになることがあります。
- 動的な件数の推定にかかる時間を短縮するため、CBR のヒットがすべてのコレクションで均一に発生しない場合は、コレクション数が 12 を超えると、カウントが続行されなくなります。動的な件数の推定が最も有効に機能するのは、ほとんどのドキュメントで出現する可能性がある共通の単語を検索する場合のように、CBR のヒットが各コレクションで均一に発生する場合です。 デフォルトの動作をオーバーライドするための有効なソリューションについては、IBM サポートにお問い合わせください。
- DB 優先検索は、以下の条件を使用する検索では機能しません。
- CBR との外部結合 (ContentSearch クラス)
- CBR Contains 条件とともに OR 演算されるプロパティー条件
- CBR 内部結合が右端にない場合の、複数の結合照会内に存在する外部結合
- コンテンツ検索のプロパティー条件 (ランク > 100 など)
- 選択リスト内でランクが指定された特殊な照会
カスタム検索関数
上記の条件を使用する検索は、CBR 優先検索として実行する必要があります。CBRQueryOptimization プロパティーが DYNAMIC_SWITCHING に設定されている場合、これらの条件のいずれかを使用する検索は CBR 優先検索として実行されます。ただし、検索によって CBRQueryOptimization プロパティーが SQL オプションの CBR_DB_FIRST または CBR_DYNAMIC_THRESHOLD でオーバーライドされると、その検索はエラーになります。
- 動的切り替えモードの場合、データベース優先検索でランク別の順序付けを行うことはできません。
結果が常にランクの順序で返されるようにするには、CBRQueryRankOverride プロパティーを DISABLED (0) に設定します。この設定により、CBR 検索と DB 検索を組み合わせた照会で、CBR 優先検索が強制的に実行されます。ただし、ランクのオーバーライドを無効にすると、これらの照会タイプの最適化された実行も無効になります。
最適化された実行を維持するには、CBRQueryRankOverride プロパティーを ENABLED (1) または REQUIRED (2) に設定します。この設定により、サーバーは CBR 優先検索と DB 優先検索を動的に切り替えるようになります。このプロパティーを ENABLED に設定すると、CBR 優先検索はランクの順序で返されますが、DB 優先検索はランクの順序では返されません。このプロパティーを REQUIRED に設定すると、DB 優先検索と CBR 優先検索はランクの順序では返されません。
ランクの順序を要求し、CBRQueryOptimization プロパティーを SQL オプション CBR_DB_FIRST でオーバーライドする検索は、エラーになります。
- ランクの順序を要求して、CBR_DYNAMIC_THRESHOLD の SQL オーバーライドを使用するマージされていないスコープ検索は、次のように実行されます。CBRQueryRankOverride プロパティーが DISABLED (0) または ENABLED (1) に設定されている場合、CBR 優先検索はランクの順序で返されますが、DB 優先検索はランクの順序では返されません。このプロパティーを REQUIRED (2) に設定すると、DB 優先検索と CBR 優先検索はランクの順序では返されません。
- 動的切り替えは、ランクで順序付けされるマージ済みスコープ検索ではサポートされません。サーバーがランクの順序で結果を返すようにするには、サーバーで CBR 優先検索だけを実行する必要があります。
ただし、ランクの順序付けを無効にする場合は、ランクで順序付けされたマージ済みスコープ検索で動的切り替えを許可してもかまいません。その場合は、1 つ以上のオブジェクト・ストアで CBRQueryRankOverride プロパティーを REQUIRED (2) に設定します。この設定により、各オブジェクト・ストアの検索からランクの順序が削除されます (動的切り替えは、CBRQueryOptimization プロパティーまたは CBR_DYNAMIC_THRESHOLD の SQL オーバーライド・オプションによって設定できます)。
動的切り替えモードで作動することと、結果をランクの順序で返すことは、トレードオフの関係にあります。これは、各オブジェクト・ストアで実行される照会で同じ順序付けが使用されない限り、マージ済みスコープ検索は、組み合わされた結果を要求された順序で返すことができないためです。あるオブジェクト・ストアがランクの順序を削除し、別のオブジェクト・ストアは削除しない場合、順序付けされたマージ済みの結果を返すことはできません。動的切り替えが有効になっていると、各オブジェクト・ストアの CBRQueryRankOverride 設定がそれぞれ異なる可能性があります。したがって、1 つ以上のオブジェクト・ストアで CBRQueryRankOverride プロパティーが REQUIRED に設定されていない限り、ランクで順序付けされたマージ済みスコープ検索を動的に切り替えることはできません。
動的切り替え: サポートされない検索
全文照会とリレーショナル照会の条件を組み合わせた検索には、最適化できない検索がいくつかあります。以下の表に、最適化できない検索をリストします。また、オブジェクト・ストアの CBRQueryOptimization 設定の SQL 照会のオーバーライドを実行する場合と実行しない場合に、サポートされない検索に対してサーバーがどのように応答するかについて示しています。ダッシュ (–) で示されているように、CBRQueryOptimization の設定は、SQL 照会のオーバーライドが使用される場合には適用されません。
サポートされない検索 | CBRQueryOptimization 設定 | SQL 照会オプションのオーバーライド | サーバーの動作 |
---|---|---|---|
CBR との外部結合を使用する (ContentSearch クラス) | DYNAMIC_SWITCHING | なし | CBR 優先検索のみ |
- | CBR_DB_FIRST または CBR_DYNAMIC_THRESHOLD | エラーのスロー: RETRIEVE_OPTIMIZED_SEARCH_INVALID_OUTER_JOIN | |
CBR Contains 条件とともに OR 演算されるプロパティー条件を使用する検索 | DYNAMIC_SWITCHING | なし | CBR 優先検索のみ |
- | CBR_DB_FIRST または CBR_DYNAMIC_THRESHOLD | エラーのスロー: RETRIEVE_OPTIMIZED_SEARCH_INVALID_OUTER_JOIN | |
コンテンツのプロパティー条件を使用する検索 | DYNAMIC_SWITCHING | なし | CBR 優先検索のみ |
- | CBR_DB_FIRST または CBR_DYNAMIC_THRESHOLD | エラーのスロー: RETRIEVE_OPTIMIZED_SEARCH_INVALID_PROPERTY_CONDITIONS | |
外部結合と、右端にないコンテンツ検索結合を含む複数の結合を使用する検索 | DYNAMIC_SWITCHING | なし | CBR 優先検索のみ |
- | CBR_DB_FIRST または CBR_DYNAMIC_THRESHOLD | エラーのスロー: RETRIEVE_OPTIMIZED_SEARCH_INVALID_MULTIPLE_JOIN | |
選択リスト内でランクが指定された特殊タイプを使用し、オブジェクト・ストアでランクのオーバーライドが REQUIRED (2) に設定されていない検索 | DYNAMIC_SWITCHING | なし | CBR 優先検索のみ |
- | CBR_DB_FIRST または CBR_DYNAMIC_THRESHOLD | エラーのスロー: RETRIEVE_OPTIMIZED_SEARCH_INVALID_SELECT_DISTINCT | |
選択リスト内でランクが指定された特殊タイプを使用し、オブジェクト・ストアでランクのオーバーライドが REQUIRED (2) に設定されている検索 | DYNAMIC_SWITCHING または NONE | なし | エラーのスロー: RETRIEVE_CANT_SELECT_DISTINCT_RANK_WITH_OVERRIDE_REQUIRED |
ランクによる順序を使用し、ランクのオーバーライドが DISABLED (0) に設定されている検索 | DYNAMIC_SWITCHING | なし | CBR 優先検索のみ |
ランクによる順序を使用し、ランクのオーバーライドが ENABLED (1) に設定されている検索 | DYNAMIC_SWITCHING | なし | CBR 優先検索はランクの順序で返されるが、DB 優先検索はランクの順序で返されない |
ランクによる順序を使用し、ランクのオーバーライドが REQUIRED (2) に設定されている検索 | DYNAMIC_SWITCHING | なし | CBR 優先検索および DB 優先検索がランクの順序で返されない |
ランクによる順序を使用し、ランクのオーバーライドが任意の値に設定されている検索 | - | CBR_DB_FIRST | エラーのスロー: RETRIEVE_OPTIMIZED_SEARCH_INVALID_RANK_ORDER |
ランクによる順序を使用し、ランクのオーバーライドが DISABLED (0) または ENABLED (1) に設定されている検索 | - | CBR_DYNAMIC_THRESHOLD | CBR 優先検索はランクの順序で返されるが、DB 優先検索はランクの順序で返されない |
ランクによる順序を使用し、ランクのオーバーライドが REQUIRED (2) に設定されている検索 | - | CBR_DYNAMIC_THRESHOLD | CBR 優先検索および DB 優先検索がランクの順序で返されない |
マージ済みスコープ検索: ランクによる順序を使用し、ランクのオーバーライドが REQUIRED (2) に設定されていない検索 | 任意のオブジェクト・ストアで DYNAMIC_SWITCHING、またはすべてのオブジェクト・ストアで NONE | なし | CBR 優先検索のみ、ランクの順序 |
- | CBR_DB_FIRST | エラーのスロー: RETRIEVE_OPTIMIZED_SEARCH_INVALID_RANK_ORDER | |
- | CBR_DYNAMIC_THRESHOLD | エラーのスロー: RETRIEVE_OPTIMIZED_SEARCH_INVALID_MERGED_SCOPE_RANK_ORDER |