Why XML?

1.なぜXMLなのか(リレーショナルデータベースの限界)?
 1.1.表を基本としたデータモデリングの限界
 1.2.設計することのデメリット
 1.3.データの消失
 1.4.ユーザが手を出せない
2.入力データを全てXMLで記録
 2.1.入力画面とXMLによる記録
 2.2.XMLデータの加工
 2.3.更新処理
 2.4.データの一貫性
 2.5.システム変更
3.XML Table


MUSAHSIでは処理対象となるデータをXMLによって記述しています。
XMLについてはたのしいXMLOWL学習室ZVONのチュートリアルなどで非常にわかりやすく学習できます。ここではXMLに関する基本的知識があるという前提で話を進めていきます。

1.なぜXMLなのか(リレーショナルデータベースの限界)?

なぜMUSASHIではXMLを使うのかを見ていく前に、次の各質問について考えてもらいたい。

1.1.表を基本としたデータモデリングの限界

 企業の情報システムでは、通常、データの保管にリレーショナルデータベースを利用しています。リレーショナルデータベースは項目と行からなる表によってデータを表現します。しかしながら、企業での業務の流れを見ると、表で表現することが非常に困難な業務活動があります。身近な例で言うと、Excelを使って日記をつけることを考えて見るとよい。先の質問のxはまさにこの例である。業務は時間の経過と共に起こる事象であり、RDBに見られるような表を基本としたデータモデリングでは、通常、「商品」「顧客」「発注伝票」などの事物を中心としてモデリングされます。そのために、レジでの割り込みといった時間的な関係をモデリングするのは困難であり、またモデリングしても非常に複雑なものとなってしまいます。

1.2.設計することのデメリット

 さらにRDBで問題となることは、データベースの設計が非常に困難でかつ時間を要します。通常、データベースを設計する際には、システム部門と現場との打ち合わせで、必要なデータについて検討され、それらのデータを管理するためのデータ構造の設計に入ります。そして、データベースの専門家は、RDBの設計で求められる正規化や各種制約についてじっくり吟味し、できる限り完全な構造を設計しようとします。一旦完成したデータベースを、実際に運用が開始されてから修正することは非常に困難であるからです。
 このように設計活動が重要でありかつその修正が困難であるという事実は、ユーザを待たせることになり、ユーザから見ればいつまでたっても結果がでないという話につながってしまいます。そしてできあがった頃には、ユーザは既に他のことに興味が移り、もはやその結果を必要としないということにもなってしまいます。またユーザが思いとは異なった結果がでてきて、再度変更ということにもなりかねません。このRDBにおける設計の問題は、このようなユーザとの齟齬という問題以外にも、次にあげるような「データ消失」や「ユーザが手を出せない」という問題にもつながっていきます。

1.3.データの消失

 システム部門がRDBを用いてデータベースの設計をする際には、通常、「ユーザはどのような情報にアクセスしたいと考えているのか」など必要となる出力を想定します。そして、その想定以外の情報は切り捨てられる傾向にあります。先の質問Xにあるように、ユーザが「つり銭」の情報を必要としないという言うならば、その項目はデータベース項目からはずされるでしょう。しかし、レジの現場を見ると、つり銭は、レジのディスプレイにも表示されているし、レシートにも印刷までされています。次のような話があります。ある企業のコンピュータに詳しくない社長は、現場でレシートを見て、「コンピュータには、このレシートの情報が全て入ってるんだよな」とつぶやきました。この感覚はいたって正常です。しかし、データベース設計によって必要でないと判断された情報は、入力されているにも関わらず消失してしまっているのが事実です。「つり銭」の情報だけならともかく、「レシート番号」や「値引き金額」といった情報が失われているのもよくあることです。
 データマイニングという観点から考えると、これは重大な問題です。何らかの分析を売上データを元におこなおうとするとき、分析者はどのような項目が必要となるか前もって予測できません。突然「つり銭」情報が必要となる場合もあるかもしれません。そこで、我々は、「入力されたデータは、全て記録しておく」ということが決定的に重要であると認識しています。今や40Gバイトのハードディスクが数万円で手に入る時代で、物理的なコストは制約にならない時代です。そうなれば、いかにして記録するかが次に重要な問題となるわけです。そこでXMLに注目したのです。

1.4.ユーザが手を出せない

 最後に現在の情報システムの問題としてあげたいのが、ユーザがコンピュータに詳しくないために、企業の情報システムに対して手が出せないという問題があります。リレーショナルデータベースは簡単だという意見もあります。しかし現状はそうではありません。ちょっとした規模のシステムをRDBで構築している企業ならば、そのデータ構造を一般の人が理解するのは非常に困難でしょう。ユーザが「○○の項目を追加してくれ」とシステム部門に頼んだとして、「システム部門が××の理由で難しい」と回答してきたら、その時点でユーザは何も言い返せないのが事実です。ユーザから見ればRDBによって実装されたシステムは、単にシステム部門が用意してくれたメニューにしか見えない。コンピュータに詳しいユーザはSQLでデータベースにアクセスするかもしれない。しかしデータ消失の問題や設計の問題は依然として残り、なぜわが社のシステムはこんなに使えないんだと文句を言う。またSQLによる問合せで10分待たされたとすれば、「なんでこんなに遅いんだ」ということになってしまう。
 これは人間の心理の問題に大きく関わっている。ユーザからみればシステムはブラックボックスである。中身がわからないから10分待たされれば遅いと感じ、中身がわからないから設計変更の要求に1ヶ月待たされれば遅いと感じる。もしユーザがシステムの内容を熟知していれば、待たされる時間は遅いと感じないかもしれない。システムはより明示的にならなければならないと我々は考える。そしてユーザも簡単に理解できるようなものでなければならないと考える。しかし、そう考えるとリレーショナルデータベースは複雑すぎる。

2.入力データを全てXMLで記録

我々が提案する考え方はいたってシンプルである。入力データは全てXMLによって記録する。企業の情報システムに対しては、様々な形でデータが入力される。POSによる商品スキャン、商品マスターのメンテナンス入力、他社からのオンラインによる受注入力、営業担当者による返品入力など様々である。通常のシステムでは、 これら多様な入力減からのデータを一元的にリレーショナルデータベースで管理され、新たな入力データがデータベースの各テーブルに追加もしくは更新される。しかしRDBによるデータ管理には先に見てきたようないくつもの弊害がある。その弊害をさけるならば、いっそRDBを使わなければよい。そして入力されたデータは全て時間の経過に従ってXMLで記述していけばよい。ユーザから見れば、システムに存在するのは、入力されたデータだけ。そのデータだけを見れば、全ての情報がそこにはある。中身を見るには特別なソフトは必要ない。エディタもしくはブラウザーでそのファイルを開くだけでよい。システム部門のコンピュータにアクセスするのが怖ければ、そのファイルをコピーしてもらえばよい。非常にシンプル。

 さてオリジナルな発想は以上の通りであるが、ここで考えなければならない問題がいくつかある。

2.1.入力画面とXMLによる記録

ここでは簡単な受注処理プログラムを例に話を進めていく。通常、受注処理においては、図1に示されるような画面にて、担当者が電話を片手に入力を行っていくでしょう。

図1 受注画面

 この画面で実際に入力されるのは、顧客コード、商品コード、数量の3項目である。その他の顧客名、商品名、単位、単価といった項目は、通常、顧客マスターや商品マスターファイルから読み込まれ表示される。また金額や金額合計は計算項目で、コンピュータが計算して、これも自動的に表示してくれる。また日付や時間もコンピュータの内部時計に従って表示されるであろう。
 さて、このような受注画面に対してどのようにXMLで記述すればよいであろうか?データの重複を嫌う人であれば、この画面上で新たに発生した、入力項目および時間項目だけを記録すれば十分であると考え、図2に示されるようなXMLを記述するかもしれない。

図2
<?xml version="1.0" encoding="EUC-JP"?>
<受注伝票 番号="0001">
  <入力日付>2001/12/06</入力日付>
  <入力時間>10:15:20</入力日付>
  <顧客コード>0001</顧客コード>
  <明細 行="1">
    <商品コード>010001</商品コード>
    <数量>10</数量>
  </明細>
  <明細 行="2">
    <商品コード>010002</商品コード>
    <数量>1</数量>
  </明細>
</受注伝票>

しかし、このような記録には問題がある。1)商品マスターを参照して表示された情報が、今後永久的に残っているという保証がない。2)合計計算のプログラムにバグがあり、その時に間違った値が表示されているかもしれない。3)そして何よりも、後からこのXMLファイルを閲覧した人間にとって内容を理解しにくい(010001という商品は何かわからない)。このような理由から、入力者がコンピュータの画面上で確認したデータは全て残すべきである。それは図3に示されるようなXMLとなるであろう。

図3
<?xml version="1.0" encoding="EUC-JP"?>
<受注伝票 番号="0001">
  <入力日付>2001/12/06</入力日付>
  <入力時間>10:15:20</入力日付>
  <顧客コード>0001</顧客コード>
  <顧客名>お得意商事</顧客名>
  <明細 行="1">
    <商品コード>010001</商品コード>
    <商品名>USビーフ</商品名>
    <数量>10</数量>
    <単位>kg</単位>
    <単価>240</単価>
    <金額>2400</金額>
  </明細>
  <明細 行="2">
    <商品コード>010002</商品コード>
    <商品名>ミンチボール</商品名>
    <数量>1</数量>
    <単位>袋</単位>
    <単価>1200</単価>
    <金額>1200</金額>
  </明細>
  <合計金額>3600</合計金額>
</受注伝票>

 以上の記述方法によって、前に示した問題は解決された。誰が見てもその内容を理解できよう。我々も、現在のところ、XMLによるデータの記述に関する見解はこのレベルまでである。しかし、このような記録で十分であろうか?この方法は、「時間に従って生じた事象を順番に記録する」ということにはならない。すなわち、受注という行為について、だれかがXMLという言語をもちいてモデリングしたにすぎないのである。例えば先に示した「割り込み入力」はどのように記録すればよいのであろうか?
 これ以降の記述はまだ我々のアイデア段階として考えてもらいたい。我々が現在考える最良の記録方法は、あくまでも時間に従って生じた事象をその順序で記録するというものである。受注画面にしろ何にしろコンピュータ上で動作するものは全て何らかのプログラミング言語で記述されている。そして今日のプログラムは多くが構造化手法をもちいている。単位となる処理は一つのモジュールで記述される。そしてそれらのモジュールはXML同様ツーリー構造で記述されている。しからば、そのプログラムが処理の開始と終了に何をしたかについてXMLタグを吐き出せば、そのプログラムを動作させるだけで、XMLデータが出力されることになる。そして全てのタグには時間属性を加えるべきであろう。しかし物事はそう単純にはいかない。一昔前ならば、プログラムは上から順番に実行されるものと決めてかかれたが、現在のGUIの普及に伴い、特に入力画面においては、イベントによりプログラムが起動される方式に変わってきた。つまり各モジュールの呼び出し順序を想定することができなくなったのである。そうなると、モジュールが単にXMLタグを出力するだけで果たしてうまくいくのかといった疑問がでてくる。
 さて、XMLによるデータの蓄積に関してはいろいろ問題があるにしろ、入力されたデータを全て記録するにあたっては、その柔軟性からXMLによって記述することは非常に効果的であることに変わりはない。今後の研究により、どのように履歴データをXMLで蓄積させるべきかについて追求していく予定である。

2.2.XMLデータの加工

一旦XMLで蓄積されたデータをどのように加工していくのであろうか?これまでのRDBにかわって、XMLそのものをデータベースとして蓄積していき活用しようとする流れは、例えばYgdracillなどのソフトで積極的に進められている。しかしXMLのデータ構造は非常に柔軟である一方で、効率面において難がある。また、マイクロソフトのExcelがこれほどまでに人気をはくしていることを考えると、表によるデータの表現も、そのシンプルさから捨てがたいものがある。そこで我々が考え出したのがXML Tableである。簡単に言うと、データの保管はXMLで、処理はXML Tableでということになる。XMLデータを表構造のXMLtableに変換して処理を進めていく。詳しくは次の節にて。

2.3.更新処理
2.4.データの一貫性
2.5.システム変更

 さてMUSASHIは、データマイニグの実施においてこれまで利用され発展してきた。データマイニングにおいて利用するデータは、所与であり、これまでに論じてきた内容とはあまり関係のない世界かもしれない。しかし、同様の発想で効果的な基幹系の情報システムを既に構築してきた企業もあり、我々の単純な発想がいわゆる情報系のシステムだけでなく、基幹系のシステムにも十分に適用できると考えている。
 しかし、現在のところ、まだ基幹系のシステムとしてMUSASHIを活用していくということに関する十分な研究は間に合っておらず、上記の「更新処理」、「データの一貫性」、「システム変更の柔軟性」については、随時、明らかにしていく予定である。

3.XML Table

MUSASHIが処理対象とするデータはXMLで記述したXMLtableもしくはPlain Textの表データです。Plain Textを対象とした実績は5年ほどあり、非常に効果的であることがわかっています。しかし、Plain Textを対象とすると、項目を項目番号として指定する必要があり、項目の並びをどうしても意識しなければならないという欠点がありました。そこで今回XMLtableにより、項目を項目名で指定するという試みで開発を進めてきました。

それでは実際にXMLtableについて見ていきましょう。図4は、図3から変換されたXMLtableを示しています。

図4 XMLtable
<?xml version="1.0" encoding="EUC-JP"?>
<xmltbl version="1.1">
<header>
<field no="1" name="受注伝票_番号"></field>
<field no="2" name="明細_行番号"></field>
<field no="3" name="商品コード"></field>
<field no="4" name="商品名"></field>
<field no="5" name="数量"></field>
<field no="6" name="金額"></field>
</header>
<body><![CDATA[
0001 1 010001 USビーフ 10 2400
0001 2 010002 ミンチボール 1 1200
]]></body>
</xmltbl>

このデータは図3のXMLデータより図5に示すコマンドによって変換される。コマンドの詳しい利用方法についてはコマンドリファレンスを参照してもらうとして、ここでは、-kパラメータによって「/受注伝票/明細」のタグで囲まれる範囲を表の一行の単位とし、-fパラメータによって、受注伝票の番号属性、明細の行属性、商品コード、商品名、数量、金額を項目値として出力するという処理をおこない、結果として図4のXMLtableが出力される、と理解してください。

図5
xml2xt -k/受注伝票/明細 -f受注伝票@番号,明細@行,商品コード,商品名,数量,金額

このデータを見て分かるように、XMLtableは完全なXML文書です。そしてトップの要素<xmltbl>は、<header>と<body>の二つの要素をもちます。bodyタグには、表形式のデータが記述され、項目区切りとしてスペース、行区切りとして改行が用いられます。ここだけを見るとUNIXで標準となっているデータ構造で、awkやgrepといったツール群が適用可能な構造となっています。<body>タグの次に「<![CDATA[....]]>」なるタグがありますが、これはXMLパーサーに、内容をそのまま扱うことを指示します。XMLパーサーは通常タグ内の改行は無視し、一つのスペースとして捉えるために、このようなタグが必要となってきます。ただし、Xmltableを扱うコマンド群は、実際には<body><![CDATAという文字列を検索し、それ以降を表データとして扱うという処理をしているだけで、特にまじめにパースしているわけではありません。ただ、このように書いておくことによって、例えばInternetExploreなどのXMLを解釈できるアプリケーションで、このデータを表示したとき、きれいに表構造のデータが表示されます。もしCDATAタグがなければ、改行が無視されるために、一つなぎの文字列としてしか表示されません。
そしてheaderタグは、このデータに関する辞書として機能します。それぞれの項目に関する名前と位置情報が<field>タグによって記述されます。<header>タグ内には項目名や位置情報以外にも様々な情報が格納されます。

XMLtableに関する詳しい説明はここを参照してください。