リレーショナル・データモデルの拡張への挑戦
リレーショナルDBの実用化の過程で、リレーショナル・データモデルの拡張を含む仕様面への配慮、試みも行った。それについて触れてみたい。
リレーショナルDBの基礎となるリレーショナル・データモデルでは、データの冗長性を排除することを原点とする「正規形」のテーブルに分割・整理してデータベースを構成するという基本的な考え方がある。正規形には第1次正規形、第2次正規形、第3次正規形とあり、第1次正規形では、テーブルの各項目（フィールド）には複数の値を入れないフラットなテーブルに整理することが求められている。
例えば、書誌データの場合、書籍番号、書籍名、著者、発行日といった項目から構成されるが、著者は複数人となる場合があるので、第1次正規形とするためには、書籍番号、書籍名、発行日から構成されるテーブルと、書籍番号、著者から構成されるテーブルに分離することになる。しかしながら、このことはテーブルの数を増加させ、直感的でないデータベース操作をユーザーに課すことになるのと、結合処理が必要となり性能を劣化させることになる要因でもあった。
この正規形を崩すかどうかは当時としては大いに迷うところであったが、大規模な文献データベースとしてリレーショナルDBを適用するにあたって、当時は金科玉条的であった「正規形」からの離脱とも言える1個のフィールドに複数の値を持つ「繰り返し列」を実装することにし、業務処理での性能確保を図った。この「繰り返し列」はその後、多少仕様の変遷はあったものの、1999年に制定された国際規格SQL99で「配列型」として取り込まれるに至っている。
また、絞り込み検索機能が必要な情報検索の分野にリレーショナルDBを適用するにあたって、SQLのSELECT文では、検索した結果データの集合に対して、さらにSELECT文を使って絞り込むことができなかった。そこで、SELECT文と同様の検索条件を指定して検索した結果のデータ集合に対して「リスト」と呼ぶ一時的なテーブルを生成するASSIGN LIST文なるものをサポート。リスト間の共通集合、和集合、差集合を求める集合演算も実装して、絞り込み検索ができるようにSQLを機能拡張し、リレーショナルDBの適用範囲の拡大を図った。
リレーショナルDBは、データベースの物理構造やDBMS側の処理が隠蔽され仮想化されているところに美しさがあると言えるが、リレーショナルDBMSを利用する周辺の製品が高速にデータ処理を実行するために、「このテーブルのこの行を処理すればいいよ」と伝える手段がないもどかしさがあった。この目的で、ROWIDというテーブルの特定の行を指す内部的なポインタ情報を示すキーワードを初期のSQLに導入したが、そのために予約語となり、テーブルや列の名称に関する自由度をわずかばかり制限することとなった。
ここまで、リレーショナル・データモデルの拡張ということで述べてきたが、1980年代後半に大規模な文献情報検索システムを構築するにあたって、リレーショナルDBを熟知されていた顧客から「リレーショナルDBの最適化技術は理解するが、業務処理プログラムを書く人はどのインデクスを使えば処理が早いか分かっているのだから、プログラムで書くSELECT文にUSING（インデクス名）というような構文を入れたらどうか」というご示唆を頂いたことがあった。
実用化するという思いからするとあまりに魅惑的なお言葉であったが、SELECT文というSQLの基本中の基本である文にローカルな仕様拡張をすることへの抵抗感から当時は断念させて頂いたが、現在、SELECT文に対するDBMS側への補助的な情報という形でいくつかのDBMSで実装されており、実用的な解決策と言える。
以上のような実用化に向けたリレーショナルDBMSの改良やリレーショナルDBの仕様の改良、ハードウェアの高速化などによって、オンライントランザクションシステムでも十分に利用できるようになった。
ユビキタス情報社会に向けての挑戦
ここまで、メインフレーム時代のリレーショナルDBMSの黎明期とでもいうべき時期における、リレーショナルDBの高速化や実業務システムへの適用拡大に向けたいくつかの取り組みについて紹介してきた。
DBMSにとって最もクリティカルな問題は、システムダウンなどのシステム障害が発生した時にも、DB破壊やデータ不正を発生させないことであり、システム再立ち上げに向けて、障害の原因をすみやかに突き止めて、DBの状態をシステム障害発生直前の整合性のある状態にできるだけ短時間で回復させることである。
障害の早期検知や詳細情報の取得などの観点から見ると、本連載の第4回で述べられているように、メインフレームのDBMSは、同一ベンダーのハードウェアやOSと密に連携して開発されるために、ハードウェアやOSとのインターフェースの中に障害に備えた、きめの細かいインターフェースを組み込んで、障害部位のより狭い範囲での特定や早期検出をできるようにして、ハードウェア、OS、DBMSが一体となってシステム信頼性を高めている。
これに対して、オープンサーバのDBMSは、複数ベンダーのハードウェアとOS上で稼動させるために、DBMSの下位層にOSやファイルシステムの違いを吸収し仮想化する層を設けて、ユーザー（DB運用者）にOSの違いによる物理的なDB構造の差異を見せずにユニバーサルな運用操作ができるようにしている。そして、その仮想化層において、個々のOSで実装に違いのある信頼性確保のための機能とインターフェースを個々のOS対応に最大限利用して、DBMS自身によるメインフレームDBMS並みの信頼性確保の実現を図っている。
また、システム再立ち上げ時にDBをシステム障害発生直前の整合性のある状態に短時間で回復させる方式としては、メインフレーム時代のDBMSで実装されていた「チェックポイント」方式をオープンサーバ時代のDBMSでも継承している。
