本シリーズを見返してみたら、ガイドラインとは何かの説明が必要な気がしてきましたが、本編をさっさと仕上げます。
値 = テーブル名(キーワード)
の関数表現でデータベースを説明してきました。しかしこれだとRDBではたった2欄で、左がキーワードの列、右がその値の列、の感じです。いや、このような対応表は珍しくは無く、確実に役立ちます。しかし、何か物足りない。
例えば部品表だったら、キーワードが部品番号で、値の方は名称、大きさ、重さ、用途などと続くはずです。RDBだと欄を右に増やしてゆきます。
階層型データベースでは、第二のキーワードを設けて、項目名を入れます。
値 = テーブル名(部品番号、項目名)
の感じです。もちろん項目名も管理されているはずで、項目名が筆頭のキーワードの表が他にあるはずです。そう、キーワードが2個となります。改めて書くと、
値 = テーブル名(キーワード1、キーワード2)
となります。RDBだとインデックスを2欄に渡って付ける感じです。
かつての私の上司の観察だと、取引のデータは、
値 = テーブル名(取引先番号、日付、項目名)
の3段階で、いろいろ試してみたが、この順が決定版だそうです。ううむ、有料記事みたいな核心情報ですが、これだけだと多分訳分からないので公開しました。なので細かい説明は省略します。
キーワードにしても値にしても、前項の区切り文字の表記を使えば、最初に上げた単純な対応表で表せると思います。階層にするのはプログラムが書きやすくなる、言い換えると見通しが良くなって他の人にもよく分かる、くらいの意味です。軽くは無いですが。
意外に大切なことを私は言いました。二分探索表ならキーワードは階層を持っていようとフラットな表になります。ということは、ISAMの多進木の木構造はハード的な構造であって、必ずしもデータベースの論理的階層とは対応しません。この意味で、Btreeは高度に抽象的な構造です。
排他制御も決定版は無く、しかしこれらの経験的な複雑なデータ構造が現在の我々の生活を支えています。私としてはもう少し計算機科学の理論的背景が欲しいところです。
