３章 XMLDB XMLDB物理設計 目次

ビジネス・ユニットの名前
IBM Information Management software
３章 XMLDB物理設計
© 2007 IBM Corporation
1
ビジネス・ユニットの名前
IBM Information Management software
XMLDB物理設計 目次
3 XMLDB物理設計
3.1 物理設計のためのDB2 pureXML機能概要
3.2 XMLDB物理設計のステップ
XMLDB物理設計の流れ
A
論理モデルから物理モデルへの展開
A-① 表構造の検討
A-② XML構造の検討
A-③ DB2実装への適用
A-④ XML索引の設計
B
データベース・スキーマの作成
B-① XMLスキーマの生成
C
データベース物理設計
C-① データ容量の見積もり
C-② インスタンスの構成とDBの分割
C-③ 表の分類と表スペースの構成
C-④ 表スペースの配置
C-⑤ 表スペース以外のオブジェクトの配置
C-⑥ 構成パラメータの設定
C-⑦ シェル/コマンドの作成
2
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3.1 物理設計のためのDB2 pureXML機能概要
© 2007 IBM Corporation
3
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
4
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
DB2におけるXMLデータの格納
ƒ DB2のpureXML機能では、XMLデータを保持するための「XMLデータ型」を提供する
ƒ XMLデータ型はリレーショナル表の中に定義し、レコードの中の1カラムとして取り扱う
ƒ XMLデータは分解(Parse)されDOMに似た階層型のフォーマット(XDM)で格納される
–
照会時にはParseしない
ƒ XML格納方法は2通り
–
inline格納
–
XDA(XML Data Area)格納
insert into dept values (1,……, ’<dept><emp>夏目漱石</emp></dept>’)
dept表の論理構造
deptID
…
deptdoc
1
…
<dept> …
inline格納する表の定義
create table dept (deptID int,…,
deptdoc xml inline length 10000 )
</dept>
…
リレーショナル
deptID
…
…
create table dept (deptID int,…,
deptdoc xml)
…
XML
deptdoc
リレーショナル
deptID
inline格納時のdept表の物理構造
XML
XDA(XML Data Area)
deptdoc
XML記述子
1
5
XDA格納する表の定義
<emp>夏目漱石</emp>
regions
index
XMLデータ
XDA格納時のdept表の物理構造
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説:
„
DB2では、「XMLデータ型」がサポートされ、intなどのリレーショナルデータ型と同様に、列のデータ型として使用できます。
„
XMLデータは、保存されるときに分解(Parse)され、DOMに似た階層型のフォーマット(XDM)で格納されており、照会時に
はParseしません。
„
XMLデータの保持形態には、inline格納と、XDA格納の2種類があります。
–
inline格納 (V9.5より)
–
• XML列を定義する際に、inlineキーワードを指定した場合に採用されます。
• XMLデータは、他のリレーショナルデータと同じデータページに格納されます。
XDA格納
•
•
•
•
表のレコード中にはXML記述子（XML descripter）のみが保管され、XML部分はRelationalデータとは別
に保管されます。
XMLデータの実体を保管するエリアをXDA（XML Data Area）と呼びます。
記述子とデータの実体が分かれた構造はLOBと類似していますが、XDAはバッファープールを使用しま
す。また、LOBは連続したデータであり、XDAは構造を持ったデータの集まりです。
表定義の際、XML列のinlineキーワードを指定しない場合(デフォルト)に採用されます。
regions
index
XDAでは、XMLデータはDB2のページ構造に格納されます。
ƒ
XMLインスタンスが1ページに収まらない場合、regionと呼ばれるXMLのサブツリー
に分割し、それぞれのregionをページに格納します。
ƒ
regionはページをまたがることはありませんが、1つのページに複数のregionが
格納されることはあります。
XDA (XML Data Area)
（それぞれのXMLインスタンスがページサイズに比して小さい場合など）
ƒ
6
XMLインスタンスとregionの関係は、region indexに保持されます。
page
page
page
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
inline格納とその利点
ƒ DB2 V9.5では、指定したサイズ以下のXMLデータを基礎表に保持可能
– 基礎表に保持させたいXML列を定義する際に「INLINE LENGTH <integer>」キーワードを付加する
– LENGTH指定より長いXMLは、自動的にXDAに格納される
ƒ 利点
– Reagions IndexやXML記述子がなくなることによる、データ格納域の削減
– XMLデータを参照する際に必要なI/Oリクエスト削減
– 行圧縮の対象にすることが可能
insert into dept values (1,……, ’<dept><emp>夏目漱石</emp></dept>’)
insert into dept values (2,……, ’<history>昔、昔あるところに…
（10000バイト以上のデータ)…</history>’)
insert into dept values (3,……, ’<dept><emp>樋口一葉</emp></dept>’)
create table dept (deptID int,…,
deptdoc xml inline length 10000 )
リレーショナル
deptID
1
2
3
inline指定時は、XMLごとに
XML
deptdoc
XML記述子
XDA(XML Data Area)
regions
index
最適な格納方式を選択
XMLデータ
© 2007 IBM Corporation
7
ビジネス・ユニットの名前
IBM Information Management software
解説:
ƒ
DB2 V9.5では、CREATE TABLE時にXML列にINLINE LENGTH <integer>オプションを指定することにより、指定し
たサイズ以下のXMLデータを基礎表に保持することが可能です。INLINEオプションはALTER TABLEによって、後か
ら指定することも可能です。
ƒ
INLINE LENGTHで指定された長さより挿入されるXMLが長い場合は、そのXMLは自動的にXDAに格納されます。こ
の選択はカラムごとに行われます。
ƒ
inline格納には、以下の利点があります。
– Reagions IndexやXML記述子がなくなることによる、データ格納域の削減できます。
– XMLデータを処理する際にReagions IndexやXDAの参照が不要になるため、XMLデータを参照する際に必要なI/O
リクエストが削減されます。
– inline格納されているXMLは、行圧縮の対象にすることが可能です。
ƒ
INLINE LENGTHオプションで指定できる長さの最大長は、基礎表が存在する表スペースのページサイズの行の最大
長以下(単位はバイト, 292バイト以上)です。他の列を含めたレコード長が、制限値以下になるようにする必要がありま
す。
– 各ページサイズにおいて格納可能な一行の最大長は、以下のとおりです。
ページサイズ
ƒ
8
行の最大長
4KB
4,005
8KB
8,101
16KB
16,293
32KB
32,677
XMLの長さは、解析(parse)された後の内部表現によって決まるため、XMLインスタンスをテキストに表現した場合の長
さと同じではありません。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XML索引
ƒ XML索引の概要
– XML索引の種類
•
XMLデータ型に関連して3種類のIndexが存在する。
– Regions Index
– Paths Index
– XML Index
上記の中でユーザーが明示的に作成するのは最後のXML Indexのみであり、残りの二つ
は自動的に作成され、DB2が内部的に使用する。
•
Regions Index （XMLインスタンスRegionへの
Paths Index （全文書に対しユニークなパスを保持）
ポインタを保持）
root
name
Company2
Regions 索引
id
company
id
31664
31664
salary
salary
60000
gender
Male
emp
emp
name
name
gender
Male
id
id
M55
dept
Marketing
page
page
60000
page
first
Chris
last
Murphy
dept
first
last
Nicole
Murphy
K55
Sales
© 2007 IBM Corporation
9
ビジネス・ユニットの名前
IBM Information Management software
解説:
ƒ
XML索引の種別
–
Regions Index
–
• XML列を含む表を作成したときに、表に対して1つ自動的に作成される
• DB2が内部的に使用する索引。XMLインスタンスがどのページに格納されているかを管理する。
Paths Index
•
•
•
–
XML列を含む表を作成したときに、XML列ごとに1つ自動的に作成される
DB2が内部的に使用する索引。
各XML列に属するすべてのXMLインスタンスで、ユニークなパスを保存する。
XML Index
•
•
•
ユーザーがXML列に対して作成する索引
従来の索引と同様、表スペース内にページがとられる
一つのXML列に対して複数の索引を作成可能
CREATE TABLE t1 (docID int, XMLDoc1 xml, XMLDoc2 xml);
XML Regions
Index
10
XML Column
Path Index on
XMLDoc1
XML Column
Path Index on
XMLDoc2
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLデータへのアクセス
ƒ
XMLDBへのアクセス方法は、XQueryとSQLの二通り
–
XQuery : XMLデータ照会のための言語。W3C XQuery標準。
–
SQL: : XML列照会をサポート。ANSI/ISO SQL標準の拡張であるSQL/XMLでXQueryも利用可能
DB2 9 SERVER
CLIENT
DB2 Client /
Customer Client
Application
–
ƒ
SQL/XML
Relational
Interface
Hybrid
DB2 Storage
Relational
DB2
Engine
XQuery
XML
Interface
XML
XQueryとSQLを組み合わせて、いずれのクエリーからでも、リレーショナル・データとXMLデータの両方にアクセス可能
サポートするプログラミング言語
–
C or C++ (組み込みSQL or DB2 CLI)
–
COBOL
–
Java (JDBC or SQLJ)
–
C# and Visual Basic (IBM DataServer Provider for .NET)
–
PHP
–
Perl
–
Ruby
© 2007 IBM Corporation
11
ビジネス・ユニットの名前
IBM Information Management software
解説:
12
ƒ
DB2 では、リレーショナル・データ用のクエリー言語であるSQLに加え、XML用のクエリー言語としてXQueryをサ
ポートしています。これによって、柔軟なXMLデータの照会が可能となります。XQuery内部からリレーショナル列に
対してSQLを発行し、その結果をXQueryで利用することもできます。
ƒ
また、SQLもXML照会機能のサポート／拡張を行っています。 SQLのselect句にXML列を指定した照会がサポート
され、ANSI /ISO準拠のSQL/XML関数を利用してSQL内部からXQueryも実行できます。
ƒ
このようにDB2 9では、XQuery、SQL(SQL/XML)のどちらを使用してもXMLデータ及びリレーショナル・データにアク
セスできます。
ƒ
XML データを DB2の表に保管したり、表からデータを検索したり、XML パラメーターのあるストアード・プロシー
ジャーまたはユーザー定義関数を呼び出したりするアプリケーションを作成することができます。
ƒ
利用できる言語は、前ページのとおりです。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XQuery
ƒ XMLデータに対するクエリー言語
– XQuery1.0はW3Cにより2007/1/23に勧告（Recommendation）
• http://www.w3.org/TR/xquery/
• XQuery1.0はXPath2.0の拡張仕様
– 式の組み合わせでクエリを表現
• FLWOR式
右のXMLインスタンスの内容から、従業員名(emp/name)を抜き出し、
給与(salary)により並べ替える
xquery
declare namespace dept=http://example.com/dept;
for $d in db2-fn:xmlcolumn('DEPT.DEPTDOC')//emp
let $dsalary := xs:decimal($d/salary)
where $d/@id < '20'
order by $dsalary
return ($d/name) ;
<name>
福沢 諭吉
</name>
<name>
夏目 漱石
</name>
dept表 deptdoc列の内容
<dept:dept
xmlns:dept=“http://example.com/dept">
<emp id="11">
<name>夏目 漱石</name>
<phone>123-4567</phone>
<salary>1000</salary>
<speciality>English</speciality>
</emp>
<emp id="12">
<name>福沢 諭吉</name>
<phone>123-5678</phone>
<salary>10000</salary>
</emp>
<emp id=“33">
<name>樋口 一葉</name>
<phone>987-6543</phone>
<salary>5000</salary>
</emp>
</dept:dept>
© 2007 IBM Corporation
13
ビジネス・ユニットの名前
IBM Information Management software
解説:
14
ƒ
XQueryはXMLデータに対する汎用的に利用できる照会言語として設計されました。W3Cにおいて標準化が行われ
ており、2007/1/23にW3Cの勧告となっています。
ƒ
XQueryはXPath2.0を拡張したものです。XPathは端的に言えば、XMLの中のどの部分かを指し示すためのもので
す。
ƒ
XQueryは、式の組み合わせによって記述されます。代表的な式として、FLWOR式があり以下の、for、let、order by、
where、returnの頭文字をとったものです。
– forは「for 変数 in 式」という記述方法で式によって示されるシーケンスを変数に代入します。複数のシーケンスに
対して同じ処理を行う場合に使用します。
– letは「let 変数:= 式」という記述方法でひとつのシーケンスを変数に代入します。
– whereは処理を行う条件を指定する場合に使用します。
– order byはwhereで指定された条件に合致するものの順序を決めます。昇順、降順を指定します。指定しない場
合は昇順になります。
– returnは戻りのシーケンスを作ります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLデータの部分更新
ƒ XQuery Update Facility
– XQueryの拡張として、W3Cで仕様策定中（勧告候補）
• W3C Candidate Recommendation 14 March 2008（http://www.w3.org/TR/xquery-update-10/）
ƒ transform式を使用してXML文書を更新
– transform、copy、modify、returnの4つの文節
– 変更したいノードのコピーを変数に代入し、
変数を変更して返す
transform
copy $new := ….
modify ….$new….
transform式の開始
変数に変更したいXML
シーケンスを代入
変更を記述
return $new
変更された変数を返す
© 2007 IBM Corporation
15
ビジネス・ユニットの名前
IBM Information Management software
解説:
ƒ
V9.5より、transform式を使用してXML文書を更新することができます。
– XQueryの拡張としてW3Cで使用策定中(2008年3月勧告候補)のXQuery Update Facilityのうち、transform式
を実装したものです。XQuery Update Facilityについては、以下を参照
• W3C Candidate Recommendation 14 March 2008（http://www.w3.org/TR/xquery-update-10/）[3-1]
– SQLのUPDATE文と組み合わせてDB内の文書を更新することができます。
• XQuery transform式を含むUPDATE文の例
update dept
set doc = xmlquery(
'declare default element namespace "http://example.com/dept";
transform
copy $new := $i
modify do replace value of $new/dept/emp/salary with 5000
return $new'
passing info as "i")
where deptid = 1
– DB内の文書を取り出し、クエリー中でオンザフライ（変更をDBに反映しない)でも実行することができます。
– 実行できるノード操作には以下のものがあります。
• ノード、値の置き換え（replace value、replace node）
• ノードの挿入（insert node、insert after、insert before、insert as last、insert as first）
• ノードの削除（delete node）
• ノード名の変更（rename node）
– V9.1で部分更新用に提供されていたストアード・プロシージャーは、内部的には文書全体の更新を行っていまし
た。V9.5でも、XML全体がUPDATEの対象となりますが、分解(パース)は変更部分だけ実施しているため、パ
フォーマンスが向上しています。DB2のトランザクションログに書き出される変更ログの量は、XML全体の更新と
同様です。
16
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
3.2 XMLDB物理設計のステップ
© 2007 IBM Corporation
17
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
18
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLDB物理設計の流れ
A 論理モデルから物理モデルへの展開
①表構造の検討
RDBの物理設計で必要な作業項目
・表構造の性能面からの検討
-非正規化や導出項目、参照の整合性や制約の検討
XML DBとして必要な作業項目
・リレーショナル列の活用
・XMLインスタンスの表と列への割り当て
・XML構造の検討（性能面から）
②XML構造の検討
③DB2実装への適用
・物理的な属性の付与の検討
④XML索引の設計
・索引の設計
・DB2実装への適用
-英語名の付与、属性の物理タイプ、長さの決定
・XML索引の設計
-主キー（１次索引）、検索や結合のパターンから２次索引設計
B データベース・スキーマの生成
・表定義・索引定義の生成
・XMLスキーマの生成
①データ容量の見積もり
・ページ・サイズの決定
・表、（索引）サイズの見積もり
・XML列を含む表の容量見積もり
・XML特有のページ・サイズ考慮
・XML列更新によるログ量の考慮
②インスタンスの構成とDBの分割
・インスタンスの分割も検討
・バックアップ単位であるデータベースの分割を検討
・文字コードの制約の考慮
③表の分類と表スペースの構成
・表の分類と表スペース構成の決定
・表スペースのタイプ、その他の属性の決定
・表スペースの設計方針を決定
（XDAを配置する表スペースを検討）
④表スペースの配置
・物理ディスク上への表スペースの配置
・コンテナーの設計
・XML索引を含む表スペースの物理配置
・ログ、バックアップ用、ワークスペースの配置
・XMLの更新を見込んだログ容量を確保
・再編成の考慮
・物理設計にあわせた構成パラメータの変更
・コードページの考慮
・XML処理に特有なヒープサイズの検討
・これまでに設計したオブジェクトを作成する
コマンドおよびシェルを作成
・スキーマ管理（XSR登録、Xlinkの削除）
①XMLスキーマの生成
C データベース物理設計
⑤表スペース以外のオブジェクトの配置
⑥構成パラメータの設定
⑦シェル／コマンドの作成
19
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説:
ƒ
上記の表は、RDBでの物理設計の流れに対して、XMLデータが含まれる場合に追加で必要となる作業項目を整理
したものです。
– 中央が「RDB物理設計」を行う際に必要となる作業項目
– 右側が「XMLDB物理設計」を行う際に、追加で必要となる作業項目
を表します。
ƒ
この章では、「XMLDB物理設計」を行う際に、追加で考慮が必要なポイントについて記述します。
– 「RDB物理設計」については、参考資料として下記を参照してください。
•
20
DB2 V9 デザイン・ガイド：データベース物理設計[3-2]
http://www-06.ibm.com/jp/domino01/mkt/dminfo.nsf/doc/001E5347
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-①表構造の検討 - リレーショナル列の活用
ƒ
DB2のpureXML機能では、レコードにXML列と共にリレーショナル列を持たせることが可能
ƒ
–
必須ではなく、リレーショナル列のない定義も可能
–
XMLインスタンス内のデータをリレーショナル列に持たせることも可能
リレーショナル列の候補
–
文書管理のための列（サロゲート・キー、 NSEによる全文検索用Primary Key、TIMESTAMPな
ど）
–
XMLを意識せずにSQLのみでアクセスしたい場合
–
リレーショナル列/索引の使用が適している場合
–
• COUNT、DISTINCTなどの列関数を使用する列
リレーショナル列を任意で使用可能
• 複合索引に含める列
• 索引を使用したソートを行う列
XML列の制限
リレーショ リレーショ リレーショ
•
参照制約
ナル列
ナル列
ナル列
XML列
XML
ƒ
リレーショナル列へのデータ格納方法
XML
–
XML分解アノテーション
–
生成列
–
アプリケーションでの対応
XML
XML
© 2007 IBM Corporation
21
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XMLインスタンスのデータをリレーショナル列とする場合の候補としては、以下が挙げられます。
– 文書管理のための列を使用する場合
全文検索（NSE）使用時のユニークなID列や、サロゲート・キーとしてのID列、運用に用いるTIMESTAMP列
などが考えられます。
– 必要なデータをリレーショナル列に持たせることで、XMLを意識しないSQLのみによるアクセスも可能となります。
•
– 次のような場合、パフォーマンス上の問題が発生した場合、リレーショナル列/索引を使用すると改善される可能
性があります。
•
•
•
COUNT関数やDISTINCT関数などの列関数を使用する場合、リレーショナル索引を付与した列があると
XML索引のみの場合よりも結果が高速に取得できます。
XML索引では複合索引がサポートされていません。
XML索引を使用してソートすることはできません。
– XML列の制限により、リレーショナル列が必要となる場合があります。
•
ƒ
XML列を参照制約の一部として定義することはできません。
XMLインスタンスのデータをリレーショナル列に格納する場合は、整合性を確保したデータの格納方法を考慮する必
要があります。
– XML分解アノテーション機能を利用し、 DECOMPOSE XML DOCUMENTコマンドまたはxdbDecompXMLスト
アドプロシージャの実行時に、XMLインスタンスの挿入と同時にXML内のデータをリレーショナル列に挿入するこ
とが可能です。
– ID列として、生成列を使用することが可能です。
– 更新までを考慮した場合、アプリケーションでの対応が必要となります。
22
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-①表構造の検討 - 表と列の定義
ƒ
XMLインスタンスを実際に表へ格納する際の割り当てを考慮する
ƒ
CRUD、メンテナンス要件、索引対象、パフォーマンス要件を考慮し決定する
ƒ
XMLスキーマ数からみた代表的な保持パターン
–
XMLスキーマが一つの場合
XML
XML
XML
–
XML列
XMLスキーマ
XMLスキーマが複数の場合
XML列
XML
XML
XML
–
XMLスキーマ
XMLスキーマ
XMLスキーマ
XML列1
XML列2
XML列3
XMLスキーマを使用しない場合
XML列
XML
XML
XML
ƒ
XMLスキーマを変更する際の対応
–
XMLスキーマが一つの場合
–
XMLスキーマが複数の場合
© 2007 IBM Corporation
23
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
DB2では、XMLインスタンスをXML列という単位で格納します。
–
一つのXML列に異なるXMLスキーマのXMLインスタンスを格納することが可能です。
–
一つの表には複数のXML列を定義することが可能です。
–
一つのXML列に対して複数のXMLスキーマを関連付けることが可能です。
ƒ
XML列の定義を決定するには、 CRUD、メンテナンス要件、索引対象、パフォーマンス要件といった要素を考慮すること
が必要です。
ƒ
XMLインスタンスを表に対して格納する場合、選択可能なパターンが複数挙げられます。
–
ƒ
24
採用するパターンによりメリット、デメリット、考慮点が異なるため、重要視する要件に応じてそのパターンを採用
するかを決定します。
代表的ないくつかのパターンについて、解説していきます。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-①表構造の検討 表と列の定義 - XMLスキーマが一つの場合
ƒ
使用するXMLスキーマが一つの場合
–
特徴
•
•
1つの表に1XML列（及び、関連するリレーショナル列）のみ格納
適用するXMLスキーマは1種類のみ
–
メリット
–
考慮点
•
•
シンプルで分かりやすい
XMLスキーマ変更時の取り扱い
XMLインスタンスに関連するリレーショナル列
（使用する場合）
ID1
(INT)
ID2
(INT)
ID3
(CHAR)
order.xsd
OrderXML
(XML)
<a>
<a>
<b>bla</b>
<a>
<b>bla</b>
<a>
</a> <b>bla</b>
</a> <b>bla</b>
</a>
</a>
© 2007 IBM Corporation
25
ビジネス・ユニットの名前
IBM Information Management software
解説
26
ƒ
1つの表に1つのXML列とし、1つのXML列に1つのXMLスキーマを適用するシンプルなケースです。
ƒ
XMLスキーマを変更する場合は、後述のスキーマを変更する際の対応が必要です。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-①表構造の検討 表と列の定義 - XMLスキーマが複数の場合（1XML列）
ƒ
使用するXMLスキーマが複数の場合で、「XMLスキーマ:XML列 = n:1」のように1つのXML列に対して
複数のスキーマを使用する場合
特徴
–
•
1つの列に異なる複数のXMLスキーマで定義されるXMLインスタンスを格納
メリット
–
•
•
類似したXMLスキーマのXMLインスタンスをグルーピング可能
異なるXMLスキーマをまたがった検索
考慮点
–
•
•
•
件数が多くなると、索引付けの性能や索引がないタグの検索性能が悪化
異なる複数XMLスキーマで同じ要素名が使用されている場合に、XPath条件以外に行(文書)の特定条件
が必要
新規XML索引追加時の負荷
order1.xsd
XMLインスタンスに関連するリレーショナル列
（使用する場合）
ID1
(INT)
ID2
(INT)
ID3
(CHAR)
<a>
<a>
<b>bla</b>
<b>bla</b>
</a>
</a>
OrderXML
異なるXMLスキーマの
XMLインスタンスをまた
がった検索が可能
(XML)
b要素を検索
order2.xsd
27
<a>
<a>
<b>bla</b>
<b>bla</b>
<c>blub</c>
<c>blub</c>
</a>
</a>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
1つの表に1つのXML列とし、1つのXML列に複数のXMLスキーマを適用するケースです。
–
XMLスキーマが類似していて検索したい内容が同一の場合、複数のXMLスキーマのXMLインスタンスに対して一括で
検索できます。
ƒ
スキーマ・エボリューションのように徐々にスキーマが変化し、複数のXMLスキーマを適用する必要がある場合に適しています。
ƒ
同じXPathでも全く異なる意味を持つ可能性がある場合は、XMLインスタンスを特定する条件が追加で必要となる可能性があり
ます。
ƒ
レコード数と共に格納するXMLインスタンスの種類が増えた場合以下のような考慮点があります。
–
XML索引を使用しない場合は、複数のXMLスキーマのXMLインスタンスを検索するため、パフォーマンスが悪化する可
能性があります。
–
XML索引を使用する場合でも、1列に対するXML索引の数が多くなり、挿入時の負荷が大きくなる可能性があります。
–
新規にXML索引を追加する場合、全てのスキーマのXMLインスタンスを読み込む必要があります。XML索引の作成時
にはALLOW WRITE ACCESS指定が使用できないため、索引追加中の更新が停止されます。
XML索引を使用しない場合
<item>cat</item>
<item>cat</item>
</items>
</items>
<parent>
<parent>
<child>bla</child>
<child>bla</child>
<customer>
<name>ac</name>
</customer>
<a1>
<b>bla</b>
</a1>
items/itemに対するXML索引
parent/childに対するXML索引
</parent>
</parent>
28
XML索引を使用する場合
<items>
<items>
child要素を検索するため
に、child要素のないもの
も含めて全ての種類の
XMLインスタンスを検索す
る必要がある
<customer>
<name>ac</name>
</customer>
customer/name
に対するXML索引
<a1>
<b>bla</b>
a1/bに対するXML索引
XMLインスタンスの種
類ごとにXML索引が
必要なため、索引数
が増加しデータ挿入
時の負荷が増える
</a1>
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-①表構造の検討 - 表と列の定義 XMLスキーマが複数の場合（複数XML列）
ƒ
使用するXMLスキーマが複数の場合で、 「XML列:表 = n:1 (XML列を複数持つ表)」のようにXML列を
複数定義する場合
–
特徴
•
•
–
メリット
•
–
関連を持つ複数のXMLインスタンスを1レコードに格納
同一XMLインスタンスを分割して保持する場合（後述）等に使用
関連した複数のXMLインスタンスが表の1レコードとなるためにわかりやすい
考慮点
•
XML列間の整合性
cont.xsd
meta.xsd
XMLインスタンスに関連するリレーショナル列
（使用する場合）
Meta.xml
Contents.xml
ID1
(INT)
ID2
(INT)
Meta
(XML)
Contents
(XML)
Meta.xml
Contents.xml
1レコード
Meta.xml
Contents.xml
Meta.xml
Contents.xml
© 2007 IBM Corporation
29
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
1つの表に複数のXML列を持たせるケースです。
ƒ
複数のXMLインスタンスを1レコードとして保持できます。
ƒ
主な使用例として以下のようなものが考えられます。
–
同一XMLインスタンスを分割して保持するケース
•
ƒ
30
例：コンテンツを管理するXMLでメタデータ部分とコンテンツ部分を別カラムに保持
レコードの挿入時にXML列間の整合性を考慮する必要があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-①表構造の検討 表と列の定義 XMLスキーマを使用しない場合
ƒ
XMLスキーマの有無にかかわらず、DB2側で妥当性検査を行わない場合
–
特徴
•
•
–
メリット
•
•
–
1つの表に1XML列（及び、関連するリレーショナル列）のみ格納
XMLスキーマは使用しない
シンプルで分かりやすい
どんなXMLインスタンスでも一つの表に挿入できる
考慮点
•
•
行が増加した際の、検索対象増加によるパフォーマンス劣化
XML索引数の増大による索引メンテナンス負荷の増大
XMLインスタンスに関連するリレーショナル列
（使用する場合）
<a>
<b>bla</b>
ID1
(INT)
ID2
(INT)
ID3
(CHAR)
OrderXML
(XML)
</a>
<parent>
<child>bla</child>
</parent>
<a>
<c>bla</c>
</a>
<a1>
<b>bla</b>
</a1>
© 2007 IBM Corporation
31
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
DB2側でXMLスキーマを登録して妥当性検査を行わず、多様なXMLインスタンスを格納したい場合です。
–
ƒ
32
表や列の配置を考慮せずにXMLインスタンスを検索することが可能です。
レコード数と共に格納するXMLインスタンスの種類が増えた場合、1XML列に複数XMLスキーマのXMLインスタンスを格
納するケースと同様以下のような考慮点があります。
–
XML索引を使用しない場合は、複数のXMLスキーマのXMLインスタンスを検索するため、パフォーマンスが悪化
する可能性があります。
–
XML索引を使用する場合でも、 1列に対するXML索引の数が多くなり、挿入時の索引作成負荷が大きくなる可
能性があります。
–
同じXPathでも全く異なる意味を持つ可能性がある場合は、XMLインスタンスを特定する条件が追加で必要とな
る可能性があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-①表構造の検討 - 表と列の定義 XMLスキーマ変更への対応
ƒ
将来的にXMLスキーマの変更がある場合は、パターンにより対応が必要
–
一つのXML列に対して、変更後も一つのXMLスキーマのみを利用する場合
•
•
–
レコードの再Validation (V9.1)
DB2 V9.5ではUPDATE XMLSCHEMAが使用可能
一つのXML列に対して複数のXMLスキーマを許す場合
•
新規レコードは新規XMLスキーマでValidation
XML列
XMLスキーマをV1からV2へ変更
XML列
新規レコード→
：XMLスキーマV1で妥当性検査済のXMLインスタンス
：XMLスキーマV2で妥当性検査済のXMLインスタンス
旧XMLスキーマと新XMLス
キーマそれぞれで妥当性検
査されたXMLインスタンス
が混在することになるため、
対応が必要
© 2007 IBM Corporation
33
ビジネス・ユニットの名前
IBM Information Management software
解説
–
XMLスキーマのバージョン・アップ（スキーマ・エボリューション）など、将来的にXMLスキーマの変更が想定される場合は、
パターンに応じた対応を行う必要があります。
–
一つのXML列に対して、一つのXMLスキーマを使用する場合、変更後のXMLスキーマで全てのレコードを再妥
当性検査する必要があります。(V9.1)
–
DB2 V9.5では、スキーマ・エボリューションへの対応が強化され、一つのXMLスキーマで再妥当性検査なしに
XMLスキーマのバージョン・アップを実現できます。
•
–
34
UPDATE XMLSCHEMAコマンドを提供
– 登録済みのXMLスキーマに対して、「互換性がある」変更を行う際にXMLスキーマの更新が可能
となります。
• 「互換性がある」XMLスキーマの変更とは、以下のような変更を指します。
– オプションの要素や属性の追加
– ストリングタイプのサイズの増加(maxLength facet)
– 繰り返し可能要素の増加 (maxOccurs)
– 等
• スキーマ・エボリューションについては、「第4章 スキーマ管理」を参照してください。
複数のXMLスキーマを許す場合は、新しいXMLスキーマを登録し、それ以降に挿入されるレコードはこのXMLス
キーマで妥当性検査します。以前のXMLスキーマで妥当性検査済みのものは、それを意識して運用します。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-② XML構造の検討(1)
ƒ 論理設計が完了したXMLインスタンスに対して、必要に応じて、DB2に格納することを前提
とした性能面からの見直しを行う
–
空要素の削除によるノード数削減
<a>
<b1>30</b1>
<b2/>
</a>
–
<a>
<b1>30</b1>
</a>
XMLインスタンスの分割による1文書当たりのノード数削減
<a>
<b1>bla</b1>
<b2>bbb</b2>
<c1>cla</c1>
<c2>ccc</c2>
</a>
<a>
<b1>bla</b1>
<b2>bbb</b2>
</a>
<a>
<c1>cla</c1>
<c2>ccc</c2>
</a>
© 2007 IBM Corporation
35
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
検証後にパフォーマンスの問題がある場合、XMLインスタンスの構造を変更することで改善する可能性があります。
ƒ
DB2のpureXML機能では、XMLインスタンスあたりのノード数がパフォーマンスに影響を与えることがあります。いくつか
の手段により、ノード数の減少が可能です。
–
–
36
格納時にデータを持たない空要素を省略することにより、ノード数を減らすことができます。
• 特に、業界標準の汎用スキーマをそのまま用いた際など、不要な空要素が多い場合に有効となります。
• 空要素の検索（要素が空であるという検索）を行う場合は、空要素を残すことでXML索引が使用されます。
要素の数が多いXMLインスタンスなど、ノード数が多いためにパフォーマンスに問題がある場合は、分割により
改善する可能性があります。
ƒ
XML構造の整理には、アプリケーション側で調整する、XSLTを使用して変換するといった対応が必要となります。
ƒ
これらの対応には、スキーマ変更が伴う場合もあります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-② XML構造の検討(2)
ƒ 論理設計が完了したXMLインスタンスに対して、必要に応じて、DB2に格納することを前提
とした性能面からの見直しを行う（続き）
–
XML要素の属性への変換によるノード数削減
<a>
<b1>30</b1>
<b2>bbb</b2>
<a b1=“30”>
<b2>bbb</b2>
</a>
</a>
–
外部XMLインスタンスとのJoin数削減のための外部データ取り込み
<Sales_Detail>
<Item_Id>30</Item_Id>
<Quantity>3</Quantity>
</Sales_Detail>
<Sales_Detail>
<Item>
<Item_Id>30</Item_Id>
<Name>water</Name>
<Price>100</Price>
</Item>
<Quantity>3</Quantity>
</Sales_Detail>
© 2007 IBM Corporation
37
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
DB2のpureXML機能では、XMLインスタンスあたりのノード数がパフォーマンスに影響を与えることがあります。いくつか
の手段により、ノード数の減少が可能です。（続き）
–
要素を属性へ変更することで、XMLインスタンスのノード数を減らすことができます。
–
外部のマスター・データとのJoinが必要となるようなケースでは、XMLインスタンス内に外部のデータを取り込む
ことで、Joinの負荷を減らすことが可能です。
•
•
38
外部データとXMLインスタンス内に取り込んだデータとの整合性が必要ない場合（例：売上伝票の顧客住
所データなど、最新ではなく発生時点のデータで良いもの）は、論理データモデル設計の段階で考慮され、
XMLインスタンスが定義されており、この段階でデータの取り込みは発生しません。
一方、単にJoinの負荷を減らすために外部データとXMLインスタンス内にデータを取り込む場合（例：売上
伝票でも外部の最新データと同期を取りたい場合）は、データの整合性を考慮する必要があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-③DB2実装への適用 - 実装を考慮したデータ型の検討
ƒ 数値データ型
– 整数（BIGINT/INT/SMALLINT）
• 対応するデータ型の名称
備考
DB2データ型
Javaデータ型
XMLデータ型
単精度整数
SMALLINT
short
short
2byte整数（32767 以下、および -32768 以上）
長精度整数
INTEGER
int
int
4byte整数（2147483647 以下、2147483648 以上）
64ビット整数
BIGINT
long
long
8byte整数（9223372036854775807 以下、9223372036854775808 以上の整数）
• 制約、考慮点
– 制約は特になし
– 業務要件によっては、下記のようなビルドイン派生型の使用も可能
> positiveInteger（正の整数）、nonNegativeInteger（0以上の整数）
> negativeInteger（負の整数）、nonPositiveInteger（0以下の整数）
© 2007 IBM Corporation
39
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
RDBで、チェック制約等を使用してより厳密な制約を実装していた場合、必要な制約を付加した派生型をユーザー定義型
として定義する事も可能です。
–
ƒ
40
詳細は2章「F. XMLスキーマの詳細設計 - 派生型の宣言」を参照してください。
整数型が使用可能なファセット
–
pattern
–
enumeration
–
whiteSpace（collapaeのみ設定可能）
–
maxInclusive
–
maxExclusive
–
minInclusive
–
minExclusive
–
totalDigits
–
fractionDigits（「0」のみ設定可能）
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-③DB2実装への適用 - 実装を考慮したデータ型の検討
ƒ 数値データ型（続き）
– 浮動小数点（単精度/倍精度）
– 対応するデータ型の名称
DB2データ型
Javaデータ型
備考
XMLデータ型
単精度浮動小数点
REAL
float
float
32bit浮動小数点
倍精度浮動小数点
DOUBLE/FLOAT
double
double
64bit浮動小数点
• 制約・考慮点
– DB2/Java/XMLスキーマ共にIEEE754に準拠するが、上限値/下限値に若干の違いが存在する。
> ただし、DB2 9 for LUWの実装ではXMLデータ型の上限/下限もRDBデータ型と同じ。
– IBM形式の浮動小数点を使用している場合、IEEE754形式への移行が必要。ただし、有効桁数が低下
するため、データ精度の要件上問題ないかの考慮が必要
> IBM形式の浮動小数点では実数部のデータ長が長いため、同じ64bit浮動小数点でもIEEE形式より
も有効桁数が長い。
– XML データ型は、RDBデータ型が許容しない特殊値（正負の無限大、正負のゼロ、非数値）を許容する。
© 2007 IBM Corporation
41
ビジネス・ユニットの名前
IBM Information Management software
解説
•
DB2とXMLスキーマでの浮動小数点の上限値/下限値の違いについて
– DB2 9に格納する場合、許容する値の範囲がW3C XML Schema 1.1で定義された範囲と若干異なることを考慮する。
– DB2 9内でのSQLデータタイプ/XMLデータタイプ間では許容する範囲は同じ。
– 単精度（32bit）の場合
負の下限値
負の上限値
正の下限値
正の上限値
DB2 LUW RDB
-3.402e+38
-1.175e-38
1.175e-38
3.402e+38
DB2 LUW XML
-3.402e+38
-1.175e-38
1.175e-38
3.402e+38
W3C XML Schema1.1
-3.402e+38
-1.401e-45
1.401e-45
3.402e+38
Java
-3.402e+38
-1.401e-45
1.401e-45
3.402e+38
– 倍精度（64bit）の場合
•
42
負の下限値
負の上限値
正の下限値
正の上限値
DB2 LUW RDB
-1.797e308
2.225e-308
2.225e-308
1.797e308
DB2 LUW XML
-1.797e308
2.225e-308
2.225e-308
1.797e308
W3C XML Schema1.1
-8.988e307
-2.470e-324
2.470e-324
8.988e307
Java
-1.797e308
-4.940e-324
4.940e-324
1.797e308
浮動小数点型が使用可能なファセットは、整数型と同様
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-③DB2実装への適用 - 実装を考慮したデータ型の検討
ƒ 数値データ型（続き）
– 10進数
• 対応するデータ型の名称
DB2データ型
１０進数
DECIMAL
Javaデータ型
java.math.BigDecimal
XMLデータ型
備考
Decimal
• 制約・考慮点
– DB2 for LUW、z/OSのDECIMAL型の最大桁数は31桁であり、取り得る値の範囲は -10^31+1 か
ら 10^31-1 。
– XMLスキーマのdecimalは、デフォルトでは範囲/精度についての制約が存在しない。必要に応じて
制約を付加する。
© 2007 IBM Corporation
43
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
使用可能なファセットについて
– 整数型で使用可能なファセットと同様
•
44
fractionDigitsには0以外の値が設定可能
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-③DB2実装への適用 - 実装を考慮したデータ型の検討
ƒ 文字ストリング型
• 対応するデータ型の名称
DB2データ型
Javaデータ型
備考
XMLデータ型
固定長文字ストリング
CHAR
string
string
データ長を固定する場合、lengthで対応
可変長文字ストリング
VARCHAR
string
string
最大長はminLength/maxLengthで対応
固定長GRAPHICスト
リング
GRAPHIC
string
string
データ長を固定する場合、lengthで対応
可変長GRAPHICスト
リング
VARGRAPHIC
string
string
最大長はminLength/maxLengthで対応
• 制約・考慮点
– ホストからの移行を行う場合、SO/SIの取り扱いに考慮が必要
> 通常はコード変換時に除去する。
© 2007 IBM Corporation
45
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
46
文字列型で使用可能なファセットは下記の通り
–
length
–
minLength
–
maxLength
–
pattern
–
enumeration
–
whiteSpace
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-③DB2実装への適用 - 実装を考慮したデータ型の検討
ƒ 日付・時刻型
• 対応するデータ型の名称
DB2データ型
日付
Javaデータ型
備考
XMLデータ型
DATE
java.sql.Date
date
時刻
TIME
java.sql.Time
time
タイムスタンプ
TIMESTAMP
java.sql.Timestamp
dateTime
フォーマットが異なるため変換が必要
• 制約・考慮点
– dateTimeデータ型では、オプションとしてマイクロ秒とタイムゾーンを保持できる。
– SQLデータ型のTIMESTAMPはタイムゾーンを保持できないため、移行時に取り扱いの方針を検
討する。
– フォーマットが異なるため、移行時に変換を行う必要がある。
© 2007 IBM Corporation
47
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
dateTime型のフォーマットは下記の様に表記されます
–
yyyy-mm-ddThh:mm:ss.sssssszzzzzz
•
•
•
–
タイムゾーンの考え方
•
•
•
–
「T」は固定文字
「.ssssss」はマイクロ秒。 6桁以下で任意の精度で付加可能。
「zzzzzz」はタイムゾーン
dateTime型、Time型ではオプションとしてタイムゾーンを保持することが可能です。
タイムゾーンが記述されない場合、暗黙的にUTCとして取り扱われます。
タイムゾーンは「±HH:MM」で与えます。
– UTCを表す場合は「Z」、「-00:00」、「+00:00」として表現します。
dateTime型の表記の解釈例
内容
48
dateTimeフォーマットでの記述
UTCでの時刻
タイムゾーンなし（UTCとして解釈される）
2007-08-19T12:00:00
2007-08-19T12:00:00
UTCを表す表記法の1つ（ズールー時）
2007-08-19T12:00:00Z
2007-08-19T12:00:00
日本時間（JST）での2007/8/19 12:00
2007-08-19T12:00:00+9:00
2007-08-19T03:00:00
US東海岸時刻（EST)での2007/8/19 12:00
2007-08-19T12:00:00-5:00
2007-08-19T17:00:00
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
RDBのタイムスタンプ型を移行する場合
–
前述の通り、XMLスキーマにおけるdateTimeデータ型、Timeデータ型は、タイムゾーンを持たない場合、暗黙的
にUTCとして解釈されます。
–
複数のタイムゾーンを取り扱う業務では、移行時にタイムゾーンを付加してデータ投入することも検討必要があり
ます。
–
また、XQueryで定義された関数であるcurrent-dateTime、current-Time、current-DateはタイムゾーンUTCの現
在時刻を戻すため、タイムゾーンなしで時刻データを投入していた場合、意図と異なる結果が得られる可能性が
あります。
© 2007 IBM Corporation
49
ビジネス・ユニットの名前
IBM Information Management software
解説：RDBと同様の制約が必要な場合の考慮
ƒ
固有制約
– 文書単位（もしくはそれ以下のスコープ）でユニーク性を確保する場合
•
UNIQUE要素を使用し、XPathで指定したスコープで値が一意となることを指定
– XML列全体を通してユニーク性を確保する場合
•
ƒ
ユニークXML索引を作成し、XML Patternで一意となるエントリを指定
チェック制約
– 新たな派生型を定義し、制限（restriction）を付加して対応
ƒ
参照制約
– 参照制約は表間のデータの関連を表現するため、複数表を１XMLインスタンスに集約し、XMLの階層として表現できない
かを検討する。
– 独立したXMLインスタンス間で参照制約を保持する場合は、XMLスキーマとしては対応不可
•
•
50
アプリケーションでの対応を考慮する。
リレーショナル列として取り出し、RDBの参照制約を適用することも可能。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-③DB2実装への適用 - 使用文字の制約
ƒ DB2 pureXML機能でXML名（要素名、属性名、接頭辞名）に使用可能な文字
– 最初の文字は、文字または_(アンダースコア)のいずれか
– 2番目以降の文字は、文字、数字、.(ピリオド)、-(ハイフン)、_(アンダースコア)
– 半角カタカナ、全角英数字、(株)などの特殊文字は使用できない
ƒ DB2 pureXML機能ではXML名の長さは1000バイト以下の必要がある
© 2007 IBM Corporation
51
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
DB2 pureXML機能は、XML1.0規格に準拠しており、XML名の命名規則は規格により定められています。
XML名の命名規則の詳細については、 W3C Extensible Markup Language (XML) 1.0 [2-1]の資料を参照してください。
ƒ
DB2 pureXML機能は、XML名として使用可能な文字には、半角英数、全角ひらがな、全角カタカナ、UCSによりCJK統合
漢字として定義されている漢字は使用できますが、以下の文字は使用できません。
・ .(ピリオド)、-(ハイフン)、_(アンダースコア)以外の半角記号
・ 半角カタカナ
・ 全角の英数字、記号
・ ローマ数字
・ ㈱、①などの特殊文字
これらの文字はXML名には使用できませんが、テキストエレメントの値などで使用することは可能です。
ƒ
DB2 V9.1及びV9.5におけるpureXML機能では、XML名は1000バイト以下であるという制限があります。
XML名として使用できる文字列の例
日本IBM
日本アイビーエム
XML名として使用できない文字列の例
日本ＩＢＭ
日本ｱｲﾋﾞｰｴﾑ
日本IBM㈱
日本アイ・ビー・エム
52
=> ＩＢＭが全角英文字
=>アイビーエムが半角カタカナ
=> ㈱が使用不可
=>中黒の使用不可
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-③DB2実装への適用 - 関数使用時の制約
ƒ 関数の入力として、xs:string型を使用する場合のデータ長
• xs:stringを保持するノードの値を関数の入力として使用する際に、長さの制約がある関数が存在する。
– 関数の入力として使用するデータ長が32000byteを超えた場合、SQL16074Nが返却されエラーと
なる。
– XMLデータとして保持する上では特に制約はない
– 現時点ではDB2のマニュアルに記載されていないが、今後記載予定。
ƒ 桁数の多い数値要素をfloat/doubleにキャストする場合
• 31桁以上の数値要素を浮動小数点（float/double）にキャストする場合、SQLSTATE=10902が返却さ
れエラーとなる。
– XQuery関数上の長さ制限に抵触したとのメッセージが返却され、その時点でXQueryの実行は中
断される。
– SQL上で文字列からfloat/doubleへのキャストを行った場合も、31桁以上の場合エラーとなる。
© 2007 IBM Corporation
53
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
ƒ
32000byteを超えるxs:stringを入力した場合に、エラーの発生が確認できている関数
–
fn:matches
–
fn:contains()
–
fn:ends-with() / fn:start-with()
–
fn:matches()
–
fn:substring-after() / fn:substring-before()
–
fn:tokenize()
–
fn:translate()
31桁以上の数値要素を浮動小数点にキャストした場合のメッセージ
–
XQueryの場合
SQL16074N An XQuery atomic value with the lexical representation starting
with "1234567890123456789012345678901" of type "xdt:untypedAtomic" cannot be
processed in the XQuery operation or function "xs:double()" because the length
exceeds the operation or function limit of "30" bytes. SQLSTATE=10902
–
SQLの場合
SQL0443N Routine "SYSFUN.DOUBLE" (specific name "CHARTODOUBLE") has returned
an error SQLSTATE with diagnostic text "SYSFUN:11". SQLSTATE=38552
54
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-④XML索引の設計 - XML索引の作成方法
ƒ XML索引の作成方法
–
XML索引は、CREATE INDEXステートメント中にxPetternを記述して指定する。
CREATE INDEX EMPINDEX ON COMPANY(COMPANYDOCS)
GENERATE KEY USING XMLPATTERN '/company/emp/@id' AS SQL DOUBLE
COMPANY表
EMPINDEX索引
COMPANYDOC (XMLデータタイプ列）
<company name="Company1">
<emp id="31201" salary="60000" gender="Female">
<name><first>Laura </first><last>Brown</last></name>
<dept id="M25">Finance</dept>
</emp>
</company>
<company name="Company2">
<emp id="31664" salary="60000" gender="Male">
<name><first>Chris</first><last>Murphy</last></name>
<dept id="M55">Marketing</dept>
</emp>
<emp id="42366" salary="50000" gender="Female">
<name><first>Nicole</first><last>Murphy</last></name>
<dept id="K55">Sales</dept>
</emp>
</company>
1row
1row
COMPANYDOC
(DOUBLE)
31201
31664
42366
DOUBLE型の索引が作成される
© 2007 IBM Corporation
55
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
作成されたXML索引の確認
–
作成された索引はSYSCAT.INDEXESビューに登録される
–
XML INDEX1つに対して、Logical Index、Physical Indexが1エントリずつ作成される。
–
Logical Index
–
• ユーザーが作成した索引
• 論理的な索引のため、物理的には存在しない
Physical Index
•
•
•
•
Logical Indexに紐づく索引
物理的に存在する
Logical Indexが作成されると、自動的に作成される
DB2が内部的に使用する索引
select substr(indname,1,20) as indname,IID,substr(TABNAME,1,10) as TABNAME, INDEXTYPE
from syscat.INDEXES where TABNAME='COMPANY‘
INDNAME
IID
TABNAME
INDEXTYPE
-------------------- ------ ---------- ---------
56
SQL060518113414530
1 COMPANY
XRGN
←Region Index
SQL060518113414950
2 COMPANY
XPTH
←Path Index
EMPINDEX
3 COMPANY
XVIL
←XML Logical Index
SQL060518113548400
4 COMPANY
XVIP
←XML Physical Index
Table作成時に、DB2が自動
的に内部的に作成する索引
ユーザーがXML Indexを作成を
すると、それはLogical Indexとな
り、内部的にPhysical Indexが自
動的に作成される
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-④XML索引の設計 - XML索引でのデータ型の選択
– XML索引のデータ型の選択
• XML索引を作成する場合、CREATE INDEXステートメント中の
「AS SQL XXXX」キーワードで、どのSQLデータ型で索引を作成するか選択する。
CREATE INDEX EMPINDEX ON COMPANY(COMPANYDOCS)
GENERATE KEY USING XMLPATTERN '/company/emp/@id' AS SQL DOUBLE
• XML索引としてサポートされるSQLデータ型は下記の5種類
–
–
–
–
–
VARCHAR(n)
VARCHAR HASHED
DOUBLE
DATE
TIMESTAMP
– XML索引に関するデータ型全般の考慮点
•
•
•
XMLのデータ型がそのまま索引キーとなるのではなく、SQLデータ型にマップされる。
– 全ての数値型はDOUBLEデータタイプとして索引に保持される。
数値型の索引では前後の半角スペースは無視されて索引キーが生成される。文字型の索引では、半角ス
ペースは無視されない。
索引のデータタイプとXML内のデータタイプは一致させる
– 型が不一致の場合にはINSERT失敗、索引エントリが作成されない等が発生する。
© 2007 IBM Corporation
57
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML索引としてサポートされるデータ型の考慮点
–
VARCHAR(n)
•
•
–
nはXML索引の対象となる文書ノードの最大長をbyteで定義する。定義可能な最大長は索引を格納する
表スペースのページサイズによって決まる。（下記表を参照）
32Kページサイズの最大長（7985byte）以上のデータ長になる可能性がある場合VARCHAR型では索引
が作成できない。その場合VARCHAR HASHEDで作成する。
VARCHAR HASHED
•
•
XMLの索引対象となるストリングに対し、8byteのハッシュ・コードを生成する。索引対象となるストリング
の長さに制約はない
– ハッシュコードで索引キーを保持するため、範囲検索はできない。
– 異なるストリングが同じハッシュ・コードに変換される可能性があるため、ユニーク索引を作成す
る際、予期しない重複エラーが発生し得る。
末尾に半角スペースを含む場合、半角スペースを含めたストリングがハッシングされる。
– 検索条件として半角スペースを含まないリテラルを指定した場合、マッチしない。
「VARCHAR」型の索引を作成する際の、文書ノードの最大長
58
ページサイズ
文書ノードの最大長（byte）
4KB
817
8KB
1841
16KB
3889
32KB
7985
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML索引としてサポートされるデータ型の考慮点
–
DOUBLE
•
•
•
•
全ての数値型は、索引上ではSQLデータタイプのDOUBLEに変換して保持される。
大きな桁数の64bit整数値や、桁数に制約のないDecimal型では、索引キー値には精度落ちが発生する。
– 精度落ちの結果、異なる整数値が同一のdouble値にマップされる現象が発生する。
> 64bit整数値の場合、16桁程度（上限値の約1/1000）の値でも重複が発生する。
– ユニーク性を保証する必要がある場合、double型としてユニーク索引を作成すると、重複値では
なくても固有制約が発生しうる。
– そのため、ストリングとして取り扱う等の考慮が必要
バリデーションされていないXMLインスタンスでは、double値のまま比較されるため、丸め誤差により意
図する検索結果が得られない可能性がある。
– 条件指定を範囲で行う等、誤差が生じることを意識したアプリケーション・ロジックが必要。
バリデーション済みのXMLインスタンスでは、DB2はXML索引スキャンでXML本体の取得した後に再度
データの比較を行うため、スキーマ上で定義されたデータ型で比較される。
– イコールでの比較等、大きな桁数の数字を正確に取り扱う必要がある場合は、longやDecimal等
の誤差が生じないデータ型をXMLスキーマで定義し、XMLインスタンスのバリデーションを行う。
© 2007 IBM Corporation
59
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
ƒ
ƒ
60
ＤＢ２ Ｖ9.5でXML索引に無効な値を挿入しようとしたときの挙動
–
索引のターゲットデータ型へキャスト時に、エラーが発生しても無視する（デフォルト）
• CREATE INDEXステートメントに「IGNORE INVALID VALUES」キーワードを付加
• V9.1と同様の動き
–
索引のターゲットデータ型へキャスト時に、エラーが発生したらレコードを拒否する
• CREATE INDEXステートメントに「REJECT INVALID VALUES」キーワードを付加
• V9.5で新たに選択可能となった
• 索引の新規作成時に、違反するデータがあった場合CREATE INDEX失敗（SQLSTATE 23526）
–
ただし、索引のデータ型へキャスト可能な値でかつ、無効な値の場合はオプションによらず拒否する。（V9.1と同様）
• CHAR(10）の索引に対して、10byteを超える文字列をINSERTする場合等
ＤＢ２ V9.1では、XML索引への無効な値の挿入を防止できなかった
–
例 DOUBLE型の索引に、「AA00315」を挿入する。
–
無効な値の場合、索引エントリは作成されない。
索引メンテナンスに関連する挿入/更新エラーのパターン
–
索引定義より長いデータ
• CHAR(10)型で定義された索引に、10文字を超える文字列をINSERT。SQL20305N(RC=1)
–
DB2の許容仕様を超えるデータ
• DOUBLE型で定義された索引に、30桁を超える数字の列をINSERT。SQL20305N(RC=4)
–
フォーマット不正等によるキャストエラー
• 英字を含む数字列（double型の索引）
– DOUBLE型で定義された索引に、「123A678」をINSERT。SQL20305N(RC=5)
• 正しくない日付フォーマット（date/time/timestamp）
– DATE型で定義された索引に、「2007:11:09」をINSERT。SQL20305N(RC=5)
– DATE型で定義された索引に、「2007-11-31」をINSERT。SQL20305N(RC=5)
IGNORE INVALID VALUES/REJECT INVALID
VALUESキーワードで動作を制御できるケース。
（最初の2ケースは、必ずREJECTされる）
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-④XML索引の設計 - XML索引に特徴的な考慮点
•XML索引スキャンが使用される基本ルール
①索引が示す範囲が、クエリーが示す範囲より広い
②索引のデータタイプと、クエリーのデータタイプが一致している
③索引とクエリーで使用される/text()に、一貫性がある
但し、オプティマイザーにより索引が使用されない場合もある
© 2007 IBM Corporation
61
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
62
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
索引が示す範囲が、クエリーが示す範囲より広い
CUSTOMER
INFO
<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
(XML)
*
– “phone”に対して索引を作成する
– 索引候補
その１
create index idx1 on customer(info) generate key using
xmlpattern '/customerinfo/phone' as sql varchar(40);
その２
create index idx2 on customer(info) generate key using
xmlpattern '//phone' as sql varchar(40);
その３
create index idx3 on customer(info) generate key using
xmlpattern '/customerinfo/*' as sql varchar(40);
© 2007 IBM Corporation
63
ビジネス・ユニットの名前
IBM Information Management software
索引が示す範囲が、クエリーが示す範囲より広い
<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
索引定義→
↓クエリー
索引を使う
索引を使わない
…using xmlpattern
'/customerinfo/phone‘
…using xmlpattern
'//phone‘
…using xmlpattern
'/customerinfo/*‘
as sql varchar(40);
as sql varchar(40);
as sql varchar(40);
where $i//phone
= “905-555-4789”
where $i/customerinfo/phone
= “905-555-4789”
where $i/customerinfo/*
= “905-555-4789”
64
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
索引のデータタイプと、クエリーのデータタイプが一致している
<customerinfo cid=“1004”>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
索引定義→
↓クエリー
…using xmlpattern
'/customerinfo/@cid' as sql
varchar(10);
索引を使う
索引を使わない
…using xmlpattern
'/customerinfo/@cid' as sql
double;
for $i in db2-fn:sqlquery(…) where
$i/customerinfo/@cid = “1004”…
for $i in db2-fn:sqlquery(…) where
$i/customerinfo/@cid = 1004 …
© 2007 IBM Corporation
65
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
66
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
索引とクエリーで使用される/text()に、一貫性がある
for $i in db2-fn:sqlquery(…)/customerinfo where $i/phone = “905-555-4789”
return $i/name
<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
<name>Matt Foreman</name>
結果が異なる
結果が異なる
customerinfo
要素ノード
name
テキスト・ノード
phone
Matt Foreman
Matt Foreman 905-555-4789
for $i in db2-fn:sqlquery(…)/customerinfo where $i/phone = “905-555-4789”…
return $i/name/text()
© 2007 IBM Corporation
67
ビジネス・ユニットの名前
IBM Information Management software
索引とクエリーで使用される/text()に、一貫性がある
<customerinfo>
<name>Matt Foreman</name>
<phone>905-555-4789</phone>
</customerinfo>
索引を使う
索引定義→
↓クエリー
customerinfo
要素ノード
name
phone
テキスト・ノード
Matt Foreman 905-555-4789
索引を使わない
…using xmlpattern
'/customerinfo/name‘
…using xmlpattern
'/customerinfo/name/text()‘
as sql varchar(35);
as sql varchar(35);
where $i/customerinfo/name
= “Matt Foreman”
where
$i/customerinfo/name/text()
= “Matt Foreman”
68
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
A-④XML索引の設計 - XML索引に特徴的な考慮点
– 索引を作成する場合の考慮点
•
•
•
•
アプリケーションからのアクセスを考慮して、適切な型の索引を選定する
– 同じxPatternに対して、異なるSQLデータ型にマップした複数の索引を作成可能。
– たとえばクエリーで「 a/b [ c = 44] 」とする場合、数値型の索引が必要。文字列の
索引は有効ではない
要件を満たす範囲で、索引エントリ数はなるべく少なくなるよう考慮する。
– 「//name」よりも「/customerinfo/name」
非効率的なI/Oや、更新性能の低下を避けるため、該当要素が多すぎる索引は避ける
– 「//text()」、「//*」等
複合索引は作成できない
– 「リレーショナル列＋XMLエントリ」及び、「XMLエントリ＋XMLエントリ」のどちらも
作成できない。
– NSEの考慮
•
•
XMLインスタンス内の全文検索が必要な場合、Net Search Extender（NSE）の使用を検
討する。
NSEはDB2に付属する全文検索エンジンであり、属性検索、ファジー検索、Boolean検索、
Stemming、など多様な検索が可能
© 2007 IBM Corporation
69
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
索引エントリ数が増えすぎるxPatternの例
create index idx4 on customer(info)
generate key using
xmlpattern '//text()'
as sql varchar(40);
ƒ
NSEの参考資料
–
XML full-test search in DB2 [3-3]
–
• http://www-128.ibm.com/developerworks/db2/library/techarticle/dm-0606seubert/?ca=dnw-724
DB2 Net Search Extender V8の使用 [3-4]
•
70
<customerinfo Cid="1004">
<name>Matt Foreman</name>
<addr country="Canada">
<street>1596 Baseline</street>
<city>Toronto</city>
<state>Ontario</state>
<pcode>M3Z-5H9</pcode>
</addr>
<phone type="work">905-555-4789</phone>
<phone type="home">416-555-3376</phone>
<assistant>
<name>Peter Smith</name>
<phone type="home">416-555-3426</phone>
</assistant>
</customerinfo>
http://www-06.ibm.com/jp/domino01/mkt/dminfo.nsf/doc/0016B3B6
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
B-①XMLスキーマの作成
ƒ XMLスキーマの作成
– 「A. 論理モデルから物理モデルへの展開」の検討結果を反映してデータ
ベーススキーマを作成
• リレーショナル表定義、索引定義(DDL)作成
• XMLスキーマ(.xsd)の作成
© 2007 IBM Corporation
71
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
72
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-①データ容量の見積もり - XML列を含む表の容量見積もり
ƒ XML列（データ）の容量について
–
XML列に格納されると、テキスト時より多くの容量が必要
–
日本語を含むデータの場合、元ファイルの文字コードにより膨張率が変化
–
格納後のXMLサイズは、タグ長には無関係
ƒ どのようにして本番データ量を見積もるか
–
少量データを試験的にDB2に投入し、そのデータ量から見積もる
–
ページサイズによっても格納効率が変化するため、少量データの試験から1ページ
あたりに格納できるXMLインスタンス数を見積もる
–
XML列を含む場合のレコード長には、XML descriptorの長さ（84byte）も考慮に入れ
て算出
ƒ DB2に格納したXMLデータの容量確認方法
–
SYSIBMADM.ADMINTABINFO 管理ビュー
–
db2pd -tablespaces コマンド
–
db2 inspect コマンド
© 2007 IBM Corporation
73
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML列（データ）の容量について
– XMLデータがXML列に挿入されると、DB2がツリー上に展開して格納するために、テキスト時より多くの容量が必要と
なります。
• 膨張率はデータの構造により影響を受けるため、見積もるのが困難です。
– 日本語を含むデータの場合、XMLファイルがUTF-8かSJISかといった文字コードの種別により膨張率が変化します。
• DB2内部ではXMLデータはUTF-8で保持されます。UTF-8では1文字を1～6バイトで表現するため、同じ長さの文
字列を表すためのデータ量がSJISの場合よりも大きくなります。
• XMLファイルがUTF-8の場合、DB2に格納しても文字コードの違いによる膨張は発生しません。（つまり、膨張率
が低くなる）
• XMLファイルがSJISであった場合、DB2に格納するためUTF-8に変換するので、元のファイルサイズよりも膨張し
ます。（つまり、膨張率が高くなる）
• 投入元ファイルの文字コードによらず、DB2に格納された後のサイズは同じです。（必ずUTF-8になるため）
– XMLのタグ部分は、DB2が内部的に数値に置き換えるため、格納後のサイズは、タグ長には無関係となります。
• XMLファイルのサイズが、長いタグ名を多く持つために大きくなっている場合、XMLファイルの膨張率は低くなる可
能性があります。
– リレーショナル部分のレコード長の算出の際、各XML列にはXML descriptorとして84bytesを含めます。
• inline格納を行う場合は、XML descriptorは使用されません。
– 次のページから、容量を確認する方法を見ていきます。
– Sample DBのPRODUCT表と同定義の表について、リレーショナル、索引、XMLの各表スペースを分けて定義した例
です。
– 例で使用したデータの概要は解説の最後に掲載しています。
74
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
ƒ
DB2に格納したXMLデータの容量確認方法
–
管理ビュー「SYSIBMADM.ADMINTABINFO」
• 表の各データ・オブジェクト（データ、索引、LOB、LONG、XML）ごとにキロバイト単位での容量が取得可能です。
常に最新の情報が取得可能です。（Runstats不要）
• 各オブジェクトが同一表スペースでも、使用量を別々に取得可能です。
• データはエクステント単位で増加するため、1XMLインスタンスあたりに占める容量を直接取得することは出来ませ
ん。1エクステント分増加するまでINSERTを行い、1エクステントあたりに格納可能な文書数から逆算する必要があ
ります。
SampleDBのPRODUCT表と同定義の表の0件時の出力
SELECT SUBSTR(TABNAME,1,15),DATA_OBJECT_P_SIZE,INDEX_OBJECT_P_SIZE,XML_OBJECT_P_SIZE FROM SYSIBMADM.ADMINTABINFO
WHERE TABNAME ='PRODUCT2'
1
DATA_OBJECT_P_SIZE
INDEX_OBJECT_P_SIZE XML_OBJECT_P_SIZE
--------------- -------------------- -------------------- -------------------PRODUCT2
256
256
256
1 レコードが選択されました。
SampleDBのPRODUCT表DESCRIPTION列のXMLデータを10000行挿入後
SELECT SUBSTR(TABNAME,1,15),DATA_OBJECT_P_SIZE,INDEX_OBJECT_P_SIZE,XML_OBJECT_P_SIZE FROM SYSIBMADM.ADMINTABINFO
WHERE TABNAME ='PRODUCT2'
1
DATA_OBJECT_P_SIZE
INDEX_OBJECT_P_SIZE XML_OBJECT_P_SIZE
--------------- -------------------- -------------------- -------------------PRODUCT2
2048
2176
6144
1 レコードが選択されました。
© 2007 IBM Corporation
75
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
–
db2pdコマンド
•
•
db2pd -tablespaces -db <DB名>で表スペースの使用ページ数を取得可能です。
データ、索引、XMLの表スペースを分けている場合は、それぞれの使用量が確認できます。
SampleDBのPRODUCT表DESCRIPTION列のXMLデータを10000行挿入後（抜粋）
$ db2pd -tablespaces -db sample
Database Partition 0 -- Database SAMPLE -- Active -- Up 0 days 00:53:42
Tablespace Configuration:
Address
Id
Type
0x0780000020A7F940 0
DMS
0x0780000020F01AC0 1
SMS
0x0780000020F06320 2
DMS
0x0780000020F06B80 3
DMS
0x0780000020F073E0 4
DMS
0x078000002100A2A0 5
DMS
0x0780000021049DA0 6
DMS
0x0780000021045BA0 7
DMS
Tablespace Statistics:
Address
Id
0x0780000020A7F940 0
0x0780000020F01AC0 1
0x0780000020F06320 2
0x0780000020F06B80 3
0x0780000020F073E0 4
0x078000002100A2A0 5
0x0780000021049DA0 6
0x0780000021045BA0 7
76
Content
Regular
SysTmp
Large
Large
Large
Large
Large
Large
TotalPgs
16384
1
8192
8192
8192
8192
8192
8192
PageSz
4096
4096
4096
4096
4096
4096
4096
4096
ExtentSz
4
32
32
32
32
32
32
32
UsablePgs
16380
1
8160
8160
8160
8160
8160
8160
Auto
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
UsedPgs
10688
1
1888
608
1504
608
1632
640
Prefetch
24
192
192
192
192
192
192
192
BufID
1
1
1
1
1
2
2
2
PndFreePgs
0
0
0
0
0
0
0
0
BufIDDisk
1
1
1
1
1
2
2
2
FreePgs
5692
0
6272
7552
6656
7552
6528
7872
FSC
On
On
On
On
On
On
On
On
HWM
10688
0
1888
608
1504
608
1632
288
NumCntrs
1
1
1
1
1
1
1
1
MaxStripe
0
0
0
0
0
0
0
0
State
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
0x00000000
LastConsecPg
3
31
31
31
31
31
31
31
MinRecTime
0
0
0
0
0
0
0
0
Name
SYSCATSPACE
TEMPSPACE1
USERSPACE1
IBMDB2SAMPLEREL
IBMDB2SAMPLEXML
TS01
TS01LONG
TS01IND
NQuiescers
0
0
0
0
0
0
0
0
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
– db2 inspectコマンド
• db2 inspectコマンドにより、各オブジェクトの使用量を取得することが可能です。
• 各オブジェクトが同一表スペースでも、使用量を別々に取得可能です。
• 下記コマンドでインスタンス・ホームディレクトリのdb2dumpディレクトリに出力されます。
– db2 inspect check table name <表名> schema <スキーマ名> results keep <出力ファイル名>
• 下記コマンドで上記の出力をテキスト・ファイルにフォーマットします。
– db2inspf <上記の出力ファイル名> <フォーマット後ファイル名>
SampleDBのPRODUCT表DESCRIPTION列のXMLデータを10000行挿入後（抜粋）
表フェーズが開始しました。(ID 符号付き: 4、符号なし: 4; 表スペース ID: 5) : DB2INST1.PRODUCT2。
データ・フェーズが開始しました。 オブジェクト: 4、表スペース: 5。
この表の索引タイプは 2 です。
エクステント・マップの全探索 DAT、アンカー 96。
エクステント・マップの全探索が完了しました。
DAT オブジェクト・サマリー: 合計ページ数 477 - 使用済みページ数 477 - フリー・スペース 3 %。
データ・フェーズが終了しました。
索引フェーズが開始しました。 オブジェクト: 4、表スペース: 7。
エクステント・マップの全探索 INX、アンカー 96。
エクステント・マップの全探索が完了しました。
INX オブジェクト・サマリー: 合計ページ数 487 - 使用済みページ数 487。
索引フェーズが終了しました。
XML/XDA フェーズが開始しました。オブジェクト: 4、表スペース: 6。
エクステント・マップの全探索 XDA、アンカー 96。
エクステント・マップの全探索が完了しました。
XDA オブジェクト・サマリー: 合計ページ数 1504 - 使用済みページ数 1504 - フリー・スペース 5 %。
XML/XDA フェーズが終了しました。
表フェーズが終了しました。
© 2007 IBM Corporation
77
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
ƒ 今回の例で使用したデータの概要です。
- SYSIBMADM.ADMINTABINFO
- db2pd -tablespaces -db sample
- db2 inspect
XMLデータ
XMLデータ
XMLデータ
SAMPLEデータベースのProduct表
のDescription列の文書と同じ構造
（1文書はファイルで約268バイト）
実行環境
AIX5.3
DB2 V9.1 FixPak2
78
Product2表
10000件挿入
--表スペース
create tablespace ts01 bufferpool bp01;
create tablespace ts01long bufferpool bp01;
create tablespace ts01ind bufferpool bp01;
--表
create table product2 like product in ts01 long in ts01long index in ts01ind;
--XML索引
create index product_desc_xind3 on product2(description) generate key using
xmlpattern 'declare default element namespace "http://posample.org";
/product/@pid' as sql double;
create index product_desc_xind1 on product2(description) generate key using
xmlpattern 'declare default element namespace "http://posample.org";
/product/description/name' as sql varchar(128);
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-①データ容量の見積もり - XML列を含む表の容量見積もり
ƒ XML列（索引）の容量
–
XML索引の容量見積もり
–
DB2が内部的に作成するRegions Index、Paths Index
ƒ 再編成時に必要な容量
–
一時表スペースを利用する場合
–
通常表スペースを利用する場合
© 2007 IBM Corporation
79
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XML列（索引）の容量について
– XML索引
索引を付与する要素の構造や、XML索引のオーバーヘッドのために、リレーショナル索引と比較して多少大きくなりま
す。
• 一文書内に繰り返し出現する要素に対して索引を付与した場合は、1行のデータに対して複数の索引エントリが作成さ
れます。
• XMLデータ容量と同様に、少量データの試験により見積もります。
– XML索引の他に、XMLデータがどのページに格納しているかを管理するRegions Indexと、XMLデータのパスを保持する
Paths Indexが索引表スペースに格納されます。
•
•
ƒ
これらは管理用のデータであり、大きな容量を占めることはありません。
（SampleDBのPRODUCT表のDESCRIPTION列のXMLデータ10000件挿入に対して500KB程度）
再編成時に必要となる容量
– XMLデータを再編成する際に、リレーショナル・データと同様に一時表スペースを使用することが可能です。
– 指定しない場合、表の存在する通常表スペースの領域が使用されます。
– リレーショナルと同様、XMLデータの容量の2から3倍を見積もる必要があります。
80
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-①データ容量の見積もり - XML列を含む表のページ・サイズ選択
ƒ XMLデータもリレーショナル・データと同様にページに格納される
ƒ XMLを格納する表スペースはリレーショナル列と分割が可能
ƒ ページサイズ選択にあたって、Inline格納を使用するかどうかを決定する
–
Inline格納を使用する場合、最適なページサイズは大きくなる傾向にある
–
• XMLインスタンスがリレーショナル・データと同じデータ・ページに格納されるため。
Inline格納を使用しない場合、最適なページ・サイズが異なるため分割が推奨
• DB2ではページサイズとして、4KB、8KB、16KB、32KBの4種類が表スペースごと
に選択可能。
ƒ リレーショナルデータとXMLデータを分割した場合
–
リレーショナル列については、従来と同様にレコード長を見積り、ページ・サイズを決定
–
XML列については、充填率を考慮してページ・サイズを決定
© 2007 IBM Corporation
81
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XMLデータを格納するページサイズの決定に当たって最初に検討すべき事は、Inline格納を使用するかどうかです。
–
–
ƒ
XMLデータをInline格納するケース
–
ƒ
Inline格納を使用する場合は、inlineキーワードを付加したXML列のデータはリレーショナルデータと同じデータページに格納され
るため、最適なページサイズは大きくなる傾向にあります。
Inline格納を使用しない場合は、XML列のデータはリレーショナルデータとは分離されたXDAへ格納されるため、リレーショナル
データとXDAそれぞれで最適なページサイズを決定する必要があります。
このケースでは、リレーショナルデータのデータ長にXMLインスタンスの長さを加えた値が実際のレコード長となります。また、
Inline格納の最大長（inline length）を超えるXMLインスタンスは、たとえInline格納を有効にしたXML列であってもXDAへ格納さ
れます。そのため、この場合のレコード長は「Inline格納の最大長を下回るXMLインスタンスの平均値」をリレーショナルデータの
データ長に加えて算出します。
XMLデータをInline格納しないケース
–
この場合、リレーショナル列とXML列は大きさが異なるため、XMLインスタンスを格納する表スペースはリレーショナル列と分割す
ることが推奨されます。
–
XMLインスタンスは一般的にサイズが大きくなるため、リレーショナル列とXMLインスタンスを同じページサイズに格納した場合、
どちらかが最適でなくなる可能性があります。
XMLインスタンスのregion分割をなるべく押さえるため、XMLインスタンス用のページサイズは大きめにします。
–
•
•
ƒ
分割した場合、リレーショナル列については、従来と同様にレコード長を見積り、ページ・サイズを決定します。
– リレーショナル列の列長に、XML descriptorの長さも考慮に入れてレコード長を算出します。
–
ƒ
• 1XML列あたりのdescriptorのサイズは84バイト
• 特に表の構造として前述の「パターン3（XML列を横持ち）」を取るケースでは、レコード長への影響が大きくなるため注意
レコード長を元にページサイズを決定します。
XML列は、充填率を考慮してページ・サイズを決定します。
–
82
ただし、必ず32KBページサイズを採用すべきと言うわけではありません。
たとえば、ランダムなアクセスが多い場合、「平均1KBのXMLインスタンスを32KBページに格納」はお勧めできません。
– 一文書取得のために大きなページを取得しなければならないため、I/O負荷が高くなる可能性があります。
格納後のXMLデータ容量を元にページサイズを決定します。小さなページを使用すると、XMLデータが複数リージョンにまたがる
可能性があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-①データ容量の見積もり - XML列更新によるログ量
ƒ 更新によるログ量について
–
XML列は部分更新でも全入れ替えとなるため、ログ容量の考慮が必要
• ログ容量を明確に見積もる方法はない
• varcharの更新よりも使用ログ量は多くなる傾向
• 更新時でも挿入時と少なくとも同等のログ容量が必要
© 2007 IBM Corporation
83
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
84
更新によるログ量について
–
現在のバージョンのDB2では、XMLインスタンスの更新は文書の入れ替えとなるために、多くのログが必要とな
ります。
–
varcharに文字として挿入されたXMLインスタンスを更新するのと比較して、多くのログ容量が必要となる傾向が
あります。
–
XMLインスタンスの構造によりログ量は変化するため、一概にファイルサイズから見積もるのは困難です。
–
更新時に必要なログ量も見積もり、更新の割合を考慮する必要があります。
–
実際にデータを更新し、ログ量を測定して見積もる必要があります。
–
DB2 V9.5からTransform式によるXMLインスタンスの一部更新が可能となっていますが、この場合でも更新のロ
グ量は変わりません。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-②インスタンスの構成とDBの分割
ƒ 文字コードの制約（Unicodeで保持できないデータの管理）
–
DB2 V9.1でのpureXML機能では、XMLデータ型を格納するデータベースは
Unicodeデータベースにする必要がある。
–
DB2 V9.5ではその制約は緩和され、非UnicodeデータベースでもXMLデータ
型を格納可能となった。
• ただし、XMLデータ自身は依然としてUnicodeで保持される。
• 非Unicodeデータとの連携時に頻繁な文字コード変換が発生しうる。
–
データ容量や他システムとの連携上、Unicodeで保持できないデータが存在す
る場合、BLOB型として保持したり、XMLインスタンスを保持するデータベースと、
それ以外のデータを保持するデータベースを分割することを検討する。
•
•
二つのデータベース間を透過的にアクセスする場合、DB2の提供するFederation機
能を使用する。
Federation機能を使用するため別フィーチャーであるHFF（Homogeneous
Federation Feature）を別途購入する必要あり。
© 2007 IBM Corporation
85
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
ƒ
86
DB2 V9.1ではXMLデータ型を保持するデータベースはUnicodeデータベースである必要がありましたが、DB2 V9.5では
非UnicodeデータベースでもXMLデータ型が保持できるようになりました。
–
ただし、非UnicodeデータベースでもXMLデータそのものはUnicodeで保持されます。
–
そのため、データベースに接続するクライアントのコードページがUnicodeである場合、クライアントとデータベー
ス間でUnicodeから非Unicodeへの変換が行われ、データベース内部でXMLへの変換時に非Unicodeから
Unicodeへの変換が行われると言った、不要な文字コード変換が発生する可能性があります。
–
このような不要なコード変換を避けるため、XMLデータをBLOB型として取り扱う等の考慮が必要です。BLOB型
として取り扱う場合、文字コード変換は行われません。
DB2 V9.1を使用するケースで、データ容量や他システムとの連携上、Unicodeで保持できないデータが存在する場合は、
XMLインスタンスを保持するデータベースと、それ以外のデータを保持するデータベースを分割することを検討します。
–
2つのデータベース間を透過的にアクセスする場合、DB2の提供するFederation機能を使用できます。
–
Federation機能を使用するため別フィーチャーであるHFF（Homogeneous Federation Feature）を別途購入す
る必要があります。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-③表の分類と表スペースの構成
ƒ リレーショナル・データと同様、XMLインスタンスも表スペースに格納される
ƒ 表スペースの設計方針（XMLデータの割り当てを検討）
– XMLインスタンスを格納する表スペースの選択
• リレーショナル・データと別の表スペースを使用
• リレーショナル・データと同様の表スペースを使用
– XML索引、リレーショナル索引は共通
– 一時表スペース
ƒ バッファープール
– XMLインスタンスのI/Oにはバッファープールが使用される
– バッファープール定義の選択
• XMLインスタンスのためのバッファープールをリレーショナルと分
割
• 同一のバッファープールを使用
© 2007 IBM Corporation
87
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
リレーショナル・データと同様、XMLインスタンスも表スペースに格納されます。
–
ツリー構造に変換され、DB2のページに格納されます。
–
複数ページにまたがるXMLインスタンスは、Region Indexにより管理されます。
ƒ
表スペースの設計方針として、XMLデータ（XML Data：XDA）の表スペースへの割り当てを検討します。
–
XMLインスタンスを格納する表スペースの選択
• リレーショナル・データと別の表スペースを使用
– CREATE TABLE時にLONG INオプションで指定することで、XMLインスタンスを別の表スペースに格納
することができます。
– この場合、バッファープール、ページ・サイズをXMLインスタンスとリレーショナル・データで分けることが可
能となります。
• リレーショナル・データと同様の表スペースを使用
– LONG INオプションを使用しない場合、INで指定された表スペースにXMLインスタンスも格納されます。
– この場合、表スペース、バッファープールの数が少なくなり、管理の負担を減少させることが可能となります。
–
XML索引、リレーショナル索引は共通
• 索引については、INDEX INで指定した場合、同じ表スペースが使用されます。
–
一時表スペース
• XML列を含む表の再編成を、一時表スペースを用いて行う場合、必要量に応じたサイズを確保する必要がありま
す。
88
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
解説（続き）
ƒ
バッファープール
–
XMLインスタンスではバッファープールが使用されます。
• XMLインスタンスでも、リレーショナル・データと同様にバッファープールが使用されます。
• XMLインスタンスの読み込みでは、XSCANにより論理読み込みの値が大きくなる傾向があるので、リレーショナル
と比較してバッファープール・ヒット率が大きめになる可能性があります。
• 複数ページに格納されているXMLインスタンスの一部分を出力する場合でも、文書全体がバッファープールに格納
されます
–
バッファープール定義の選択
• XMLインスタンスのためのバッファープールをリレーショナルと分割
– 表スペース定義を分けることにより、バッファープールを分割することが可能となります。
– この場合、バッファープール使用状況のモニタリングが容易になります。
– ページ・サイズによる分割が可能となります。（リレーショナルは4K、XMLインスタンス32Kなど）
• 同一のバッファープールを使用
– XMLインスタンス/リレーショナル・データを格納する表スペースのページ・サイズを共通にする必要があり
ます。
– XMLインスタンス/リレーショナル・データ個別のバッファープール使用量見積が不要となり、管理が容易に
なります。
© 2007 IBM Corporation
89
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
90
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-④表スペースの配置
ƒ XMLインスタンスを格納する表スペースの物理配置
– 物理ディスクへの配置
ƒ 再編成の考慮
– XMLインスタンスを含む表スペースを再編成の対象とするかどうかを
まず決定
• パフォーマンス劣化度合い、フリースペースの調査
– LONGLOBDATAオプションの使用
– 一時表スペースの指定
– オンライン再編成の未サポート
© 2007 IBM Corporation
91
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
XMLインスタンスを格納する表スペースの物理配置
–
ƒ
リレーショナルと同様、ページ単位でアクセスされるため、DISK I/Oを分散させるために複数の物理ディス
クに配置します。
再編成の考慮
–
XMLインスタンスを含む表スペースを再編成の対象とするかどうかをまず決定します。
–
単一のXMLインスタンスがディスク上の分散したページに格納された場合、パフォーマンスが劣化
する可能性があります。
• db2 inspectコマンドを利用して、フリースペースなど実際に使用されているXDA領域を調査可能で
す。
再編成を行う場合、以下のような点を考慮します。
•
•
•
•
92
再編制上の取り扱いはLONG/LOBと同様にLONGLOBDATAオプションを使用します。
再編成に使用する領域として、一時表スペースを指定できます。
オンライン再編成はサポートされていません。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-⑤表スペース以外のオブジェクトの配置
ƒ ログの配置
– XMLインスタンスの更新を見込んだログ容量を確保する
ƒ ワーク/バックアップ領域の配置
– XMLインスタンスもバックアップ・イメージに含まれる
– COMPRESSオプションが有効
ƒ 全文検索（NSE : Net Search Extender ）オブジェクトの配置
© 2007 IBM Corporation
93
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
ログの配置
–
大きなXMLインスタンスの更新が頻繁に発生する場合、ログ領域へのI/O負荷が高くなる可能性があります。
–
使用されるログ量については、XML構造等に依存するため、実際に測定して見積もる必要があります。
•
ƒ
DBスナップショットの「データベースで使用されたログ・スペース（バイト）」やdb2pd -logsコマンドで確
認できます。
ワーク/バックアップ領域の配置
–
XDA（XML Data Area）もバックアップ・イメージに含まれる
•
–
XMLインスタンスが含まれるXDAについても、リレーショナル・データと同様にバックアップ・イメージに
含まれます。
COMPRESSオプションが有効
•
ƒ
全文検索（NSE : Net Search Extender）オブジェクトの配置
–
94
XDAを含んだバックアップ・イメージについても、COMPRESSオプションを指定することで圧縮すること
が可能となります。
XMLインスタンスに対する全文検索使用時はNSEを利用します。
–
DB2の導入とは別に、NSEの導入、設定が必要となります。
–
索引のオブジェクト配置や運用については、通常のNSE使用時と同様に行います。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-⑥構成パラメータの設定
ƒ コードページの考慮
– UNICODE DBの使用
ƒ XML処理に特有のヒープ消費を考慮
– XML処理に使用されるヒープの初期サイズを大きくする
•
•
•
•
STMTHEAP
PCKCACHESZ
APPLHEAPSZ
STAT_HEAP_SZ
ƒ pureXMLに特有のパラメータ
– RUNSTATS時のDB2_XML_RUNSTATS_PATHID_K、
DB2_XML_RUNSTATS_PATHVALUE_Kレジストリー変数
© 2007 IBM Corporation
95
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
コードページの考慮
–
ƒ
V9.1ではpureXMLはUNICODE DBでのみサポートされます。
XML処理に特有のヒープ消費を考慮
–
以下に挙げる、XML処理に使用されるヒープについては、初期サイズを大きくすることを検討します。
•
•
•
•
ƒ
pureXMLに特有のパラメータ
–
RUNSTATS時のDB2_XML_RUNSTATS_PATHID_K、DB2_XML_RUNSTATS_PATHVALUE_Kレジ
ストリー変数
•
•
•
96
コンパイル時のSTMTHEAP増加
PCKCACHESZの圧迫(Automatic可能)
Insert時のXMLパースに伴うAPPLHEAPSZ増加
RUNSTATS時（サンプリング）のSTAT_HEAP_SZ増加
これらのレジストリー変数により、RUNSTATSで取得するXMLインスタンスのPath-CountとPathValueの最大値を設定することが可能となります。
階層の多いXMLインスタンスを使用する場合に、より詳細な統計情報の取得が可能となります。
Path-Count、Path-Valueの実際の値については、db2catで確認が可能です。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
参考：XMLに関連する統計情報
ƒ RUNSTATSによる統計情報の収集
–
XML関連の統計情報も、通常と同様RUNSTATSを使用して収集する。
•
•
–
収集される統計情報
•
•
•
–
デフォルトで、XML列の統計情報も収集される
XML列の統計情報収集を除外する場合、「EXCLUDING XML COLUMNS」を指定
Path-Count（doc count及び、node count）
Path-Value
収集するPath、Path-Valueの上限は、レジストリ変数によって指定可能（デフォルト200）
– DB2_XML_RUNSTATS_PATHID_K
– DB2_XML_RUNSTATS_PATHVALUE_K
SYSIBM.SYSTABLESの記述子（PACED DESCRIPTOR）に保存される
ƒ db2catによる統計情報の分析
–
システムカタログ表に格納されている記述子の内容を分析するツール。
–
db2lookの「-m」オプションでは、格納されているXMLインスタンスに関する詳細な情報は取得で
きない。
•
そのため、db2catを使用して取得する。
© 2007 IBM Corporation
97
ビジネス・ユニットの名前
IBM Information Management software
解説 db2catの実行例
$ db2cat -t -d SAMPLE -s TEST -n PRODUCT2
DB2 Universal Database Version 9.1, 5622-044 (c) Copyright IBM Corp.
Licensed Material - Program Property of IBM
IBM DATABASE 2 Catalog Analysis and Repair Tool
Please use single quote for delimited name
*****************************************************************
Table: TEST
.PRODUCT2 (TABLE)
XML列
----------------------------------------------------------------「DESCRIPTION」
TABLE PACKED DESCRIPTOR:
の出力
＜省略＞
COLUMN NAME
: DESCRIPTION
Length of column name
: 11
Column id
: 6
Col type {hex, type}
: 0x0112 , XML
Col dist. type {hex, type}: 0x0090 , XML
Column length
:
80
lengthは記述子
Blob length
: 80
の長さのみ
Statistic offset
: -1
Flags
: 0x00000090
- SQLRG_MIXED
- SQLRG_NULLIND
Codepage
: 0
Length of user
default : 0
Logged
: 0
Compact
: 0
Datalink Features
: 000000
Ref. row type desc. offset: 0
No. unique values in col. : -1
Average column length
: 1
High2key and Low2key len. : 66
Types of Data Model
: 0
Delimiter length
: -1
Number of Subelements
: -1
Number of nulls
: -1
High2key
:
Low2key
:
Statistic Descriptor
: None
Security Label ID
: 0
98＜省略＞
「-d」でDB名、「-s」でスキーマ名、「-n」で表名を指定
「-t」は標準出力への出力を指定。
---------------------------------------格納されているXMLインス
Top-k Pathid node counts
タンスの、Path情報に関す
---------------------------------------る統計情報
Max no. of path counts = 11
Cur no. of path counts = 11
Cnt( /root()/product/description ) = 7277
Cnt( /root()/product/description/weight ) = 7115
Cnt( /root()/product ) = 7092
Cnt( /root()/product/description/name/text() ) = 7053
Cnt( /root()/product/description/details/text() ) = 7038
Cnt( /root()/product/description/name ) = 7030
Cnt( /root()/product/description/weight/text() ) = 7015
Cnt( /root()/product/description/price/text() ) = 6922
＜省略＞
---------------------------------------Path-Valueに関する統計
Top-k Pathid-Value node counts
情報
---------------------------------------Max no. of path-value counts = 12
Cur no. of path-value counts = 12
Cnt( /root()/product/description/weight/text(),3:7kg ) = 7112
Cnt( /root()/product/description/details/text(),28:Basic Snow Shovel, 22
inches ) = 6829
Cnt( /root()/product/description/price/text(),3:4.0 ) = 798
Cnt( /root()/product/description/price/text(),3:0.0 ) = 742
Cnt( /root()/product/description/price/text(),3:6.0 ) = 735
Cnt( /root()/product/description/price/text(),3:7.0 ) = 735
Cnt( /root()/product/description/price/text(),3:5.0 ) = 732
Cnt( /root()/product/description/price/text(),3:2.0 ) = 707
Cnt( /root()/product/description/price/text(),3:8.0 ) = 704
Cnt( /root()/product/description/price/text(),3:3.0 ) = 686
Cnt( /root()/product/description/price/text(),3:1.0 ) = 623
Cnt( /root()/product/description/price/text(),3:9.0 ) = 613
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
C-⑦シェル／コマンドの作成
ƒ 表、索引作成用DDL
ƒ XML スキーマ登録用のシェルの作成
– XSR
• XSR Objectを格納するためのRepository
– XSRオブジェクトは、以下の二つの方法で登録可能
• CLP
• ストアード・プロシージャー
© 2007 IBM Corporation
99
ビジネス・ユニットの名前
IBM Information Management software
解説
ƒ
表、索引作成のDDL
–
ƒ
XMLスキーマのXSRへの登録用シェル
–
XSR Objectを格納するためのRepository
–
• XML Schema, DTD, 外部エンティティの登録が可能です。
• XMLインスタンスをValidateするために使用されます。
• XSR Objectは、BLOBとしてシステム・カタログに格納されます。
• XMLインスタンスが挿入される前に登録しておく必要があります。
XSRオブジェクトは、以下の二つの方法でXSRに登録可能
–
100
XMLDBでは、リレーショナル表作成、リレーショナル列への索引の他、XML索引の作成も必要となります。
• CLP
• ストアード・プロシージャー
XMLスキーマのXSRへの登録方法、妥当性検査の方法などについては、「第4章 スキーマ管理」をご覧
ください。
© 2007 IBM Corporation
ビジネス・ユニットの名前
IBM Information Management software
XMLDB物理設計 付録 XML特有のチューニングTips
ƒ 文書サイズ/タグ種類
– タグ種類数はInsert性能に影響を与える。少ないほどXMLパース負荷が低
く、Insert性能が良い。
– 文書サイズは照会性能に大きな影響を与える。
– タグ種類数はRunstats性能に影響を与える。
ƒ XML索引
– XML索引の作成時間は、XMLパターンの総数（繰り返し要素の１文書内の
出現回数 x 文書の件数）に影響を受ける。
– データ更新時の索引メンテナンスは、XML索引よりリレーショナル索引の
方が負荷は軽い
– 索引の対象ノード数や索引サイズ、索引数がInsert性能に影響を持つ。
© 2007 IBM Corporation
101
ビジネス・ユニットの名前
IBM Information Management software
ブランク・ページです。
102
© 2007 IBM Corporation