思考支援：雑誌連載の内容：第26回 |
今号と次号の２回にわたって、値が変化するデータ、つまり値の履歴を持つ機能について解説していこう。身長や住所など、時間が経過するにつれて値が変化するデータは、日常生活のなかでもかなり目にすることがある。これらの値の履歴を持つようになれば、前の値も簡単に調べることができる。また、経過した間の値についても細かく計算することも可能だ。こうした機能は、データを重視して設計する今後のシステムでは、当たり前となってくるだろう。
前回は、変更や削除されたデータを元に戻す機能について述べた。これは、変更した値がまちがいだった場合に利用するのが基本だ。さて、その値の変更だが、いったいどんな場合に発生するのだろうか？ これを分析することが今回のテーマに大きく関係する。細かく調べてみると、値の変更は大きく２つに分類できる。
まず１つは、入力した値がまちがっていたときだ。正しいデータへと直すために、値を変更する。もう１つは、その項目の値が変化したケースだ。たとえば、身長が少し伸びた、商品の単価や名前が代わった、会長が別な人物に交代したなど、いろいろな項目が考えられる。
ここで重要なのは、後者の場合だ。途中で値が変わったとしても、前の値も残しておきたいときがある。商品の単価や名前なら、前の単価や名前を調べることもあるだろう。もし上書きして変更されてしまうと、昔の値を調べられなくなってしまう。また、いつの時点で変わったのかも残しておきたい情報だ。このように、ある値に履歴を持たせることおができれば、長期間にわたって取られたデータでも、より詳細な値が得られるし、値の正確さも向上する。
世の中のデータというものを見渡してみると、値が変化する項目は意外に多い。身長や体重、住所や電話番号、商品名や単価、地区の人口や予算など、数多くを挙げることができる。我々の氏名も値が変わる項目の１つで、結婚や離婚がきっかけとなる。氏名すら変わるのだから、変わらない項目のほうが少ない。
ただし、値が変化する全項目で履歴を持ったとしたら、データ量も増えるし、入力も大変だ。一般的には、必要と思われる項目でのみ、履歴を持つことになるだろう。どちらでも好きなほうを選べることが、今後のシステムでは重要となる。
「１つのデータに履歴が含まれていれば、
それ以前の詳細情報も容易にトレースできる」
データに履歴を持たせる機能というのは、既存OSでは特に用意されていない（表１）。実現するとすれば、アプリケーション側でつくることになる。これに、もっとも適しているのは、データベースソフトだろう。しかし、データベース自体の基本機能として履歴をサポートするソフトはないので、付属のプログラミング機能でつくるしかない。とはいってもこれは容易な作業ではない。履歴の入力や表示に加え、履歴データを利用する機能までつくらなければならないからだ。また、項目ごとに各履歴機能を作成するため、作業量は非常に多くなる。こんなことは実現は困難なので、つくる人はほとんどいない。
表１、OSの種類ごとに、履歴を持つ機能を比較した結果。情報中心システム以外では、履歴を持つことを考慮していないので、ほとんど使えない
OSの進歩 ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＞
オブジェクト指向OSとなった場合でも、既存OSと同様だ。データを細かな単位で管理せず、ファイル単位で扱う仕組みであるため、もし上のような機能を実現したいなら、アプリケーション側でつくるしかない。だが、これはかなり面倒なので、作成する人はほとんどいないだろう。
どうしても履歴を持ちたいユーザーは、使い方で工夫する。データベースであれば、メモ欄を用意して、「旧住所：東京都...」といった具合いに、そこに古い値を残す。ただし、、この方法だと住所の項目では検索できなくなるため、使い勝手はかなり悪い。だが、ほかによい方法がなく仕方なく使う、というのが現状だろう。
情報中心システムでは、上で説明したような値の履歴を持つ機能を標準で装備する。その細かな内容を紹介する前に、値の履歴が持つ特性を先に解説しよう。
値が変わる項目には、変化の基準となる軸が必ずある。たいていは時間で、日付や時刻などだ。身長や体重なら測定日、会長なら就任日、単価や商品名なら採用日だ。個々の項目名は異なるが、データとしては日付や時刻としておく。変化の軸が決まったら、軸の値と項目の値をペアで入力し、それが複数になれば履歴として扱う。
履歴データで注目すべきなのは、入力した値ではなく、入力していない部分の値だ。例を上げて、商品の単価を考えてみよう。
ある品物を４月12日に300円で発売した場合、軸に相当する日付は４月12日で、値が300円のデータとなる。次に、11月25日に単価を320円に変えた場合、日付が11月25日で値が320円というデータを入力する。この履歴付き単価を参照するには、４月12日なら300円を、11月25日なら320円を返すような設定にしておく。では、それ以外の日付はどうするのか。４月13日や11月24日なら、４月12日と同じ300円を、11月26日なら320円という値を返すようにする（図１）。この例からわかるように、入力していない部分を補間する仕組みも必要とされる。
図１、値の補間方式の１例。次の入力値が来るまで、前の入力値を用いる。商品の単価などに適した方式
補間の方法は、１種類だけでは不十分である。たとえば、身長を毎年１回測定して履歴データをつくったとする。測定していない日の身長の値は、測定したデータを補間する方法で推測できる。前後の値からなだらかに変化したと考えて、計算する方法を採用する（図２）。当たり前のことだが、こうしたケースは、補間の仕方が前述の品物の単価の場合とちがう。
図２、値の補間方式の１例で、入力値をなだらかな曲線で結ぶ。身長や体重のように、だんだんと変化する値に適した方式
このように、項目が持つ特性に適した補間方法を選んで割り当てなければならないが、よく使われる補間方法は決まっているので、数種類を用意すれば十分だ。２次曲線でなだらかにつなぐ以外に、直線でつなぐ折れ線方法（図３）なども標準で持つようになる。
図３、値の補間方式の１例で、入力した値を折れ線で結ぶ。特殊な係数のように、人工的な項目で利用する
再び、単価の例に戻ろう。新しい商品を追加するようなときには、発売開始日というのが必ずある。それが最初のデータになり、発売開始日を日付として入力する。では、発売開始日より前の日付で参照したらどうだろうか。単価を０円として返すのはまちがいで、そのデータが存在しないという具合いに処理すべきだ。結果として、その商品自体がまだ存在しないときと同じ扱いになる。システム内部での処理は、データが存在しないと同じ扱いにして、処理を続けさせる。
このように、補間すべき範囲の設定も必要になってくる。単価の場合には、最初のデータより前は存在しないという扱いにしておき、最後のデータより後は、同じ値が続くと設定する。
値の補間範囲は、補間方式ごとに最適な決め方がある。単価のように、同じ値を継続する補間方式なら、最初のデータより前は空で、最後のデータが永遠に続く設定が多い。より使いやすくするためには、補間範囲の設定を補間方式ごとに持つのがベストだ。それぞれの補間方式で、もっともよく使われる補間範囲をデフォルトにしておけば、補間範囲を設定する手間が省ける。データのない状態も扱えることで、補間方式として「補間しない」ということも可能になる。つまり入力したデータ以外には、データが存在しないという扱いにする。これは、履歴を持つという目的以外にも役立つだろう。
「データが存在していないことと、
データがゼロであることを混同してはいけない」
値の補間方法は、これまで説明したような種類だけではまだ十分とはいえない。扱う内容によっては、もっとちがう補間方法も用いたくなる。しかし、すべての補間方式を登録するのは無理なので、補間方法を定義できる機能も用意する。
難しい補間方式は、数値や日付などの計算できるデータに対して用いる。そのため、補間方式は計算式として表現が可能だ。範囲ごとに複数の式を用いたい場合も考慮して、範囲と式をペアで複数登録できる機能にする（図４）。計算式で使う関数には、前後の値だけでなく、値の平均値や最大値などを返すものも含める。また、データなしを返す関数も用意し、凝った補間方式をつくれる環境に仕上げる。
図４、値の補間方式を登録する画面の概略イメージ。軸の値の範囲ごとに、対象の値を求めるための式を設定する。計算式の代わりに、「値なし」や「直前の入力値」などの値も選べる
ユーザーが作成した補間の式は、いろいろな条件で正しく動くか確かめる必要がある。とくに注意したいのが、履歴のデータ数が１件や２件の場合だ。その条件でも意図したような結果になるのか、簡単に確かめられる機能を用意する。１〜３件の３種類の条件で、式の計算結果をグラフで表示すれば十分だろう。１本の式で対応できない場合も考慮し、データ件数が少ないときだけ別の定義を加える機能も必要だ。補間方式によっては、１件用、２件用、３件以上用の３つを作成することもある。
「データの補間方式は、あらゆる状況に対応できるよう、
多数の方式を柔軟に採用できる仕組みにする」
履歴データを入力する際には、前後の値を確認できたほうがよい。それも、値の変化まで視覚的に見ることができればベストだ。補間部分まで含めてグラフ化し、その横に入力用の項目を並べる（図５）。入力部分は表としてつけたほうが全体を把握しやすいので、グラフの軸は縦方向に配置する。入力データのグラフ上の位置も、表と関連づけて表示することが大切だ。また、データなしの範囲も明示する。
図５、履歴データの入力では、これまでの履歴データとグラフを表示して、値を確認しながら進める。グラフを用いることで、おかしなデータを発見しやすい
前後のデータと補間値がグラフとして見られれば、入力したデータの一部がまちがっていても、どのデータが正しくないかを見つけやすい。前後のデータと比べるからこそエラーを発見できる点は、履歴を持つ機能のメリットの１つである。データの正確さを向上させるのにも、履歴機能は役立つ。
履歴データの入力では、軸を何にするかを決めなければならない。この手間も最小限にして、入力の効率を上げたいところだ。項目ごとに軸となる内容は決まっているので、最初から用意する。知識ベース内の項目定義に、履歴の軸となる項目を含める。入力の際には、軸となる項目の入力欄も一緒に表示する。そこに何も入力しなければ、履歴を持たないデータと解釈される。この方法なら、履歴を持つかどうか選べるうえに、履歴を入力するときの操作も簡単ですむ。
同じ項目であっても、データごとに履歴を持つかどうかを選べるようにしておく。たとえば身長の場合、ある人物のデータでは履歴を持つが、別な人物では持たないという使い方も可能だ。入力の手間を考えると、必要なデータにだけ履歴を持つのが賢い使い方になる。
どの補間方式を採用するかも、知識ベースの項目で定義できるようにしておく。こうしておけば、補間方式を毎回選ぶ必要がない。項目ごとに最適な補間方式が決まるので、この方法が使える。ただし、一部のデータでだけ補間方式を変更したい場合も考えられるので、項目定義とは異なる補間方式を、個々のデータごとに設定できる機能をも用意する。
補間方式をあとから変更するとき、いままで入力したデータが無駄になっては困るはずだ。だが心配ご無用。履歴データは、軸と対象項目の値のペアでしかない。補間方式を変えても、そのまま移行できるので、方式変更の機能は簡単に実現が可能だ。新しい補間方式で、補間範囲などを設定すればよい。
履歴を持つかどうかは、２つ目のデータを入力するときに考えればよいことだと思っている人もいるだろう。しかし、これは正しくない。１つ目のデータでの軸の値が、あとから入力できるとは限らないからだ。
具体的に説明しよう。身長データの２つ目を入力するとき、履歴を持とうと決めたとする。が、２つ目の身長データの測定日は明らかだが、１つ目の身長データの測定日はわからないこともありうる。だが、これだと履歴として入力できない。こんな状況まで考慮すると、最初のデータを入力するときに、これに履歴を持たせるかどうかを決める必要がある。実際には、データに履歴があるほうがメリットは多い。それに慣れてくれば、ユーザーも無条件に履歴を持たせるようにするだろう。入力の手間としては、軸の値の分だけ増えるだけなので、大量のデータを入力するのでなければ、履歴データとして入力したほうがよいわけだ。
この結果、値を変更するのは、まちがっているデータを直すときだけに限られる。前回説明したデータ修復機能は、この種の修正に対して働くわけだ。
値に履歴を持たせる機能は、情報を重視するシステムなら必須といえる。ところが既存OSでは、データベースソフトでさえサポートしていない。そのため、最新のデータだけを残し、昔のデータを消してしまう。もし保存したい場合は、本来とは別な形でメモするしかない。これでは、使いやすいシステムにはならない。
情報中心システムでは、情報が持つ性質を理解し、それに合わせた機能を組み込む。その１つが、データの履歴を持つ機能だ。ほかにも、データの正しさを向上するためのチェック機能などがある。それらを総合的に利用して、情報を扱うための質の高い環境を実現する。これからのシステムでは、情報が持つ特性を理解することが必須だ。そこまで徹底しなければ、良いシステムとは呼べない段階に達しつつある。
次回は、履歴データを利用する機能や、補間方式の拡張について解説していこう。
時間とともに「変化するデータ」、履歴を持つ機能 |
