多次元データエンジン

我々のデータベースエンジンの最大の特徴（売り）は、おそらくこの多次元データエンジンということになると思いますが、これを理解してもらうことがなかなか骨が折れます。

わかってしまえば、わりと単純なのですが、データベースというと最近ではテーブルでしか理解できない人が増えているようで、テーブルで考えるとどうなんだろうと、そこで混乱している人が結構います。

多次元というと、まずOLAPのデータベースですか？というステレオタイプ的な反応が多いです。

本国USでは、こういう誤解を受けないようにTMD(Transactional Multi Dimensional Data Engine)という言い方をしますが、これを日本語にすると、取引的多次元データエンジン？となり、なんだかわけがわかりません。

要するに、データウェアハウス用ではなく、トランザクション処理用の多次元データエンジンであるというということを言いたいわけです。

もっとも構造的には、多次元なので、いわゆるOLAP的な多次元構造（ドリルダウンなど）を表現することは難なくできます。

また、ある程度わかってくると、なんだ階層構造（または、木構造）じゃんと納得することも可能です。

ただし、階層構造であるということをあまり強調しない理由は、昔あった階層型データベースと同列に取り扱ってほしくないからです。

同じ階層構造でも、決定的に違うのは、昔の階層型DBMSというのは、スキーマ定義で階層構造を決めると、そのデータの関係は物理的なリンクで形成されるのに対して、多次元データエンジンの場合は、あくまでもその次元のキー要素の値に基づき、実行時に関係付けられる点です。（動的に決まるけれども、キーの値を指定することによって、得られるデータ取得は物理リンクによる結合に劣らず非常に高速です。）

これは、RDBMSのテーブル間のリレーションシップを外部キーで動的に表現することに概念的には近いのではないかと思います。

階層型DBMSの場合には、構造を変更するためには、その物理リンクをメンテナンスしなければならず、それが非常に骨の折れる作業だったわけです。

同じ階層型でも、ずっと変化に強い柔軟な構造なわけです。

これは、いくつかのプログラミング言語にあるハッシュ変数（連想記憶）という概念に近いと思います。

実際、多次元データエンジンが取り扱うデータは、プログラム言語の変数です。

しかも永続性のある（つまりディスクに書かれる）変数です。

大抵の場合、ハッシュ変数のそのキーは、1次元で表現することが多いですが、多次元データエンジンでは、それを複数次元のキーとして表現できます。

これは、複合キーを表現できるということです。

プログラマの裁量により自由自在にデータ構造（変数）を形成していくことができるわけで、極めてアジャイルなデータベース環境なわけですが、一般的なまずスキーマありきのデータベースの概念からは、かけ離れているためになかなか理解してもらえにくいのかなと思ったりしています。

やっぱり、言葉で説明するのは難しいですね。