イントロダクション

apllodb は何のためのデータベースか#

apllodbは、 デジタル資料管理 に特化したデータベースです。

デジタル資料管理というのは造語で、デジタルアーカイブや、より小規模の資料の管理（作成・検索・使用）全般を指しています。デジタル資料管理の中でも、資料がまだアナログな状態で保管されており、これからデジタルデータにしていくケースにapllodbは役立ちます。アナログデータをデジタル化する目的は、資料保管スペースの削減の他に、多くの場合は可視化・検索・集計などの応用があるのではないでしょうか。応用を見据えてデータ化する場合、情報整理をしながらデータを蓄積し、データを 構造化 していく必要があります。構造化にはいろいろな手法がありますが、アプリケーションプログラムからも人間からも扱いやすい構造化として、関係代数のモデルがあります。関係代数というと難しく聞こえますが、要するにテーブル構造を使った構造化です。Excelやスプレッドシートを思い浮かべると近いと思います。

アナログデータをテーブル構造に落とし込むというのは、いつでも簡単なわけではないです。書籍などの元データがきっちりと構造化されてれば良いですが、例えば以下のようにフラットに記述されていることも多いでしょう。

アルベルト・アインシュタイン[† 1]（独: Albert Einstein[† 2][† 3][1][2]、1879年3月14日 - 1955年4月18日）は、ドイツ生まれの理論物理学者である。特殊相対性理論および一般相対性理論、相対性宇宙論、ブラウン運動の起源を説明する揺動散逸定理、光量子仮説による光の粒子と波動の二重性、アインシュタインの固体比熱理論、零点エネルギー、半古典型のシュレディンガー方程式、ボーズ＝アインシュタイン凝縮などを提唱した業績で知られる。それまでの物理学の認識を根本から変え、「20世紀最高の物理学者」とも評される。特殊相対性理論、一般相対性理論が有名だが、光量子仮説に基づく光電効果の理論的解明によって1921年のノーベル物理学賞を受賞した。

(Wikipediaより引用)

この記述から構造を見出し、

人物名
生年月日
没年月日
出身地
分野
主な功績1
...
主な功績8
受賞歴

というようなカラムを作成したとします。

しかし同じ資料の別ページ、または別の資料に、次のような記述がありました。

サー・アイザック・ニュートン（英: Sir Isaac Newton、1642年12月25日 - 1727年3月20日、グレゴリオ暦：1643年1月4日 - 1727年3月31日[注 1]）は、イングランドの自然哲学者、数学者、物理学者、天文学者、神学者。主な業績としてニュートン力学の確立や微積分法の発見がある。1717年に造幣局長としてニュートン比価および兌換率を定めた。ナポレオン戦争による兌換停止を経て、1821年5月イングランド銀行はニュートン兌換率により兌換を再開した。

(Wikipediaより引用)

ここで 分野 カラムが1つでは足りないことや、場合によっては 職歴 のカラムもほしくなることがわかります。アナログデータをデジタル化する際、「構造を最初から決定する」ことは難しく、「データを見ながら構造を修正していく」作業が必要となることが多いでしょう。

データベースの中で関係代数モデル（テーブル）でデータを構造化するものは、RDBMS (Relational Database Management System) と呼ばれます。通常のRDBMSは、テーブル構造を頻繁に変更することを想定した作りにはなっていません。既にテーブルにレコードが入っている場合に（空欄非許容・デフォルト値のない）カラムを追加するのは困難ですし、今後のレコードについては不要だと判断したカラムを削除した場合、既存レコードのカラムの値まで消えてしまいます。人間がアナログデータをデジタル化しながら、試行錯誤して情報設計していく用途には、既存のRDBMSは不向きだと言えます。

apllodbはまさにこのような用途のためのRDBMSです。

apllodb のデータベースとしての概要#

apllodbはRDBMSのひとつです。 RDBMSのアーキテクチャを採用した理由は以下のとおりです。

テーブル構造によるデータモデルが、デジタル資料管理においてデータを追加する人にとっても、データを応用に使うアプリケーション開発者にとっても扱いやすい。
RDBMSにはSQLという標準的なクエリ言語（データを検索・集計するための言語）があり、アプリケーションからの利用だけでなくアドホックな分析もSQLを通じて簡便に行える。
多くのRDBMSにはトランザクションの概念があり、データの保存時にデータべースシステムやコンピューターの故障に見舞われても、データに一貫性がある（半端な状態のデータが残らず、全て消えるか全て残るかのどちらか）。

ただし前述の通り、ただのRDBMSではデータを追加しながらテーブルの構造を試行錯誤する用途には不向きです。そのため、apllodbはRDBMSに Immutable Schema という概念を付け加えました。

テーブル構造の頻繁な変更以外にもデジタル資料管理で重要な特性はありますが、初期バージョンの v0.1 においてはまずは Immutable Schema に注力して開発しました。今後力を入れてサポートしていく特性については今後の開発方針にまとめています。

Immutable Schema とは#

通常のRDBMSにおいては、テーブル操作（テーブル構造の作成・変更・削除）やレコード操作（レコードの追加・更新・削除）はミュータブル、つまり破壊的です。テーブルやレコードを変更や削除すると、基本的には元に戻せません。 Immutable Schema ではこれらの操作をイミュータブル、つまり非破壊的に行います。

これは単に「変更前のバックアップを残しておく」というだけのことではありません。例えばあるテーブルに既にレコードが存在する時、カラムを1つ削除することを考えます。通常のミュータブルなRDBMSは、削除するカラムの値を全レコードについて消去してしまいます。これをイミュータブルに行うにはどうすればよいでしょうか。 Immutable Schema の枠組みでは、

カラム削除前のテーブル構造とレコードを残しておき、
カラム削除後のテーブル構造を新たに作成し、
次回以降のレコードは（可能であれば）新しいテーブル定義の方に追加する。

という挙動をし、元のテーブル構造やレコードを非破壊にテーブル構造の変更を実現します。

RDBMSの世界ではテーブルの作成や更新の操作をDDLと呼ぶので、上述のようなイミュータブルなテーブル操作を Immutable DDL と呼びます。同様に、イミュータブルなレコード操作については Immutable DML と呼びます。

Immutable DMLにより、あるレコードのカラム値を更新してしまった後も、更新前の値に戻すことができたり、削除してしまったレコードを復旧することができます。

Immutable Schemaは、Immutable DDLとImmutable DMLを総称したもので、apllodbの主な特徴となります。