|
||||||||||||||
| 前のページ 1 2 3 4 | ||||||||||||||
| 変化を阻む万里の長城 | ||||||||||||||
|
実はプログラム言語のレベルでの「変化を抱擁する」ための手法はエクストリームプログラミングなどにより、事実上完成しているということができる。 それにも関わらず、「変化を抱擁する」システムが増えたという話はまったく聞かれない。その理由の中には、もちろん新しいスタイルを知らない古い技術者が多いなどの理由もあるだろう。だが、それだけではない。 実はシステムが「変化を抱擁する」ことを妨げる巨大な壁が存在しているのである。 それはデータベースである。プログラム言語がいくら変化を手に入れても、データベースが変化を拒む限り、システムは変化を抱擁できない。 では、変化を拒むデータベースとはいったい何だろうか。それは現在のデータベースの主流となるRDB(リレーショナルデータベース)である。しかしRDBが変化を妨げるというのはどういうことだろうか。 その秘密は「正規化」という手順にある。RDBはデータベースを設計する際に、正規化という手順を必要とする。正規化によって、データをどのように分割して保存するかを確定する。 ここで問題になるのは、保存すべきデータの種類が変わる場合である。つまりデータベースが扱う情報の種類が追加・削除される場合である。情報が追加・削除されれば、RDBは「正規化」をやり直さねばならない。 それによって、データの分割方法が大きく変わらない場合は良いのだが、これが変わってしまうと大変なことになる。これは、データベース内でのある情報が置かれた場所が変わるということなので、プログラムの大規模な変更が要求されてしまう。また、データベース本体も構造を変換しなければならない。変換中は業務が止まるかもしれないし、万一変換中にデータの欠落などがあれば、大問題である。 ![]() 図2:変化とRDB RDBにおいては、できるだけ変化を回避しようとする態度を取ることが正当だといえる。RDBにおいてデータを変化させることは、たとえ僅かなデータの追加であっても、大規模なシステムの変更につながる可能性が存在するのだ。寓話ドラマのラストシーンで、技術者が法外な値段と長い納期を提示したのは何ら不思議なことではない。 だからこそRDBを扱う技術者が、それを全力で回避しようと努力を払ったとしても何ら不思議ではない。寓話ドラマの中で設計変更を求めたときに、逆に激怒して「それを解消するために説得するのがあなたの仕事だろう!」と正当な変更要求を他人の努力不足に責任転嫁してしまうのは、データベースの設計変更を回避するためだといえる。 |
||||||||||||||
| 取りこぼされるニーズ | ||||||||||||||
|
さて、ここで重要なことを述べておこう。 世の中には、それほど大きな変更要求にさらされていない業務と変化し続ける業務が存在する。前者はRDBでも十分に実用的なシステムを構築することができる。そのため、RDBに実用性はない…、と言い切ることは間違いだといえる。分野によっては、RDBは十分に強力であり、問題解決能力を持つ。 しかしすべての業務に対して問題解決能力を持っているわけではない。それが、RDBによって取りこぼされたニーズである。そして、ほとんどの場合RDBを中核にしてシステムを構築してみせる現在のIT業界が取りこぼしてきたニーズである。 「本当にそのようなニーズがあるのだろうか?」「RDBであらゆるシステムを上手く構築してきたのではないか?」という疑問を持つ方も多いと思う。 その答えは簡単である。 まず筆者自身が取りこぼされたニーズを持つ者であり、まるでそのようなニーズが存在しないかのようされてきた数十年の歴史を刻んできた事実がある。 そして、2005年より徐々に起こりつつあるいわゆる第2世代XMLデータベース・ブームの担い手達も、実は同じように取りこぼされたニーズを持つ者たちであったといえるのである。 次回は、いかにしてそのようなニーズとXMLデータベースが結びついていくのかについてと、XMLデータベースの特徴や種類を解説していく。 |
||||||||||||||
|
前のページ 1 2 3 4 |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||


