2004年10月 1日 作成 カプセル 化 と 情報隠蔽 >> 目次 (テーマ ごと)
2008年11月 1日 補遺  


 
 抽象 データ 型の特徴は、カプセル 化にある。
 そして、データ (table) の名前と、それぞれの操作の呼び出しが、インタフェース として定義されていれば、データ の詳細を知らなくても──たとえば、table の構造は、物理的に、flat-file でもいいし、ポインタ を使った リスト でもよい──、インタフェース を守れば、アルゴリズム を自由に使うことができる、という考えかあが、抽象 データ 型と理解してよい。

 さて、「カプセル 化」 機能を、どのように考えるか、という点が、「手続き型 プログラミング」 と 「オブジェクト 指向 プログラミング」 の 「曖昧な」 境界線となっているのではないでしょうか。

 というのは、カプセル 化機能は、そもそも、「情報隠蔽」 を前提にした機能である。
 とすれば、たとえば、モジュール 化する際、(Pascal のような) 「手続き型言語」 を対象にしても、1 つのモジュール を、「仕様」 と 「本体」 というふうに、2 つに切り離して、「本体」 を カプセル 化することはできる。ここでいう 「仕様」 というのは、モジュール を使う人が、自由に使用できる手続きや変数である。「本体」 というのは、「仕様」 のなかで記述された手続きや変数を、実行する記述文であって、外部での使用を許さない、とする。

 とすれば、ストアード・プロシジャー は、まさに、カプセル 化の典型になる。

  Specification (public):
   PACKAGE name IS (PROCEDURE name) END

  body (private):
   PACKAGE BODY name IS (PROCEDURE name)
   BEGIN...END
   END

 
 とすれば、もし、SQL を、ストアード・プロシジャー のなかで扱うことにすれば、SQL は、カプセル 化の対象となる。
 とすれば、SQL を、抽象 データ 型の パラダイム のなかで語っても 「整合的」 になる。

 手続き型言語であっても (あるいは、SQL でも)、モジュール 化を、「仕様 (public)」 と 「本体 (private)」 というふうに切り離して、「本体」 の使用を外部に対して隠蔽して扱えば、プログラミング・パラダイム では、「オブジェクト 指向 (抽象 データ 型) のなかで語ることができる」 ということである。

 ただし、SQL は、プログラミング・パラダイム のなかには、いれないという考えかたも成立する。
 すなわち、SQL は、あくまで、集合論の代数演算を担う言語 (データベース 設計論の関係 モデル のなかで考えるべき 「I/O 言語」) であり、アルゴリズム を記述するための──したがって、モジュール 化ができる──独立した言語ではない、と考えることができる。つまり、SQL を、プログラミング・パラダイム のなかで考えるか、データベース・パラダイム のなかで考えるか、という前提が違えば、オブジェクト 指向 (カプセル 化) のなかでも考えることができるし、データベース の範疇で考えることもできる。

 ちなみに、私 (佐藤正美) は、SQL を、データベース・パラダイム のなかで考えていて、コッド 関係 モデル の 「原案」 に近い 「タプル を操作する I/O 言語」 として考えています。つまり、テーブル に対する集合論代数演算の言語として考えていて、「アルゴリズム を記述する独立した言語」 として考えていない──したがって、SQL に対して、データ と プログラム の 「カプセル 化」 という概念を適用していない。なぜなら、「強い意味では」、タプル を 「合成」 する アルゴリズム は、「合成」 の アルゴリズム を知っている人が操作することを前提にしているので。たとえば、Dynamic SQL を考えてみればよい。

 ただし、SQL 自体は、リレーショナル 代数演算だけを対象にしていないので──たとえば、「拡張された」 SQL では、IF...WHILE なども考慮されているし、プロダクト のなかには、ストアード・プロシジャー も用意されているので──、「(RDB を対象とする) 言語」 として考えることもできるし、タプル を 「合成」 する アルゴリズム を プログラム の 「本体」 として用意することができるので、プログラミング・パラダイム のなかで、抽象 データ 型として語ることもできる。



[ 補遺 ] (2008年11月 1日)

 本文が綴られたのは、2004年ですが、どうして、この時点で、こういう文を私は綴ったのか理由を思い起こすことができない。本文では、SQL を コッド 関係 モデル の 「原案」 に近い 「I/O 言語」 というふうに記述していますが、SQL が 関係代数 (relational algebra) を 「忠実に実現している」 とは私には思えないし、コッド 氏 みずからが IBM/SQL を非難なさっていたのが歴史的事実です (1980年代)。

 本文では、カプセル 化を 「情報隠蔽」 の観点で語っていますが、カプセル 化を 「情報隠蔽」 のみの観点で語るのも必要条件を満たしていないでしょうね。

 以上の 2点から判断しても、こういう文を私が どうして綴ったのか理由を思い起こすことができない。もし、理由を強いて考えるならば、たぶん、ストアード・プロシジャー が 「カプセル 化」 と同値類になるのかどうかを検討したかったという点にあるのかもしれない。そして、その答えは、「SQL は、オブジェクト 指向言語のなかで、imbedded な I/O 言語でいい」 ということです。寧ろ、私は、SQL (Dynamic SQL) を エンドユーザ が使う言語として考えています──すなわち、テーブル 構成を対象にして 「情報」 を検索する程度の アルゴリズム (非定型・一過性) であれば、エンドユーザ が使うべき言語だと思っています。





  << もどる ベーシックス すすむ >>
  データベースの基礎知識