SE関のノーツ/ドミノ徒然草

第2回 やわらかさが身上のノーツデータベース

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:SE関のノーツ/ドミノ徒然草

このシリーズの続きに乞うご期待。

ノーツデータベースを理解するための端的な言葉としてまずあげたいのが『やわらかさ』という言葉でしょう。ソフトウェアの世界に『やわらかい』とか『かたい』とかという言葉はあいまいだとお叱りをうけそうですが、一言で言い表せといわれればこの言葉が私の頭には浮かびます。『やわらかい』というのは良く言えば、いろんなものが入り、柔軟で変更しやすいというイメージです。一方悪く言えば、あいまいでしっかりしていないと言ったところでしょうか。これではまだ良く分からないでしょうから、具体的に反対の『かたい』データベースを引き合いに出してみましょう。

『かたい』データベースの代表格はやはりリレーショナルデータベース(RDB)でしょう。全てのデータを複数のテーブルで表現し、共通するデータは正規化と称してキーを元に小さなテーブルにどんどん分離したテーブルに保存し、常に矛盾なく誤りのない完全なデータを保証するようにするデータベース。必要とあればユーザーの要件に応じて複数のテーブルからあらゆる仮想的な視点を作成してキーを元に高速にアクセスできるようにしてくれるデータベース。まさにマシーンと呼びたくなるような響きです。たしかに昔からコンピュータに求められてきたのは、間違いがなく、矛盾がなく、完全なデータを高速に扱う『マシーン』でした。

コンピュータがビジネスの世界に入ってきて半世紀近く。たしかに多くのビジネスデータがコンピュータに入れられ、データベースで管理されてとても便利になってきました。しかしあたりを見回してみるとどうでしょうか。オフィスには大量の紙があふれ、コンピュータに入らないデータがいたるところにあり、ファイルキャビネットやバインダーには誰も探せない埋もれた紙が静かに眠っています。一方ビジネスの猛烈な変化スピードは新たな文書や今までの文書の改訂版をどんどん生み出しています。このような世界に『かたい』データベースは使えないのでしょうか? もちろんきちんとしたデータ理論に基づいたRDBでしたらそれは可能でしょう。文書のデータを分析し、ダイアグラムを描き、正規化し、モデルを作り、画面を設計し、開発をし、テストをする。ところが開発が終わったころになると、『新しい項目を加えたい』『画面を変えたい』『フォームを加えたい』などなど変化がやってきます。そしてその変更を検討して開発が済んだころにはまた同じことがやってくるのです。何が問題でしょうか?

たしかに良いデータベース、良いシステムのためには分析や正規化などの順序だったステップが必要です。これを怠ることは高速で完全なデータを放棄することになってしまうでしょう。でも考えてみてください。これらのデータベース化されていなかった文書はもともとコンピュータに入らなかったのです。それはその文書の多様性、あいまいさ、変化の速さなど、いろいろな理由があるでしょう。それがもし多様なままで、あいまいのままで、変更もすぐにできる状況のままでコンピュータに入ることで、自由な検索や人との共有ができるようになるという大きなメリットがあるはずです。まさにノーツデータベースはこの線を狙ったものです。

データベース

データベース
ノーツデータベースではその基本単位が文書です。つまり世の中の紙のフォームに近いものがそのままノーツデータベースの基本単位になっているのです。ノーツの文書の設計をすることは、即ちデータベースの設計であり、と同時に画面までいっしょに設計してしまいます。また設計しているときはノーツクライアントですでに開発自身を行っていることです。そうそうデータの分析はというと、同時進行でデータが数値かテキストか、あとはいろいろ貼り付くリッチテキストかぐらいしか決めません。データのそれぞれの長さはいっさい決める必要がありません。厳密なことはとりあえずさておいてともかくノーツクライアントで開発してしまう。これで分析と設計と開発が同時進行します。どちらかと言えばこの同時進行を何度か繰り返すプロトタイピングでの開発がノーツの開発として典型的な例でしょう。

さてたいへん安易に開発が進んでしまいました。データの正規化はどこに行ったのでしょう。ある報告書にその記入者の組織が入っていたとしましょう。その人の組織はしょっちゅう変更があるとしたら、RDB的に考えれば人がどの組織に属しているか別テーブルにしておけば組織の変更があってもどこに使われている組織名でも最新に保つことができます。でもノーツはこう言うでしょう。『記入時点の組織名のままで何か困りますか?』と。現実の世界でも一度書いた報告書の記入者の組織名が古いからと言ってその報告書は使い物にならないなんてことはないでしょう。むしろ報告書が見つけられればそれで御の字と言う場合も多々ありです。正規化してすべてのデータを最新に保つようにするためにお金をかけるより、すぐに報告書を他のキーや全文検索で探し出せることのほうがよっぽど重要という考え方です。もちろん短期間でそれらのシステムが開発できてです。

加えてビジネスの文書にはいろいろな添付資料もクリップなどでつけます。写真も時としてつけます。また誰かが見た後にコメントをつけておきます。これらは文書には日常よく起こりうることですからノーツデータベースもまじめにサポートしています。他のワープロで作成した文書を文書上に添付したり、ビットマップを参考のため貼り付けたり、そして元の文書の付属の文書(子文書)として、まるでクリップで止めているように他の文書を何ら特別なキーなど作成せずに関連付けておいたり。まさにノーツはオフィスに散乱している紙の文書をコンピュータにできるだけ自然にのせようとするものです。当然紙に近いものですから項目の追加もたいへんに楽です。試しにすでに存在するノーツデータベースの開発者にこう質問してみてください。『機密文書かどうか記入する新しい欄を作ってほしいのだけどどのくらいかかりますか?』と。おそらくこんな答えが期待できるでしょう。『そのくらいだったら1時間待ってくれますか?』。『画面設計はどうしようか。古いデータの移行はどうしようか。テストはどうしようか。新しいクライアントプログラムの配布はどうしようか。』このように考えてしまうあなたはノーツのエンジニアではなくRDBの良いエンジニアでしょう。

私どもが数多くのノーツデータベース設計を行うなかで、最も教訓的なのは『RDB的に考えてはだめ』ということです。もちろんノーツでもとことんプログラミングさえすればRDB的なアプリケーションを開発はできます。しかしその結果としてできあがるのはノーツの顔はしているものの、たくさんのプログラムコードによって極めて遅くなった、またそのためほとんど変更も恐くてできないような代物です。それを思い出すたびに『RDBで作ればよかった』という後悔の気持ちでいっぱいになるのは私以外にもたくさんいらっしゃることでしょう。

1993年にLotus社の副社長のFrank Ingariが言った言葉を引用しておきましょう。『文書というものをRDBでサポートしようとすることは、象に飛ぶことを教えるようなものだ』。最後にRDBの名誉のために一言加えておきましょう。『完全なテーブルをノーツでサポートしようとすることは、魚に歩くことを教えるようなものだ』


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=338994
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第2回 やわらかさが身上のノーツデータベース
publish-date=07252004