目次


データ用のXML: XQueryの紹介

XQueryワーキング・ドラフトの概要、およびデータ用XMLとの関係

Comments

2組の要素の結合、リレーションのピボット、(比較的簡単な) 算術計算といった複雑なデータ操作を行うのにXSLを使用したことのある読者は、データ操作機能の点で少し物足りないと感じているでしょう。この問題を回避するために、スタイルシート作成者はさまざまな工夫をせざるを得ません。たとえば複数のスタイルシートを連鎖させたり、xsl:for-each 演算子を深くネストさせたり、Perl専門家の頭を悩ませる複雑な構文のコードを書いたりします。でも、助けが差し伸べられています。2002夏にリリース予定のXQuery仕様は、これらすべての問題に答えて余りあるほどの機能を提供してくれます。

XML Queryとは何か

XML Query (略してXQuery) は、ここ何年かの間にさまざまな経緯をたどっている仕様です。1999年9月に公認されたXML Queryワーキング・グループの任務は、XML文書からデータを取り出す柔軟な照会言語を作成することです。最新のワーキング・ドラフト (参考文献 を参照) は、この目標に大きく近づいています。

XQueryはXPath仕様の上に成り立っています。実際、XQueryの機能の一部は、その重要性が認められてXPath 2.0仕様に組み込まれました。今やこの仕様は、W3CのXML Queryワーキング・グループとXSLワーキング・グループによって共有されています。これはよいことです。スタイルシート作成者はやがて、シーケンス、数量化、より強固な型制御といった機能を利用できるようになるでしょう。さらに、(XSL言語の一部であった) 条件式とiteratorがXPath言語に追加されました。これによって、スタイルシートのコードがより簡潔になり、スタイルシート作成者の悩みも減るでしょう。

FLWR式

XQueryの最もパワフルな新機能はFLWR式です。FLWR (フラワー と読む) はFor-Let-Where-Returnの頭字語です。FLWR式ではこれらの文節を使用することができます。FLWR式を使えば、これまで夢にも見なかったような数多くの機能がXSLスタイルシートで実現します。

それぞれのFLWR式には1つまたは複数のfor 文節、1つまたは複数のlet 文節、オプションのwhere 文節、および1つのreturn 文節が含まれます。

for文節

for 文節を使って、リスト1のように、式の残りの部分の評価基準となる一組のタプルを指定します。タプルの順序によって、評価順序を制御します。

リスト1. 単一のfor文節
for $exp1 in (<a/>, <b/>)

プログラムの実行時には、$exp 変数をそれぞれ<a/> および<b/> に設定して、リスト1の式が二度評価されます。仮にfor 式をもう1つ使用すると、プログラムは直積 (Cartesian product) を評価します。複数の for 文節を使った例として、リスト2をご覧ください。

リスト2. 複数のfor文節
for $exp1 in (<a/>, <b/>)
for $exp2 in (<c/>, <d/>)

リスト2の場合、以下のように、各タプルごと1回ずつ、合計4回にわたって式を評価します。

  • (<a/>, <c/>)
  • (<a/>, <d/>)
  • (<b/>, <c/>)
  • (<b/>, <d/>)

let文節

let 文節は、変数に値またはシーケンスを割り当てます。where 文節またはreturn 文節では、これを手軽に使用できます。

where文節とreturn文節

where 文節は、特定の条件を満たさない特定のタプルを破棄するよう、プログラムを誘導します。return 文節は、それぞれのタプルごとに何を戻すかを定義します。

この例の照会は、文書内に含まれる、4冊以上の書籍を書いたすべての著者 (author) の名前を戻します。式はまず、リスト3のようなサンプル文書を処理します。

リスト3. サンプル文書authorList.xml
<authorList>
<author name="Kevin Williams">
<book>Professional XML, 2nd Edition</book>
<book>Professional XML Databases</book>
<book>Professional XML Schemas</book>
</author>
<author name="John Q. Somebody">
<book>Esoteric Topics in Programming, Vol. 1</book>
<book>Esoteric Topics in Programming, Vol. 2</book>
</author>
</authorList>

文書authorList.xmlを操作する照会は、リスト4のようになります。

リスト4. 4冊以上を書いた著者を選択するサンプル照会
<frequentWriters>
{
let $inDoc := document("authors.xml")
for $author in ($inDoc//author)
let $cb := count($author/book)
where ($cb >= 3)
return
<author>$author/@name</author>
}
</frequentWriters>

リスト4のXQueryは、リスト5のような内容を戻します。

リスト5. たくさんの本を書いた著者の照会結果
<frequentWriters>
<author>Kevin Williams</author>
</frequentWriters>

distinct-values関数

XQueryには、データ操作に非常に役立つ関数distinct-values が含まれています (これはXPath 2.0にも含まれています)。この関数を使って、文書内の関係を簡単にピボットできます。たとえば、ソフトウェア企業の顧客と、顧客がこれまでに購入した製品のリストがあるとしましょう (リスト6を参照)。

リスト6. サンプル顧客データcustomerList.xml
<customerList>
<customer name="Big Bank, Inc.">
<product name="MyDataMinder" />
<product name="MyDataFinder" />
</customer>
<customer name="PharmaCorp, Inc.">
<product name="MyDataFinder" />
<product name="MyDataBinder" />
</customer>
</customerList>

たとえばこの文書から、すべての製品一覧と、その製品を購入した顧客をリストアップした文書に変換したい場合、大量の作業を手動でしなければなりません。これは可能ではありますが、コードの見映えは良くありません。でも、XQueryを使えば、簡単に解決されます。リスト7をご覧ください。

リスト7. 製品と顧客の関係をピボットするコード
<productList>
{
let $inDoc := document("customerList.xml")
for $product in distinct-values("$input//customer/product/@name)
return
<product name={$product}>
{
for $customer in $input//customer
where $customer/product/@name = $product
return
<customer name={$customer/@name} />
}
</product>
}
</productList>

リスト7の出力結果は、リスト8のようになります。

リスト8. ピボット・コードの結果
<productList>
<product name="MyDataMinder">
<customer name="Big Bank, Inc." />
</product>
<product name="MyDataFinder">
<customer name="Big Bank, Inc." />
<customer name="Pharmacorp, Inc." />
</product>
<product name="MyDataBinder">
<customer name="Pharmacorp, Inc." />
</product>
</productList>

パワフルで、簡単に使えて、わかりやすいXQueryのおかげで、データ操作がこのように簡単になります。

どんな場合にXQueryを使用すべきか

では、XQueryをいつ使い始めるべきでしょうか。それは、あなたがこの記事をいつ読んでいるか、そしてどれほど熱意があるかによります。2002年2月の時点で、この仕様はまだワーキング・ドラフトです。つまり、最終的に発表されるまでに、大きく変更される可能性があります。いったん勧告案 (Proposed Recommendation) のレベルになったら、ほぼ内容が固まっていますから、使い始めて差し支えないでしょう。実際W3Cは、勧告案レベルの仕様を利用してフィードバックを送るよう開発者たちに提案しています。そうしたフィードバックのおかげで、仕様がさらに微調整され、やがては勧告レベルに達する日がやって来るのです。勧告案になりしだい、使い始めたいと考えている読者にとっては、2002年の春ごろがちょうど良い時期かもしれません。

具体的な時期はともかく、XQueryをソリューションとしてどんな場合に使い始めるのが適切か、判断に役立つ基準をいくつか示しましょう。

まず第1に、XQueryは魔法の薬ではありません。確かに、構文的にはXQueryはXSLよりもデータ操作に有利です (しかも、XSLでは直接的に行えない機能がXQueryにはいくつもあります)。しかし、基本的なエンジンは依然として照会言語を使ってそれぞれの文書を読み取り、構文解析し、操作しなければなりません。このためXQueryは、文書の細部にすばやくアクセスできる索引付き文書リポジトリー (いわゆるXML「データベース」) に関しては効果的なソリューションですが、索引のない文書を処理するにはそれほど効果的とは言えません。

第2に、XQueryには、リポジトリー内の複数の文書にアクセスするためのメカニズムがいくつか含まれています。document関数のおかげで、同じ照会で複数の文書にアクセスすることがプログラム的に可能になります。しかし、これまでと同じ問題があります。すべての文書をロードして構文解析しなければなりません。ですから、最高のパフォーマンスを得るには、XMLデータベースその他の索引付けモデルを使用した方がよいのです。

最後に、XQueryは「混成型」文書、つまり記述的なフローと数量データの両方が含まれる文書の処理に最も適しています。たとえば、医療記録には、手術中に執刀医が行った処置についての記述と、手術中に患者に提供された薬、血液、その他の物質の数量が記載されるでしょう。そのような文書は、リレーショナル・データベースに格納するには向いていませんが、XQueryであれば、数量化された情報を効果的にXML文書から直接取り出すことができます。しかし、純粋なデータのみを含む文書の場合は、リレーショナル・データベースで操作した方が依然として効果的です。

結論

XQueryは、XML文書内のデータを操作する強力な文法を提供します。XQueryは、記述テキストと数量データの両方を含む文書を扱うのに最も向いています。XQueryを使ってこのような種類の文書を操作する際、最高のパフォーマンスを得るには、何らかの索引付きXMLリポジトリーに文書をロードしてください。

W3Cがこの仕様を夏にリリースするかどうかは断定できません。現時点で、解決すべき大きな問題がまだ残っています (たとえば、XPath 2.0式用の予約語を設けるかどうか)。こうした問題の解決には、確かに時間がかかるでしょう。それでも、我々が文書のニーズに敏感であれば、このテクノロジーが広く使用できるようになったとき、最大限に活用できることでしょう。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=243018
ArticleTitle=データ用のXML: XQueryの紹介
publish-date=02012002