| 2004年 9月16日 作成 | データベース・パラダイム と プログラミング・パラダイム | >> 目次 （作成日順） |
| 2008年10月16日 補遺 | ||
|
（1） 手続き型 プログラミング （Fortran、COBOL、Pascalなど） C および Java を （4） にいれるかどうか、という点は論点になるかもしれない。
（1） 構造的プログラミング いっぽう、抽象 データ 型では、データ に固有な操作も同時に扱う。カプセル 化機能を使う。
（1） 概念設計 （意味 データモデル）
RDB、構造的 プログラミング および抽象 データ 型は、それぞれ、設計思想がちがうので、それらを、それぞれの設計思想を最大限に活かしながら接続することは、なかなか、むずかしい。 |
|
[ 補遺 ] （2008年10月16日）
本 エッセー では、データベース・パラダイム と プログラミング・パラダイム を それぞれ まとめていますが、どうして、本 エッセー を綴ったのかしら、、、（本 エッセー を綴った理由が私には思い出せない、、、）。たぶん、SQL の 「拡張」 に対して異議を申し立てるために綴ったのかもしれない。SQL が、バージョンアップ として、「IF」 とか 「indexing」 とか 「配列」 を導入したことに対して私は疑問を抱いています。というのは、それらの機能は、コッド 関係 モデル の 「関係代数 （Relational algebra）」 に対して──あるいは、単純に言って、セット・アット・ア・タイム 法に対して──矛盾するから。 もっとも、コッド 関係 モデル と プロダクト としての RDB は、たとえ、RDB が、当初、コッド 関係 モデル を基底にして作られたとしても、それぞれ、べつの存在であると RDB ベンダー が言い張るのであれば、「そうであれば、それでもいいでしょう」 としか私には応えられないけれど。ただ、SQL は、できるかぎり、集合論演算と リレーショナル 代数演算 （join, select, projection） を前提にして使うのが──言い換えれば、「IF」 や 「indexing」 や 「配列」 など使わないほうが──プログラム は コンパクト になります （高生産性・高保守性を実現します）。 SQL と オブジェクト 指向言語を接続するのが難しいいっぽうで、さらに やっかいな現象は、それらの言語の特性を無視して、それらの言語を使って 「構造的 プログラミング」 をやっていることが多いという実態です。本 エッセー で述べているように、SQL も オブジェクト 指向言語も、「構造的 プログラミング」 とは正反対の前提に立っています──SQL も オブジェクト 指向言語も、「事実」 として記述された データ を前提にしていて、「ソリューション」 を第一義に構成することを前提にしていないのですが、現実の プログラミング では、SQL や オブジェクト 指向言語を使って 「構造的 プログラミング」 をやっているのは、どうしてかしら、、、。 |
| << もどる | HOME | すすむ >> | |
| ▼ ベーシックス | |||