概念設計とは、データベース 化の対象を調べる作業である。現実世界のなかで扱われている情報の構造や、情報の使いかたを調べることを目的としている。概念設計段階のなかで使われている手法として、たとえば、DFD や ER モデル （entity-relationship model） や意味データモデル （semantic data model） がある。

　論理設計とは、概念設計のなかで記述された対象を、論理的な データ 構造や演算系として変換する作業である。論理設計段階のなかで使われている手法として、たとえば、リレーショナル・データベース （RDBMS） を対象とすれば、関係 モデル （relational data model） がある。

　概念設計と論理設計では、それぞれ、使用されている手法が違うので、概念設計の アウトプット を論理設計の関係 モデル に変換することは、「機械的 （単純な「1 対 1 対応）」には できないので、システム・エンジニア の判断が介入することになる。概念設計のなかで使われている手法には、「モノ」 を認知する判断規準がないし、「（モノ と モノ との間に成立する） 関連」の網羅性を検証する規準もないので、概念設計のアウトプット 自体が 「恣意的」 である。
　論理設計では、事業のなかで使われている データ 項目 （属性値集合） に対して、関係 モデル を使って、「包含従属性 （inclusion dependency）」 と 「関数従属性 （functional dependency）」 の 2点さえ考慮していれば、タプル （tuple） の設計は、ほとんど、恣意的にはならない。^{（注 1）}

　概念設計 （意味論） と論理設計 （数理 モデル） を結ぶ際、最大にむずかしい点は、以下の 2点である。

　（1） null の扱い
　（2） 属性集合の 「意味 （事業のなかで使われている意味）」

　或る意味では、（1） は、（2） から派生する論点である。
　まず、null であるが、属性値集合の直積集合に対して、以下の 2つの 「解釈」 を考えることができる。

　（1） [ 空集合を前提としない ] いかなる テーブル にも null は起こらない。
　（2） [ 空集合を前提とする ] 関係 R と同じ次数をもつ空集合 R (φ) を認める^{（注 2）}。

　関係 R と同じ次数をもつ空集合 R (φ) を認めるかどうか、という論点である。関係 モデルは、（2）を前提にしている。したがって、outer join では、null の生じる テーブル を認める。リレーショナル 代数演算として、関係 R と同じ次数をもつ空集合 R (φ) を前提にすることは、記号の操作上、整合的であるが^{（注 3）}、コッド 博士自らが、（1980年代後半に公になさった） 「SQL 致命的な欠点 （Fatal Flaws）」 のなかで、SQL が （maybe として記述される） null を扱えない点を非難なさっている。ただし、「SQL が null を扱えない」 と非難されているのであって、「関係 R と同じ次数をもつ空集合 R (φ) 」 を否認なさった訳ではない。

　関係 モデル では、記号の操作上、タプル （tuple） は、直積集合および選択公理を 「きびしく」 適用されていない──つまり、タプル のなかでは、属性値の並びは論点にされていない^{（注 4）}。選択公理では、「空でない」 集合の族を前提にしているが、リレーショナル 代数演算のなかで、R (φ) を前提にすることを小生は反対しない。
　しかし、たとえば、outer join 以外でも、関係 スキーマ のなかで、以下の テーブル を使って、null を考えてみる。

　　　｛従業員番号、従業員名称、部門 コード（R）｝.　　　｛部門 コード、部門名称｝.

　「配属されていない」 従業員は、部門 コード が null である。
　あるいは、部門の或る 「行 （row）」 が削除されたら、その部門 コード の値をもつ従業員 テーブル の部門 コード （R） は、nullになる。関係 スキーマ のなかでも、null が起こる。

　小生は、（リレーショナル 代数演算のなかではなくて、） 直積集合を前提にした関係 スキーマ のなかに生じる null に対しては、なんらかの対応をしなければならない、と思っている。
　なぜなら、１つの 「列 （column）」 のなかに、「いくつかの」 null が起こるというのは、直積集合 （あるいは、選択公理） の前提に抵触している、と考えているから。

　R (φ) を最初に論点にしたので、論点が逆になってしまったが、論理設計のなかで、最大にむずかしい点は、（関係 モデル は属性値集合を対象としているので、） 属性値集合の 「意味 （事業のなかで使われている意味）」 を、システム・エンジニア が正しく理解するためには、事業の知識を習得していなければならない、という点である。つまり、論理設計は概念設計を前提にしていなければならない、という点である。したがって、2つの工程間に生じる隔絶を結ばなければならないので、データベース の品質は、（システム・エンジニア の力量に依存した） 恣意性に晒される。意味論と数理 モデル の接続 （あるいは、統合・融合） という悩ましい問題点が出てくる。
　とすれば、この恣意性を排除するためには、以下の 3点が検討されなければならない。

　（1） 概念設計のなかで、「モノ」 を認知する判断規準と 「関連」 を認識する判断規準を提示する。
　（2） 概念設計のなかで、データベース 化の対象 （「モノ」 と 「関連」 ）の網羅性を証明する。
　（3） 論理設計のなかで、「モノ と関係」 の構造を作る推論 ルール を提示する。
　　　　推論 ルール とは、同じ インプット を使えば、つねに、同じ アウトプット になる モデル のことをいう。

　以上の 3点を実現しようとすれば、現実世界の事態を対象にして、事態を写像した 「論理的な構造」 を システム・エンジニア が考え出すのではなくて、事業のなかで使われている 「（伝達を目的とした） 情報 [ つまり、事業に関与している人たちの言葉の使いかた ]」を対象にしたほうが良い。この点に関しては、（本 ホームページ の）「論理 データベース 論考を読む」 のなかで記述した 「『基準編第 9章 （言語 ゲーム）』 を読む」 を参照されたい。

　
[ 注釈 ]

^{（注 1）}
　このほかの従属性として、「多値従属性」 と 「結合従属性」 を考慮しなければならないことがある。
　「多値従属性」 を考慮した正規形が第 4正規形であり、「結合従属性」 を考慮した正規形が第 5正規形である。

　
^{（注 2）}
　端的に言えば、R ｛a, b｝ があれば、それに対応する R ｛null, null｝ のこと。

　
^{（注 3）}
　outer join のなかで、null が出る例として、以下を考えてみればよい。

　テーブル A　｛1, a｝ ｛2, b｝ ｛3, c｝
　テーブル B　｛a, ○｝ ｛b, △｝

　テーブル A とテーブル B の outer join は以下のようになる。

　｛1, a, ○｝ ｛2, b, △｝ ｛3, c, null｝

　たとえば、属性値として、1 と 2 と 3 を従業員とする。
　また、属性値として、a と b と c を等級とする。
　さらに、属性値として、○ と △ を等級に対して適用される手当とする。

　以上の outer join の テーブル を給与計算 「原簿」 とする。
　もし、給与計算 「原簿」 が、認知番号を付与されていれば、Ｔ字形 ER手法では、entity として認知される。
　Null を認めないＴ字形 ER手法では、この outer join の 「原簿」 は、相違の サブセット として記述される。

　
^{（注 4）}
　関係 モデル は、タプル に対して、直積集合と選択公理を、きびしく適用していないので──つまり、タプル を 「選択関数」 として扱っていないので──、コッド 博士は、自らの論文のなかで、「関係」 を relation という言いかたではなくて、relationship という日常的な呼称を使ってもよい、と記述された。小生は、20年前、コッド 博士の指摘を 「誤解」 して、コッド 正規形 の テーブル （と参照整合性） を、チェン ER のいう 「主体 （entity） および関連 （relationship）」 を使って記述すればよい、という間違いを犯してしまった。すなわち、コッド 正規形を チェン ER 図を使って描写する、という間違いを、セミナー や講演のなかで指導して、撒き散らしてしまった。だから、「従業員 entity のなかに、部門 コード が挿入される」 という奇怪な ER 図が作成されることになってしまった──なぜなら、チェン ER手法は、主体集合間の結びを関連として記述するのであって、主体集合のなかでは、包含従属性や関数従属性は成立しない。
　チェン ER手法も、直積集合を前提にしている──タプル を形成するのが主体集合から選ばれた値である。ただし、主体集合たる entity は、例示されているが、「定義されていない」。