目次


XMLの論考: 第8回

XMLを階層モデル、リレーショナル・モデル、オブジェクト指向モデルに適応させる

Comments

XMLはきわめて用途の広いデータ移送 形式ですが、XMLに高い期待が寄せられるにもかかわらず、データの保管 およびアクセス の形式としては平凡で貧弱です。複雑なデータを迅速かつ信頼できる方法で照会できる (SQL) リレーショナル・データベースを、まだまだ捨て去るべき時ではありません。では、XMLとリレーショナル・データ・モデルはどのような関係があるのでしょうか。より具体的には、XMLとリレーショナル・データベースの間でデータを移送し、この両方を有効に活用できるようなプロジェクトをどのように設計すればいいのでしょうか。このコラムでは、コンピューター・サイエンスの専門家たちによって考え出されたデータ・モデル という抽象的な論理が、特定の多重表記型データ・フローを設計するうえでどのように役立つかを示します。将来のコラムでは、移送を援助してくれる特定のコードやツールについて見ていきます。今回のコラムでは、設計について考慮します。

データ・モデル

XMLの話は少し後回しにするとして、まず抽象的データ・モデルについて説明しましょう。特定のプロジェクト要件のもとでの良きデータベース設計とはどんなものかについて、多くの研究がなされてきました。私は個々の要件よりもっと一般的なこと、つまりデータ・モデルのパラダイム (枠組み) に関心があります。

データベース管理システム (database management systems、DBMS) には従来から階層、リレーショナル、オブジェクト指向の3種類あります。一般的に言って、階層データベースは、1960年代にメインフレーム・データ処理テクノロジーとして登場しました。ネットワーク・データベース も階層データベースと同じようなものですが、ネットワーク・データベースの場合は多重の親子関係が可能です。1970年代になって、E. F. Codd氏らによる精密な数学的研究の結果、今ではすっかり普及したリレーショナル・データベース・モデルが生まれました。1980年代になり、主にオブジェクト指向プログラミングの普及が原因で、オブジェクト・データベースが広がりました。これはとくに、マルチメディア形式などのいわゆるリッチ・データ ・モデルによく適用されました。

現在のところ、大規模システムのデータ保管手法としては、リレーショナル・データベース管理システム (RDMS) が依然として主流です。階層データベースとオブジェクト・データベースは、特定分野の要件を満たすために利用されています。ただし、ここ何年もの間に普及した多数のDBMSは、オブジェクト・リレーショナル混合型でした。したがって、実際には、データ・モデル・パラダイム間の境界がいくらかぼやけてきたわけです。

階層モデル

階層データベース (HDBMS) では、まず、複数のノードからなるツリーを厳密に定義します。各ノードにはいくらかの識別データと、特定の子タイプの一連のサブノードが含まれます。同じレベルの兄弟ノードの間では、サブノードの数がさまざまに異なりますが、「いとこ」のタイプはすべて同じです。図1はこの関係を示しています。

図1. 仮想的な階層データベース・モデル
図1. 仮想的な階層データベース・モデル
図1. 仮想的な階層データベース・モデル

階層データベースの場合、データ・アクセス方法は構造に従って完全に予測できます。このため、検索と更新のどちらもDBMSによって高度に最適化できますす。たとえば、上図のモデルでは、次のような疑似照会構文を使って特定の本の発行者を検索できます。

リスト1. 図1の階層データベースでの一般的な照会
Programming/C.J.Date/An Introduction to Database Systems/Publisher?

リスト1のような照会では、指定されたデータまでの正確なパスが示され、DBMSはバランス・ツリーとバイト・オフセット・コーディングで簡単に判別することができます。まったく同じ (固有の) 形式を使って、別のカテゴリー、著者などの中からどんな本の発行者でも照会できます。引き続き上記のDBMSの例に従えば、より一般的なプロシージャー照会を、リスト2のような (Python風の) 疑似コードとして作成することができます。

リスト2. プロシージャー・スタイルの一般的なデータベース照会
for book in get_children("Programming/C.J.Date"):
 print book.field("Title"), book.field("Publisher")

ここまでのところで、XMLプログラマーの読者は、疑似照会の構文がXPath (XML Path Language) にとてもよく似ていること、そしてプロシージャー疑似コードがDOM (Document Object Model) にかなり似ていることにお気付きでしょう。他のモデルについて説明する間、この点をどうか忘れないでください。

リレーショナル・モデル

リレーショナル・データベースは一連のテーブルから成り、各テーブルは、固定数の列 (フィールド ともいう) の集合で構成されます。各テーブルには、可変数の行 (またはレコード) が入ります。ただし、各行には一意的な基本キー (1次キー) が必要で、このキーはその特定のデータを表す名前のようなものです。図2はリレーショナル・データベース構造を表しています (先ほどの階層データベースの例とほぼ同じデータです)。

図2. 仮想的なリレーショナル・データベース・モデル
図2. 仮想的なリレーショナル・データベース・モデル
図2. 仮想的なリレーショナル・データベース・モデル

通常、テーブルには1次キーに加えて2次キー がいくつかあります。2次キーは、他のテーブルの1次キーです。たとえば、図2ではBOOKSテーブルに2次キーAuthorID (著者ID) およびPubID (発行者ID) があります。これらのキーは、それぞれテーブルAUTHORSおよびPUBLISHERSの1次キーです。ここでの考え方は、BOOKSの各行には固有のISBN値、AUTHORSの各行には固有のAuthorID、そしてPUBLISHERSの各行には固有のPubIDが存在するということです。

テーブル間の関係 を定める制約として、たとえばBOOKS内の各行に対応して、BOOKSで使われるPubIDを持つ1つの行がPUBLISHERS内に存在しなければならない、というように宣言できます。このように1つの発行者が複数の本を「持つ」ことができる場合を、1対多 関係といいます。一方、1人の著者が複数の本を「持つ」ことができ、しかも1冊の本が多数の著者を持つことができるような場合を、多対多 関係といいます。説明を省略しますが、このほかにも、1つの1次キーが必ず1つの2次キーにマッチする1対1 関係を定義できます。これらの規則は、RDBMSによって実施されます。

リレーショナル・データベースでは、微妙な判断が必要となり、テーブル設計が非常に複雑になることがあります。設計の際、テーブルの正規化 が最重要課題になります。正規化の最初の5つの「形態」をまとめて言うと、正規化の目的は、データ保管方法において余分なものをすべて取り除くことです。キー以外の各データを、ただ1つの 場所にだけ格納しなければなりません。この目標は階層データベースではほとんど自動的に達成されますが、リレーショナル・データベースではかなりの作業を必要とします。たとえば、図2 に示された例は、おそらく正規化の問題をかかえることでしょう。それぞれの本に複数の著者が対応し得るのであれば、第2の著者をデータベースのどこに保管すればいいのでしょうか。実際、唯一の解決策は、BOOKSに余分の行を1つ追加することです。しかし、そうする場合、単に2番目の著者だけのために同じPubID、Date、Titleを繰り返す必要があります。これには余分な記憶域が必要なだけでなく、各行のTitleが正しくマッチしなくなって誤りの原因となる危険をはらんでいます。これを解決するために、設計を考え直す必要があるかもしれません。テーブルや関係をもっと作成しなければならないでしょう。

階層モデルと比べて、リレーショナル・モデルは非常に複雑です。しかし、複雑であるがゆえに機能も強力になるのです。RDBMSに対して、実質的にどんな 質問でも照会することができます。HDBMSの場合は、システム内に設計された質問しか問い合わせられません。たとえば、1970年より後に生まれた著者を知りたい場合、上記の例のようなHDBMSで答えを見つける唯一の方法は、すべての 本の葉ノードを1つずつ検索するという途方もない作業です。RDBMSでは、リスト3のような単純なSQL照会で済みます。

リスト3. RDBMSのSQL照会
SELECT AuthorName FROM AUTHORS WHERE AuthorBDay &gt 1970

もっと複雑な質問の場合、複数のテーブルを結合する 必要がありますが、正規化を使えば複雑な方法でそれを行なうことができます。たとえば、上記の例でRandom House社を発行者とする著者を照会するには、次のようにします。

リスト4. Random House社から発行されている本の著者を検索する一般的な照会
SELECT AuthorName
FROM AUTHORS a, BOOKS b, PUBLISHERS p
WHERE AuthorBDay &gt 1970
 AND a.AuthorID = b.AuthorID
 AND b.PubID = p.PubID
 AND p.Publisher = "Random House"

リスト4の照会では、必要な関係をいくつか宣言しています。これはテーブルのフィルターのようなもので、それぞれのフィルターで検索を絞り込んでいると考えることができます。RDBMSでは、これらを内部的に自由にインプリメントできます。ここで、次の各ステップを考えてみてください (照会の指定とは逆の順序ですが、照会条件はどんな順序でも指定できます)。

  1. PUBLISHERSを "Random House" (PubID 03-4472822) のみに絞り込む
  2. そのPubIDを持つBOOKSだけに絞り込む
  3. こうして見つかったBOOKS 行のAuthorIDのリストを作成する
  4. そのAuthorIDを持つAUTHORS行の中で、該当するAuthorBDayの著者を調べる

リスト4のような照会の問題点は、多数のステップを必要とすることです。その中には、リソースを消費するステップもあるでしょう。HDBMSでは簡単にできるのに、RDBMSでは比較的難しい操作もあることでしょう。しかし、HDBMSで極端に 困難な作業が、ほとんどの場合、RDBMSではそれほど 難しくないのです。

オブジェクト・データベース・モデル

オブジェクト・データベース (ODBMS) は、いくつかの点で階層モデルへの逆戻りです。ODBMSのオブジェクトはオブジェクト指向プログラム言語のオブジェクトとよく似ていて、データや振る舞いを束ねたものです。この意味で、オブジェクトは、同じように下位ノードの束を含むHDBMSの分岐ノードに似ています。

オブジェクト・データベースには、次のような独特の特徴があります。

  • さまざまな異種オブジェクトを混合でき、各オブジェクトには「所有された」データの集まりが格納される
  • オブジェクトに、継承された「知能」を格納することができる

こうした特徴は、簡単に説明しておく価値があります。まず、他のモデルの場合と同様に、図で説明しましょう (図3をご覧ください)。

図3. 仮想的なオブジェクト・データベース・モデル
図3. 仮想的なオブジェクト・データベース・モデル
図3. 仮想的なオブジェクト・データベース・モデル

1つのODBMSにさまざまな異種オブジェクトを格納できるので、まさに必要な情報のみをそれぞれのデータの束に含めることができます。分かりやすくするために、図書館 (ライブラリー) の本に関するレコードだけを扱っていたデータベースの例を拡張しましょう。図3は実際のオンライン・ライブラリーに近いもので、コンテンツがデータベースの中から送り出されます。サウンド、e-text、ムービーなどの異種メディア用にさまざまな記述情報が必要とされます (そして、さまざまな内容のビット・ストリームが含まれています)。既知のObjectIDが各オブジェクトをポイントしますが、オブジェクトにはHDBMSのように厳密に定められた下位ノードが存在するわけではありません。

ODBMSのオブジェクトの属性やデータはさまざまに異なるので、オブジェクト照会には多くの場合、複数のメソッドをまとめて使用します。それぞれのオブジェクトは、そのオブジェクト自身に適切な方法でこれらのメソッドをインプリメントします。図3の例で言うと、「要約」および「移送」の2つのメソッドが考えられます。本の要約は抄録から取り出し、ムービーの要約は予告編から得ることができるでしょう。各オブジェクトには、自分自身をどんな方法で要約すべきかについて認識する知能があります。「知能」とは、そのオブジェクトのメタデータのことだと考えることもできます。

Object Database Management Group (ODMG) はODBMSの標準的な照会言語を提案し、これはOQLと呼ばれています (参考文献を参照)。

XMLはどれにフィットするか

XMLに詳しい読者ならもうお気付きと思いますが、XMLはこれらを混合したようなものです。XMLはデータ・モデルの中ではおそらくオブジェクト・データベースに最も近いでしょう。XMLもまた多数のノードから成り、ノードの中にはさまざまな異種データが含まれるからです。他方、各ノードのデータがどの程度異種であるかは、XML文書の構造を定義するDTDまたはスキーマにかなり依存します。XHTMLやDocBookの場合、あらゆる要素があらゆる場所に現れ得ると言っても過言ではありません。しかしデータ・レコード指向の強いDTDでは、XML文書は階層データベースと同じくらい厳密に定められています。XMLは移送 形式としては、DTD (スキーマ) が正しい限り、オブジェクトと階層のどちらも詳細に表現できる十分な機能を持っています。

XMLでリレーショナル・データベースを表現するのはやや不自然です。「やや不自然」とは厳密にどういう意味かを述べる必要があるでしょう。XMLには、RDBMSから取り出されるものを適切に表現する能力は確かにあります。それぞれのテーブルを直接的に表記することもできます (ただし実際のRDBMSよりかなり冗長になりますが)。たとえば、リスト5のようなDTDを作って、サンプル・データベースのBOOKSテーブルを表現することができます。

リスト5. BOOKSテーブルを表現するDTD
<?xml version="1.0" encoding="UTF-8"?&gt
<!ELEMENT BOOKS (BOOK*)&gt
<!ELEMENT BOOK (ISBN,AuthorID,PubID,Date,Title)&gt
<!ELEMENT ISBN (#PCDATA)&gt
<!ELEMENT AuthorID (#PCDATA)&gt
<!ELEMENT PubID (#PCDATA)&gt
<!ELEMENT Date (#PCDATA)&gt
<!ELEMENT Title (#PCDATA)&gt

より豊富な型を使用するにはスキーマを使う必要がありますが、要するに、特定のRDBMSテーブルをXMLとして表記することには何の問題もありません。

同様に、(リスト3 およびリスト4 のSQLの例のような) 特定の結合もまた、XMLで簡単に表現できます。実際、照会結果をXMLで表記することは、XMLをRDBMSで利用するうえで最も便利かつ一般的な方法です。通常、特定の接続先つまり要求者にとって必要なのはデータ・セット全体ではなく、その一部を何らかの形でフィルターして構造化したものです。SQLのGROUP BY文節とSORT文節は、今回のコラムで紹介した例よりも多くの構造化機能を持っていますが、そのような結果もまた、XMLノード階層によって表現できます。

XMLの普及 (そしてXMLによる独占) を目指すうえで最も問題になるのは、RDBMSの中心に関係 という概念があることです。とくに、テーブル間の制約が問題となります。制約が実施されるからこそ、RDBMSは強力で役立つのです。一連の制約を転送するためにXMLで表記することは確かに可能ですが、XMLには、こうした制約を実施する機能がそもそもありません (DTDやスキーマは別の種類の、より限定された制約です)。制約が不可能であれば、単純に言って、そこにあるのはデータ・モデルではなく単なるデータです。

XMLを支持する一部の人々はRDBMS型の制約をXMLに付け加えるよう提唱しています。また、RDBMSの中にXMLを何らかの形で深く構築することを提案する人々もいます。私の意見では、こうした案はどれも専門的見地に立った考えから出たもので、きわめて不適切だと思います。主要なRDBMSベンダーはリレーショナル・データベースの改善、とりわけパフォーマンス最大化に長年の努力を費やしてきました。堅固で信頼性の高いリレーショナル制約を、いとも簡単にXMLで表記できるようになるはずがありません (実際、XMLは別のモデル・パラダイムに近いのです)。さらに、XMLの冗長さと形式のゆるやかさは、固定長レコード、圧縮記憶形式などを駆使してパフォーマンスの最大化 (および、2次的な目標として高い信頼性) を目指すRDBMSのストラテジーとは本質的に逆です。言い換えると、汎用的なデータ移送メカニズムとしてのXMLには大いに期待をかけて結構ですが、同時に、あなたのバック・エンド・データをDB2やOracle (あるいは小規模システムであればPostgresやMySQL) など、当初の設計どおりの形で残しておくことが必要です。


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


関連トピック

  • リレーショナル・データ・モデルを紹介した最初のペーパーは、"A Relational Model of Data for Large Shared Data Banks," です (E.F. Codd, Comm. ACM 13 (6)、June 1970、377-387ページ)。
  • リレーショナル・データベースの理論を学ぶための標準的な優れた参考書は、An Introduction to Database Systems (Introduction to Database Systems第7版) です (C. J. Date著、Addison-Wesley Pub Co、1999年、ISBN: 0201385902)。
  • XMLを (Pythonで) オブジェクト指向風に簡単に扱えるようにする2つのツールは、David Mertzによるxml_objectify およびxml_pickle です。詳しくは、連載記事XMLの論考 第1回 (xml_objectify)、およびXMLの論考 第2回 (xml_pickle) をご覧ください。これらのツールは、xml_pickle およびxml_objectify からダウンロードできます。
  • Object Database Management Group (ODMG) ホーム・ページは、データ移送形式としてXMLを利用するうえでもう1つの情報源です。
  • David Mertzによるこれまでの「XMLの論考」コラム
    • XMLの論考 第1回ではPython xml_pickleオブジェクトについて紹介しています。
    • XMLの論考 第2回では、Pythonのxml_objectifyの使用方法を説明しています。
    • XMLの論考 第3回では、DocBookについて紹介しています。
    • XMLの論考 第4回では、第3回の続きとして、DocBookを使ってレガシー文書のアーカイブを構築する方法について説明しています。
    • XMLの論考 第5回では、XSLTを使ってXML文書をHTMLに変換する方法を説明しています。
    • XMLの論考 第6回では、いくつかのXMLエディターを比較し、とくに大量のテキストを扱う文書に適しているかどうかに焦点を絞ります。
    • XMLの論考 第7回では、DTDとXML Schemaを比較して、W3C XML Schema仕様が進展するにもかかわらず、開発者はどんな場合に引き続きDTDを使用できるかについて提案しています。

コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=XML
ArticleID=240798
ArticleTitle=XMLの論考: 第8回
publish-date=04012001