データ設計が杜撰であっても、システムは稼働するので、データ設計が軽視されているのかもしれない。データ設計が杜撰であっても、アルゴリズムのなかで、判断しながら、データを扱えばよいから。ただ、そういう やりかた が、本来、作成しなくても済むアルゴリズムを作成するはめになっていることを、プログラマは、どの程度、意識しているのだろうか。そして、最大の効果および最高の効率を実現するためには、理論に従うことが最短の道であることを、ＳＥおよびプログラマは、いったい、どの程度、理解しているのだろうか。

　それが理解しにくい点は、理論を遵守した設計と、理論を遵守していないけれど、少々、考えながらやった設計が、ときどき、同じ実装形になることがあるからかもしれない。ただし、全体としてみれば、それらの２つの構造には、大きな相違があるのだが、、、。

　たとえば、従業員のデータを例にしながら、ＲＤＢ向けの設計と階層構造型データベース （あるいは VSAM ファイルを前提にした構造化プログラミング）向けの設計を比べてみましょう。階層構造型データベース（あるいは、VSAM ファイルを前提にした構造化プログラミング）向けの設計として、以下のデータ構造を生成した、とします。

　（１）｛部門コード、従業員番号、従業員名称、入社日｝
　　　　　[ 「部門コード＋従業員番号」はマスター・キー ]

　コッド正規形（ＲＤＢ向けのデータ設計）の観点から判断すれば、従業員名称や入社日は、「部門コード＋従業員番号」に対して、関数的依存関係が成立しないし、部門コードは従属関数なので、以下の構造とするのが正しいでしょうね。

　（２）｛従業員番号、従業員名称、入社日、部門コード (R)｝
　　　　　[ 従業員番号は primary-key ]

　そして、コッド正規形に対して、CREATE INDEX を使って、「部門コード＋従業員番号」のインデックスを生成した、とします。
　さて、以上の２つの設計は、実装形は同じになります。とすれば、ＲＤＢに対して、（１）を設計しても、（理論的に）間違いであるとは気づかないでしょう。そして、間違いであると気づかないかぎり、マスター・キーを前提にして、平然と、ＲＤＢ向けのデータ設計をやり続けるでしょう（苦笑）。そして、間違いを続けながらも、「システムを実際に稼働してきた」と言い張ることでしょうね。

　マスター・キーは、ＳＥ（およびプログラマ）の頭なかに継承されてきたＤＮＡかもしれない（苦笑）。だから、マスター・キーを、なかなか、捨てることができないのかもしれない。
　ＲＤＢにとって、indexing は後付にすぎないのですが--したがって、ＲＤＢの internals とは、全然、無関係なのですが--、ＲＤＢが indexing を搭載しているので、こういう間違いが起こるのでしょうね。

　さて、ＲＤＢ（セット・アット・ア・タイム法）を信奉している理論家の皆さん（あるいは、ＤＯＡを信奉している理論家の皆さん）、「システムを実際に稼働してきた」と言い張る実務家 （practitioner）に対して、どのように、以上の間違いを説得しますか。コッド正規化の手順を丸暗記しているだけじゃ、説得することはできないでしょうね（笑）。

　 　（2003年11月8日）