レベル: 初級 David Mertz, Ph.D (mertz@gnosis.cx), Author, Gnosis Software, Inc.
2001年 5月 01日 このコラムは、ポータブルXML結果セットをRDBMSの種類に依存せず生成できるようにする、、パブリック・ドメイン sql2dtd および sql2xml ユーティリティーについての考察を取り上げています。リレーショナル・データベースからデータを抽出するSQL照会は、照会結果をXMLで表現するもので、これによりきわめて実用的な形で、非定型の文書タイプの情報を提供できます。
前回の「XMLの論考」コラムでは、さまざまなデータ・モデルの基礎になっている理論と利点のいくつかについて論じました。前回のコラムの結論の1つは、RDBMSが (正当な理由により) 広く普及していること、またこれに関連して、RDBMSの替わりになる のではなく、さまざまなRDBMSの間で データを移送する手段として、XMLが最も多く使用されているということでした。XPathおよびXSLTは、特定の「データ照会」目的では役に立ちますが、それらのアプリケーションは、RDBMSのアプリケーション、特にSQLに比べて、普及の度合いがはるかに低くなっています。ただし、紙面の都合がありますので、XPathおよびXSLTの特定の機能 (および制限) に関する話題は、後のコラムに回すことにします。
最近の多くのRDBMS (少なくともDB2とOracleはこれに該当し、そしておそらくその他についても同様です) は、XMLをエクスポートするための、組み込み (または少なくともオプションの) ツールを備えています。ただし、このコラムで採り上げるツールは、汎用のものです。特に、これらのツールによって生成されるDTDは、同じ照会が異なるRDBMSに対して実行された場合にも同一です。これにより、データの透過性という目標にさらに近づくことを願っています。
単純すぎる方法
リレーショナル・データベースのデータをXMLに変換するための最もわかりやすい方法は、通常はまずい方法です。つまり、表ごとにすべてのRDBMSの内容を対応するXML文書にダンプすることは、概念上も実際上も、十分に簡単です。たとえば、(前回の例を用いて) LIBRARYデータベースに、次のような内容のBOOKPRICEという1つの表が含まれているとします。
SELECT * FROM BOOKPRICE;
+------------+-------+
| ISBN | Price |
+------------+-------+
| 2994927282 | 34.99 |
| 3920202049 | 47.50 |
+------------+-------+
|
これをそのまま、次のような文書BOOKPRICE.xml に変換することもできます。
リスト1.BOOKPRICE.xml 文書
<?xml version="1.0"?>
<SQL>
<row>
<ISBN>2994927282</ISBN>
<Price>34.99</Price>
</row>
<row>
<ISBN>3920202049</ISBN>
<Price>47.50</Price>
</row>
</SQL>
|
データベース内のそれぞれの表ごとに同様のXML文書を作成すると、データベースの完全なスナップショットが得られます。
必要なだけ単純化した方法
上に示した方法には、2つの基本的な問題があります。第1の問題は、XMLダンプがきわめて非効率であるということです。XMLは、皆さんもよくお分かりのように、非常に冗長なフォーマットであり、大規模なデータベースのXMLダンプを行うと、さらに大きなXML文書のコレクションが出来上がってしまいます。そのうえ、主要なDBMSにはすでに、コンパクトで効率の良いフラット・ファイルまたはパック・レコード・スタイルのダンプが備わっています。上に示したXMLには、こうした単純なフォーマットに比べて追加機能があるわけでもなく、しかも移送ファイルのサイズを著しく大きくしてしまいます。
2番目の問題は、最初の問題よりも重要です。ある意味で「DASDは安あがり」であり、通信も安くなっています (「DASD」とは、「ハード・ディスク」を意味する古いIBM流の言い方であり、設計でよく使います)。したがって、単なる効率だけが、必ずしも決定的な要因になるわけではありません。さらに重要なことは、同僚、他の部門、あるいはユーザーなどにデータベースのすべての内容を伝える必要があることは、めったにないということです。ときには、個人的な内容が含まれていることもあります。また、ほとんどすべての場合、大部分の内容は個々の特定の受信者にとって無関係なものです。
役に立つSQL照会の結果をXMLにダンプすれば、未加工の表をXMLにダンプするよりも適切な内容になるはずです。また、DTDをこうした役立つ照会に関連付けて、XMLのトランザクション処理または提供に必要な、正確な構文解析と処理を常に期待できるようにできれば、さらによいでしょう。こうした2つの興味深い処理は、パブリック・ドメインのPythonユーティリティーであるsql2dtd とsql2xml を使用することにより、実現することができます。
仮に、AとBの双方が固有の内部データ保管ストラテジー (たとえば、異なるRDBMSへの保管) を実施しているとします。それぞれが、AとBの間での対話には関係のない、あらゆる種類の関連情報を維持し、しかも双方が、相互で共用したいような情報も所有しています。ここで、Aが特定の種類のデータ・セットを、頻繁にBに送る必要があるものとします。AとBにできることの1つとして、あらかじめ合意されたDTDに準拠するXML文書のセットを、AがBに対して定期的に送信することに合意する、という方法があります。送信時に送られるデータは、そのたびに異なりますが、妥当性に関するルールは前もって決められています。AとBはともに、相互の間のプロトコルを承知して、それぞれのプログラミングを行うことができます。
DTDの生成
AとBの間でのこの通信を促進させるための1つの方法は、AとBの特定の要求を満たすDTD (つまりスキーマ) を開発することです。その場合Aは、自分の現行のRDBMSから、合意されたDTDにデータをエクスポートするためのカスタム・コードを開発することが必要になります。またBは、同じデータを (異なる構造のデータベースに) インポートするための、カスタム・コードを開発する必要があります。その後でようやく、通信チャネルを開くことができます。
しかし、通常は、これよりも手早くできる方法 (既存のエクスポート/インポート手順の効率を高める可能性のある方法) があります。Standard Query Language (SQL) は、RDBMSデータベース内のどのデータがユーザーに有益であるのかを表現するための、すばらしくコンパクトな手段です。XPathやXSLTなどのXMLネイティブな技法をリレーショナル・モデルと組み合わせることは、おそらく不自然に思えるでしょうが、XMLの基本的に階層化されたモデル内で照会機能を表現することは、確かに可能なのです。
多くの組織は、すでに、既知のタスクを行うための、十分にテストされたSQLステートメントのセットを開発しています。現にRDBMSは多くの場合、保管照会文を最適化する手段を備えています。データ交換のための豊富な機能を持つDTDを設計することが理にかなっている場合も確かにありますが、たいていは、SQL照会に暗黙的に含まれている構造化情報をそのままXMLデータ伝送の基礎として使用することが、優れたソリューションとなる可能性があります。
SQL照会は表データを複雑な方法で結合することがありますが、SQL照会の結果 は、かなり単純な行と列の配置になっています。照会出力には、固定された数の列があり、各行にあるそれぞれの固定列に値が入ります。(つまりSQLの結果では、数が変わらないのと同様に、値のタイプも、列の名前も変化しません -- ただし、XML文書では、これらの両方を変更することができます。)複雑にネストされたエレメントのパターンを表現できるXMLの潜在能力は、SQL結果の表示という仕事ではあまり発揮されることがなさそうです。しかし、単なる行と列の位置だけでなく、SQL照会のいくつかの重要な働きをXML DTDで表現することは可能であり、また、そうすべきです。
SQL照会から何を表現するか?
AとBの間で今検討しているデータ交換を行おうとする場合、2つの側面を分けて考える必要があります。一方では、Aのデータの内部編成について考慮する必要があります。たとえば、正規化や非正規化による最適化が行われている可能性があります。Bは、Aの内部を問題にすることはなく、またその必要もありません。他方では、実際に何を送信するのかを記述するメタデータについて考慮する必要があります。もちろん、これらの2つの側面を切り離すことは、必ずしも容易ではありません。
sql2dtd の作成にあたり (また、Scott Hathawayのsql2xml の計画作成を手伝うにあたって)、私は、データ伝送の対象として何を含めるのか、また、何を送信側が内部的に設定できるようにするのか (そしてDTDで表現する必要がないものとするのか) を決定しました。リスト2に示したサンプルの (内部セットとしてDTDを使用した) XML出力は、これらの決定を理解するのに役立つと思います (この出力はすべて、属性として含まれているSQL照会によって生成されたものです -- もちろん、SQL照会を適切なデータベースに対して実行したときに)。
リスト2. 内部セットとしてDTDを使用したサンプルXML出力
<?xml version="1.0"?>
<!DOCTYPE SQL [
<!ELEMENT SQL (row)*>
<!ATTLIST SQL
GROUP_BY NMTOKEN #FIXED "AuthID"
query CDATA #FIXED "SELECT AuthID AS SSN,COUNT(GroupID)
FROM AUTHGROUP GROUP BY AuthID
ORDER BY AuthID"
>
<!ELEMENT row (SSN, column2)>
<!ATTLIST row num ID #IMPLIED>
<!ELEMENT SSN (#PCDATA)>
<!ELEMENT column2 (#PCDATA)>
<!ATTLIST column2 CALC CDATA #FIXED "COUNT(GroupID)">
]>
<SQL>
<row num="1">
<SSN>111-22-3333</SSN>
<column2>1</column2>
</row>
<row num="2">
<SSN>333-22-4444</SSN>
<column2>2</column2>
</row>
<row num="3">
<SSN>666-44-5555</SSN>
<column2>1</column2>
</row>
</SQL>
|
この簡単なXML文書には、実際には、見た目以上に多くのメタデータが含まれている可能性があります。もちろん、SQL自体をルート・ノードの属性として含めることにより、SQL内のどのような項目でも 暗黙的に再構成することができます。しかし、そうするためにはSQLを構文解析し直す必要がありますので (これについては、sql2dtd のドキュメントに記載してあります)、一般にはこれを行う必要はありません。
CALC 属性を指定することは、計算されるエレメントがXMLに含まれるという事実を意味します。計算される式が長くなったり、XMLタグとしては正しくない文字が含まれたりする可能性があるため、計算される列の名前には、その位置をそのまま使用しています。ただし、エレメントの内容に取り込まれる特定の計算は、タグの属性として含まれています。XML本体でこの属性が繰り返されないようにするために、DTDではこれが#FIXED として指定されています。
計算される列が使用される場合、"GROUP BY" 修飾子による列のグループ化が計算に反映されることがよくあります。このようなグループ化が行われる場合にはそれらはすべて、ルート・エレメントのGROUP_BY 属性中にリストされます。
さらに、"ORDER BY" 文節が使用される場合、それぞれの<row> タグには、出力データの順序を指定するnum 属性が付けられます。ただし、結果セットが順序付けされない場合には、num 属性は使用されません。
DTD内部で表現されていない内容について考え、それが実際に、送信されるメッセージではなく、Aの内部データ表現に関するものであることを確認しましょう。
組み込まれたオリジナルのSQL照会以外には、データの照会が行われた1つまたは複数の表に関する記述 ("FROM" 文節) は残されていません。特定の表の編成がどのようなものであるのかについては、Bは関心を払う必要がありません。事実、伝送プロトコルの設定後にAがデータベース設計を変更する可能性は大いにあります。しかし、Bは、なんらかの方法で同じフィールド (列) が抽出されているかぎり、そのことを考慮する必要がありません。特に、"AS" 文節は実際の表の列名を指定変更しますので、Aのデータベース内でリテラルとして直接の意味を持たなくなっているXMLエレメントを送信し続ける可能性があります。
sql2dtd の設計で最も重要なことは、"WHERE" および "HAVING" 文節 (そしてまた、JOIN、DISTINCT、およびALL修飾子) が無視されていることです。表名と同じように、Aの表からデータを入手するためにどのような結合およびフィルターが必要であるのかについては、Bは考慮する必要がありません。Aがなんらかのデータを得るためにいくつかの表を結合する必要が生じたとしても、それはAによる正規化ストラテジーにすぎません。Bは、(別のデータ・サブセットに関して) 類似のストラテジーを使用する場合もあれば、使用しない場合もありますが、いずれにしても、Aがどのような処置を取ったのかを気にすることはありません。フィルター (ほとんどの場合 "WHERE" 文節または "DISTINCT" 修飾子を使用します) も、それに似ていて、しかしやや異なる理由により、無視されます。なんらかの業務上の理由により、whatzit値が25を超えているwoozlesについてだけ、AがBに通知する必要がある場合、Bから見れば、whatzitが25を超えているというのはwoozlesの性質にすぎません。つまり、Bが気にとめていないwoozlesのサブクラスについて、Aが関心を持っている場合があるのです。しかし、Aが関心のある情報を入手するために (あるいは逆に、ある情報を除いたり、ある情報を別の表に入れたりするために) フィルターを使用する必要があったという特定の事実は、Bにとってどうでもよいことです。その点では、サブ選択もフィルターの一種にすぎません。
まとめ
sql2dtd とsql2xml の具体的な使い方については、何も示しませんでした。両方とも、関連ドキュメントで十分に説明されていますので、ここで採り上げる必要はあまりないでしょう。一般に、sql2dtd はSQL照会 からDTDを生成することができますが、それ自体でデータベースを照会することはありません。sql2xml はODBCを介して照会を行い、オプションでsql2dtd を使用してDTDを入手します (あるいは、DTDのないXML文書を生成することもできます)。
これらのツールは、AとBの間で起こると考えられるプロセスのうちの半分程度にしか役立ちません。AとBは、これらのツールを使用してDTDに迅速にアクセスすることができ、同様にAは、これらのDTDに準拠した出力XML文書を迅速に生成することができます。しかしBのほうは、依然として、これらの受信された文書の構文解析、保管、および処理に関するすべての作業を行う必要があります。この後のコラムでは、Bの仕事についてもう少し詳しく論じることにします。
参考文献
- 私の仲間のXMLゾーンのコラムニストUche Ogbujiが、RDBMS/XML接続に関して、この記事で述べたものとやや異なる要素を扱った、興味深い記事をLinuxWorld 誌に載せています。Ucheは、優れた記事を書いているだけでなく、広範な関連リソースのリストも載せています。
- 私のsql2dtd をオンラインで入手することができます。
- IBMのDB2 Extenderページには、DB2がXMLを扱う方法について基本的な概要を示し、PDFファイルとして表示可能な詳しいホワイト・ペーパーへのリンク、およびDB2 Extenderダウンロードへのリンクを提供しています。
- David Mertzのこれまでの「XMLの論考」もご覧ください。
-
XMLの論考 第1回では、Pythonのxml_pickleオブジェクトを紹介しています。
-
XMLの論考 第2回では、Pythonのxml_objectifyの使い方について説明しています。
-
XMLの論考 第3回では、DocBookを紹介しています。
-
XMLの論考 第4回では、引き続き、DocBookでレガシー文書アーカイブを構築する方法について説明しています。
-
XMLの論考 第5回では、XSLTを介してXML文書をHTMLに変換する方法について説明しています。
-
XMLの論考 第6回では、いくつかのXMLエディターを比較し、特に、テキスト中心の文書に適しているものを取り上げています。
-
XMLの論考 第7回では、DTDとXML Schemaを比較検討し、開発者がどのような場合に、成熟しつつあるW3C XML Schemaに背を向けてDTDにこだわりたくなるのかを示しています。
-
XMLの論考 第8回 では、コンピューター科学者たちによって概念化されたデータ・モデル という抽象的な理論が、特定の複数表現データ・フローを開発するために、どのように役立っているのかを説明しています。
著者について  | 
| | David Mertz氏は多くの分野で活躍しています。ソフトウェア開発や、それについて著述もしています。その他、学術政策理念について分野を問わず、関係する雑誌に記事も書いています。かなり以前には、超限集合論、ロジック、モデル理論などを研究していました。その後、労働組合組織者として活動していました。そして、David Mertz氏自身は人生の半ばにもまだ達していないと思っているので、これから何かほかの仕事をするかもしれません。 |
記事の評価
| 
