ヌル (SQL)

SQLでは、nullまたはNULL は、データ値がデータベースに存在しないことを示すために使用される特別なマーカーです。リレーショナルデータベース モデルの作成者であるE. F. Coddによって導入されたSQL null は、すべての真のリレーショナル データベース管理システム ( RDBMS )が「欠落した情報および適用できない情報」の表現をサポートするという要件を満たすのに役立ちます。Codd は、データベース理論で null を表すために小文字のギリシャ語オメガ(ω) 記号の使用も導入しました。SQL では、 は、このマーカーを識別するために使用される予約語です。 NULL

null を0の値と混同しないでください。null は値がないことを示しますが、ゼロ値とは異なります。たとえば、「アダムは本を何冊所有していますか?」という質問を考えてみましょう。答えは「ゼロ」(アダムが1冊も所有していないことはわかっている) または「null」(アダムが何冊所有しているかはわからない) になります。データベース テーブルでは、この答えを報告する列は値なし (null でマーク) で始まり、アダムが本を所有していないことが確認されるまで値ゼロに更新されることはありません。

SQL では、null は値ではなくマーカーです。この使用法は、参照のnull 値がどのオブジェクトも指していないことを意味するほとんどのプログラミング言語とはまったく異なります。

EF Coddは、1975 年にACM - SIGMODの FDT Bulletinに発表した論文で、リレーショナル モデルで欠損データを表す方法として NULL について言及しています。SQL で採用されている NULL の意味論とともに最もよく引用される Codd の論文は、1979 年にACM Transactions on Database Systemsに発表した論文です。この論文で Codd はRelational Model/Tasmaniaも発表していますが、後者の論文の他の提案の多くは不明瞭なままです。1979 年の論文のセクション 2.3 では、算術演算における NULL 伝播の意味論と、 NULL と比較する際に3 値ロジックを使用する比較について詳しく説明されています。また、他の集合演算における NULL の扱いについても詳しく説明されています (後者の問題は今日でも議論の的となっています)。データベース理論の分野では、Codd の元の提案 (1975、1979) は現在「Codd テーブル」と呼ばれています。^{[1]コッドは1985年に}Computerworld誌に2部構成の記事を掲載し、すべてのRDBMSが欠損データを示すNullをサポートするという要件を強化した。^{[2] [3]}

1986 年の SQL 標準では、 IBM System Rでの実装プロトタイプの後に、基本的に Codd の提案が採用されました。Don Chamberlin は、 NULL (重複行と並んで) が SQL の最も物議を醸す機能の 1 つであると認識していましたが、SQL における NULL の設計を擁護し、それが欠損情報に対するシステム サポートの最も安価な形式であり、プログラマーを多くの重複したアプリケーション レベルのチェック (半述語問題を参照) から救い、同時に、データベース設計者に、必要に応じて NULL を使用しないという選択肢を提供するという実用的な議論を持ち出しました。たとえば、よく知られている異常 (この記事のセマンティクスのセクションで説明) を回避するためです。Chamberlin はまた、欠損値機能の提供以外に、NULL に関する実際の経験から、特定のグループ化構造や外部結合など、NULL に依存する他の言語機能も生まれたと主張しました。最後に、彼は、実際には、Null は、既存のスキーマを元の意図を超えて進化させる必要がある場合に、欠落している情報ではなく適用できない情報をコード化して、既存のスキーマを素早く修正する方法としても使用されると主張しました。たとえば、ガロンあたりの走行距離の列を持ちながら、電気自動車をすぐにサポートする必要があるデータベースなどです。^[4]

コッドは 1990 年の著書『データベース管理のためのリレーショナル モデル バージョン 2』で、 SQL 標準で義務付けられている単一の Null では不十分であり、データが欠落している理由を示す 2 つの別々の Null 型マーカーに置き換える必要があると述べています。コッドの著書では、これらの 2 つの Null 型マーカーは「A 値」と「I 値」と呼ばれ、それぞれ「欠落しているが適用可能」と「欠落しているが適用不可能」を表しています。^[5] コッドの推奨事項では、SQL のロジック システムを拡張して 4 値ロジック システムに対応する必要がありました。この複雑さが増すため、異なる定義を持つ複数の Null というアイデアは、データベース実務家の間では広く受け入れられていません。ただし、これは依然として活発な研究分野であり、多数の論文が現在も出版されています。

Null は、関連する3 値ロジック(3VL)、 SQL 結合での使用に関する特別な要件、集計関数と SQL グループ化演算子に必要な特別な処理のために、論争の的となり、議論の的となってきました。コンピューター サイエンスの教授である Ron van der Meyden は、さまざまな問題を次のようにまとめています。「SQL 標準の不一致は、SQL での Null の扱いに直感的な論理的意味を当てはめることができないことを意味します。」^[1]これらの問題を解決するためのさまざまな提案がなされてきましたが、代替案の複雑さのために、それらの広範な採用は妨げられてきました。

Nullはデータ値ではなく、存在しない値を表すマーカーであるため、Nullに対して数学演算子を使用すると、Nullで表される未知の結果が得られます。^[6] 次の例では、10にNullを掛けるとNullになります。

10 * NULL -- 結果はNULLです            

これにより、予期しない結果が生じる可能性があります。たとえば、Null をゼロで除算しようとすると、プラットフォームは、予期される「データ例外 - ゼロ除算」をスローする代わりに、Null を返すことがあります。^[6] この動作は ISO SQL 標準では定義されていませんが、多くの DBMS ベンダーがこの操作を同様に扱っています。たとえば、Oracle、PostgreSQL、MySQL Server、および Microsoft SQL Server プラットフォームはすべて、次の場合に Null 結果を返します。

NULL / 0  

SQLで一般的な文字列連結演算も、オペランドの1つがNullの場合、Nullになります。^[7] 次の例は、SQL文字列連結演算子でNullを使用した場合に返されるNull結果を示しています||。

'Fish ' || NULL || 'Chips' -- 結果は NULL です       

これはすべてのデータベース実装に当てはまるわけではありません。たとえば、Oracle RDBMSでは、NULLと空の文字列は同じものとみなされるため、「Fish ' || NULL || 'Chips'」は「Fish Chips」になります。^[8]

Nullはどのデータドメインのメンバーでもないため、「値」とはみなされず、未定義の値を示すマーカー（またはプレースホルダー）と見なされます。このため、Nullとの比較ではTrueまたはFalseのいずれにもならず、常に3番目の論理結果であるUnknownが返されます。^[9] 値10をNullと比較する以下の式の論理結果はUnknownです。

SELECT 10 = NULL -- 結果は不明          

ただし、Null に対する特定の操作では、存在しない値が操作の結果に関係しない場合に値を返すことがあります。次の例を検討してください。

SELECT NULL OR TRUE -- 結果は True になります      

この場合、OR の左側の値が不明であるという事実は無関係です。なぜなら、OR 演算の結果は左側の値に関係なく True になるからです。

SQLは3つの論理結果を実装するため、SQL実装では特殊な3値ロジック（3VL）を提供する必要があります。SQLの3値ロジックを管理するルールは、以下の表に示されています（pとqは論理状態を表します）。" ^[10] SQLがAND、OR、NOTに使用する真理値表は、KleeneとŁukasiewiczの3値ロジックの共通フラグメントに対応しています（これらは含意の定義が異なりますが、SQLではそのような演算は定義されていません）。^[11]

SQL の 3 値ロジックは、データ操作言語(DML) の DML ステートメントおよびクエリの比較述語で使用されます。句により、述語が True と評価される行に対してのみ DML ステートメントが実行されます。述語が False または Unknown と評価される行は、 DML ステートメント、、またはクエリWHEREによって処理されず、クエリによって破棄されます。Unknown と False を同じ論理結果として解釈することは、Null を処理する際によく発生するエラーです。^[10] 次の簡単な例は、この誤りを示しています。 INSERTUPDATEDELETESELECT

SELECT * FROM t WHERE i = NULL ; 
 
   

上記の例のクエリは、 i列と Nullの比較で常に Unknown が返されるため、論理的には常に 0行を返します。これは、 iが Nullである行に対しても当てはまります。Unknown の結果により、SELECTステートメントはすべての行を即座に破棄します。(ただし、実際には、一部の SQL ツールは Null との比較を使用して行を取得します。)

基本的なSQL比較演算子は、何かをNullと比較すると常にUnknownを返します。そのため、SQL標準では2つの特別なNull固有の比較述語が用意されています。述語IS NULLと述語（接尾辞IS NOT NULL構文を使用）は、データがNullかどうかをテストします。^[12]

SQL 標準にはオプション機能 F571「真理値テスト」が含まれており、これも接尾記法を使用して 3 つの追加の論理単項演算子 (構文の一部である否定を数えると、実際には 6 つ) が導入されています。これらの演算子には次の真理値表があります: ^[13]

F571 機能は SQL のブールデータ型の存在とは直交しており (この記事の後半で説明します)、構文上の類似性にもかかわらず、F571 は言語にブール値または 3 値リテラルを導入しません。F571 機能は実際にはSQL92に存在しており、^[14]ブールデータ型が 1999 年に標準に導入されるずっと前から存在していました。ただし、F571 機能を実装しているシステムは少数で、PostgreSQL はこれを実装しているシステムの 1 つです。

SQLの3値ロジックの他の演算子にIS UNKNOWNを追加すると、SQLの3値ロジックは機能的に完全になります。^[15]つまり、その論理演算子は（組み合わせて）考えられるあらゆる3値論理関数を表現できます。

F571 機能をサポートしていないシステムでは、式 p を Unknown にする可能性のあるすべての引数を調べて、それらの引数を IS NULL またはその他の NULL 固有の関数でテストすることにより、IS UNKNOWN pをエミュレートできますが、これはより面倒になる可能性があります。

SQL の 3 値論理では、排中律p OR NOT p は、すべてのpに対して true と評価されなくなりました。より正確には、SQL の 3 値論理では、p OR NOT p はpが不明な場合にのみ不明であり、それ以外の場合は true です。Null との直接比較は不明な論理値となるため、次のクエリでは

SELECT * FROM stuff WHERE ( x = 10 ) OR NOT ( x = 10 );                

SQLでは同等ではない

SELECT * FROMスタッフ;   

列 x に Null が含まれている場合、2 番目のクエリは最初のクエリが返さない行、つまり x が Null であるすべての行を返します。従来の 2 値ロジックでは、排中律によって WHERE 句の述語を簡素化でき、実際には削除できます。排中律を SQL の 3VL に適用しようとすると、事実上誤った二分法になります。2 番目のクエリは実際には次のクエリと同等です。

SELECT * FROM stuff ; -- は (3VL のため) 以下と同等です: SELECT * FROM stuff WHERE ( x = 10 ) OR NOT ( x = 10 ) OR x IS NULL ;   

                    

したがって、SQL の最初のステートメントを正しく簡略化するには、x が null ではないすべての行を返す必要があります。

SELECT * FROM stuff WHERE x IS NOT NULL ;        

上記を踏まえて、SQL の WHERE 句では排中律に似たトートロジーを記述できることに注目してください。IS UNKNOWN 演算子が存在すると仮定すると、すべての述語pに対してp OR (NOT p ) OR ( p IS UNKNOWN) が真になります。論理学者の間では、これは排中律と呼ばれています。

誤ったジレンマが発生する場所がわかりにくい SQL 式がいくつかあります。次に例を示します。

SELECT 'ok' WHERE 1 NOT IN ( SELECT CAST ( NULL AS INTEGER )) UNION SELECT 'ok' WHERE 1 IN ( SELECT CAST ( NULL AS INTEGER ));          

         

行は生成されませんIN。これは、引数セットの等価性の反復バージョンに変換され、1=NULL が不明であるのと同様に、1<>NULL が不明であるためです。(この例の CAST は、PostgreSQL などの一部の SQL 実装でのみ必要です。それ以外の場合は、型チェック エラーで拒否されます。多くのシステムでは、単純な SELECT NULL がサブクエリで機能します。) 上記の不足しているケースは、もちろん次のとおりです。

SELECT 'ok' WHERE ( 1 IN ( SELECT CAST ( NULL AS INTEGER ))) IS UNKNOWN ;           

結合は、WHERE句と同じ比較規則を使用して評価されます。したがって、SQL結合条件でnull可能な列を使用する場合は注意が必要です。特に、nullを含むテーブルは、それ自体の自然な自己結合と等しくありません。つまり、リレーショナル代数の任意の関係Rに対してが真であるのに対し、SQL自己結合では、どこにでもNullがある行がすべて除外されます。^[16]この動作の例は、Nullの欠損値セマンティクスを分析するセクションで示されています。 ${\displaystyle R\bowtie R=R}$

SQLCOALESCE関数またはCASE式を使用して、結合条件で Null の等価性を「シミュレート」できます。また、述語IS NULLをIS NOT NULL結合条件で使用することもできます。次の述語は、値 A と B の等価性をテストし、Null を等しいものとして扱います。

( A = B )または( AはNULLであり、B はNULLである)          

SQL には2 種類の条件式が用意されています。1 つは「単純 CASE」と呼ばれ、switch 文のように動作します。もう 1 つは標準では「検索 CASE」と呼ばれ、 if...elseifのように動作します。

単純な式では、DML句の Null のルールCASEと同じルールに従って動作する暗黙的な等価比較が使用されます。したがって、単純な式では Null の存在を直接チェックすることはできません。単純な式で Null をチェックすると、次の例のように常に Unknown という結果になります。 WHERECASECASE

SELECT CASE i WHEN NULL THEN 'Is Null' -- これは返されませんWHEN 0 THEN 'Is Zero' -- i = 0 の場合に返されますWHEN 1 THEN 'Is One' -- i = 1 の場合に返されますEND FROM t ;        
                      
                       
              
 

列ii = NULLにどのような値が含まれていても(Null が含まれていても)、式は Unknown と評価されるため、文字列は返されません。 'Is Null'

一方、「検索」式では、条件にandCASEなどの述語を使用できます。次の例は、検索式を使用して Null を適切にチェックする 方法を示しています。IS NULLIS NOT NULLCASE

SELECT CASE WHEN i IS NULL THEN 'Null Result' -- i が NULL の場合にこれが返されますWHEN i = 0 THEN 'Zero' -- i = 0 の場合にこれが返されますWHEN i = 1 THEN 'One' -- i = 1 の場合にこれが返されますEND FROM t ;         
                              
                               
            
 

検索式では、 iが Nullであるすべての行に対してCASE文字列が返されます。 'Null Result'

DECODEOracle の SQL 方言には、単純な CASE 式の代わりに使用でき、2 つの null を等しいと見なす 組み込み関数が用意されています。

SELECT DECODE ( i 、NULL 、'Null Result' 、0 、'Zero' 、1 、'One' ) FROM t ;         

最後に、これらのすべての構造は、一致するものが見つからない場合は NULL を返します。これらにはデフォルトELSE NULL句があります。

SQL/PSM (SQL Persistent Stored Modules)は、ステートメントなどの SQL の手続き型IF拡張機能を定義します。ただし、主要な SQL ベンダーは、歴史的に独自の手続き型拡張機能を組み込んできました。ループと比較の手続き型拡張機能は、DML ステートメントおよびクエリの場合と同様の Null 比較ルールに従って動作します。次の ISO SQL 標準形式のコード フラグメントは、ステートメントでの Null 3VL の使用法を示していますIF。

IF i = NULL THEN SELECT '結果は True' ELSEIF NOT ( i = NULL ) THEN SELECT '結果は False' ELSE SELECT '結果は不明' ;    
       
    
       

       

ステートメントIFは、True と評価される比較に対してのみアクションを実行します。False または Unknown と評価されるステートメントの場合、ステートメントIFは制御をELSEIF句に渡し、最終的にELSE句に渡します。Null との比較は常に Unknown と評価されるため、上記のコードの結果は常にメッセージになります'Result is Unknown'。

T.イミエリンスキとW.リプスキ・ジュニア（1984年）^[17]の画期的な研究は、欠損値セマンティクスを実装するためのさまざまな提案の意図されたセマンティクスを評価するためのフレームワークを提供しました。これはイミエリンスキ-リプスキ代数と呼ばれています。このセクションは、おおよそ「アリス」教科書の第19章に倣っています。^[18]同様の説明は、ロン・ファン・デル・メイデンのレビューの§10.4に掲載されています。^[1]

Codd テーブルなどの欠落情報を表す構造は、実際には、パラメータの可能なインスタンスごとに 1 つの関係のセットを表すことを目的としています。Codd テーブルの場合、これは Null を具体的な値に置き換えることを意味します。たとえば、

構成要素 (Codd テーブルなど) は、その構成要素に対して行われたクエリに対する回答を、それが表す関係(構成要素のモデルと見なされる) に対する対応するクエリの回答を取得するために特定化できる場合、(欠落情報の) 強力な表現システムであると言われます。より正確には、qが(「純粋な」関係の)リレーショナル代数のクエリ式であり、 q が欠落情報を表すことを意図した構成要素へのその持ち上げである場合、強力な表現には、任意のクエリqと (テーブル) 構成要素Tに対して、q がすべての回答を構成要素に 持ち上げるという特性があります。つまり、

${\displaystyle \mathop {\mathrm {モデル} } ({\bar {q}}(T))=\{q(R)\,|R\in \mathop {\mathrm {モデル} } (T)\}}$

（上記は、任意の数のテーブルを引数として取るクエリに当てはまる必要がありますが、この議論では1つのテーブルに制限することで十分です。）選択と投影がクエリ言語の一部であると考えられる場合、明らかにCoddテーブルにはこの強力な特性がありません。たとえば 、

SELECT * FROM Emp WHERE年齢= 22 ;       

EmpH22 のような関係が存在する可能性も考慮する必要があります。ただし、Codd テーブルでは、論理和「0 行または 1 行の結果」を表すことはできません。ただし、条件テーブル (または c テーブル) と呼ばれる、主に理論的な興味をそそるデバイスでは、次のような答えを表すことができます。

ここで、条件列は、条件が偽の場合、行が存在しないと解釈されます。c-table の条件列の式は任意の命題論理式になる可能性があるため、c-table が何らかの具体的な関係を表しているかどうかという問題に対するアルゴリズムは、共 NP 完全な複雑性を持つため、実用的な価値がほとんどないことがわかります。

したがって、より弱い表現の概念が望ましい。イミエリンスキーとリプスキは、弱い表現の概念を導入した。これは、構成に対する（持ち上げられた）クエリが、確実な情報、つまり構成のすべての「可能世界」インスタンス化（モデル）に対して有効である場合にのみ表現を返すことを可能にする。具体的には、構成が弱い表現システムであるのは、

${\displaystyle \bigcap \mathop {\mathrm {モデル} } ({\bar {q}}(T))=\bigcap \{q(R)\,|R\in \mathop {\mathrm {モデル} } (T)\}}$

上記の式の右側は確実な情報、つまりデータベース内の Null を置き換えるためにどのような値が使用されるかに関係なく、データベースから確実に抽出できる情報です。上で検討した例では、クエリ選択のすべての可能なモデルの共通部分 (つまり確実な情報) が実際には空であることが簡単にわかります。これは、たとえば (リフトされていない) クエリが関係 EmpH37 の行を返さないためです。より一般的には、クエリ言語が射影、選択 (および列の名前変更) に制限されている場合、Codd テーブルは弱い表現システムであることが Imielinski と Lipski によって示されました。ただし、次のセクションで証明されるように、クエリ言語に結合または結合を追加するとすぐに、この弱いプロパティさえも失われます。 WHERE Age = 22

前のセクションと 同じ Codd テーブルEmpに対する次のクエリを検討してください。

SELECT Name FROM Emp WHERE Age = 22 UNION SELECT Name FROM Emp WHERE Age <> 22 ;       

       

Harriet の年齢にどのような具体的な値を選択するかに関係なくNULL、上記のクエリはEmpの任意のモデルの名前の完全な列を返しますが、(リフトされた)クエリがEmp自体に対して実行されると、Harriet は常に欠落します。つまり、次のようになります。

したがって、クエリ言語に UNION が追加されると、Codd テーブルは欠落情報の弱い表現システムでさえなくなり、クエリでは確実な情報がすべて報告されるわけではありません。ここで重要なのは、後のセクションで説明する Null に対する UNION のセマンティクスがこのクエリでは機能していないことです。2 つのサブクエリの「忘れやすい」性質は、上記のクエリが Codd テーブル Emp で実行されたときに確実な情報が報告されないことを保証するのに必要なすべてでした。

自然結合の場合、あるクエリによって確実な情報が報告されない可能性があることを示すために必要な例は、少し複雑になります。次の表を考えてみましょう。

そしてクエリ

SELECT F1 , F3 FROM ( SELECT F1 , F2 FROM J ) AS F12 NATURAL JOIN ( SELECT F2 , F3 FROM J ) AS F23 ;   
           
      
           

上記で何が起きるかの直感は、サブクエリの射影を表す Codd テーブルが、列 F12.F2 と F23.F2 の Null が実際にはテーブル J のオリジナルのコピーであるという事実を見失っているということです。この観察から、Codd テーブルの比較的単純な改善 (この例では正しく機能します) は、単一の NULL シンボルの代わりに、スコーレム定数(つまり、定数関数でもあるスコーレム関数)、たとえば ω ₁₂と ω _{22 を}使用することであることがわかります。v テーブルまたは Naive テーブルと呼ばれるこのようなアプローチは、上で説明した c テーブルよりも計算コストが低くなります。ただし、v テーブルは選択で否定を使用しない (および差集合も使用しない) クエリの弱い表現にすぎないという意味で、不完全な情報に対する完全なソリューションではありません。このセクションで検討する最初の例は、否定選択句 を使用しているため、v テーブル クエリが確実な情報を報告しない例でもあります。 WHERE Age <> 22

SQL の 3 値ロジックが SQLデータ定義言語(DDL) と交差する主な場所は、チェック制約の形式です。列に設定されたチェック制約は、DML 句のルールとは若干異なるルール セットに従って動作しますWHERE。DMLWHERE句は行に対して True と評価される必要がありますが、チェック制約は False と評価されてはなりません (ロジックの観点からは、指定値は True と Unknown です)。つまり、チェックの結果が True または Unknown の場合、チェック制約は成功します。チェック制約を含む次の表の例では、列iに整数値が挿入されることは禁止されますが、チェックの結果が Null に対して常に Unknown と評価されるため、Null の挿入は許可されます。^[19]

テーブルtを作成します( i INTEGER 、制約ck_i CHECK ( i < 0 AND i = 0 AND i > 0 ) );   
      
                     

WHERE句に対する指定値の変更のため、論理的観点からは、排中律はCHECK制約のトートロジーであり、常に成功することを意味します。さらに、Null は存在するが未知の値として解釈されると仮定すると、上記のような一部の異常な CHECK では、Null 以外の値で置き換えることができない Null の挿入が許可されます。 CHECK (p OR NOT p)

列が Null を拒否するように制約するには、NOT NULL以下の例に示すように制約を適用します。この制約は、述語を含むチェック制約NOT NULLと意味的に同等です。 IS NOT NULL

テーブルtを作成します( i はINTEGER NOT NULL です);        

デフォルトでは、外部キーに対するチェック制約は、キーのフィールドのいずれかがNullの場合に成功します。たとえば、テーブル

テーブルBooks ( title VARCHAR ( 100 )、author_last VARCHAR ( 20 )、author_first VARCHAR ( 20 )、FOREIGN KEY ( author_last 、author_first ) REFERENCES Authors ( last_name 、first_name )を作成します。  
  
   
   
   
    

NULLは、Authors テーブルの定義方法やテーブルに含まれる内容に関係なく、author_last または author_first がある行の挿入を許可します。より正確には、これらのフィールドのいずれかが null の場合、Authors テーブルにないフィールドであっても、もう一方のフィールドに任意の値が許可されます。たとえば、Authors に のみが含まれている場合('Doe', 'John')、 は('Smith', NULL)外部キー制約を満たします。SQL -92では、このような場合に一致を絞り込むためのオプションが 2 つ追加されました。宣言MATCH PARTIALの後に が追加された場合REFERENCES、null 以外の値は('Doe', NULL)すべて外部キーと一致する必要があります。たとえば、 はまだ一致しますが、 は('Smith', NULL)一致しません。最後に、MATCH FULLが追加された場合、 は('Doe', NULL)制約にも一致しませんが、 は(NULL, NULL)まだ一致します。

左外部結合、右外部結合、完全外部結合などのSQL外部結合では、関連するテーブル内の欠落値のプレースホルダーとして Null が自動的に生成されます。たとえば、左外部結合の場合、演算子の右側に表示されるテーブルから欠落している行の代わりに Null が生成されますLEFT OUTER JOIN。次の簡単な例では、2 つのテーブルを使用して、左外部結合での Null プレースホルダーの生成を示します。

最初のテーブル ( Employee ) には従業員 ID 番号と名前が含まれ、2 番目のテーブル ( PhoneNumber ) には関連する従業員 ID 番号と電話番号が含まれます(以下を参照)。

次のサンプル SQL クエリは、これら 2 つのテーブルに対して左外部結合を実行します。

SELECT e.ID 、e.LastName 、e.FirstName 、pn.Number FROM Employee e LEFT OUTER JOIN PhoneNumber pn ON e.ID = pn.ID ;​​​​​​​​​​​​    
  
    
   

このクエリによって生成された結果セットは、次に示すように、SQL が右側のテーブル ( PhoneNumber ) に欠落している値のプレースホルダーとして Null を使用する方法を示しています。

SQLでは、サーバー側でのデータ集計計算を簡素化するために集計関数を定義しています。関数を除いてCOUNT(*)、すべての集計関数はNull除去ステップを実行し、計算の最終結果にNullが含まれないようにします。^[20]

Null の除去は、Null をゼロに置き換えることと同じではないことに注意してください。たとえば、次の表では、AVG(i)( の値の平均i) は の結果とは異なりますAVG(j)。

ここでAVG(i)は 200（150、200、250 の平均）であり、AVG(j)は 150（150、200、250、0 の平均）です。このよく知られた副作用は、SQL ではがではなく とAVG(z)同等になることです。^[4]SUM(z)/COUNT(*)SUM(z)/COUNT(z)

集計関数の出力は Null になることもあります。次に例を示します。

SELECT COUNT ( * ) , MIN ( e.Wage ) , MAX ( e.Wage ) FROM Employee e WHERE e.LastName LIKE ' % Jones % ' ;   
  
   

このクエリは常に 1 行だけを出力し、姓に「Jones」が含まれる従業員の数をカウントし、それらの従業員の最低賃金と最高賃金を示します。ただし、従業員のいずれも指定された基準に適合しない場合はどうなるでしょうか。空のセットの最小値または最大値を計算することは不可能であるため、結果は NULL になり、答えがないことを示します。これは不明な値ではなく、値が存在しないことを示す Null です。結果は次のようになります。

SQL:2003では、すべての Null マーカーが互いに等しくないと定義されているため、特定の操作を実行するときに Null をグループ化するには、特別な定義が必要でした。SQL では、「互いに等しい 2 つの値、または任意の 2 つの Null」を「区別できない」と定義しています。 ^[21] この区別できないという定義により、句 (またはグループ化を実行する別の SQL 言語機能) が使用されている場合、SQL は Null をグループ化して並べ替えることができますGROUP BY。

Null の処理に「not distinctive」定義を使用するその他の SQL 操作、句、およびキーワードには、次のものがあります。

• ランキング関数とウィンドウ関数の節PARTITION BYは、ROW_NUMBER
• UNION、、INTERSECTおよび演算子EXCEPTは、行の比較/削除の目的でNULLを同じものとして扱います。
• クエリDISTINCTで使用されるキーワードSELECT

NULL は互いに等しくない (結果は不明である) という原則は、SQL の演算子仕様では事実上違反しているUNION。この演算子は NULL を互いに識別する。^[1]その結果、SQL の集合演算 (和集合や差集合などWHERE) の一部は、NULL との明示的な比較を伴う演算 (前述の句など) とは異なり、確実な情報を表さない結果を生成する可能性がある。Codd の 1979 年の提案 (SQL92 で採用された) では、この意味の不一致は、集合演算における重複の削除は「取得演算の評価における等価性テストよりも詳細度が低い」という主張によって合理化されている。^[11]

SQL 標準では、Null のデフォルトのソート順序は明示的に定義されていません。代わりに、準拠システムでは、リストのNULLS FIRSTor句を使用して、Null をすべてのデータ値の前または後にソートできます。ただし、すべての DBMS ベンダーがこの機能を備えているわけではありません。この機能を実装していないベンダーは、DBMS での Null ソートに異なる処理を指定する場合があります。^[19]NULLS LASTORDER BY

一部のSQL製品では、NULLを含むキーをインデックス化しません。例えば、PostgreSQLバージョン8.3より前では、 Bツリーインデックス のドキュメントには次のように記載されています。 ^[22]

B ツリーは、何らかの順序でソートできるデータに対する等価性および範囲クエリを処理できます。特に、PostgreSQL クエリ プランナーは、インデックス付けされた列が以下の演算子のいずれかを使用した比較に関係する場合は常に、B ツリー インデックスの使用を検討します: < ≤ = ≥ >

BETWEEN や IN など、これらの演算子の組み合わせに相当する構造も、B ツリー インデックス検索で実装できます。(ただし、IS NULL は = と同等ではなく、インデックス付けできないことに注意してください。)

インデックスが一意性を強制する場合、NULLはインデックスから除外され、NULL間の一意性は強制されません。ここでもPostgreSQLのドキュメントから引用します: ^[23]

インデックスが一意であると宣言されている場合、インデックス値が等しい複数のテーブル行は許可されません。Null は等しいとはみなされません。複数列の一意のインデックスでは、2 つの行でインデックスが付けられたすべての列が等しい場合のみ拒否されます。

これは、 SQL:2003で定義されたスカラー Null 比較の動作と一致しています。

NULLをインデックス化する別の方法としては、SQL:2003で定義された動作に従って、 NULLを区別できないものとして扱う方法があります。たとえば、 Microsoft SQL Serverのドキュメントには次のように記載されています。^[24]

インデックス作成の目的では、NULL は等しいものとして比較されます。したがって、キーが複数の行で NULL の場合、一意のインデックスまたは UNIQUE 制約は作成できません。一意のインデックスまたは一意の制約の列を選択するときは、NOT NULL として定義されている列を選択してください。

これらのインデックス戦略は両方とも、SQL:2003 で定義された Null の動作と一致しています。インデックス手法は SQL:2003 標準で明示的に定義されていないため、Null のインデックス戦略の設計と実装は完全にベンダーに委ねられています。

SQLでは、Nullを明示的に処理するための2つの関数が定義されています。NULLIFと です。どちらの関数も検索式COALESCEの略語です。^[25]CASE

このNULLIF関数は 2 つのパラメータを受け入れます。最初のパラメータが 2 番目のパラメータと等しい場合はNULLIFNull を返します。それ以外の場合は、最初のパラメータの値が返されます。

NULLIF (値1 ,値2 ) 

したがって、NULLIFは次の式の略語ですCASE。

値1 =値2の場合NULLそれ以外の場合値1終了         

このCOALESCE関数はパラメータのリストを受け入れ、リストから最初の Null 以外の値を返します。

COALESCE (値1 、値2 、値3 、...)   

COALESCEは、次の SQLCASE式の省略形として定義されます。

CASE値1 がNULLでない場合、値1値2がNULLでない場合、値2値3 がNULLでない場合、値3 ...終了       
           
           
     
     

一部の SQL DBMS は、 に類似したベンダー固有の関数を実装していますCOALESCE。一部のシステム ( Transact-SQLなど)はISNULL、 関数、または と機能的に類似したその他の類似関数を実装していますCOALESCE。( Transact-SQL の関数の詳細については、Is関数をIS参照してください。)

OracleNVL関数は 2 つのパラメータを受け入れます。最初の NULL 以外のパラメータを返します。すべてのパラメータが NULL の場合は NULL を返します。

式は次のようにCOALESCE同等の式に変換できますNVL。

COALESCE ( val1 、... 、val { n } )      

次のように変わります:

NVL ( val1 , NVL ( val2 , NVL ( val3 , … , NVL ( val { n - 1 } , val { n } ) … )))                  

この関数の使用例は、式内の NULL を NVL(SALARY, 0)、次のように「SALARYNULL の場合は値 0 に置き換える」という値に置き換えることです。

ただし、注目すべき例外が 1 つあります。ほとんどの実装では、 はCOALESCE最初の NULL 以外のパラメータに到達するまでパラメータを評価しますが、 はすべてのパラメータを評価します。これはいくつかの理由で重要です。最初の NULL 以外のパラメータの後のNVLパラメータは関数である可能性があり、計算コストが高くなったり、無効になったり、予期しない副作用が生じたりする可能性があります。

SQLではリテラルNULL は型指定されていません。つまり、整数、文字、またはその他の特定のデータ型として指定されていません。 ^[26]このため、Nullを特定のデータ型に明示的に変換することが必須（または望ましい）になる場合があります。たとえば、 RDBMSでオーバーロードされた関数がサポートされている場合、SQLは、Nullが渡されるものも含め、すべてのパラメータのデータ型を知らなければ、正しい関数を自動的に解決できない可能性があります。

リテラルから特定の型の Null への変換は、SQL-92で導入されたNULLを使用して可能です。例: CAST

CAST ( NULL を整数として)   

INTEGER 型の存在しない値を表します。

Unknownの実際の型付け（NULL自体と異なるかどうか）はSQL実装によって異なります。たとえば、次のようになります。

SELECT 'ok' WHERE ( NULL <> 1 ) IS NULL ;       

NULL ブール値を Unknown と統合する一部の環境 ( SQLiteやPostgreSQLなど) では解析と実行に成功しますが、他の環境 ( SQL Server Compactなど) では解析に失敗します。この点では、 MySQL はPostgreSQLと同様に動作します(ただし、MySQL ではTRUE と FALSE が通常の整数 1 と 0 と何ら変わらないとみなされるという小さな例外があります)。PostgreSQL はさらにIS UNKNOWN、3 つの値の論理結果が Unknown かどうかをテストするために使用できる述語を実装していますが、これは単なる構文上の糖衣です。

ISO SQL:1999標準ではSQLにBOOLEANデータ型が導入されましたが、これはまだオプションの非コア機能であり、コードT031となっています。^[27]

制約によって制限されている場合NOT NULL、SQL BOOLEAN は他の言語のブール型のように機能します。ただし、制限されていない場合、BOOLEAN データ型は、その名前にもかかわらず、真理値 TRUE、FALSE、および UNKNOWN を保持できます。これらはすべて、標準に従ってブール リテラルとして定義されています。標準では、NULL と UNKNOWN は「まったく同じことを意味するために互換的に使用できる」とも主張しています。^{[28] [29]}

ブール型は、特にUNKNOWNリテラルの強制的な動作のために批判の対象となってきた。UNKNOWNリテラルはNULLと同一視されるため、決してそれ自身と等しくなることはない。^[30]

上で説明したように、PostgreSQLのSQL実装では、UNKNOWN BOOLEANを含むすべてのUNKNOWN結果を表すためにNullが使用されます。PostgreSQLはUNKNOWNリテラルを実装していません（ただし、直交機能であるIS UNKNOWN演算子は実装しています）。他のほとんどの主要ベンダーは、2012年現在、ブール型（T031で定義）をサポートしていません。^{[31]ただし、Oracleの}PL/SQLの手続き型部分はBOOLEAN変数をサポートしています。これらにはNULLを割り当てることもでき、その値はUNKNOWNと同じと見なされます。^[32]

Null の動作に関する誤解は、ISO 標準の SQL ステートメントと実際のデータベース管理システムでサポートされている特定の SQL 方言の両方で、SQL コードにおける多数のエラーの原因となっています。これらの間違いは通常、Null と 0 (ゼロ) または空の文字列 (長さがゼロの文字列値で、SQL では と表されます'') との混同によって生じます。ただし、SQL 標準では、Null は空の文字列や数値 とは異なるものとして定義されています0。Null は値が存在しないことを示しますが、空の文字列と数値のゼロはどちらも実際の値を表します。

典型的なエラーは、等号演算子を=キーワードと組み合わせて使用​​してNULL、Null を含む行を検索しようとすることです。SQL 標準によれば、これは無効な構文であり、エラー メッセージまたは例外が発生します。しかし、ほとんどの実装ではこの構文が受け入れられ、このような式は と評価されます。その結果、Null を含む行が存在するかどうかに関係なく、行は見つかりません。Null を含む行を取得するために提案されている方法は、 の代わりにUNKNOWN述語を使用することです。 IS NULL= NULL

SELECT * FROM sometable WHERE num = NULL ; -- 「WHERE num IS NULL」とすべき 
 
     

関連しているが、より微妙な例として、WHERE句または条件文で列の値を定数と比較することがあります。そのフィールドに Null が含まれている場合、欠落した値は定数より小さいか、定数と等しくないと誤って想定されることがよくありますが、実際には、このような式は Unknown を返します。次に例を示します。

SELECT * FROM sometable WHERE num <> 1 ; --多くのユーザーの予想に反して、num が NULL の行は返されません。 
 
     
                 

これらの混乱は、同一性の法則がSQLのロジックで制限されているために発生します。NULLリテラルまたは真理値を使用して等価比較を扱う場合、SQLは常に式の結果としてUNKNOWN返します。これは部分的な同値関係であり、SQLを非反射的ロジックの例にします。^[33]UNKNOWN

同様に、Null は空の文字列と混同されることがよくあります。LENGTH文字列内の文字数を返す関数を考えてみましょう。この関数に Null が渡されると、関数は Null を返します。ユーザーが 3 値ロジックに精通していない場合、予期しない結果が生じる可能性があります。次に例を示します。

SELECT * FROM sometable WHERE LENGTH ( string ) < 20 ; -- string が NULL の行は返されません。 
 
    

一部のデータベース インターフェイス プログラム (または Oracle のようなデータベース実装) では、NULL が空の文字列として報告され、空の文字列が誤って NULL として保存される可能性があるという事実によって、状況は複雑になります。

ISO SQL の Null 実装は、批判、議論、変更要求の対象となっている。『データベース管理のためのリレーショナル モデル: バージョン 2』で、Codd は、SQL の Null 実装には欠陥があり、2 つの異なる Null 型マーカーに置き換える必要があると提案した。彼が提案したマーカーは、 「欠落しているが適用可能」と「欠落しているが適用不可能」を表すもので、それぞれA 値とI 値と呼ばれる。Codd の提案が受け入れられた場合、SQL に 4 値ロジックを実装する必要があった。^[5] 他の人は、Codd の提案に Null 型マーカーを追加して、データ値が「欠落している」理由をさらに示すことを提案したが、SQL のロジック システムの複雑さが増した。SQL に複数のユーザー定義 Null マーカーを実装するという提案も、さまざまな時期に出された。複数の Null マーカーをサポートするために必要な Null 処理とロジック システムの複雑さのため、これらの提案はいずれも広く受け入れられなかった。

『第三の宣言』の著者であるクリス・デイトとヒュー・ダーウェンは、SQL Null実装は本質的に欠陥があり、完全に排除されるべきであると示唆しており、^[34] SQL Null処理の実装（特に集計関数）の不一致と欠陥を指摘し、Nullの概念全体に欠陥があり、リレーショナルモデルから削除されるべきであることを証明しています。^[35]ファビアン・パスカルなどの他の著者は、「関数の計算で欠損値をどのように扱うべきかは、リレーショナルモデルによって制御されない」という信念を述べています。^[要出典]

Null に関するもう 1 つの矛盾点は、リレーショナル データベースの閉世界仮定モデルにオープン ワールド仮定を導入することで、このモデルに違反している点です。^[36] データベースに関する閉世界仮定は、「データベースによって明示的または暗黙的に述べられるすべてのことは真であり、それ以外はすべて偽である」としています。^[37] この見解は、データベース内に格納される世界に関する知識が完全であると仮定しています。ただし、Null はオープン ワールド仮定に基づいて動作し、データベースに格納される一部の項目は未知と見なされるため、データベースに格納される世界に関する知識は不完全になります。

• 構文
• NULL について: Wikibook SQL
• 3値論理
• データ操作言語
• コッドの12のルール
• チェック制約
• リレーショナルモデル/タスマニア
• リレーショナルデータベース管理システム
• 結合 (SQL)

• EF Codd. 関係の理解（第7回）. FDT Bulletin of ACM-SIGMOD, 7(3-4):23–28, 1975.
• Codd, EF (1979). 「データベースリレーショナルモデルの拡張による意味のさらなる獲得」ACM Transactions on Database Systems . 4 (4): 397–434. CiteSeerX  10.1.1.508.5701 . doi :10.1145/320107.320109. S2CID  17517212.特に§2.3。
• Date, CJ (2000)。データベースリレーショナルモデル: 過去を振り返るレビューと分析: データベーステクノロジー分野への EF Codd の貢献に関する歴史的説明と評価。Addison Wesley Longman。ISBN 978-0-201-61294-3。
• Klein, Hans-Joachim (1994). 「確実な回答を保証するためにSQLクエリを変更する方法」ACM SIGMOD Record . 23 (3): 14–20. doi : 10.1145/187436.187445 . S2CID  17354724.
• Claude Rubinson、「SQL における Null、3 値ロジック、および曖昧性: Date の批判に対する批判」、Wayback Machineに 2016 年 3 月 5 日にアーカイブ、SIGMOD Record、2007 年 12 月 (第 36 巻、第 4 号)
• John Grant、「SQL の Null 値」、SIGMOD レコード、2008 年 9 月 (第 37 巻、第 3 号)
• Waraporn、Narongrit、Kriengkrai Porkaew。「サブクエリとアトミック述語の Null セマンティクス」。IAENG International Journal of Computer Science 35.3 (2008): 305-313。
• Bernhard Thalheim、Klaus-Dieter Schewe (2011)。「NULL '値' 代数と論理」。人工知能とアプリケーションの最前線。225 (情報モデリングと知識ベース XXII)。doi : 10.3233 /978-1-60750-690-4-354。
• Enrico Franconi および Sergio Tessaris、「SQL Null のロジックについて」、第 6 回 Alberto Mendelzon 国際データ管理基礎ワークショップの議事録、ブラジル、Ouro Preto、2012 年 6 月 27 ～ 30 日。pp. 114 ～ 128

• Oracle NULL は 2013-04-12 にWayback Machineにアーカイブされています
• 第三の宣言
• データの順序付けにおけるNULLの影響
• jdbc が null と空の文字列を区別しないという Java のバグ レポート。Sun はこれを「バグではない」としてクローズしました。