Japan [変更]

目次:
	はじめに
	DB2 での XML スキーマ処理の概要
	スキーマ進化 (展開) の例
	まとめと利点
	参考文献
	著者について
	記事の評価

関連リンク
	Information Management 記事一覧
	XML 記事一覧

developerWorks Japan > Information Management | XML >

DB2 pureXML を使って XML スキーマを進化させる

互換性のガイドラインに従い、例をとおして学ぶ

ページオプション

JavaScript を要するドキュメントオプションは表示されません

原文はこちら

レベル: 中級

Khurram Faraaz (khfaraaz@in.ibm.com), Systems Software Engineer, IBM
Ronny Bartsch (rbartsc@us.ibm.com ), Software Developer, IBM
Susan Malaika (malaika@us.ibm.com), Senior Technical Staff, IBM

2008年 3月 20日

XML を使用する多くのシステムでは、時間と共に XML スキーマが進化します。この記事では、そうした変更を、大きな変更であれ小さな変更であれ DB2 の XSR (pureXML Schema Registry) 機能を使って処理するための方法を学び、またスキーマの進化 (展開) の一例を、順を追って説明します。

はじめに

DB2 pureXML は XML データ型をサポートしているため、文書が整形式である限り、さまざまな XML インスタンス文書を 1 つの列に保管することができます。保管された XML 文書は、DB2 の XSR (XML Schema Repository) に登録されている 1 つあるいは複数の XML スキーマに対して妥当性検査をすることができます。

多くのシステムでは、XML スキーマは、例えば年に 1 度か 2 度、変更されます。場合によると変更は小規模 (つまり、いくつかのオプション要素や属性が導入されるのみ) であり、データベースに保管された既存の文書は新しいスキーマに準拠していることもあります。スキーマの変更が小規模であり、「 XML スキーマの展開のための互換性要件」に準拠している場合、そうしたスキーマは互換性があるとされます。この場合、新しいスキーマは XSR の中にある古いスキーマを置き換えることができます。

場合によると、スキーマの変更は大規模なものであり、もはやデータベースの中にある既存の文書を新しいスキーマで妥当性検査することはできないかもしれません。こうした場合には、古いスキーマを置き換えることなく、新しいスキーマが XSR に追加されます。データベースに挿入される新しい文書や、データベースの中で変更される新しい文書は、妥当性検査が必要であり、新しいスキーマに対して妥当性検査が行われることになるはずです。この検査は XMLVALIDATE 関数の中で新しいスキーマを明示的に参照することで行われるか、あるいは XML インスタンスの中に含まれる、スキーマの場所を示す URI (uniform resource indentifier) の新しいスキーマを参照することで行われます。

スキーマの変更が大規模であれ小規模であれ、またスキーマに対する妥当性検査が行われるか否かによらず、どのような場合でも XML インスタンス文書は DB2 pureXML の中の同じ XML 列に保管され、同じ XML 列でアクセスできることに変わりはありません。

上に戻る

DB2 での XML スキーマ処理の概要

スキーマの登録

スキーマを登録する際には、REGISTER SCHEMA コマンドを使うことでスキーマに 2 種類の名前を付けることができます。

SQL 名、例えば TEST.customer など。この名前は通常、妥当性検査の際、アプリケーションの中で妥当性検査を行っているスキーマを厳密に制御する必要がある場合、あるいは対応する XML インスタンス文書にスキーマの場所についてのヒントが含まれていない場合に使われます。
スキーマの場所を示す URI、例えば http://www.test.com/customer など。この名前は通常、XML インスタンス文書がスキーマの場所についてのヒントによってスキーマを参照している場合に使われます。

図 1. スキーマの登録

スキーマの妥当性検査

XMLVALIDATE 関数を使うと、XSR に登録されている 1 つ以上の XML スキーマにインスタンス文書が準拠しているかどうかをチェックすることができます。スキーマの指定には SQL 名を利用するか、あるいはインスタンス文書の中に含まれる、スキーマの場所を示す URI を利用します。

スキーマの進化 (展開)

ビジネスの性質の変化を反映して XML スキーマも進化していく (変更される) ことがよくあります。これから変更しようとしているスキーマに対して、保管されている文書の妥当性検査をする場合、DB2 pureXML には新しいスキーマを登録する 2 つの方法があります。

2 つのスキーマが十分似ている (互換性がある) 場合には、新しいスキーマを XSR に登録して元々のスキーマを置き換え、それまでと同じように妥当性検査を行うことができます。互換性のある 2 つのスキーマの間で、スキーマの持つ両方の名前 (SQL 名と、スキーマの場所を示す URI) は同じまま維持されます。
2 つのスキーマに互換性がない場合、新しいスキーマを、新しい SQL 名と、新しいスキーマの場所を示す URI で登録します。

以前のスキーマから互換性のある新しいスキーマへと変更 (展開) した場合、XMLVALIDATE を使う際には、それまでと同じように既存の SQL 名を使って新しい XML スキーマを参照することができ、あるいは XML インスタンス文書の中にある、スキーマの場所を示す URI を利用することもできます (ただし既存の XML インスタンス文書と新しい XML インスタンス文書の間で URI は変化しないことが前提です)。通常、スキーマの変更が小規模の場合には、互換性のあるスキーマへの変更 (展開) が行われます。

スキーマ進化 (展開) のステップ

ここで紹介するのは、スキーマの変更が小規模な場合に、XSR に登録されている XML スキーマを進化させ (展開し)、既存のスキーマを新しい、変更されたスキーマで置き換えるステップです。

XSR_REGISTER ストアード・プロシージャーを呼び出すか、あるいは REGISTER XMLSCHEMA コマンドを実行することによって、XSR に新しい XML スキーマを登録します。もし、ステップ 2 のように既存のスキーマを新しいスキーマで置き換えるという計画であれば、どの文書も、新たに登録された XML スキーマに対して妥当性検査をするべきではないことに注意してください。
XSR_UPDATE ストアード・プロシージャーを呼び出すか、あるいは UPDATE XMLSCHEMA コマンドを実行して XSR の中の新しい XML スキーマを更新し、既存のスキーマを置き換えます。

スキーマの進化 (展開) に成功すると、元の XML スキーマが置き換えられ、更新された XML スキーマしか利用できなくなります。

XSR_UPDATE ストアード・プロシージャーや UPDATE XMLSCHEMA コマンドでオプション dropnewschema が使われている場合は、新しいスキーマは既存のスキーマの名前でしか利用することができず、その新しいスキーマを登録する際に使われた名前で利用することはできません。

図 2. スキーマの進化 (展開)
Schema evolution

DB2 での互換性ルール

先ほど説明したとおり、DB2 は古い XML スキーマを新しいスキーマで置き換えるための、XML スキーマを更新するストアード・プロシージャーとコマンドを提供しています。置き換えが成功するためには、互換性のある XML スキーマが必要です。2 つの XML スキーマに互換性がない場合には、更新は失敗し、エラー・メッセージが生成されます。

確実に互換性を持たせるには以下の条件が必要です。

属性の内容: 元の XML スキーマの複合型の内部で宣言または参照されている属性は、新しい XML スキーマでも記述されている必要があります。元の XML スキーマに必須属性がない場合は、新しい XML スキーマにも必須属性を含めることはできません。
要素の内容: 元の XML スキーマの複合型の内部で宣言または参照されている要素は、新しい XML スキーマでも記述されている必要があります。元の XML スキーマに必須要素がない場合は、新しい XML スキーマにも必須要素を含めることはできず、オプションの要素のみを追加することができます。
ファセットの競合: 新しい XML スキーマの単純型のファセット値は、元の XML スキーマに定義されている単純型の値の範囲に対応している必要があります。例えば下記の例は、
<xs:restriction base="xs:decimal" />
次のようになります。
<xs:restriction base="xs:decimal"> <xs:totalDigits value="7"/> </xs:restriction>
非互換型: すでに挿入されている XML 文書が新しい XML スキーマに対する妥当性検査に失敗した場合、または新しい XML スキーマに含まれている単純型の注釈が元の XML スキーマに含まれているものとは異なる場合、新しい XML スキーマの要素または属性の型には互換性がありません (例えば type="xs:string" と type="xs:integer" など)。
混合内容から非混合内容へ: 複合型の内容モデルが元の XML スキーマで混合内容として宣言されている場合、それを新しい XML スキーマで非混合内容と宣言することはできません (例えば mixed="true" と mixed="false" など)。
nillable から非 nillable へ: 元の XML スキーマの要素宣言で nillable 属性が有効にされている場合には、新しい XML スキーマでも nillable 属性を有効にする必要があります。
削除された要素: 元の XML スキーマで宣言されているグローバル要素は、新しい XML スキーマでも記述されている必要があり、抽象化することはできません (例えば <xs:element name="b" type="xs:string"/> と <xs:element name="b" abstract="true"/> など)。
削除された型: 元の XML スキーマのグローバル型が別の型から派生したものである場合、そのグローバル型は新しい XML スキーマでも記述されている必要があります。
単純型から複合型: 元の XML スキーマで単純内容を含む複合型は、更新された XML スキーマで複合内容を含むように再定義することはできません。
単純内容: 元の XML スキーマと新しい XML スキーマで定義されている単純型は同じ基本型を共有する必要があります。

詳細については「XML スキーマの展開のための互換性要件」を参照してください。

上に戻る

スキーマ進化 (展開) の例

この例で示す customer というスキーマは、互換性のあるスキーマ customer1 で更新され、そして次に互換性のないスキーマ customer2 で更新されます。2 番目の XSR 更新は失敗します。この例では、XML 文書を妥当性検査する際にはスキーマの SQL 名を使ってスキーマを参照し、XML インスタンス文書に含まれる、スキーマの場所を示す URI は使いません。

リスト 1. customer.xsd

                
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.test.com/customer">
<xsd:element name="customerType">
        <xsd:complexType>
                <xsd:sequence>
                        <xsd:element name="Name" type="xsd:string"/>
                        <xsd:element name="Address" type="xsd:string"/>
                        <xsd:element name="Phone" type="xsd:string"/>
                        <xsd:element name="email" type="xsd:string"/>
                </xsd:sequence>
                <xsd:attribute name="type" type="xsd:string"/>
        </xsd:complexType>
</xsd:element>
</xsd:schema>

リスト 2. customer1.xsd

                
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.test.com/customer">
<xsd:element name="customerType">
   <xsd:complexType>
        <xsd:sequence>
          <xsd:element name="Name" type="xsd:string"/>
          <xsd:element name="Address" type="xsd:string"/>
          <xsd:element name="Phone" type="xsd:string"/>
          <xsd:element name="email" type="xsd:string"/>
        </xsd:sequence>
        <xsd:attribute name="type" type="xsd:string"/>
        <xsd:attribute name="optType" type="xsd:string" use="optional"/>
   </xsd:complexType>
</xsd:element>
</xsd:schema>

リスト 3. customer2.xsd

                
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.test.com/customer">
<xsd:element name="customerType">
<xsd:complexType>
        <xsd:sequence>
                <xsd:element name="Name" type="xsd:string"/>
                <xsd:element name="Address" type="xsd:string"/>
                <xsd:element name="Phone" type="xsd:string"/>
                <xsd:element name="email" type="xsd:string"/>
        </xsd:sequence>
        <xsd:attribute name="type" type="xsd:string"/>
        <xsd:attribute name="reqType" type="xsd:string" use="required"/>
</xsd:complexType>
</xsd:element>
</xsd:schema>

ステップ 1: customer.xsd を登録する

REGISTER XMLSCHEMA http://www.test.com/customer
FROM c:\article\customer.xsd AS TEST.customer;
COMPLETE XMLSCHEMA TEST.customer;

http://www.test.com/customer がスキーマの場所を示す URI であり、TEST.customer がこのスキーマの SQL 名であることに注意してください。

ステップ 2: customer1.xsd を登録する

REGISTER XMLSCHEMA http://www.test.com/customer1
FROM c:\article\customer1.xsd AS TEST.customer1;
COMPLETE XMLSCHEMA TEST.customer1;

http://www.test.com/customer1 がスキーマの場所を示す URI であり、TEST.customer1 がこのスキーマの SQL 名であることに注意してください。

ステップ 3: customer2.xsd を登録する

REGISTER XMLSCHEMA http://www.test.com/customer2
FROM c:\article\customer2.xsd AS TEST.customer2;
COMPLETE XMLSCHEMA TEST.customer2;

http://www.test.com/customer2 がスキーマの場所を示す URI であり、TEST.customer2 がこのスキーマの SQL 名であることに注意してください。

ステップ 4: customer スキーマを、互換性のある customer1 スキーマで更新します。そのためアプリケーションは、それまでと同じように TEST.customer スキーマを参照することができます。
注意: customer1.xsd には optType というオプション属性があります。
CALL sysproc.xsr_update('TEST','CUSTOMER','TEST','CUSTOMER1',0);

ステップ 4 の結果
Return Status = 0

ステップ 5: customer スキーマを customer2 スキーマで更新します。
注意: customer2.xsd には reqType という必須属性があります。
CALL sysproc.xsr_update('TEST','CUSTOMER','TEST','CUSTOMER2',0);

ステップ 5 の結果:
返されるメッセージ: SQL20432N The original XML schema contains "customerType" that is enclosed within or referenced by "" which is not compatible with the updated XML schema. The reason for the incompatibility is: "1" ("ATTRIBUTE CONTENT"). SQLSTATE=22538 (元の XML スキーマには、"" で囲まれる、あるいは "" で参照される “customerType” が含まれていますが、これは更新された XML スキーマと互換性がありません。互換性がない理由は "1" ("ATTRIBUTE CONTENT") です。 SQLSTATE=22538

ステップ 6: 登録されているスキーマに対してインスタンス文書の妥当性検査を行います。

リスト 4. 登録されているスキーマに対して妥当性検査を行う

                    
<?xml version="1.0" encoding="UTF-8"?>
<n1:customerType type="String" 
xsi:schemaLocation="http://www.test.com/customer" 
xmlns:n1="http://www.test.com/customer" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <Name>Kestle Ferder</Name>
        <Address>Ring Road, Bangalore</Address>
        <Phone>900400558765</Phone>
        <email>m22@ibm.com</email>
</n1:customerType>

上記の XML インスタンスは、(customer.xsd を参照し、その後 customer1.xsd を参照する) TEST.customer に対する妥当性検査に成功します。

INSERT INTO T1(XMLCOL) VALUES (XMLVALIDATE (? ACCORDING TO XMLSCHEMA ID TEST.customer))

ステップ 7: 登録されているスキーマに対してインスタンス文書の妥当性検査を行います。

リスト 5. 登録されているスキーマに対して妥当性検査を行う

                    
<?xml version="1.0" encoding="UTF-8"?>
<n1:customerType type="String" optType="testschemaevol"
xsi:schemaLocation="http://www.test.com/customer1" 
xmlns:n1="http://www.test.com/customer1" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <Name>Kes Sales</Name>
        <Address>Ring Road, Bangalore</Address>
        <Phone>900400658765</Phone>
        <email>m23@ibm.com</email>
</n1:customerType>

上記の XML インスタンスは、customer1.xsd (つまり customer.xsd から customer1.xsd に進化 (展開) した後のスキーマ) を参照する TEST.customerに対する妥当性検査に成功します。

INSERT INTO T1(XMLCOL) VALUES ( XMLVALIDATE ( ? ACCORDING TO 
XMLSCHEMA ID TEST.customer) )

上に戻る

まとめと利点

DB2 pureXML のスキーマ展開機能を利用すると、妥当性検査を行う際に、その変化するスキーマを参照するアプリケーションを変更しなくてもスキーマを変更 (展開) することができます。

スキーマの変更が大規模な場合は次のとおりです。

妥当性検査の際にスキーマを表す SQL 名を使用している場合には、新しいスキーマに対して妥当性検査を行えるように、アプリケーションを少し変更して新しいスキーマ名を参照する必要があります。
妥当性検査の際に XML インスタンス文書の中の、スキーマの場所を示す URI を使用している場合には、その XML インスタンスが適切なスキーマを参照している限り、アプリケーションには何も変更が必要ありません。

どの場合にも、すでに DB2 に保管されている文書を再度妥当性検査する必要はありません。スキーマの変更が大規模であれ小規模であれ、またスキーマによる妥当性検査を行うか否かによらず、XML インスタンス文書は DB2 pureXML の中の同じ XML 列に保管され、同じ XML 列でアクセスできることは変わりません。

それだけではなく、注意して行えば、進化するスキーマに基づく XML データに対してクエリーを実行する際にアプリケーションの大幅な変更を避けることができます。

参考文献

学ぶために

DB2 インフォメーション・センターの「XML スキーマの展開のための互換性要件」セクションは互換性に関する要件を詳細に説明しています。
XML スキーマの展開の詳細については DB2 インフォメーション・センターの「XML スキーマの展開」セクションを参照してください。
「スキーマが進化するなかで XML クエリーを維持する方法」(developerWorks、2007年6月) は、XML スキーマがさまざまに変化しても適切に動作するクエリーを作成するためのガイドです。
REGISTER XMLSCHEMA コマンドの構文が DB2 インフォメーション・センターに説明されています。
UPDATE XMLSCHEMA コマンドの構文が DB2 インフォメーション・センターに説明されています。
XSR (XML Schema Repository) に関する詳細が DB2 インフォメーション・センターに説明されています。
XMLVALIDATE SQL/XML 関数に関する詳細が DB2 インフォメーション・センターに説明されています。
XSR_REGISTER プロシージャーの詳細が DB2 インフォメーション・センターに説明されています。
XSR_UPDATE プロシージャーの詳細が DB2 インフォメーション・センターに説明されています。
developerWorks の IBM DB2 Database for Linux, UNIX, and Windows リソース・ページには、豊富な記事やチュートリアルが用意されており、またこのページから DB2 のスキルを向上させるための他のリソースに行くこともできます。

製品や技術を入手するために

DB2 Enterprise 9 の無料の試用版をダウンロードしてください。
DB2 が無料で使えるようになりました。DB2 コミュニティーのための DB2 Express Edition の無料版、DB2 Express-C をダウンロードしてください。DB2 Express Edition と同じコア・データ機能を持っており、アプリケーションを構築、デプロイするための堅固なベースとなります。
IBM 製品の試用版をダウンロードし、DB2® や Lotus®、Rational®、Tivoli®、WebSphere® などが提供するアプリケーション開発ツールやミドルウェア製品をお試しください。

議論するために

ディスカッション・フォーラムに参加してください。
developerWorks blogs から developerWorks のコミュニティーに加わってください。

著者について


		Khurram Faraaz はインドのバンガロールにある、IBM の Information Management Group (IBM Software Group の一部) のシステム・ソフトウェア・エンジニアです。彼は DB2 での XML の機能検査テストに従事しています。また彼は pureXML の industry bundle (業界別サンプル) に関する業務にも従事しています。連絡先は Khurram at khfaraaz@in.ibm.com です。


		Ronny Bartsch はアメリカの Somers にある IBM の Information Management Group (IBM software Group の一部) の co-op (働きながら学ぶ) ソフトウェア開発者です。彼は XML と DB2 pureXML を使用した業界標準に関連する industry bundle (業界別サンプル) とデモに関する業務に従事しています。連絡先は rbartsc@us.ibm.com です。


		Susan Malaika は IBM の Information Management Group で働いています。彼女の専門はグリッド・コンピューティングを含む XML と Web 技術です。彼女は Web に関する何本かの記事を発表しており、また共著の本もあります。彼女は IBM Academy of Technology のメンバーです。連絡先は malaika@us.ibm.com です。

記事の評価

この記事を共有する

はてなブックマーク	livedoorクリップ	del.icio.us	Buzzurl（バザール）	Choix！


Saafブックマーク	FC2ブックマーク	MM/memo	ニフティクリップ	Yahoo!ブックマーク

CZブックマーク	newsing

上に戻る

日本IBMについて

プライバシー

お問い合わせ