SQLは、そのバージョンの3VL（3値論理）ごとにNULLを特別に扱います。正規化と他の関係理論はそうではありません。ただし、SQLデザインをリレーショナルデザインに変換したり、元に戻したりすることはできます。 （ここでは重複する行はないと想定します。）
正規化は関係に起こります また、NULLを特別に処理しない演算子で定義されます。 「正規化」という用語には、2つの最も一般的な明確な意味があります。テーブルを「1NF」と「より高いNF（正規形）」に配置することです。 NULLは、「1NFへの正規化」には影響しません。 「より高いNFへの正規化」は、テーブルを、自然に結合される小さなテーブルに置き換えます。正規化の目的で、SQLタイプの値に加えて、NULL可能列のドメインで許可される値のようにNULLを扱うことができます。 SQLテーブルにNULLがない場合は、関係として解釈でき、SQL結合などは結合などとして解釈できます。ただし、null可能な列がコンポーネント間で共有されている場所を分解する場合は、SQLで元の列を再構築するには、SQL結合を行う必要があることに注意してください。同じ名前の列が等しいまたは両方がNULL 。また、SQLデータベースにそのようなCK（候補キー）は必要ありません。たとえば、SQL PK（主キー）として宣言することはできません。これは、UNIQUENOTNULLを意味するためです。たとえば、null許容列を含むUNIQUE制約では、行の値がすべての列で同じであっても、その列にNULLを持つ複数の行が許可されます。たとえば、SQL FKのNULLは、参照されるテーブルに表示されないことで失敗しないように、（MATCHモードごとにさまざまな方法で）満たされるようにします。 （ただし、DBMSは標準のSQLとは特異的に異なります。）
残念ながら、分解すると allのテーブルが作成される可能性があります NULLを含むCK。そのため、SQLPKまたはUNIQUENOTNULLとして宣言するものはありません。唯一確実な解決策は、NULLのないデザインに変換することです。次に正規化した後、コンポーネントにnull可能性を再導入したい場合があります。
実際には、SQLPKまたはUNIQUENOT NULLを介して、CKとして宣言できるNULLのない列のセットが常に存在するようにテーブルを設計することができます。次に、null許容列をテーブルから削除し、その列とNULLフリーCKの列を含むテーブルを追加することでnull許容列を取り除くことができます。古いデザインの行の列がNULLでない場合、そのCKサブ行と列の値は追加されたテーブルに入れられます。それ以外の場合、古いデザインではNULLであり、追加されたテーブルには対応する行がありません。 （元のテーブルは、新しいテーブルの自然な左結合です。）もちろん、クエリを古いデザインから新しいデザインに変更する必要もあります。
古いnull許容列ごとにブール列を追加し、古い列をNOT NULLにする設計を使用すると、常にNULLを回避できます。新しい列は、古いデザインで古い列がNULLであったかどうかを行に示し、trueの場合、古い列は、データベース全体でそのタイプに対してその目的のために選択する1つの値になります。もちろん、クエリを古いデザインから新しいデザインに変更する必要もあります。
NULLを避けたいかどうかは別の問題です。データベースは、どちらの設計でも、アプリケーションにとって何らかの形で「より良い」または「より悪い」可能性があります。 NULLを回避する背後にある考え方は、クエリの意味を複雑にするため、NULLのないテーブルからの結合が増えることと比較して、逆にクエリを複雑にすることです。 （その逆境は通常、クエリ式のNULLを可能な限り表示される場所に近づけることで管理されます。）
PS PKおよびFKを含む多くのSQL用語は、リレーショナル用語とは異なります。 SQL PKは、スーパーキーのようなものを意味します。 SQL FKは、外部スーパーキーのようなものを意味します。しかし、SQLの「スーパーキー」について話すのは意味がありません：
SQLテーブルはリレーションに似ているため、リレーションを含む用語はテーブルにだらしなく適用されます。ただし、用語を借用してSQLの意味を与えることはできますが、値、テーブル、FD（機能依存関係）、スーパーキー、CK（候補キー）、PK（主キー）、FK（外部キー）、結合、および述語、NF （正規形）、正規化、1NFなど-RM定義、定理、またはアルゴリズム内のこれらの単語をSQLの意味に置き換えて、意味のあるまたは真の何かを取得することはできません。さらに、RM概念のSQLプレゼンテーションはほとんどありません 実際にSQLデータベースにRMの概念を適切に適用する方法を教えてください 。彼らはRMプレゼンテーションをオウムにするだけで、用語にSQLの意味を使用することで、意味がないか無効になるかを認識していません。