抽象 データ 型の特徴は、カプセル 化にある。
　そして、データ （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 を考えてみればよい。