xml データ型と列 (SQL Server)

適用対象:データベースのSQL Server (サポートされているすべてのバージョン) Azure SQL

この記事では、SQL Serverでの xml データ型の利点と制限事項について説明し、XML データを格納する方法を選択するのに役立ちます。

リレーショナル データ モデルまたは XML データ モデル

データが既知のスキーマで高度に構造化されている場合、リレーショナル モデルはデータ ストレージに最適に機能する可能性があります。 SQL Server に用意されています。 ただし、データが構造化されていないか構造化が部分的である場合、または構造化の状態が不明な場合は、データのモデリングを検討する必要があります。

構造や意味によるマークアップを行ってデータを移行できるようにするために、プラットフォームに依存しないモデルが必要な場合、XML が適しています。 また、次に示す条件に該当する場合も XML が適切です。

  • データがスパースであるか、データの構造がわからない場合や、データの構造が将来大きく変化する可能性があります。

  • データがエンティティ間の参照ではなく包含階層を成していて、再帰的な性質がある場合。

  • データの順序が固定している場合。

  • データの構造を基にして、データへのクエリやデータの部分的な更新を行う場合。

上記の条件のいずれにも該当しない場合は、リレーショナル データ モデルを使用してください。 たとえば、データが XML 形式であってもデータの格納と取得にしかデータベースを使用しない場合、 [n]varchar(max) 列で十分です。 XML 列にデータを格納すると、それ以外の利点があります。 たとえば、データが適切な形式であり有効であることをデータベース エンジンで判断できることや、XML データに対するきめ細かいクエリや更新がサポートされることなどです。

SQL SERVERに XML データを格納する理由

次に、ファイル システムによる XML データの管理ではなく、 SQL Server のネイティブ XML 機能を使用する理由を示します。

  • XML データの共有、クエリ、および変更をトランザクション方式で効率的に行うため。 アプリケーションにとって、きめ細かいデータ アクセスは重要です。 たとえば、XML ドキュメントのセクションの一部を抽出したり、ドキュメント全体を置き換えることなく新しいセクションを挿入することができます。

  • リレーショナル データと XML データがあり、アプリケーションで双方のデータ間の相互運用性が必要なため。

  • XML とリレーショナルの 2 つの領域にまたがるアプリケーションで、クエリやデータ変更に対する言語サポートが必要なため。

  • データが整形式であることの保証、および必要に応じて XML スキーマに従ったデータの検証をサーバーで行うため。

  • クエリの処理を効率化し、スケーラビリティを高めるため XML データにインデックスを設定し、特に優れたクエリ オプティマイザーを使用するため。

  • SOAP、ADO.NET、および OLE DB で XML データにアクセスするため。

  • XML データの管理にデータベース サーバーの管理機能を使用するため。 たとえば、バックアップ、復旧、およびレプリケーションなどです。

上記の条件のいずれにも該当しない場合、XML 以外のラージ オブジェクト型 ( [n]varchar(max)varbinary(max) など) でデータを保存するのが適切です。

XML ストレージ オプション

次に、 SQL Server での XML のストレージ オプションを示します。

  • xml データ型としてのネイティブ ストレージ

    データの XML コンテンツを保持できる内部表現を使用してデータが保存されます。 内部表現には、包含階層、表示順、要素や属性の値に関する情報などがあります。 具体的には、XML データの InfoSet コンテンツが保持されます。 InfoSet の詳細については、「http://www.w3.org/TR/xml-infoset」を参照してください。 InfoSet コンテンツはテキスト XML の同一のコピーではない可能性があります。これは、重要でない空白、属性の順序、名前空間プレフィックス、および XML 宣言という情報が保持されないためです。

    型指定された xml データ型、つまり XML スキーマにバインドされた xml データ型の場合、PSVI (スキーマ検証後の InfoSet) によって型情報が InfoSet に追加され、内部表現にエンコードされます。 その結果、解析速度が大幅に向上します。 詳細については、http://www.w3.org/TR/xmlschema-1http://www.w3.org/TR/xmlschema-2 で W3C の XML スキーマの仕様を参照してください。

  • XML ストレージとリレーショナル ストレージのマッピング

    AXSD (注釈付きスキーマ) を使用することで、XML は 1 つ以上のテーブルの複数の列に分解されます。 分解されても、リレーショナル レベルでのデータの忠実性は保たれます。 したがって、要素間の順序は無視されますが階層構造は保持されます。 スキーマを再帰的にすることはできません。

  • ラージ オブジェクト ストレージ、 [n]varchar(max)varbinary(max)

    データの完全なコピーが保存されます。 これは、法務文書など、特殊な用途に使用します。 ほとんどのアプリケーションでは、正確なコピーは必要なく、XML コンテンツ (InfoSet の忠実性) に満足しています。

一般的には、上記のいくつかの方法を組み合わせることができます。 たとえば、 xml データ型の列に XML データを保存して、列のプロパティをリレーショナル列に昇格させることができます。 または、再帰しない部分を XML 以外の列に格納し、再帰部分のみを xml データ型の列に格納するためにマッピング テクノロジを使用することができます。

XML テクノロジの選択

ネイティブ XML と XML ビューのどちらの XML テクノロジを選択するかは、主に次の要因によって決まります。

  • ストレージ オプション

    XML データは、ラージ オブジェクトとして保存するのが適切な場合 (製品マニュアルなど) と、リレーショナル列に保存するのに向いている場合 (XML に変換した商品品目など) があります。 それぞれのストレージ オプションで保持される忠実性の度合いが異なります。

  • クエリ機能

    クエリの性質およびクエリの対象になる XML データの範囲を基に、最適なストレージ オプションがわかる場合があります。 XML ノードの述語評価など、XML データへのきめ細かいクエリは、2 つのストレージ オプションでのサポートの度合いに差があります。

  • XML データのインデックス設定

    XML クエリのパフォーマンスを向上するために、XML データにインデックスを設定できます。 インデックス設定のオプションはストレージ オプションによって異なります。ワークロードを最小にするために、適切な選択を行う必要があります。

  • データ変更機能

    一部のワークロードは、XML データのきめ細かい変更を伴います。 たとえば、ドキュメント内に新しいセクションを追加することも含まれますが、Web コンテンツなどの他のワークロードでは追加できません。 アプリケーションで、データ変更言語のサポートが重要になる場合があります。

  • スキーマのサポート

    XML データは、スキーマを使用して記述できる場合があります。このときのスキーマは、XML スキーマ ドキュメントであっても、そうでなくてもかまいません。 スキーマにバインドされた XML がサポートされるかどうかは、XML テクノロジによって異なります。

どの選択肢を選ぶかで、パフォーマンス特性が異なります。

ネイティブ XML ストレージ

XML データを、サーバーの xml データ型の列に保存できます。 次の条件に該当する場合、この方法が適しています。

  • 簡単にサーバーに XML データを保存すると同時に、表示順やドキュメント構造を保持する場合。

  • XML データのスキーマがあるかどうかが明確でない場合。

  • XML データに対し、クエリや変更を行う場合。

  • クエリ処理を高速化するために XML データにインデックスを設定する場合。

  • XML データと XML スキーマを管理するためのシステム カタログ ビューが必要な場合。

構造が多様な XML ドキュメントがある場合、またはリレーショナル構造へのマッピングが難しい複雑なスキーマや複数のスキーマに従った XML ドキュメントがある場合に、ネイティブ XML ストレージが役立ちます。

例: xml データ型を使用して XML データをモデル化する

トピックごとに章が設けられ、それぞれの章の中には複数の節がある構成の XML 形式の製品マニュアルを考えてみます。 節には項が含まれる場合があります。 したがって、<section> は再帰要素になります。 製品マニュアルには、混合コンテンツ、図表、および技術データが大量に含まれているので、データは部分的に構造化された状態です。 ユーザーは、「インデックス設定」に関する章の「クラスター化インデックス」に関する節を検索するなど、関心のあるトピックをコンテキストにより検索したり、技術データにクエリを実行します。

この XML ドキュメントに適したストレージ モデルは xml データ型列です。 このモデルであれば、XML データの InfoSet コンテンツが保持されます。 XML 列にインデックスを設定して、クエリ パフォーマンスを向上できる利点もあります。

例: XML データの正確なコピーを保持する

たとえば、政府の規定により、XML ドキュメントのテキストの正確なコピーを保持する必要があるとします。 署名済み文書、法務文書、株取引の注文書などが該当します。 このようなドキュメントは [n]varchar(max) 列に保存できます。

クエリを実行するには、実行時にデータを xml データ型に変換し、そのデータに対して XQuery を実行します。 実行時の変換は、ドキュメントが大きい場合は特にコストが高くなる可能性があります。 頻繁にクエリを実行する場合は、 xml データ型の列にドキュメントを冗長に保存してインデックスを設定しておき、 [n]varchar(max) 型の列からドキュメントの正確なコピーを返すことができます。

XML 列は [n]varchar(max) 型の列を基にした計算列にすることができます。 ただし、計算された XML 列に XML インデックスを作成することも、[ n]varchar(max) 列または varbinary(max) 列に XML インデックスを作成することもできません。

XML ビュー テクノロジ

XML スキーマとデータベース内のテーブルの間のマッピングを定義することで、永続的なデータの XML ビュー を作成します。 XML ビューを使用して基になるテーブルのデータを格納する場合に、XML 一括読み込みを行うことができます。 XML ビューには XPath Version 1.0 を使用してクエリを実行できます。テーブルでクエリが実行されるときには SQL クエリに変換されます。 これと同様に、更新もテーブルに反映されます。

このテクノロジは、次のような場合に役立ちます。

  • 既存のリレーショナル データの XML ビューを使用した XML 中心のプログラミング モデルが必要な場合。

  • 外部のパートナーから提供された XML データのスキーマ (XSD、XDR) がある場合。

  • データの順序は重要ではないか、クエリ テーブル データが再帰的でないか、再帰の深さの最大値が事前にわかっています。

  • XPath Version 1.0 を使用して、XML ビューからデータに対するクエリや変更を行う場合。

  • XML ビューを使用し、XML データの一括読み込みを行ってそれを基になるテーブルに分解する場合。

例としては、データ交換や Web サービス向けに XML として公開されたリレーショナル データ、固定スキーマにバインドされた XML データなどがあります。 詳しくは、

例: 注釈付き XML スキーマ (AXSD) を使用してデータをモデル化する

たとえば、顧客、注文、品目などの既存のリレーショナル データを XML として処理するとします。 リレーショナル データに AXSD を使用して、XML ビューを定義します。 XML ビューを使用すると、テーブルに XML データを一括で読み込み、XML ビューでリレーショナル データに対するクエリや更新を行うことができます。 SQL アプリケーションの実行を中断することなく、XML でマークアップされたデータを他のアプリケーションと交換する必要がある場合に、このモデルが役立ちます。

ハイブリッド モデル

リレーショナル列と xml データ型の列を組み合わせることがデータ モデリングとして適している場合も多くあります。 XML データの値の一部をリレーショナル列に保存し、残り (または XML 値全体) を XML 列に保存することができます。 そうすることで、リレーショナル列に作成したインデックスやロック特性を制御しやすくなり、パフォーマンスが向上する場合があります。

リレーショナル列に保存する方が適切な値はワークロードによって異なります。 たとえば、パス式に基づいてすべての XML 値を取得する場合、 /Customer/@CustId属性の値を CustId リレーショナル列に昇格させ、インデックスを作成すると、クエリのパフォーマンスが向上する可能性があります。 一方、XML データが広範囲におよび非繰り出し的にリレーショナル列に分解される場合は、再構築コストが大きくなる可能性があります。

テーブルのコンテンツを XML に変換した場合など、十分に構造化された XML データでは、すべての値をリレーショナル列にマップすることができ、XML ビュー テクノロジを使用できる場合もあります。

XML データの粒度

XML 列に格納される XML データの粒度は、ロックのために重要であり、より少ない程度では、更新にも重要です。 SQL Server では、XML データと XML 以外のデータに対して同一のロック メカニズムを使用します。 したがって行レベルのロックを設定すると、行内のすべての XML インスタンスがロックされます。 粒度が粗い場合、マルチユーザー シナリオで更新のために大きな XML インスタンスをロックすると、スループットが低下します。 一方、分割しすぎるとオブジェクトのカプセル化状態が失われ、再構成のコストが上がります。

優れた設計を行うには、データ モデリングの要件とロックや更新の特性との間でバランスを取ることが重要です。 ただし、SQL Serverでは、実際に格納されている XML インスタンスのサイズはそれほど重要ではありません。

たとえば、新旧の XML インスタンスの比較による BLOB (バイナリ ラージ オブジェクト) やインデックスの部分更新が新しくサポートされるようになったので、それにより XML インスタンスが更新されます。 BLOB (バイナリ ラージ オブジェクト) の部分更新は、2 つの XML インスタンスの差異を比較して差分のみを更新します。 インデックスの部分更新は、XML インデックスの変更が必要な行のみを変更します。

xml データ型の制限事項

xml データ型には、次の一般的な制限事項が適用されます。

  • 格納されている xml データ型インスタンスの表現は、2 GB を超えることはできません。

  • sql_variant インスタンスのサブタイプとして使用することはできません。

  • キャストやテキストまたは ntext への変換はサポートされていません。 代わりに varchar(max) または nvarchar(max) を使用します。

  • 比較または並べ替えはできません。 これは、 XML データ型を GROUP BY ステートメントで使用できないことを意味します。

  • ISNULL、COALESCE、DATALENGTH 以外のスカラー関数、組み込み関数のパラメーターとして使用することはできません。

  • インデックスのキー列として使用することはできません。 ただし、クラスター化インデックスのデータとして使用したり、非クラスター化インデックスの作成時に INCLUDE キーワードを使用して明示的に非クラスター化インデックスに追加することはできます。

  • XML 要素は 128 レベルまで入れ子にできます。

関連項目