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

第25回 シングルDBアプリケーション設計のすすめ

Comments

コンテンツシリーズ

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

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

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

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

複数のデータベースから構成されるアプリケーションは実にユーザーにとっては困ったものです。まずはせっかくデータベースアイコンがアプリケーションの入り口として整理できていたワークスペースが、新しいアプリケーションを登録したとたんに突如として意味不明のアイコンのタイルで埋められてしまうのです。以前は一つ二つと、何か作業用のデータベースでもできたかなと思いきや、最近では一つのアプリケーションの利用で、またはあるアプリケーションの機能を使っただけでデータベースアイコンが増えていきます。ユーザーとしては新しい別のワークスペースに、クリックすることのないデータベースアイコンを、蓋をするかのように隠してしまうくらいしか自衛手段はありません。

またこのような見かけの問題だけでなく、決定的に困ることがあります。モバイルでの利用です。オンラインでモバイルだとなんとかなるものの、飛行機の上とかオフラインのモバイルで利用しようと思っているデータベースをローカルに複製しても、それだけでは稼動せず、実はこのデータベースもこのデータベースもと複製をとらないと稼動しないということはしばしばです。中には、巨大なデータベースとリンクしていてその複製すらできない大きさのものもあります。

ではこのような複数データベースでのアプリケーション設計は果たして必然的なのでしょうか。一般のリレーショナルデータベースの専門化に聞けばデータの正規化からそれは必然ですと言われるでしょう。たしかにごもっともです。データをデータベースに入れる際に、正規化と称してコードをデータに割りつければ当然そのコードが一覧されているマスターデータベースが必要となってきます。入力データの正確さを求めるばかりに、多くのフィールドにコードを利用すればそれに伴いマスターデータベースがいろいろと必要になってきます。でもそうでしょうか。ノーツはもともとデータを正規化せずに非定型や半定型のままテキストで入力できるようにしてきたものです。このあたりにアプリケーションを少ない数のデータベースで実現するヒントが隠されているような気がします。

現実的な方法を考えましょう。まずは簡単なコードの一覧表、たとえば製品の種類などを入れるフィールドがあったとします。製品の種類であればそんなにたくさんの数がないかもしれません。それなら同じデータベースの別のビューなどを作って、フォームの名前を変えて入れることもできます。これなら同じデータベースの中にマスターの表を入れられます。

もちろんこんな表が全てのデータベースにそれぞれあったらデータのメインテナンスもたいへんです。そのときはそんな単純なマスターの表をできるだけ集約して一つのマスターのデータベースにしてしまうという逃げもあります。これなら最終的に一つのデータベースからなるアプリケーションとまではいきませんが、訳のわからないデータベースアイコンは激減します。また人の名前を引くようなアプリケーションだったら公開アドレス帳や漢字アドレス帳を使えばこれも汎用のマスターデータベースとなるでしょう。

もっと大胆なアイデアもあります。データの正規化をやめることです。例えば住所を入れさせるフィールドがあったとします。最近は親切に都道府県のフィールド、市町村のフィールドと分けて、マスターデータベースをそれぞれに持ち選択させるようなものが見られます。でもちょっと考えれば、電子メールなどを打てるユーザー、つまり十分かな漢字変換ができるユーザーが"東京都"と入力するのと都道府県の一覧から東京都を選択するのとどちらが速いでしょうか。どっちもどっちと言えるのではないでしょうか。ユーザーに入力させてもたいした時間がかからないフィールド、またデータとして正確さがさほど問われないようなフィールドなら、すっぱりデータ選択でなくデータ入力させたほうがよほどユーザーのためではないでしょうか。

ここまで大胆にできなくとも、ちょっとおもしろいアイデアもあります。ユーザーに関連する情報、例えば組織や住所や電話番号などを、入力時ではなく後からサーバーエージェントで入れてやるというものです。ユーザーはノーツのIDファイルにより確実にその人なのですから、その人に付随する情報などは、その文書をサーバーで処理するときにサーバーエージェントがマスターを引いてデータを入れてやることすらできます。名づけてマスターとの遅延リンクと言ったところでしょうか。

これまではマスターとの連携で複数データベースになる例でしたが、別な理由で複数データベースにしている例もあります。データベースサイズの大きさです。ワークフローアプリケーションなどで膨大な申請書や文書を入れるために、その高速化などのためにその用途別にいくつかのデータベースに分けている例があります。ただこれも必ずしも用途別にせず、承認されたらとか、ある期日がたったら別のデータベースにうつすという別な切り口でのデータベース分割を考えれば、ユーザーにとってもっと自然なデータベースの分け方になるでしょう。ユーザーは必要でなければ承認後や期日の古いデータベースはワークスペースに登録する必要もないでしょう。

この他にメニュー的に複数のデータベースの入り口を一つのデータベースにナビゲーターでまとめている例もあります。この場合はユーザーは慣れてくればメニューでなく他のデータベースに直接飛びこむわけですから、まあこれは複数でもよいのかもしれません。メニュー用のデータベースアイコンが1つ増えるだけですから。

いかがでしょうか。はじめはどうしても複数データベースでなければと思っていたアプリケーションがちょっとしたアイデアで数少ないデータベースアイコンで済むようになるのではないでしょうか。そして究極はシングルDBアプリケーションです。もちろん全てがここまで行くのはノーツの今の仕組みでは困難でしょう。ただアプリケーション設計はやはりユーザーの使い勝手を考えるのは当然と言えば当然です。それによってユーザーは自由にそのアプリケーションの利用環境、つまりオフラインのモバイルでの利用を選べるようにもなります。オフィスにあるアプリケーションのほとんどをモバイル、しかもオフラインで利用できる姿は実にすばらしいものであり、またノーツの最大の強みでもあります。

アプリケーションは複数データベースになるのは仕方ないという既成概念。考えてみれば全てのデータを正確にそして即座に入力していくというリレーショナルデータベースのアプリケーション設計の概念に思えてきます。非定型、半定型という新しいデータのパラダイムを打ち出したノーツです。このような既成概念も一度疑ってみようではありませんか。それがユーザーに便利でやさしいデータベースとなることもあるのですから。


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


関連トピック


コメント

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=339078
ArticleTitle=SE関のノーツ/ドミノ徒然草: 第25回 シングルDBアプリケーション設計のすすめ
publish-date=12242006