タグ付きデータモデル

コンピュータの本質は情報を処理する機械である

コンピュータの本質は 情報を処理する機械 です。すなわち、コンピュータを使えば、大量の情報を保存しておき、その中から必要な情報を検索することができます。しかし実際に必要な情報を得るためには、前準備が必要となります。情報を効率よく処理するために、コンピュータの都合のよいように情報を加工しなければなりません。

よく使われる手法として、 RDB (リレーショナルデータベース)を使って情報を蓄積し、 SQL という言語を使って必要な情報を検索するというものがあります。 RDB は、扱う情報を「型」や「サイズ」などの条件で細かく規定し、テーブル・カラムを指定した場所に情報を格納します。 RDB の扱いやすいように整理されたデータは、コンピュータの処理には都合がよく、効率的に検索することが可能になります。その反面、あらかじめ情報を加工する手間がかかるだけでなく、指定された形式で入力しない限り、情報を処理することができないという弱点を持ちます。したがって、情報をいかに効率的にRDB に適合した形式にするかということが、データを効率よく処理できるかどうかを決定付ける、重大な問題だということになります。

情報の質的変化に対応するには今までの手法だけでは難しい

今では Web は日常生活に入り込み、日々多くの情報がデジタル化されるようになりました。情報の量が飛躍的に増えるだけでなく、 情報の質も変化しています。

従来の情報処理のスタイルは、扱いたい情報の内容や形式があらかじめ分かっていて、それに応じたプログラムがあればよい、というようなシステムを想定していました。例えば、住所録、会員データ、通帳の取引内容のような情報は、あらかじめ情報の種類が決まっているので、 RDB に入れるべきデータの型やサイズを厳密に指定することができます。それに対応するプログラムを作れば、データを処理するシステムを構築することが可能です。

Web から入ってくる情報は多種多様で、どのような内容であるかも予測不可能だし、種類も非常に多く、一般に、型にはめることが難しいという特徴を持っています。

さらに、新しく形式が変わった情報が日々追加されたり、状況によって情報の扱い方が変わったりすることもあります。例えば数年前までは、 Web で動画を配信することは珍しかったのですが、今ではムービーは普通にみられるデータ形式なので、動画も RDB で扱いたい、といったニーズが増えつつあります。このように、今までなかったタイプの情報が増える世界では、特定の型に当てはめて対応するという戦略では、対応がどんどん困難になるばかりです。

データを保存するときに分類するのではなく、取り出すときに分類することによるメリットとは

従来のアプローチだと、データを RDB に格納する時点で、データの種類を決めなければなりません。テーブルごとに決まった種類の情報を集めますから、同種のデータは、決まった特定のテーブルに格納されます。この場合、どこに入れるかということは重要な意味を持っています。間違ったテーブルに情報を入れてしまうと、検索しても見つからないという問題が発生するからです。

情報が多種多様になればなるほど、情報の内容を型やサイズで細かく指定し、テーブルに分類して格納する、といった作業には膨大なコストがかかるようになります。また、そもそも分類することが不可能な情報もあります。

時間が経過すると情報を追加したり、不要なものを削除したりすることが必要な場合はどうでしょうか。テーブル毎に情報を割り振る設計をすすれば、初期のテーブル設計が極めて重要で、扱う情報に最適な構造をあらかじめ作る必要があります。しかし、複雑なデータになればなるほど、最適なテーブルを設計することは難しくなります。後で項目を増やしたり、データのサイズが増えてしまったりという場合は、理想的にはテーブルを再構築すればいいのですが、そのためには今までのデータを変換する処理だけでなく、場合によってはプログラム側の大幅な修正が必要になり、その作業自体のコストも見過ごせません。

テーブルの設計が大変なら、テーブルを設計しないという発想が出てきます。どのようなデータも同じテーブルに入れてしまえば、分類するという手間は不必要になるからです。

情報をあらかじめ分類しなければ、必要な情報だけを後で取り出すことができないのではないでしょうか? それを否定するモノは既にあります。例えば、Google のような全文検索エンジンです。 Google は、インターネットに散在するページをあらかじめ分類するのではなく、参照したいときに、中に含まれている文字列という条件で分類し、取り出しています。

これは、データを保存するときではなく、取り出すときに分類する、という一例です。全文検索機能というのはそれを実現するアイデアの一つです。このように データを保存時ではなく検索時に分類する というアプローチにはいくつかメリットがあります。前述したように、開発者やユーザーは、テーブルの構造を設計する必要から開放されます。データをどのテーブルに入れるべきか悩まずに済むからです。もう一つの利点は、先ほど述べたように、格納するテーブルを間違えたために見つからなかった、というような現象から開放されるということです。データを全て一箇所に集めたら、どこに入っているかは気にしなくてもいいからです。

※業務上必要なデータだけを別テーブルに分けて保存することも可能である。

情報のオブジェクト化＋タグを使った付加情報

既に述べたように、情報を処理するためには、それをコンピュータが処理しやすいような形式に変換する必要があります。ここで型やテーブルという概念を出してしまったら従来のRDBと同じことになってしまいます。

そこで、 JIRO では、あらゆる情報を Item というクラスのオブジェクトに保持することで管理するような戦略を採用しています。 Item は、与えられた情報の内容を損なわずに、できる限りそのまま保持するように設計されているため、情報をどう加工してから保存しようといった検討を最小限で済ますことができます。また、JIRO は Java というオブジェクト指向言語で作られているため、情報をオブジェクトにマッピングすることは、処理の効率化だけでなく、開発期間の短縮にも役立ちます。

あらゆる情報を Item にして保存するというアプローチは単純ですが、毎回その内容を解析して取り出すのでは非効率的です。また、処理したい情報の性質によっては、全文検索以外の方法で検索したいこともあります。また、全文検索には、文中に含まれていない言葉では検索できないという弱点があるため、ニーズによっては十分な機能とはいえません。

これらの問題を解決するために、 Item は、元の情報だけでなく、その情報の種類、意味、性質などを表現したヒント情報を与えることができる構造になっています。これらの付加情報を JIRO ではタグと呼びます。

タグは Item の中の属性として実装されていて、 1つのItem に対して、複数のタグを指定することができます。タグと元の情報とは完全に独立しているため、タグをつけることによって、元の情報の性質は一切変質しません。もう必要なら、元の情報の内容は全く変更せずに、タグだけ後で変更することができます。この場合、変化するのは、情報そのものではなく、その情報に対する外からの解釈ということになります。

元情報に対して何らかの性質を表現した付加的な情報なら、何でもタグとして扱うことができます。具体的な例としては、「メール」「名前」「生年月日」「製品の色」「曲名」「住所」…のようなものが、実際にタグとして使われます。情報に「名前」というタグを付けることで、コンピュータは「名前」という性質を持っている(とユーザーが指定した)データだけを選択することができるようになるのです。

タグを付けてデータを管理することによるメリット

タグは情報そのものを触らないし、情報がどのように表現されているかということとは独立した情報です。あくまで、対応する情報が何かを示すだけであって、そのデータ形式のような細部には立ち入りません。

例えば「日付」というタグの付いた情報は、「日付」というタグが付いているという事実だけを使って、その情報が「日付」であることを判定できます。おそらく、この場合の情報は、コンピュータの内部表現的に都合のよい「日付」を表現する型を使って実装するのが普通ですが(例えば Java の Date 型)、あるいは「平成10年5月15日」という単純な文字列であっても構わないし、コンピュータの内部表現としてよく使われる 32ビットの整数値であっても構いません。タグを使えば、このように具体的な表現方法が混在していても、情報を一元化して管理することが可能になります。

※　従来のデータモデルだと日付カラムの型・サイズを決めてしまったら、日付型以外の情報をそこに入れることはできない。

一つの Item には、一つだけでなく、タグを複数付けることができます。複数のタグを付けると、一つの情報に複数の意味を持たせることができます。その結果、情報を多面的に扱うことが可能になります。

タグは利用者全員で共有することもできますが、ユーザーが独自に非共有のタグを付けることで、情報に対して独自の解釈を行うような使い方が可能になります。

ネストした Item を使って構造化したデータを構築可能

あらゆる情報を Item という一つの形式だけで処理するといっても、実際の要求モデルの中には、もっと細かく型にはめた情報をあえて扱いたい、ということもあるでしょう。また、従来のデータをインポートして JIRO で使いたいような場合には、固定的で分類されているカラムを使うような情報も扱う必要があります。

JIRO は、 Item の扱えるデータの中に、 Item のリストを加えることで、この問題を解決します。言い換えれば、タグを付けたデータ (Item) をいくつか集めてリストにしたものを、一つの Item とみなすのです。このような Item を ListItem と呼びます。 ListItem の要素は、Item を複数個集めたものです。 Item の種類や個数は問いません。

ListItem を使う場合、従来のテーブル設計を行って使われるデータモデルと比べて、次のような特徴があります。

要素として持つ Item の順序は指定されているが、順序は Item の意味を決めるのではない。何番目は何の情報、というような制約がない。
要素として、可変個(0個以上、任意個)の Item を保持することができる。同じタグの付いた Item が含まれていても構わない。
ListItem の要素の中に別の ListItem を持つことで、複雑なデータにも対応することができる。

情報を具体的にどのように操作するかを定義する「シナリオ」

情報をオブジェクト化した Item を集めたら、それをどのように処理するかという手順が必要になります。これは JIRO ではシナリオと呼んでいます。即ち、 Item をどのように処理するかという手順を定めた内部データです。

情報を Item というオブジェクトにして集めただけでは、それをどうやって表示するとか、どのように新しい情報を作成すればいいか、ということが問題になる。 Item の中にどのような情報があるかは、実際に検索してみないと分からない。 RDB ではテーブルを指定すれば、表示できるカラムも自動的に制限されるが、 JIRO は表示できる内容も無制限である。

シナリオは、次のような情報を持っています。

どのような Item を検索するかという条件。
Item を表形式で表示するときに、どの項目を表示するかを指定する。
新しい Item を生成するための入力フォーム。
検索した Item の詳細を表示するための出力フォーム。

※シナリオ自身も、内部表現として ListItem の形式で表現されている。

共通シナリオとカスタマイズしたシナリオを使い分けて、各ユーザーに最適な操作環境を構築

シナリオはプロジェクトや部署のようなグループに対して共有して持つことができます。この場合は、シナリオを変更すると、そのシナリオを使っている全員のシナリオが変更されたことになります。

これに対して、自分だけの入力フォームを設計したり、表の項目の並び方をカスタマイズしたいような場合があります。このような場合は、共通シナリオを自分専用にコピーしてから編集するか、あるいは、最初から自作して、自分だけが使うことも可能です。