最近、以下の話を聞きました。

　「すべての リレーションシップ を外部 キー 参照として実装しない」 という SI 社さえある。

　この話は、コッド 正規形を作って、RDB 上に実装することを前提にしています。コッド 関係 モデル を使っていて、そんな いい加減な仕事は、プロフェッショナル な仕事として、ありえない、と思って、僕は、思わず、以下の コメント を綴りました。

　━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
　正美：　そんな SI 社がいるのおおおおお。　(〇o〇;)
　━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

　「反 コンピュータ 的断章」 のなかで、以前、モデル が軽視されていることを綴りました。上述した話は、まさに、その典型でしょうね。上述した話は、言いかたを変えれば、もし、リバース・エンジニアリング を使って、物理的 テーブル 構成を、論理 データ・モデル として記述したら、テーブル のあいだには、リレーションシップ がない、ということです（！）

　コッド 関係 モデル では、外来 キー （foreign-key） は、モデル のなかで、「命 （中核）」 とも言える技術です。上述した話は、モデル （理論） を正当に理解しないから、技術が でたらめ に使われている典型的な できごと でしょうね。

　
　コッド 関係 モデル に対して賛同するか反対するか、という点をべつにして、以下に、コッド 関係 モデル の 設計思想と integrity （参照制約） を まとめてみます。

　データ 構成には、「スキーマ （schema）」 と 「インスタンス （instance）」 と いう 2つの概念があります。スキーマ は 「構造」 を記述し、インスタンス は、（構造のなかで、対象となる） 具体的な 「例」 です。そして、参照制約 （integrity constraint） は、インスタンス に対して適用される規約です。リレーショナル・モデル は、以下の 2つの制約を導入しています。

　（1） 実体 integrity
　（2） 参照 integrity

　実体 integrity は、1つの テーブル のなかで適用されます。
　参照 integrity は、複数の テーブル のあいだで適用されます。

　この 2つの integrity は、コッド 関係 モデル のなかでは、意味を記述する制約条件 （関数従属性と包含従属性） と対応しています。
　実体 integrity として、「キー」 （primary-key と alternate-key） が導入されていますし、参照 integrity として、foreign-key が導入されています。つまり、コッド 関係 モデル は、「データ 構造」 を 「モノ と関係」として記述しています。

　integrity を乱す更新演算に対して、以下の対応を考えることができます。
　（1） integrity を乱す更新演算は、reject する。
　（2） integrity を維持するように、ほかの データ を更新する。

　実体 integrity では、（1） の対応が導入され、参照 integrity では、（2） の対応が導入されます。（2）として、以下が使われています。
　　- cascading
　　- nullified

　そして、或る テーブル に対する更新が、ほかの テーブル に波及することを propagation と云います。 propagation を前提にして、制約条件として記述されている 「意味」 が崩れないようにするのが、コッド 関係 モデル です。この参照整合が崩れないように、「正規形」 を作るのが、コッド 関係 モデル です。

　この参照整合性を考慮しなければ、データ 構造の整合性 （意味） が崩れてしまう 「典型的な」 正規形が、以下の 2つの正規形です。
　- Boyce-Codd 正規形
　- 射影結合正規形 （projection/join normal form）

　したがって、コッド 関係 モデル では、foreign-key は、モデル のなかで、「命 （中核）」 とも云える点なのです。そして、コッド 正規形は、無矛盾性と完全性 （relational completeness） を実現していることが証明されています。

　
　以上を理解すれば、「すべての （論理） リレーションシップ を外部 キー 参照として実装しない」 ことが、いかに、いい加減なことか、理解できるでしょう。

　そして、RDB は、パージョンアップ のなかで、indexing を搭載したので、セット・アット・ア・タイム 法が、いつのまにか、レコード・アット・ア・タイム 法のように使われるようになってしまい、コッド 関係 モデル を前提にした設計 （コッド 正規形） が無視されて、indexing を前提にした V-SAM ファイル 向けの設計が、事実上、「テーブル」 として実装されているようです。
そして、「V-SAM ファイル 上に、『view』 を導入した プロダクト が、RDB だ」 と みなされているようです。

　そうなってしまうと、データベース の設計が、とりもなおさず、昔ながらの ファイル 設計のままで良い、ということになってしまい、SE たちは、モデル （理論） を無視する、という事態が、当然 （generally accepted） のようになってしまいます。
　僕は、コッド 関係 モデル を、かならずしも、賛同していないのですが、「モデル」 という観点からすれば、（コッド 関係 モデル もふくめて、） 「モデル」 を擁護しなければならない、と思っています。

　
　ちなみに、Ｔ字形 ER手法では、「コッド 関係 モデル の参照整合性」 を使っていない点を、注意しておきます。Ｔ字形 ER手法は、セット・アット・ア・タイム 法 （コッド 関係 モデル の アクセス 技法） を、レコード・アット・ア・タイム 法にように使う 「INDEX-only」 を使っているので、「（コッド 関係 モデル の） 参照整合性」 を使っていないのであって、コッド 関係 モデル の参照整合性を無視している訳ではないので、念のため。
　その点を明示するために、（拙著 「Ｔ字形 ER による データベース 設計技法」 では、（R） を 「参照 キー」 と云っていたのですが、） 「論理 データベース 論考」 では、（R） を 「Re-used」 という言いかた （概念） に変更しています。つまり、コッド 関係 モデル が使っている参照整合性とは違う整合性を前提にします、ということを述べています。

　
　（2004年 9月16日）