お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

DB2 によるXMLスキーマの進化とXMLデータの管理

大川昌弘, IM開発, ソフトウェア開発研究所, 日本アイ・ビー・エム株式会社

大川昌弘は、ソフトウェア開発研究所のデータベース関連製品開発部門に所属するソフトウェアエンジニアで、現在は主にデータベースツール製品の開発やテストに従事しています。

概要： 「DB2 によるXMLスキーマの管理とXML データの妥当性検証」では、XMLスキーマを利用したXMLデータの妥当性検証と、その情報の取得方法などについて述べましたが、この記事では、XMLスキーマの進化におけるXMLデータの管理方法について紹介します。なお、この記事は、DB2 9.7 for Linux, UNIX and Windows に基づいて述べられています。

タグを付ける!

日付: 2009年 11月 19日
レベル: 中級
アクティビティー： 3975 ビュー
お気軽にご意見・ご感想をお寄せください：

はじめに

ビジネスの成長を図るうえで、管理する情報を継続的に見直してゆくことは重要な要素となっています。そのような中、XMLは柔軟にデータを記述してゆけることから注目を集めています。また、XMLを処理する上で、その構造を定義し、定義された構造に従って処理してゆくこともデータの品質を高める上で重要な要素となっています。その記述言語として、XMLスキーマがあります。

管理する情報の見直しにより、XMLデータの構造を変える（XMLスキーマを進化させる）際のシナリオとして、以下が挙げられます。

XMLスキーマの進化（上位互換あり）
既存のXMLスキーマを包含するように（上位互換となるように）XMLスキーマを進化させます。そうすることにより、既存のXMLデータは修正することなく新しいXMLスキーマに適合させることができます。
XMLスキーマの進化（互換性なし）とXMLデータの移行
既存のXMLスキーマとの互換性を考慮せずに、XMLスキーマを進化させます。既存のXMLデータを新しいXMLスキーマに適合させるために、XMLデータを移行します。
XMLスキーマの進化（互換性なし）とXMLデータの管理（移行なし）
既存のXMLスキーマとの互換性を考慮せずに、XMLスキーマを拡張します。既存のXMLデータは移行せず、従来どおりのXMLスキーマで管理します。

この記事では、これらのシナリオを実現するための方法を紹介します。

上に戻る

XMLスキーマの進化（上位互換あり）

このシナリオは、既存のXMLスキーマを包含するように（上位互換となるように）新しいXMLスキーマを定義することで、従来のXMLデータを修正することなく新しいXMLスキーマで管理できるようにします。

例として単純な顧客情報を取り上げます。既存のXMLスキーマをリスト1、そのXMLスキーマに適合するXMLデータをリスト2に示します。

リスト 1. cust1.xsd (XMLスキーマ)

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="xs:string"/>
                <xs:element name="email" type="xs:string"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

リスト 2. cust1.xml

<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="cust1.xsd">
    <name>cust1</name>
    <address>address1</address>
    <phone>11-2222-3333</phone>
    <email>cust1@sample.com</email>
</customer>

リスト1のXMLスキーマを以下のように登録します。（XMLスキーマの登録とXMLデータのインポート方法の詳細については、「DB2 によるXMLスキーマの管理とXML データの妥当性検証」を参照してください）

REGISTER XMLSCHEMA 'cust1.xsd'
   FROM '/work/cust1.xsd' AS SAMPLE2.CUST1;
COMPLETE XMLSCHEMA SAMPLE2.CUST1;

以下のように、T1テーブルを作成し、リスト2のXMLデータをインポートします。

CREATE TABLE T1 (ID INT NOT NULL PRIMARY KEY, XMLDATA XML NOT NULL);
IMPORT FROM /work/cust1.del of del XML FROM /work
   XMLVALIDATE USING SCHEMA SAMPLE2.CUST1 INSERT INTO T1;

インポート時に使用しているcust1.delファイルの内容は以下の通りです。IDカラムには1をセットしています。

1, "<XDS FIL='cust1.xml'/>"

ここで、T1テーブルのそれぞれのレコードについて、妥当性検証に使用したXMLスキーマのオブジェクトID、リレーショナルID、およびスキーマ・ロケーションを取得するために以下のSQL文を発行してみます。以下のSQL文は、妥当性検証を行っていないレコードや妥当性検証を行ったがその後使用しているXMLスキーマがドロップされた場合を想定し、OUTER JOINを使用しています。

db2 => SELECT T1.ID,
              XMLXSROBJECTID(T1.XMLDATA) OBJECTID,
              substr(XSR.OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(XSR.OBJECTNAME,1,12) OBJECTNAME,
              substr(XSR.SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM T1 LEFT OUTER JOIN SYSCAT.XSROBJECTS XSR
          ON XMLXSROBJECTID(T1.XMLDATA)=XSR.OBJECTID;

ID          OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
----------- -------------------- ------------ ------------ ----------------
          1    65020719620281344 SAMPLE2      CUST1        cust2.xsd

  1 レコードが選択されました。

例として挙げたXMLのphoneエレメントは、顧客の自宅の電話番号を値として保持することを想定しています。ここで、さらに、顧客の携帯番号を登録することを考えます。

既存のXMLスキーマを包含するように（上位互換となるように）新しいXMLスキーマを定義します。そのためには、既存のエレメントや属性は修正せず、新規に携帯番号を登録するためのエレメント（cell-phoneとします）を追加し、かつ、追加したエレメントはオプション(minOccurs="0")にする必要があります。（リスト3）

リスト3. cust2.xsd (XMLスキーマ)

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="xs:string"/>
                <xs:element name="cell-phone" minOccurs="0" type="xs:string"/>
                <xs:element name="email" type="xs:string"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
</xs:schema>

リスト3のXMLスキーマを以下のように登録します。

REGISTER XMLSCHEMA 'cust2.xsd'
   FROM '/work/cust2.xsd' AS SAMPLE2.CUST2;
COMPLETE XMLSCHEMA SAMPLE2.CUST2;

このXMLスキーマcust2.xsdは、リスト1のXMLスキーマcust1.xsdを包含しているため、cust1.xsdを置き換えることができます。

XMLスキーマの置き換えは、UPDATE XMLSCHEMAコマンドを発行することで行うことができます。

UPDATE XMLSCHEMA SAMPLE2.CUST1 WITH SAMPLE2.CUST2;

このコマンドにより、リレーショナルID "SAMPLE2.CUST1" に登録された cust1.xsd は、新しいXMLスキーマ cust2.xsd に置き換えられます。置き換える前に登録した新しいXMLスキーマは、そのまま残ります。

リスト4は、新しいXMLスキーマに適合するXMLデータです。

リスト 4. cust2.xml

<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="cust1.xsd">
    <name>cust2</name>
    <address>address2</address>
    <phone>22-3333-4444</phone>
    <cell-phone>090-4444-5555</cell-phone>
    <email>cust2@sample.com</email>
</customer>

これを、置き換えられたリレーショナルID "SAMPLE2.CUST1" のXMLスキーマで妥当性検証し、T1テーブルに挿入してみると、妥当性検証に成功し、正常に挿入されます。

IMPORT FROM /work/cust2.del of del XML FROM /work
   XMLVALIDATE USING SCHEMA SAMPLE2.CUST1 INSERT INTO T1;

インポート時に使用しているcust2.delファイルの内容は以下の通りです。IDカラムには2をセットしています。

2, "<XDS FIL='cust2.xml'/>"

T1テーブルのそれぞれのレコードが、どのXMLスキーマと妥当性検証を行ったかを取得するために、再度、以下のSQL文を発行してみます。

db2 => SELECT T1.ID,
              XMLXSROBJECTID(T1.XMLDATA) OBJECTID,
              substr(XSR.OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(XSR.OBJECTNAME,1,12) OBJECTNAME,
              substr(XSR.SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM T1 LEFT OUTER JOIN SYSCAT.XSROBJECTS XSR
          ON XMLXSROBJECTID(T1.XMLDATA)=XSR.OBJECTID;

ID          OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
----------- -------------------- ------------ ------------ ----------------
          1    65020719620281344 SAMPLE2      CUST1        cust2.xsd
          2    65020719620281344 SAMPLE2      CUST1        cust2.xsd

  2 レコードが選択されました。

IDが2のXMLデータは、置き換えた後のXMLスキーマで妥当性検証を行っています。上記の結果からわかるように、XMLスキーマを置き換えても、そのオブジェクトIDは変わらないため、それ以前に妥当性検証を行ったXMLデータも、新しいXMLスキーマに適合しているという情報が保持されていることになります。

また、リレーショナルIDも以前のままですが、スキーマ・ロケーションは新しいXMLスキーマを登録した際のスキーマ・ロケーションとなります。XMLスキーマのリレーショナルIDとスキーマ・ロケーションの登録情報を見てみると、以下の結果が得られます。

db2 => SELECT OBJECTID,
              substr(OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(OBJECTNAME,1,12) OBJECTNAME,
              substr(SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM SYSCAT.XSROBJECTS;

OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
-------------------- ------------ ------------ ----------------
   65020719620281344 SAMPLE2      CUST1        cust2.xsd
   66857945295662336 SAMPLE2      CUST2        cust2.xsd

  2 レコードが選択されました。

上記の結果が示すように、2つのレコードで、同じスキーマ・ロケーションを保持しています。この状態では、スキーマ・ロケーションを使用してXMLスキーマを特定し、XMLデータの妥当性検証を行うことはできません。スキーマ・ロケーションでcust2.xsdを指定して妥当性検証を行うと、どちらのXMLスキーマを選択してよいかわからず、以下のエラーとなります。

db2 => INSERT INTO T1(ID, XMLDATA) VALUES (22, 
XMLVALIDATE(XMLPARSE(DOCUMENT 
'<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="cust2.xsd">
    <name>cust2-2</name>
    <address>address2-2</address>
    <phone>33-4444-5555</phone>
    <cell-phone>090-5555-6666</cell-phone>
    <email>cust2-2@sample.com</email>
</customer>'))
);
DB21034E  コマンドが、有効なコマンド行プロセッサー・コマンドでないため、 SQL
ステートメントとして処理されました。 SQL 処理中に、そのコマンドが返されました。
SQL16196N  XML 文書に正しく指定されていない要素 "customer"
が含まれています。理由コード = "37"  SQLSTATE=2200M

下記のコマンドを発行して、一方のXMLスキーマをドロップした後、再度、実行すると、XMLデータの挿入に成功します。

DROP XSROBJECT SAMPLE2.CUST2;

したがって、スキーマ・ロケーションを使用して妥当性検証を行いたい場合、XMLスキーマの置き換え後に不要となった新しいXMLスキーマをドロップする必要があります。これは、UPDATE XMLSCHEMAコマンドでDROP NEW SCHEMAオプションを指定することで実現可能です。

UPDATE XMLSCHEMA SAMPLE2.CUST1 WITH SAMPLE2.CUST2 DROP NEW SCHEMA;

もう1つの懸案事項として、XMLスキーマを置き換えると、スキーマ・ロケーションも新しいものに置き換わってしまうため、前のスキーマ・ロケーションを使用して挿入したXMLデータ内のスキーマ・ロケーション情報と合わなくなってしまうことがあげられます。これは、新しいXMLスキーマも以下のように置き換え前と同じスキーマ・ロケーション(cust1.xsd)を使用して登録することで解決できます。

REGISTER XMLSCHEMA 'cust1.xsd'
   FROM '/work/cust2.xsd' AS SAMPLE2.CUST2;
COMPLETE XMLSCHEMA SAMPLE2.CUST2;

このようにすることで、XMLスキーマを置き換えた後も、置き換え前のスキーマ・ロケーションを使用して処理することができます。

新しいXMLスキーマを上位互換にすることで、従来のXMLデータを修正することなく管理することができます。しかしながら、上位互換にするためには、新規に追加したエレメントや属性はすべてオプションにする必要があり、必須としたい追加情報の検査ができないという欠点があります。（上記の例ではcell-phoneエレメントを追加しましたが、オプションとしているため、cell-phoneエレメントのないXMLデータも妥当性検証に成功してしまいます）

*その他、上位互換にするための要件については、DB2 Information Center「XML スキーマの展開のための互換性要件（英語）」や「DB2 pureXML を使って XML スキーマを進化させる」を参照してください。

上に戻る

XMLスキーマの進化（互換性なし）とXMLデータの移行

このシナリオは、既存のXMLスキーマとの互換性を考慮せずに、XMLスキーマを進化させます。さらに、既存のXMLデータを新しいXMLスキーマに適合するように移行します。

リスト5は、phoneエレメントの子エレメントとして、homeとcellエレメントを追加し、それらの値として、顧客の自宅電話番号と携帯電話番号を管理しています。そのXMLスキーマをリスト6に示します。

リスト 5. cust3.xml

<?xml version="1.0"?>
<customer xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
  xsi:noNamespaceSchemaLocation="cust3.xsd">
    <name>cust3</name>
    <address>address3</address>
    <phone>
      <home>44-5555-6666</home>
      <cell>090-6666-7777</cell>
    </phone>
    <email>cust3@sample.com</email>
</customer>

リスト 6. cust3.xsd (XMLスキーマ)

<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <xs:element name="customer">
        <xs:complexType>
            <xs:sequence>
                <xs:element name="name" type="xs:string"/>
                <xs:element name="address" type="xs:string"/>
                <xs:element name="phone" type="phoneType"/>
                <xs:element name="email" type="xs:string"/>
            </xs:sequence>
        </xs:complexType>
    </xs:element>
    <xs:complexType name="phoneType">
        <xs:sequence>
            <xs:element name="home" type="xs:string"/>
            <xs:element name="cell" type="xs:string"/>
        </xs:sequence>
    </xs:complexType>
</xs:schema>

上記のXMLスキーマとXMLデータを以下のように登録・インポートします。

REGISTER XMLSCHEMA 'cust3.xsd'
   FROM '/work/cust3.xsd' AS SAMPLE2.CUST3;
COMPLETE XMLSCHEMA SAMPLE2.CUST3;
IMPORT FROM /work/cust3.del of del XML FROM /work
   XMLVALIDATE USING SCHEMA SAMPLE2.CUST3 INSERT INTO T1;

インポート時に使用しているcust3.delファイルの内容は以下の通りです。IDカラムには3をセットしています。

3, "<XDS FIL='cust3.xml'/>"

ここで、再度、T1テーブルのそれぞれのレコードが、どのXMLスキーマと妥当性検証を行ったかを取得してみます。

db2 => SELECT T1.ID,
              XMLXSROBJECTID(T1.XMLDATA) OBJECTID,
              substr(XSR.OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(XSR.OBJECTNAME,1,12) OBJECTNAME,
              substr(XSR.SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM T1 LEFT OUTER JOIN SYSCAT.XSROBJECTS XSR
          ON XMLXSROBJECTID(T1.XMLDATA)=XSR.OBJECTID;

ID          OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
----------- -------------------- ------------ ------------ ----------------
          1    65020719620281344 SAMPLE2      CUST1        cust1.xsd
          2    65020719620281344 SAMPLE2      CUST1        cust1.xsd
         22    65020719620281344 SAMPLE2      CUST1        cust1.xsd
          3    68398419340809216 SAMPLE2      CUST3        cust3.xsd

  4 レコードが選択されました。

T1テーブルのIDが1と2と22のXMLデータ(XMLDATAカラム)は、リスト3のXMLスキーマcust2.xsd（スキーマ・ロケーションをcust1.xsdとして、SAMPLE2.CUST1のXMLスキーマを進化させたため、リレーショナルIDがSAMPLE2.CUST1、スキーマ・ロケーションがcust1.xsdとなっています）に適合しています。それらのXMLデータをcust3.xsdに適合させるためには、以下の変更を行う必要があります。

XPath "/customer/phone"の子エレメントとして"home"と"cell"エレメントを定義する
XPath "/customer/phone"の値を"/customer/phone/home"の値とする
XPath "/customer/cell-phone"が定義されていれば、その値を"/customer/phone/cell"の値とし、"/customer/cell-phone"エレメントを削除する
xsi:noNamespaceSchemaLocation属性の値をcust3.xsdとする（リレーショナルIDでXMLスキーマの場所を特定する場合は変更しなくても良い）

リレーショナルIDがSAMPLE2.CUST1のXMLスキーマで妥当性検証を行ってT1テーブルに挿入したすべてのXMLデータを、上記のように変更し、かつ、cust3.xsdで妥当性検証するためには、以下のSQL文を発行します。

UPDATE T1
SET XMLDATA=XMLVALIDATE(XMLQUERY(
 'declare namespace xsi="http://www.w3.org/2001/XMLSchema-instance";
  copy $new := $XMLDATA
  modify (
    do replace $new/customer/phone with 
      <phone>
        <home>{$new/customer/phone/text()}</home>
        <cell>{$new/customer/cell-phone/text()}</cell>
      </phone>,
    do replace value of $new/customer/@xsi:noNamespaceSchemaLocation with "cust3.xsd",
    do delete $new/customer/cell-phone )
	return  $new'))
WHERE XMLXSROBJECTID(XMLDATA)=(SELECT OBJECTID FROM SYSCAT.XSROBJECTS WHERE
OBJECTSCHEMA='SAMPLE2' AND OBJECTNAME='CUST1')

再度、T1テーブルのそれぞれのレコードが、どのXMLスキーマと妥当性検証を行ったかを取得してみると、以下のようにすべてのレコードが、スキーマ・ロケーションcust3.xsdで妥当性検証されていることがわかります。

db2 => SELECT T1.ID,
              XMLXSROBJECTID(T1.XMLDATA) OBJECTID,
              substr(XSR.OBJECTSCHEMA,1,12) OBJECTSCHEMA,
              substr(XSR.OBJECTNAME,1,12) OBJECTNAME,
              substr(XSR.SCHEMALOCATION,1,16) SCHEMALOCATION
          FROM T1 LEFT OUTER JOIN SYSCAT.XSROBJECTS XSR
          ON XMLXSROBJECTID(T1.XMLDATA)=XSR.OBJECTID;

ID          OBJECTID             OBJECTSCHEMA OBJECTNAME   SCHEMALOCATION
----------- -------------------- ------------ ------------ ----------------
          1    68398419340809216 SAMPLE2      CUST3        cust3.xsd
          2    68398419340809216 SAMPLE2      CUST3        cust3.xsd
         22    68398419340809216 SAMPLE2      CUST3        cust3.xsd
          3    68398419340809216 SAMPLE2      CUST3        cust3.xsd

  4 レコードが選択されました。

DB2のコマンド行プロセッサーなどでSQL文を用いてXMLを表示させる場合、以下のようにサイズ指定することで、無駄な空白行を減らすことができます。（サイズはXMLデータのサイズより大きい値を指定します）

SELECT ID, XMLSERIALIZE(XMLDATA AS VARCHAR(500)) FROM T1;

名前空間を追加したり変更したりすることも可能です。名前空間を変更すると、すべての要素が別のものとして扱われるため、すべての要素を指定して変更します。例えば、リスト6のcust3.xsdが"http://www.sample.com/customer3"という名前空間に属していると仮定すると、上記のUPDATE文は以下のようになります。

UPDATE T1
SET XMLDATA=XMLVALIDATE(XMLQUERY(
 'declare namespace xsi="http://www.w3.org/2001/XMLSchema-instance";
  declare namespace cust="http://www.sample.com/customer3";
  copy $new := $XMLDATA
  modify (
    do replace $new/customer with
      <cust:customer xsi:schemaLocation="http://www.sample.com/customer3 cust3.xsd">
        <cust:name>{$new/customer/name/text()}</cust:name>
        <cust:address>{$new/customer/address/text()}</cust:address>
        <cust:phone>
          <cust:home>{$new/customer/phone/text()}</cust:home>
          <cust:cell>{$new/customer/cell-phone/text()}</cust:cell>
        </cust:phone>
        <cust:email>{$new/customer/email/text()}</cust:email>
      </cust:customer> )
  return  $new'))
WHERE XMLXSROBJECTID(XMLDATA)=(SELECT OBJECTID FROM SYSCAT.XSROBJECTS WHERE
OBJECTSCHEMA='SAMPLE2' AND OBJECTNAME='CUST1')

上に戻る

XMLスキーマの進化（互換性なし）とXMLデータの管理（移行なし）

このシナリオは、既存のXMLスキーマとの互換性を考慮せずに、XMLスキーマを進化させます。また、既存のXMLデータは、従来のXMLスキーマで管理します。（DB2では、1つのカラムに異なるXMLスキーマに適合するXMLデータを保持することが可能となっています）

この場合、アプリケーションは、XMLデータをそれぞれが適合するXMLスキーマに応じたプログラムで処理する必要があります。

上位互換となるようにXMLスキーマを進化させる問題点として、追加した必須の情報が存在するか検証できないことを挙げましたが、このシナリオでは、必須の情報としてエレメントや属性を追加することができます。また、既存のエレメントや属性を変更しなければ、同じプログラムで処理することができます。（ただし、追加したエレメントや属性の値が得られない場合の処理が必要です）

図1の例では、予め、XMLスキーマのオブジェクトIDと、リレーショナルIDあるいはスキーマ・ロケーションを取得し、それぞれのオブジェクトIDに対応するバージョン情報を割り当てています。そして、運用中にXMLデータを取得して処理する際は、その妥当性検証を行ったXMLスキーマのオブジェクトIDも取得し、それに対応するバージョンに応じた処理を行います。

図2の例では、別のカラムの値（この例では作成日）で、どのXMLスキーマに適合しているか特定しています。運用中にXMLデータを取得して処理する際は、XMLスキーマを特定するためのカラムも取得し、その値でXMLスキーマを特定し、それに応じた処理を行います。

図1. 異なるXMLスキーマを保持するXMLデータの処理例1

図2. 異なるXMLスキーマを保持するXMLデータの処理例2

XMLデータを更新するごとに、XMLVALIDATE関数を使用して妥当性検証する代わりに、トリガーを使用して妥当性検証させることができます。以下のSQL文では、作成日カラム名をCREATION_DATE、その値が2008/01/01以降の場合、リレーショナルIDがSAMPLE2.ORDER2008のXMLスキーマを、2002/01/01から2007/12/31までの場合、リレーショナルIDがSAMPLE2.ORDER2002のXMLスキーマを使用して妥当性検証させています。XMLデータの挿入についても、同様に行うことができます。

リスト7. 作成日が2008/01/01以降のXMLデータの妥当性検証用トリガー

CREATE TRIGGER UPDATE_ORDER2008 NO CASCADE BEFORE UPDATE ON SAMPLE2.ORDER
  REFERENCING NEW AS N
  FOR EACH ROW
  WHEN (N.CREATION_DATE >= '2008-01-01')
    BEGIN ATOMIC
      SET (N.XMLDATA) = XMLVALIDATE(N.XMLDATA ACCORDING TO XMLSCHEMA ID 
	  SAMPLE2.ORDER2008);
    END

リスト8. 作成日が2002/01/01から2007/12/31までのXMLデータの妥当性検証用トリガー

CREATE TRIGGER UPDATE_ORDER2002 NO CASCADE BEFORE UPDATE ON 
SAMPLE2.ORDER
  REFERENCING NEW AS N
  FOR EACH ROW
  WHEN (N.CREATION_DATE >= '2002-01-01' AND N.CREATION_DATE < '2008-01-01')
    BEGIN ATOMIC
      SET (N.XMLDATA) = XMLVALIDATE(N.XMLDATA ACCORDING TO XMLSCHEMA ID 
           SAMPLE2.ORDER2002);
    END

上に戻る

まとめ

上位互換となるように新しいXMLスキーマを定義することにより、既に登録されているXMLデータも、修正することなく、新しいXMLスキーマで管理することができます。また、新しいXMLに置き換えた後もリレーショナルIDを用いて妥当性検証することや、スキーマ・ロケーションを用いて妥当性検証することが可能です。ただし、スキーマ・ロケーションを用いる場合、新しいXMLに置き換えた後に、置き換え前に登録した新しいXMLスキーマはドロップする必要があります。また、置き換え前に新しいXMLスキーマを登録する際は、既存のスキーマ・ロケーションと同じ名前で登録する必要があります。

上位互換となるように新しいXMLスキーマを定義する欠点として、新たに追加したエレメントや属性を必須としたい場合でも、オプションとして定義する必要があり、必須としたい追加情報の検査ができない点などが挙げられます。それを解決するためには、互換性のないXMLスキーマを定義する必要があります。その際の対応方法として、古いXMLスキーマに適合するXMLデータを、新しいXMLスキーマに適合するように移行する方法と、そのまま、それぞれ異なるXMLスキーマを意識しながら処理する方法があります。（DB2では、1つのカラムに異なるXMLスキーマに適合するXMLデータを保持することが可能となっています）

参考文献