サブセット の記述は、同一の サブセット では 「＝」 を使い、相違の サブセット では 「×」 を使う。
「同一」 とか 「相違」 というのは、DA （Data Analyst） が、作図中、すでに認知しているので、強いて、べつべつの記号を使わなくてもよいのではないか、という疑問があるかもしれない。

　べつべつの記号を使う理由は、「null」 に対して注意を促すためである。
　（数学の関数を使っている） データ・モデル では、モデル のなかで、「null」 は起こり得ない（！）

　コッド 博士 （Codd, E.F.） は、1970年代に、セット・アット・ア・タイム 法を考えて、[ キー （indexing） および レコード を使った mechanism とはちがう --物理的には、ポインター を使わない--] データ 構造として テーブル 構造を使い、テーブル に対して column 単位の アクセス 手法 （RDB） を提示した。
　セット・アット・ア・タイム 法の根底の思想が 「直積集合」 である。

　コッド 博士は、1980年代後半に、「SQL の致命的な欠点 （Fatal Flaws）」 という論文を公にして、IBM 社の SQL が （2値 ロジック [ 真と偽のふたつの値 ] を前提にしていて） 「maybe （null）」 を扱っていないと非難した。「null」 は多義 （unknown と undefined） なので、コッド 博士は、4値 ロジック [ 真・偽・unknown・undefined ] を使った。

　たとえば、直積集合 R (a, b) において、以下を考えてみる。
　（1） a は、従業員番号の集合 ｛01, 02, 03, 04｝ のなかの任意の メンバー とする。
　（2） b は、部門 コード の集合 ｛ A, B ｝ のなかの任意の メンバー とする。

　（a, b） は 「tuple （集合）」 である。
　[ 空集合ではない ] いくつかの集合のなかから、それぞれ、1つずつ メンバー を選んできて並べたら、1つの集合になる--この考えかたを「選択公理」という--。この並べられた集合のことを 「tuple」 という。
　 　R （Relation） は 「関数」 である。「tuple」 を形成するための--選ばれたそれぞれの メンバー を並べるための [ 順序対を形成するための ]--「関数」である。

　たとえば、従業員番号の集合から 01 を選んで、部門 コード の集合から A を選んで、以下のような tuple （順序対） を生成する （つまり、従業員 01 は部門 A に配属されている）。

　　R (01, A).

　同様にして、従業員 02 は部門 B に配属され、従業員 03 は部門 A に配属されている、とすれば--従業員 03 が、従業員 01 と同じ部門 A に配属されているので、部門 A は 全射である点に注意されたい--、以下のような順序対が生成される。

　　R (02, B).
　　R (03, A).

　さて、ここまで示せば、セット・アット・ア・タイム 法が、column 単位に アクセス する理由を理解できるでしょう。すなわち、従業員番号の column にある値 （メンバー） は従業員番号の集合 （セット） から選択され、部門 コード の column にある値 （メンバー） は部門 コード の集合 （セット） から選択されている。それぞれの column （メンバー） は、それぞれの集合 （セット） から選択され、こういう column 単位の アクセス のことを セット・アット・ア・タイム （set-at-a-time）--セット 単位の縦列の アクセス--という。
　ちなみに、セット は、「ドメイン （domain）」という言いかたをする

　さて、従業員番号 04 は、「どの部門にも配属されていない」 とする。

　　R (04, null).

　つまり、従業員番号 04 は、この リレーション （関数） では充足的ではないことになる（！）
　なぜなら、「null」 を部門 コード の集合から選択することはできないから。
　そもそも、部門 コード の集合を生成するときに、述語論理 f (x) を使って、「共通の述語 （性質）」 の モノ を集めて セット を生成しているのだから--「置換公理」 を前提にしているのだから--、[ 空集合でないかぎり、] 集合のなかには 「null」 は起こり得ない。

　以上にようにして、データ・モデル のなかでは--少なくとも、述語論理と集合論を使った データ・モデル のなかでは--、「null」 は 「致命的な欠点」 になる。したがって、「null」 に対しては、「適切な」 措置を施さなければならない。もし、「null」 を認めるのであれば、コッド 博士が示したように 4値 ロジック を使わなければならない。しかし、実地の システム 作りでは、はたして、プログラム を4値 ロジック で作成しているかしら。

　「null」 に関しては、以下の 2つの対応のいずれかを導入するしかないでしょうね。

　（1） 「null」 を認めないで、2値 ロジック を使う。
　（2） 「null」 を認めて、4値 ロジック を使う。

　構文論上、「null」 を認めて 3値 ロジック を使うことは、「null」 の使いかた次第では、unexpected な　アウトプット がでる危険性を孕んでいます。というのは、3値 ロジック では、null の論理的否定 （¬ null） は、null として扱われるので、もし、アルゴリズム のなかで、「¬ null」 がでてくる文があれば、思わぬ事態に陥ります。