Japan [変更]

ホーム

製品

サービス & ソリューション

サポート & ダウンロード

マイアカウント

developerWorks Japan > Information Management >

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

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

ページオプション

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

レベル: 中級

Khurram Faraaz, Information Management Group システム・ソフトウェア・エンジニア, IBM
Ronny Bartsch, Information Management co-op ソフトウェア開発者, IBM
Susan Malaika, XML 技術者,Web技術者,グリッド・コンピューティング,IBM Academy of Technology, IBM

2008年 03月 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スキーマの展開のためのDB2の互換性ルールに準拠している場合、そうしたスキーマは互換性があるとされます。この場合、新しいスキーマは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つのXMLスキーマに互換性がない場合、新しいスキーマを、新しい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. スキーマの進化 (変更)

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に対する妥当性検査に成功します。

上に戻る

まとめと利点

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のDB2 for Linux, UNIX, and Windowsリソース・ページ（US）　（日本語はこちら）には、豊富な記事やチュートリアルが用意されており、またこのページからDB2のスキルを向上させるための他のリソースにアクセスすることもできます。

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

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

議論するために

ディスカッション・フォーラム（US）　（日本語はこちら）に参加してください。
developerWorksブログ（US）　（日本語はこちら）を確認して、developerWorksコミュニティー（US）　（日本語はこちら）に参加してください。

著者について


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


		Ronny BartschはアメリカのSomersにある IBMのInformation Management Group (IBM software Groupの一部) のco-op (インターン) ソフトウェア開発者です。XMLと DB2 pureXMLを使用した業界標準に関連するindustry bundle (業界別サンプル) とデモに関する業務に従事しています。


		Susan MalaikaはIBMのInformation Management Groupで働いています。専門はXML技術とWeb技術であり、グリッド・コンピューティングも含まれます。Webに関する記事を発表しており、また共著もあります。IBM Academy of Technologyのメンバーです。

記事の評価

この記事を共有する


del.icio.us	newsing	FC2ブックマーク

Choix！	ニフティクリップ	Yahoo!ブックマーク

MM/memo	CZブックマーク	livedoorクリップ

はてなブックマーク	Buzzurl（バザール）

上に戻る

日本IBMについて

プライバシー

お問い合わせ