View source for Null (SQL)

{{Short description|Marker used in SQL databases to indicate a value does not exist}}
[[File:Db null.png|300px|thumb|right|The Greek lowercase [[Omega|omega (ω)]] character is used to represent Null in [[database theory]].]]

In [[SQL]], '''null''' or '''NULL''' is a special marker used to indicate that a data value does not exist in the [[database]]. Introduced by the creator of the [[Relational model|relational]] database model, [[E.&nbsp;F. Codd]], SQL null serves to fulfill the requirement that all ''true relational database management systems ([[Relational database#RDBMS|RDBMS]])'' support a representation of "missing information and inapplicable information".  Codd also introduced the use of the lowercase Greek [[omega]] (ω) symbol to represent null in [[database theory]].  In SQL, <code>NULL</code> is a [[List of SQL reserved words|reserved word]] used to identify this marker.

A null should not be confused with a value of [[0]]. A null indicates a lack of a value, which is not the same as a zero value. For example, consider the question "How many books does Adam own?" The answer may be "zero" (we ''know'' that he owns ''none'') or "null" (we ''do not know'' how many he owns). In a database table, the [[Column (database)|column]] reporting this answer would start with no value (marked by null), and it would not be updated with the value zero until it is ascertained that Adam owns no books.

In SQL, null is a marker, not a value. This usage is quite different from most programming languages, where a [[Null pointer|null value]] of a reference means it is not pointing to any [[Object (computer science)|object]].

== History ==
E. F. Codd mentioned nulls as a method of representing missing data in the [[relational model]] in a 1975 paper in the ''FDT Bulletin of [[Association for Computing Machinery|ACM]]-[[SIGMOD]]''. Codd's paper that is most commonly cited with the semantics of Null (as adopted in SQL) is his 1979 paper in the ''[[ACM Transactions on Database Systems]]'', in which he also introduced his [[Relational Model/Tasmania]], although much of the other proposals from the latter paper have remained obscure. Section 2.3 of his 1979 paper details the semantics of Null propagation in arithmetic operations as well as comparisons employing a [[Ternary logic|ternary (three-valued)]] logic when comparing to nulls; it also details the treatment of Nulls on other set operations (the latter issue still controversial today). In [[database theory]] circles, the original proposal of Codd (1975, 1979) is now referred to as "Codd tables".<ref name="Meyden"/> Codd later reinforced his requirement that all RDBMSs support Null to indicate missing data in a 1985 two-part article published in ''[[Computerworld]]'' magazine.<ref>{{cite journal|last=Codd|first=E.F.|title=Is Your Database Really Relational?|journal=[[Computerworld]]|date=October 14, 1985}}</ref><ref>{{cite journal|last=Codd|first=E.F.|title=Does Your DBMS Run By The Rules?|journal=[[Computerworld]]|date=October 21, 1985}}</ref>

The 1986 SQL standard basically adopted Codd's proposal after an implementation prototype in [[IBM System R]]. Although [[Don Chamberlin]] recognized nulls (alongside duplicate rows) as one of the most controversial features of SQL, he defended the design of Nulls in SQL invoking the pragmatic arguments that it was the least expensive form of system support for missing information, saving the programmer from many duplicative application-level checks (see [[semipredicate problem]]) while at the same time providing the database designer with the option not to use Nulls if they so desire; for example, to avoid well-known anomalies (discussed in the [[#missing-value semantics|semantics section]] of this article). Chamberlin also argued that besides providing some missing-value functionality, practical experience with Nulls also led to other language features that rely on Nulls, like certain grouping constructs and outer joins. Finally, he argued that in practice Nulls also end up being used as a quick way to patch an existing [[database schema|schema]] when it needs to evolve beyond its original intent, coding not for missing but rather for inapplicable information; for example, a database that quickly needs to support electric cars while having a miles-per-gallon column.<ref name="Chamberlin1998">{{cite book|author1=Don Chamberlin|title=A Complete Guide to DB2 Universal Database|url=https://books.google.com/books?id=hb4zskzHrWYC&pg=PA28|year=1998|publisher=Morgan Kaufmann|isbn=978-1-55860-482-7|pages=28–32}}</ref>

Codd indicated in his 1990 book ''The Relational Model for Database Management, Version 2'' that the single Null mandated by the SQL standard was inadequate, and should be replaced by two separate Null-type markers to indicate why data is missing. In Codd's book, these two Null-type markers are referred to as 'A-Values' and 'I-Values', representing 'Missing But Applicable' and 'Missing But Inapplicable', respectively.<ref name="isbn0201141922"/>  Codd's recommendation would have required SQL's logic system be expanded to accommodate a four-valued logic system.  Because of this additional complexity, the idea of multiple Nulls with different definitions has not gained widespread acceptance in the database practitioners' domain. It remains an active field of research though, with numerous papers still being published.

=== Challenges ===
Null has been the focus of controversy and a source of debate because of its associated [[three-valued logic]] (3VL), special requirements for its use in [[Join (SQL)|SQL joins]], and the special handling required by aggregate functions and SQL grouping operators. Computer science professor Ron van der Meyden summarized the various issues as: "The inconsistencies in the SQL standard mean that it is not possible to ascribe any intuitive logical semantics to the treatment of nulls in SQL."<ref name="Meyden">Ron van der Meyden, "[https://books.google.com/books?id=gF0b85IuqQwC&pg=PA344 Logical approaches to incomplete information: a survey]" in Chomicki, Jan; Saake, Gunter (Eds.) ''Logics for Databases and Information Systems'', Kluwer Academic Publishers {{ISBN|978-0-7923-8129-7}}, p. 344; [http://www.cse.unsw.edu.au/~meyden/research/indef-review.ps PS preprint] (note: page numbering differs in preprint from the published version)</ref> Although various proposals have been made for resolving these issues, the complexity of the alternatives has prevented their widespread adoption.

== Null propagation ==
=== Arithmetic operations ===
Because Null is not a data value, but a marker for an absent value, using mathematical operators on Null gives an unknown result, which is represented by Null.<ref name="SQL2003-Part2-Sec626">{{cite book
  | last =ISO/IEC
  | title =ISO/IEC 9075-2:2003, "SQL/Foundation"
  | publisher =ISO/IEC
  | year =2003
  | pages =Section 6.2.6: ''numeric value expressions''
  | no-pp =true
}}.</ref>  In the following example, multiplying 10 by Null results in Null:

<syntaxhighlight lang="SQL">
10 * NULL          -- Result is NULL
</syntaxhighlight>

This can lead to unanticipated results.  For instance, when an attempt is made to divide Null by zero, platforms may return Null instead of throwing an expected "data exception{{snd}} division by zero".<ref name="SQL2003-Part2-Sec626"/>  Though this behavior is not defined by the ISO SQL standard many DBMS vendors treat this operation similarly. For instance, the Oracle, PostgreSQL, MySQL Server, and Microsoft SQL Server platforms all return a Null result for the following:

<syntaxhighlight lang="SQL">
NULL / 0
</syntaxhighlight>

=== String concatenation ===
String [[concatenation]] operations, which are common in SQL, also result in Null when one of the operands is Null.<ref name="SQL2003-Part2-Sec628">
{{cite book
  | last =ISO/IEC
  | title =ISO/IEC 9075-2:2003, "SQL/Foundation"
  | publisher =ISO/IEC
  | year =2003
  | pages =Section 6.2.8: ''string value expression''
  | no-pp =true
}}</ref>  The following example demonstrates the Null result returned by using Null with the SQL <code>||</code> string concatenation operator.

<syntaxhighlight lang="sql">
'Fish ' || NULL || 'Chips'   -- Result is NULL
</syntaxhighlight>
This is not true for all database implementations. In an Oracle RDBMS, for example, NULL and the empty string are considered the same thing and therefore 'Fish ' || NULL || 'Chips' results in 'Fish Chips'.<ref>{{Cite web |date=2022-05-23 |title=Handle empty strings when migrating from Oracle to PostgreSQL {{!}} AWS Database Blog |url=https://aws.amazon.com/blogs/database/handle-empty-strings-when-migrating-from-oracle-to-postgresql/ |access-date=2023-12-30 |website=aws.amazon.com |language=en-US}}</ref>

== Comparisons with NULL and the three-valued logic (3VL) ==
{{Further|Three-valued logic}}
Since Null is not a member of any [[data domain]], it is not considered a "value", but rather a marker (or placeholder) indicating the [[undefined value]]. Because of this, comparisons with Null can never result in either True or False, but always in a third logical result, Unknown.<ref name="SQL2003-Part1-Sec442">
{{cite book
  | last =ISO/IEC
  | title =ISO/IEC 9075-1:2003, "SQL/Framework"
  | publisher =ISO/IEC
  | year =2003
  | pages =Section 4.4.2: ''The null value''
  | url =http://www.iso.org
  | no-pp =true
}}</ref>  The logical result of the expression below, which compares the value 10 to Null, is Unknown:

<syntaxhighlight lang="SQL">
SELECT 10 = NULL       -- Results in Unknown
</syntaxhighlight>

However, certain operations on Null can return values if the absent value is not relevant to the outcome of the operation. Consider the following example:

<syntaxhighlight lang="SQL">
SELECT NULL OR TRUE   -- Results in True
</syntaxhighlight>

In this case, the fact that the value on the left of OR is unknowable is irrelevant, because the outcome of the OR operation would be True regardless of the value on the left.

SQL implements three logical results, so SQL implementations must provide for a specialized [[Ternary logic|three-valued logic (3VL)]].  The rules governing SQL three-valued logic are shown in the tables below ('''p''' and '''q''' represent logical states)"<ref name="fourrules">{{cite journal | last = Coles, Michael | title = Four Rules for Nulls | journal = SQL Server Central | publisher = Red Gate Software | date = June 27, 2005 | url = http://www.sqlservercentral.com/columnists/mcoles/fourrulesfornulls.asp }}</ref> The truth tables SQL uses for AND, OR, and NOT correspond to a common fragment of the Kleene and Łukasiewicz three-valued logic (which differ in their definition of implication, however, SQL defines no such operation).<ref name="Klein">{{Cite book | last1 = Hans-Joachim | first1 = K. | chapter = Null Values in Relational Databases and Sure Information Answers | doi = 10.1007/3-540-36596-6_7 | title = Semantics in Databases. Second International Workshop Dagstuhl Castle, Germany, January 7–12, 2001. Revised Papers | series = Lecture Notes in Computer Science | volume = 2582 | pages = 119–138| year = 2003 | isbn = 978-3-540-00957-3 | chapter-url = http://www.is.informatik.uni-kiel.de/~hjk/sqlni.ps}}</ref>

{| class="wikitable"
 ! ''p'' !! ''q'' !! ''p'' OR ''q'' !! ''p'' AND ''q'' !! ''p'' = ''q''
 |-
 | {{yes2|True}} || {{yes2|True}} || {{yes2|True}} || {{yes2|True}} || {{yes2|True}}
 |-
 | {{yes2|True}} || {{no2|False}} || {{yes2|True}} || {{no2|False}} || {{no2|False}}
 |-
 | {{yes2|True}} || {{Unknown}} || {{yes2|True}} || {{Unknown}} || {{Unknown}}
 |-
 | {{no2|False}} || {{yes2|True}} || {{yes2|True}} || {{no2|False}} || {{no2|False}}
 |-
 | {{no2|False}} || {{no2|False}} || {{no2|False}} || {{no2|False}} || {{yes2|True}}
 |-
 | {{no2|False}} || {{Unknown}} || {{Unknown}} || {{no2|False}} || {{Unknown}}
 |-
 | {{Unknown}} || {{yes2|True}} || {{yes2|True}} || {{Unknown}} || {{Unknown}}
 |-
 | {{Unknown}} || {{no2|False}} || {{Unknown}} || {{no2|False}} || {{Unknown}}
 |-
 | {{Unknown}} || {{Unknown}} || {{Unknown}} || {{Unknown}} || {{Unknown}}
|}

{| class="wikitable"
 ! ''p'' !! NOT ''p''
 |-
 | {{yes2|True}} || {{no2|False}}
 |-
 | {{no2|False}} || {{yes2|True}}
 |-
 | {{Unknown}} || {{Unknown}}
|}

=== Effect of Unknown in WHERE clauses ===
SQL three-valued logic is encountered in [[Data Manipulation Language]] (DML) in comparison predicates of DML statements and queries. The <code>WHERE</code> clause causes the DML statement to act on only those rows for which the predicate evaluates to True.  Rows for which the predicate evaluates to either False or Unknown are not acted on by <code>[[Insert (SQL)|INSERT]]</code>, <code>[[Update (SQL)|UPDATE]]</code>, or <code>[[Delete (SQL)|DELETE]]</code> DML statements, and are discarded by <code>[[Select (SQL)|SELECT]]</code> queries. Interpreting Unknown and False as the same logical result is a common error encountered while dealing with Nulls.<ref name="fourrules"/>  The following simple example demonstrates this fallacy:

<syntaxhighlight lang="SQL">
SELECT *
FROM t
WHERE i = NULL;
</syntaxhighlight>

The example query above logically always returns zero rows because the comparison of the ''i'' column with Null always returns Unknown, even for those rows where ''i'' is Null.  The Unknown result causes the <code>SELECT</code> statement to summarily discard every row. (However, in practice, some SQL tools will retrieve rows using a comparison with Null.)

=== Null-specific and 3VL-specific comparison predicates ===
Basic SQL comparison operators always return Unknown when comparing anything with Null, so the SQL standard provides for two special Null-specific comparison predicates. The <code>IS NULL</code> and <code>IS NOT NULL</code> predicates (which use a [[Reverse Polish notation|postfix]] syntax) test whether data is, or is not, Null.<ref name="SQL2003-Part2-Sec87">
{{cite book
  | last =ISO/IEC
  | title =ISO/IEC 9075-2:2003, "SQL/Foundation"
  | publisher =ISO/IEC
  | year =2003
  | pages =Section 8.7: ''null predicate''
  | no-pp =true
}}</ref>

The SQL standard contains the optional feature F571 "Truth value tests" that introduces three additional logical unary operators (six in fact, if we count their negation, which is part of their syntax), also using postfix notation. They have the following truth tables:<ref>C.J. Date (2004), ''An introduction to database systems'', 8th ed., Pearson Education, p. 594</ref>

{| class="wikitable"
|-
! p !! p IS TRUE !! p IS NOT TRUE !! p IS FALSE !! p IS NOT FALSE !! p IS UNKNOWN || p IS NOT UNKNOWN
|-
| {{yes2|True}} || {{yes2|True}} || {{no2|False}} || {{no2|False}} || {{yes2|True}} || {{no2|False}} || {{yes2|True}}
|-
| {{no2|False}} || {{no2|False}} || {{yes2|True}} || {{yes2|True}} || {{no2|False}} || {{no2|False}} || {{yes2|True}}
|-
| {{Unknown}} || {{no2|False}} || {{yes2|True}} || {{no2|False}} || {{yes2|True}} || {{yes2|True}} || {{no2|False}}
|}

The F571 feature is orthogonal to the presence of the [[#BOOLEAN data type|Boolean datatype]] in SQL (discussed later in this article) and, despite syntactic similarities, F571 does not introduce Boolean or three-valued [[Literal (computer programming)|literals]] in the language. The F571 feature was actually present in [[SQL92]],<ref name="MeltonSimon1993">{{cite book|author1=Jim Melton|author2=Jim Melton Alan R. Simon|title=Understanding The New SQL: A Complete Guide|url=https://books.google.com/books?id=ZOOMSTZ4T_QC&pg=PA145|year=1993|publisher=Morgan Kaufmann|isbn=978-1-55860-245-8|pages=145–147}}</ref> well before the Boolean datatype was introduced to the standard in 1999. The F571 feature is implemented by few systems however; PostgreSQL is one of those implementing it.

The addition of IS UNKNOWN to the other operators of SQL's three-valued logic makes the SQL three-valued logic [[functionally complete]],<ref>C. J. Date, ''Relational database writings, 1991-1994'', Addison-Wesley, 1995, p. 371</ref> meaning its logical operators can express (in combination) any conceivable three-valued logical function.

On systems that don't support the F571 feature, it is possible to emulate IS UNKNOWN ''p'' by going over every argument that could make the expression ''p'' Unknown and test those arguments with IS NULL or other NULL-specific functions, although this may be more cumbersome.

=== Law of the excluded fourth (in WHERE clauses) ===
In SQL's three-valued logic the [[law of excluded middle|law of the excluded middle]], ''p'' OR NOT ''p'', no longer evaluates to true for all ''p''. More precisely, in SQL's three-valued logic ''p'' OR NOT ''p'' is unknown precisely when ''p'' is unknown and true otherwise. Because direct comparisons with Null result in the unknown logical value, the following query

<syntaxhighlight lang="sql">
SELECT * FROM stuff WHERE ( x = 10 ) OR NOT ( x = 10 );
</syntaxhighlight>

is not equivalent in SQL with

<syntaxhighlight lang="sql">
SELECT * FROM stuff;
</syntaxhighlight>

if the column x contains any Nulls; in that case, the second query would return some rows the first one does not return, namely all those in which x is Null. In classical two-valued logic, the law of the excluded middle would allow the simplification of the WHERE clause predicate, in fact its elimination. Attempting to apply the law of the excluded middle to SQL's 3VL is effectively a [[False dilemma|false dichotomy]]. The second query is actually equivalent with:

<syntaxhighlight lang="sql">
SELECT * FROM stuff;
-- is (because of 3VL) equivalent to:
SELECT * FROM stuff WHERE ( x = 10 ) OR NOT ( x = 10 ) OR x IS NULL;
</syntaxhighlight>

Thus, to correctly simplify the first statement in SQL requires that we return all rows in which x is not null.

<syntaxhighlight lang="sql">
SELECT * FROM stuff WHERE x IS NOT NULL;
</syntaxhighlight>

In view of the above, observe that for SQL's WHERE clause a [[Tautology (logic)|tautology]] similar to the law of excluded middle can be written. Assuming the IS UNKNOWN operator is present, ''p'' OR (NOT ''p'') OR (''p'' IS UNKNOWN) is true for every predicate ''p''. Among logicians, this is called [[law of excluded fourth]].

There are some SQL expressions in which it is less obvious where the false dilemma occurs, for example:
<syntaxhighlight lang="sql">
SELECT 'ok' WHERE 1 NOT IN (SELECT CAST (NULL AS INTEGER))
UNION
SELECT 'ok' WHERE 1 IN (SELECT CAST (NULL AS INTEGER));
</syntaxhighlight>
produces no rows because <code>IN</code> translates to an iterated version of equality over the argument set and 1<>NULL is Unknown, just as a 1=NULL is Unknown. (The CAST in this example is needed only in some SQL implementations like PostgreSQL, which would reject it with a type checking error otherwise. In many systems plain SELECT NULL works in the subquery.) The missing case above is of course:

<syntaxhighlight lang="sql">
SELECT 'ok' WHERE (1 IN (SELECT CAST (NULL AS INTEGER))) IS UNKNOWN;
</syntaxhighlight>

=== Effect of Null and Unknown in other constructs ===

====Joins====
Joins evaluate using the same comparison rules as for WHERE clauses. Therefore, care must be taken when using nullable columns in SQL join criteria. In particular a table containing any nulls is ''not equal'' with a natural self-join of itself, meaning that whereas <math>R \bowtie R = R</math> is true for any relation ''R'' in [[relational algebra]], a SQL self-join will exclude all rows having a Null anywhere.<ref>C.J. Date (2004), ''An introduction to database systems'', 8th ed., Pearson Education, p. 584</ref> An example of this behavior is given in the section analyzing the missing-value semantics of Nulls.

The SQL <code>COALESCE</code> function or <code>CASE</code> expressions can be used to "simulate" Null equality in join criteria, and the <code>IS NULL</code> and <code>IS NOT NULL</code> predicates can be used in the join criteria as well. The following predicate tests for equality of the values A and B and treats Nulls as being equal.

<syntaxhighlight lang="sql">
(A = B) OR (A IS NULL AND B IS NULL)
</syntaxhighlight>

====CASE expressions====
SQL provides [[Case (SQL)|two flavours of conditional expressions]]. One is called "simple CASE" and operates like a [[switch statement]]. The other is called a "searched CASE" in the standard, and operates like an [[Conditional (programming)#Else if|if...elseif]].

The simple <code>CASE</code> expressions use implicit equality comparisons which operate under the same rules as the DML <code>WHERE</code> clause rules for Null. Thus, a ''simple <code>CASE</code> expression'' cannot check for the existence of Null directly. A check for Null in a simple <code>CASE</code> expression always results in Unknown, as in the following:

<syntaxhighlight lang="sql">
SELECT CASE i WHEN NULL THEN 'Is Null'  -- This will never be returned
              WHEN    0 THEN 'Is Zero'  -- This will be returned when i = 0
              WHEN    1 THEN 'Is One'   -- This will be returned when i = 1
              END
FROM t;
</syntaxhighlight>

Because the expression <code>i = NULL</code> evaluates to Unknown no matter what value column ''i'' contains (even if it contains Null), the string <code>'Is Null'</code> will never be returned.

On the other hand, a "searched" <code>CASE</code> expression can use predicates like <code>IS NULL</code> and <code>IS NOT NULL</code> in its conditions. The following example shows how to use a searched <code>CASE</code> expression to properly check for Null:

<syntaxhighlight lang="sql">
SELECT CASE WHEN i IS NULL THEN 'Null Result'  -- This will be returned when i is NULL
            WHEN     i = 0 THEN 'Zero'         -- This will be returned when i = 0
            WHEN     i = 1 THEN 'One'          -- This will be returned when i = 1
            END
FROM t;
</syntaxhighlight>

In the searched <code>CASE</code> expression, the string <code>'Null Result'</code> is returned for all rows in which ''i'' is Null.

Oracle's dialect of SQL provides a built-in function <code>DECODE</code> which can be used instead of the simple CASE expressions and considers two nulls equal.

<syntaxhighlight lang="sql">
SELECT DECODE(i, NULL, 'Null Result', 0, 'Zero', 1, 'One') FROM t;
</syntaxhighlight>

Finally, all these constructs return a NULL if no match is found; they have a default <code>ELSE NULL</code> clause.

====IF statements in procedural extensions====
[[SQL/PSM]] (SQL Persistent Stored Modules) defines [[Procedural programming|procedural]] extensions for SQL, such as the <code>[[Conditional (programming)|IF]]</code> statement.  However, the major SQL vendors have historically included their own proprietary procedural extensions. Procedural extensions for looping and comparisons operate under Null comparison rules similar to those for DML statements and queries. The following code fragment, in ISO SQL standard format, demonstrates the use of Null 3VL in an <code>IF</code> statement.

<syntaxhighlight lang="plpgsql">
IF i = NULL THEN
      SELECT 'Result is True'
ELSEIF NOT(i = NULL) THEN
      SELECT 'Result is False'
ELSE
      SELECT 'Result is Unknown';
</syntaxhighlight>

The <code>IF</code> statement performs actions only for those comparisons that evaluate to True.  For statements that evaluate to False or Unknown, the <code>IF</code> statement passes control to the <code>[[Conditional (programming)|ELSEIF]]</code> clause, and finally to the <code>[[Conditional (programming)|ELSE]]</code> clause. The result of the code above will always be the message <code>'Result is Unknown'</code> since the comparisons with Null always evaluate to Unknown.

== {{anchor|missing-value semantics}} Analysis of SQL Null missing-value semantics ==
The groundbreaking work of [[Tomasz Imieliński|T. Imieliński]] and [[Witold Lipski|W. Lipski Jr.]] (1984)<ref name="JACM 1984">{{cite journal|first1 =T. | last1=Imieliński | author-link= Tomasz Imieliński | first2 = W. | last2 = Lipski Jr. | title=Incomplete information in relational databases | journal=[[Journal of the ACM]]|volume=31|issue=4|date= 1984|pages=761–791| doi=10.1145/1634.1886| s2cid=288040 | doi-access=free }}</ref> provided a framework in which to evaluate the intended semantics of various proposals to implement missing-value semantics, that is referred to as [[Imieliński-Lipski Algebras]]. This section roughly follows chapter 19 of the "Alice" textbook.<ref>{{Cite book
|last1=Abiteboul
|first1=Serge
|author-link=Serge Abiteboul
|last2=Hull
|first2=Richard B.
|author2-link=Richard B. Hull
|last3=Vianu
|first3=Victor
|author3-link=Victor Vianu
|title=Foundations of Databases
|publisher=Addison-Wesley
|year=1995
|isbn=978-0-201-53771-0
|url=https://archive.org/details/foundationsofdat0000abit
|url-access=registration
}}</ref> A similar presentation appears in the review of Ron van der Meyden, §10.4.<ref name="Meyden"/>

=== In selections and projections: weak representation ===
Constructs representing missing information, such as Codd tables, are actually intended to represent a set of relations, one for each possible instantiation of their parameters; in the case of Codd tables, this means replacement of Nulls with some concrete value. For example,

{{ image frame | caption=The Codd table ''Emp'' may represent the relation ''EmpH22'' or ''EmpH37'', as pictured.| align=center | innerstyle=display: flex; flex-flow: row wrap; justify-content: space-evenly;
|content={{nothing}}
{{(!}} class="wikitable" style="display: inline-table !important"
 {{!}}+      ''Emp''
 {{!-}}
 ! Name !! Age
 {{!-}}
 {{!}} George {{!!}} 43
 {{!-}}
 {{!}} Harriet {{!!}} {{Null result}}
 {{!-}}
 {{!}} Charles {{!!}} 56
{{!)}}
{{(!}} class="wikitable" style="display: inline-table !important"
 {{!}}+      ''EmpH22''
 {{!-}}
 ! Name !! Age
 {{!-}}
 {{!}} George {{!!}} 43
 {{!-}}
 {{!}} Harriet {{!!}} 22
 {{!-}}
 {{!}} Charles {{!!}} 56
{{!)}}
{{(!}} class="wikitable" style="display: inline-table !important"
 {{!}}+      ''EmpH37''
 {{!-}}
 ! Name !! Age
 {{!-}}
 {{!}} George {{!!}} 43
 {{!-}}
 {{!}} Harriet {{!!}} 37
 {{!-}}
 {{!}} Charles {{!!}} 56
{{!)}}
}}

A construct (such as a Codd table) is said to be a ''strong representation'' system (of missing information) if any answer to a query made on the construct can be particularized to obtain an answer for ''any'' corresponding query on the relations it represents, which are seen as [[Structure (mathematical logic)|models]] of the construct. More precisely, if {{mvar|q}} is a query formula in the [[relational algebra]] (of "pure" relations) and if {{mvar|{{overline|q}}}} is its lifting to a construct intended to represent missing information, a strong representation has the property that for any query ''q'' and (table) construct ''T'', {{mvar|{{overline|q}}}} lifts ''all'' the answers to the construct, i.e.:
: <math>\mathop{\mathrm{Models}}(\bar{q}(T)) = \{ q(R)\,| R \in \mathop{\mathrm{Models}}(T) \}</math>

(The above has to hold for queries taking any number of tables as arguments, but the restriction to one table suffices for this discussion.) Clearly Codd tables do not have this strong property if selections and projections are considered as part of the query language. For example, ''all'' the answers to

<syntaxhighlight lang="sql">
SELECT * FROM Emp WHERE Age = 22;
</syntaxhighlight>

should include the possibility that a relation like EmpH22 may exist. However, Codd tables cannot represent the disjunction "result with possibly 0 or 1 rows". A device, mostly of theoretical interest, called [[conditional table]] (or c-table) can however represent such an answer:

{| class="wikitable"
 |+      ''Result''
 |-
 ! Name !! Age !! condition
 |-
 | Harriet || ω<sub>1</sub> || ω<sub>1</sub> = 22
 |-
|}

where the condition column is interpreted as the row doesn't exist if the condition is false. It turns out that because the formulas in the condition column of a c-table can be arbitrary [[propositional logic]] formulas, an algorithm for the problem whether a c-table represents some concrete relation has a [[co-NP-complete]] complexity, thus is of little practical worth.

A weaker notion of representation is therefore desirable. Imielinski and Lipski introduced the notion of ''weak representation'', which essentially allows (lifted) queries over a construct to return a representation only for ''sure'' information, i.e. if it's valid for all "[[possible world]]" instantiations (models) of the construct. Concretely, a construct is a weak representation system if
: <math> \bigcap\mathop{\mathrm{Models}}(\bar{q}(T)) = \bigcap \{ q(R)\,| R \in \mathop{\mathrm{Models}}(T) \}</math>

The right-hand side of the above equation is the ''sure'' information, i.e. information which can be certainly extracted from the database regardless of what values are used to replace Nulls in the database. In the example we considered above, it's easy to see that the intersection of all possible models (i.e. the sure information) of the query selecting {{code|2=sql|1=WHERE Age = 22}} is actually empty because, for instance, the (unlifted) query returns no rows for the relation EmpH37. More generally, it was shown by Imielinski and Lipski that Codd tables are a weak representation system if the query language is restricted to projections, selections (and renaming of columns). However, as soon as we add either joins or unions to the query language, even this weak property is lost, as evidenced in the next section.

=== If joins or unions are considered: not even weak representation ===
Consider the following query over the same Codd table {{mono|Emp}} from the previous section:

<syntaxhighlight lang="sql">
SELECT Name FROM Emp WHERE Age = 22
UNION
SELECT Name FROM Emp WHERE Age <> 22;
</syntaxhighlight>

Whatever concrete value one would choose for the {{NULL}} age of Harriet, the above query will return the full column of names of any model of {{mono|Emp}}, but when the (lifted) query is run on {{mono|Emp}} itself, Harriet will always be missing, i.e. we have:

{| style="margin: 0 auto;" cellpadding="20"
|- valign="center"
| Query result on {{mono|Emp}}:
||
{| class="wikitable"
 |-
 ! Name
 |-
 | George
 |-
 | Charles
|}
|| Query result on any model of {{mono|Emp}}:
||
{| class="wikitable"
 |-
 ! Name
 |-
 | George
 |-
 | Harriet
 |-
 | Charles
|}
|}

Thus when unions are added to the query language, Codd tables are not even a weak representation system of missing information, meaning that queries over them don't even report all ''sure'' information. It's important to note here that semantics of UNION on Nulls, which are discussed in a later section, did not even come into play in this query. The "forgetful" nature of the two sub-queries was all that it took to guarantee that some sure information went unreported when the above query was run on the Codd table Emp.

For [[natural join]]s, the example needed to show that sure information may be unreported by some query is slightly more complicated. Consider the table

{| class="wikitable"
 |+      ''J''
 |-
 ! F1 !! F2 !! F3
 |-
 | 11 || {{Null result}} || 13
 |-
 | 21 || {{Null result}} || 23
 |-
 | 31 || 32 || 33
|}

and the query

<syntaxhighlight lang="sql">
SELECT F1, F3 FROM
     (SELECT F1, F2 FROM J) AS F12
     NATURAL JOIN
     (SELECT F2, F3 FROM J) AS F23;
</syntaxhighlight>

{| style="margin: 0 auto;" cellpadding="20"
|- valign="center"
| Query result on J:
||
{| class="wikitable"
 |-
 ! F1 !! F3
 |-
 | 31 || 33
|}
|| Query result on any model of J:
||
{| class="wikitable"
 |-
 ! F1 !! F3
 |-
 | 11 || 13
 |-
 | 21 || 23
 |-
 | 31 || 33
|}
|}

The intuition for what happens above is that the Codd tables representing the projections in the subqueries lose track of the fact that the Nulls in the columns F12.F2 and F23.F2 are actually copies of the originals in the table J. This observation suggests that a relatively simple improvement of Codd tables (which works correctly for this example) would be to use ''Skolem constants'' (meaning [[Skolem function]]s which are also [[constant function]]s), say ω<sub>12</sub> and ω<sub>22</sub> instead of a single NULL symbol. Such an approach, called v-tables or Naive tables, is computationally less expensive that the c-tables discussed above. However, it is still not a complete solution for incomplete information in the sense that v-tables are only a weak representation for queries not using any negations in selection (and not using any set difference either). The first example considered in this section is using a negative selection clause, {{code|WHERE Age <> 22|sql}}, so it is also an example where v-tables queries would not report sure information.

==Check constraints and foreign keys==
The primary place in which SQL three-valued logic intersects with SQL [[Data Definition Language]] (DDL) is in the form of [[check constraint]]s. A check constraint placed on a column operates under a slightly different set of rules than those for the DML <code>WHERE</code> clause. While a DML <code>WHERE</code> clause must evaluate to True for a row, a check constraint must not evaluate to False. (From a logic perspective, the [[designated value]]s are True and Unknown.) This means that a check constraint will succeed if the result of the check is either True or Unknown.  The following example table with a check constraint will prohibit any integer values from being inserted into column ''i'', but will allow Null to be inserted since the result of the check will always evaluate to Unknown for Nulls.<ref name="nullversusnull">{{cite journal | last = Coles, Michael | title = Null Versus Null? | journal = SQL Server Central | publisher = Red Gate Software |date=February 26, 2007 | url = http://www.sqlservercentral.com/columnists/mcoles/2829.asp}}</ref>

<syntaxhighlight lang="sql">
CREATE TABLE t (
     i INTEGER,
     CONSTRAINT ck_i CHECK ( i < 0 AND i = 0 AND i > 0 ) );
</syntaxhighlight>

Because of the change in designated values relative to the {{mono|WHERE}} clause, from a logic perspective the law of excluded middle is a tautology for {{mono|CHECK}} constraints, meaning <code>CHECK (''p'' OR NOT ''p'')</code> always succeeds. Furthermore, assuming Nulls are to be interpreted as existing but unknown values, some pathological CHECKs like the one above allow insertion of Nulls that could never be replaced by any non-null value.

In order to constrain a column to reject Nulls, the <code>NOT NULL</code> constraint can be applied, as shown in the example below. The <code>NOT NULL</code> constraint is semantically equivalent to a [[check constraint]] with an <code>IS NOT NULL</code> predicate.

<syntaxhighlight lang="sql">
CREATE TABLE t ( i INTEGER NOT NULL );
</syntaxhighlight>

By default check constraints against [[foreign key]]s succeed if any of the fields in such keys are Null. For example, the table

<syntaxhighlight lang="sql">
CREATE TABLE Books
( title VARCHAR(100),
  author_last VARCHAR(20),
  author_first VARCHAR(20),
FOREIGN KEY (author_last, author_first)
  REFERENCES Authors(last_name, first_name));
</syntaxhighlight>

would allow insertion of rows where author_last or author_first are {{NULL}} irrespective of how the table Authors is defined or what it contains. More precisely, a null in any of these fields would allow any value in the other one, even on that is not found in Authors table. For example, if Authors contained only {{code|('Doe', 'John')}}, then {{code|('Smith', NULL)}} would satisfy the foreign key constraint. [[SQL-92]] added two extra options for narrowing down the matches in such cases. If <code>MATCH PARTIAL</code> is added after the <code>REFERENCES</code> declaration then any non-null must match the foreign key, e.g. {{code|('Doe', NULL)}} would still match, but {{code|('Smith', NULL)}} would not. Finally, if <code>MATCH FULL</code> is added then {{code|('Doe', NULL)}} would not match the constraint either, but {{code|(NULL, NULL)}} would still match it.

==Outer joins==
[[File:Sql query1.png|270px|thumb|right|Example [[SQL]] [[Join (SQL)|outer join]] query with Null placeholders in the result set.  The Null markers are represented by the word <code>NULL</code> in place of data in the results.  Results are from [[Microsoft SQL Server]], as shown in SQL Server Management Studio.]]<!-- FAIR USE of Sql query1.png: see image description page at http://en.wikipedia.org/wiki/Image:Sql query1.png for rationale -->
SQL [[Join (SQL)|outer joins]], including left outer joins, right outer joins, and full outer joins, automatically produce Nulls as placeholders for missing values in related tables.  For left outer joins, for instance, Nulls are produced in place of rows missing from the table appearing on the right-hand side of the <code>LEFT OUTER JOIN</code> operator.  The following simple example uses two tables to demonstrate Null placeholder production in a left outer join.

The first table ('''Employee''') contains employee ID numbers and names, while the second table ('''PhoneNumber''') contains related employee ID numbers and [[Telephone number|phone numbers]], as shown below.

{|
| valign="top" |
{| class="wikitable"
|-
|+ Employee
|-
! ID
! LastName
! FirstName
|-
| 1
| Johnson
| Joe
|-
| 2
| Lewis
| Larry
|-
| 3
| Thompson
| Thomas
|-
| 4
| Patterson
| Patricia
|-
|}
| valign="top" |
{| class="wikitable"
|-
|+ PhoneNumber
|-
! ID
! Number
|-
| 1
| 555-2323
|-
| 3
| 555-9876
|-
|}
|}

The following sample SQL query performs a left outer join on these two tables.

<syntaxhighlight lang="sql">
SELECT e.ID, e.LastName, e.FirstName, pn.Number
FROM Employee e
LEFT OUTER JOIN PhoneNumber pn
ON e.ID = pn.ID;
</syntaxhighlight>

The [[result set]] generated by this query demonstrates how SQL uses Null as a placeholder for values missing from the right-hand ('''PhoneNumber''') table, as shown below.

{| class="wikitable"
|-
|+ Query result
|-
! ID
! LastName
! FirstName
! Number
|-
| 1
| Johnson
| Joe
| 555-2323
|-
| 2
| Lewis
| Larry
|  {{Null result}}
|-
| 3
| Thompson
| Thomas
| 555-9876
|-
| 4
| Patterson
| Patricia
|  {{Null result}}
|-
|}

==Aggregate functions==
SQL defines [[aggregate function]]s to simplify server-side aggregate calculations on data. Except for the <code>COUNT(*)</code> function, all aggregate functions perform a Null-elimination step, so that Nulls are not included in the final result of the calculation.<ref name="SQL2003-Part2-Sec4154">
{{cite book
  | last =ISO/IEC
  | title =ISO/IEC 9075-2:2003, "SQL/Foundation"
  | publisher =ISO/IEC
  | year =2003
  | pages =Section 4.15.4: ''Aggregate functions''
  | no-pp =true
}}</ref>

Note that the elimination of Null is not equivalent to replacing Null with zero. For example, in the following table, <code>AVG(i)</code> (the average of the values of <code>i</code>) will give a different result from that of <code>AVG(j)</code>:

{| class="wikitable" style="font-family:monospace"
|-
! i
! j
|-
| 150
| 150
|-
| 200
| 200
|-
| 250
| 250
|-
| {{Null result}}
| 0
|}

Here <code>AVG(i)</code> is 200 (the average of 150, 200, and 250), while <code>AVG(j)</code> is 150 (the average of 150, 200, 250, and 0).  A well-known side effect of this is that in SQL, <code>AVG(z)</code> is not equivalent with <code>SUM(z)/COUNT(*)</code> but with <code>SUM(z)/COUNT(z)</code>.<ref name="Chamberlin1998"/>

The output of an aggregate function can also be Null. Here is an example:

<syntaxhighlight lang="sql">
SELECT COUNT(*), MIN(e.Wage), MAX(e.Wage)
FROM Employee e
WHERE e.LastName LIKE '%Jones%';
</syntaxhighlight>

This query will always output exactly one row, counting the number of employees whose last name contains "Jones", and giving the minimum and maximum wage found for those employees. However, what happens if none of the employees fit the given criteria? Calculating the minimum or maximum value of an empty set is impossible, so those results must be NULL, indicating there is no answer. This is not an Unknown value, it is a Null representing the absence of a value. The result would be:

{| class="wikitable" style="font-family:monospace"
! COUNT(*)
! MIN(e.Wage)
! MAX(e.Wage)
|-
| 0
| {{Null result}}
| {{Null result}}
|}

==When two nulls are equal: grouping, sorting, and some set operations==
Because [[SQL:2003]] defines all Null markers as being unequal to one another, a special definition was required in order to group Nulls together when performing certain operations.  SQL defines "any two values that are equal to one another, or any two Nulls", as "not distinct".<ref name="SQL2003-Part2-Sec3168">{{cite book
  | last =ISO/IEC
  | title =ISO/IEC 9075-2:2003, "SQL/Foundation"
  | publisher =ISO/IEC
  | year =2003
  | pages =Section 3.1.6.8: ''Definitions: distinct''
  | no-pp =true
}}</ref>  This definition of ''not distinct'' allows SQL to group and sort Nulls when the <code>GROUP BY</code> clause (or another SQL language feature that performs grouping) is used.

Other SQL operations, clauses, and keywords using the "not distinct" definition in their treatment of Nulls include:

* The <code>PARTITION BY</code> clause of the ranking and windowing functions such as <code>ROW_NUMBER</code>
* The <code>UNION</code>, <code>INTERSECT</code>, and <code>EXCEPT</code> operators, which treat NULLs as the same for row comparison/elimination purposes
* The <code>DISTINCT</code> keyword used in <code>SELECT</code> queries

The principle that Nulls are not equal to each other (but rather that the result is Unknown) is effectively violated in the SQL specification for the <code>UNION</code> operator, which does identify nulls with each other.<ref name="Meyden"/> Consequently, some set operations in SQL, such as union and difference, may produce results not representing sure information, unlike operations involving explicit comparisons with NULL (e.g. those in a <code>WHERE</code> clause discussed above). In Codd's 1979 proposal (which was adopted by SQL92) this semantic inconsistency is rationalized by arguing that removal of duplicates in set operations happens "at a lower level of detail than equality testing in the evaluation of retrieval operations."<ref name="Klein"/>

The SQL standard does not explicitly define a default sorting order for Nulls.  Instead, on conforming systems, Nulls can be sorted before or after all data values by using the <code>NULLS FIRST</code> or <code>NULLS LAST</code> clauses of the <code>ORDER BY</code> list, respectively. Not all DBMS vendors implement this functionality, however.  Vendors who do not implement this functionality may specify different treatments for Null sorting in the DBMS.<ref name="nullversusnull"/>

==Effect on index operation==
Some SQL products do not index keys containing NULLs. For instance, [[PostgreSQL]]  versions prior to 8.3 did not, with the documentation for a [[B-tree]] index stating that<ref>{{cite web| url=http://www.postgresql.org/docs/8.0/interactive/indexes-types.html| title=PostgreSQL 8.0.14 Documentation: Index Types |publisher=PostgreSQL |access-date= 6 November 2008}}</ref>
{{quote|
B-trees can handle equality and range queries on data that can be sorted into some ordering. In particular, the PostgreSQL query planner will consider using a B-tree index whenever an indexed column is involved in a comparison using one of these operators: < ≤ {{=}} ≥ >

Constructs equivalent to combinations of these operators, such as BETWEEN and IN, can also be implemented with a B-tree index search. (But note that IS NULL is not equivalent to {{=}} and is not indexable.)
}}

In cases where the index enforces uniqueness, NULLs are excluded from the index and uniqueness is not enforced between NULLs. Again, quoting from the [[PostgreSQL]] documentation:<ref>{{cite web| url=http://www.postgresql.org/docs/8.0/interactive/indexes-unique.html| title=PostgreSQL 8.0.14 Documentation: Unique Indexes |publisher=PostgreSQL |access-date=November 6, 2008}}</ref>
{{quote|
When an index is declared unique, multiple table rows with equal indexed values will not be allowed. Nulls are not considered equal. A multicolumn unique index will only reject cases where all of the indexed columns are equal in two rows.
}}

This is consistent with the [[SQL:2003]]-defined behavior of scalar Null comparisons.

Another method of indexing Nulls involves handling them as ''not distinct'' in accordance with the SQL:2003-defined behavior. For example, [[Microsoft SQL Server]] documentation states the following:<ref>{{cite web| url=http://msdn2.microsoft.com/en-us/library/ms175132.aspx| title=Creating Unique Indexes|date=September 2007 |publisher=PostfreSQL |access-date=November 6, 2008}}</ref>
{{quote|
For indexing purposes, NULLs compare as equal. Therefore, a unique index, or UNIQUE constraint, cannot be created if the keys are NULL in more than one row. Select columns that are defined as NOT NULL when columns for a unique index or unique constraint are chosen.
}}

Both of these indexing strategies are consistent with the SQL:2003-defined behavior of Nulls. Because indexing methodologies are not explicitly defined by the SQL:2003 standard, indexing strategies for Nulls are left entirely to the vendors to design and implement.

==Null-handling functions==
SQL defines two functions to explicitly handle Nulls: <code>NULLIF</code> and <code>COALESCE</code>. Both functions are abbreviations for [[Case (SQL)|searched <code>CASE</code> expressions]].<ref name="SQL2003-Part2-Sec611">
{{cite book
  | last =ISO/IEC
  | title =ISO/IEC 9075-2:2003, "SQL/Foundation"
  | publisher =ISO/IEC
  | year =2003
  | pages =Section 6.11: ''case expression''
  | no-pp =true
}}</ref>

=== NULLIF ===
The <code>NULLIF</code> function accepts two parameters.  If the first parameter is equal to the second parameter, <code>NULLIF</code> returns Null.  Otherwise, the value of the first parameter is returned.

<syntaxhighlight lang="sql">
NULLIF(value1, value2)
</syntaxhighlight>

Thus, <code>NULLIF</code> is an abbreviation for the following <code>CASE</code> expression:

<syntaxhighlight lang="sql">
CASE WHEN value1 = value2 THEN NULL ELSE value1 END
</syntaxhighlight>

=== COALESCE ===
The <code>COALESCE</code> function accepts a list of parameters, returning the first non-Null value from the list:

<syntaxhighlight lang="sql">
COALESCE(value1, value2, value3, ...)
</syntaxhighlight>

<code>COALESCE</code> is defined as shorthand for the following SQL <code>CASE</code> expression:

<syntaxhighlight lang="sql">
CASE WHEN value1 IS NOT NULL THEN value1
     WHEN value2 IS NOT NULL THEN value2
     WHEN value3 IS NOT NULL THEN value3
     ...
     END
</syntaxhighlight>

Some SQL DBMSs implement vendor-specific functions similar to <code>COALESCE</code>.  Some systems (e.g. [[Transact-SQL]]) implement an <code>ISNULL</code> function, or other similar functions that are functionally similar to <code>COALESCE</code>.  (See [[Is functions|<code>Is</code> functions]] for more on the <code>IS</code> functions in Transact-SQL.)

=== NVL ===
{{Redirect|NVL}}
The Oracle <code>NVL</code> function accepts two parameters.  It returns the first non-NULL parameter or NULL if all parameters are NULL.

A <code>COALESCE</code> expression can be converted into an equivalent <code>NVL</code> expression thus:
<syntaxhighlight lang="mysql">
COALESCE ( val1, ... , val{n} )
</syntaxhighlight>

turns into:

<syntaxhighlight lang="mysql">
NVL( val1 , NVL( val2 , NVL( val3 , … , NVL ( val{n-1} , val{n} ) … )))
</syntaxhighlight>

A use case of this function is to replace in an expression a NULL by a value like in  <code>NVL(SALARY, 0)</code> which says, 'if <code>SALARY</code> is NULL, replace it with the value 0'.

There is, however, one notable exception. In most implementations, <code>COALESCE</code> evaluates its parameters until it reaches the first non-NULL one, while <code>NVL</code> evaluates all of its parameters. This is important for several reasons. A parameter ''after'' the first non-NULL parameter could be a function, which could either be computationally expensive, invalid, or could create unexpected side effects.

== Data typing of Null and Unknown ==
{{See also|Option type|Nullable type}}
The <code>NULL</code> [[Literal (computer programming)|literal]] is untyped in SQL, meaning that it is not designated as an integer, character, or any other specific [[data type]].<ref name="Understanding1999">{{cite book|author1=Jim Melton|author-link=Jim Melton|author2=Alan R. Simon|title=SQL:1999: Understanding Relational Language Components|year=2002|publisher=Morgan Kaufmann|isbn=978-1-55860-456-8|page=[https://archive.org/details/sql1999understan0000melt/page/53 53]|url=https://archive.org/details/sql1999understan0000melt/page/53}}</ref> Because of this, it is sometimes mandatory (or desirable) to explicitly convert Nulls to a specific data type. For instance, if [[Function overloading|overloaded]] functions are supported by the RDBMS, SQL might not be able to automatically resolve to the correct function without knowing the data types of all parameters, including those for which Null is passed.

Conversion from the <code>NULL</code> literal to a Null of a specific type is possible using the <code>CAST</code> introduced in [[SQL-92]]. For example:

<syntaxhighlight lang="sql">
CAST (NULL AS INTEGER)
</syntaxhighlight>

represents an absent value of type INTEGER.

The actual typing of Unknown (distinct or not from NULL itself) varies between SQL implementations. For example, the following

<syntaxhighlight lang="sql">
SELECT 'ok' WHERE (NULL <> 1) IS NULL;
</syntaxhighlight>

parses and executes successfully in some environments (e.g. [[SQLite]] or [[PostgreSQL]]) which unify a NULL Boolean with Unknown but fails to parse in others (e.g. in [[SQL Server Compact]]). [[MySQL]] behaves similarly to [[PostgreSQL]] in this regard (with the minor exception that [[MySQL]] regards TRUE and FALSE as no different from the ordinary integers 1 and 0). PostgreSQL additionally implements a <code>IS UNKNOWN</code> predicate, which can be used to test whether a three-value logical outcome is Unknown, although this is merely syntactic sugar.

== BOOLEAN data type ==
The ISO [[SQL:1999]] standard introduced the BOOLEAN data type to SQL, however it's still just an optional, non-core feature, coded T031.<ref name="ISO-9075-1">{{cite web |title=ISO/IEC 9075-1:1999 SQL Standard |year=1999 |publisher=ISO}}</ref>

When restricted by a <code>NOT NULL</code> constraint, the SQL BOOLEAN works like the [[Boolean type]] from other languages. Unrestricted however, the BOOLEAN datatype, despite its name, can hold the truth values TRUE, FALSE, and UNKNOWN, all of which are defined as Boolean literals according to the standard. The standard also asserts that NULL and UNKNOWN "may be used
interchangeably to mean exactly the same thing".<ref name="Date2011">{{cite book|author=C. Date|title=SQL and Relational Theory: How to Write Accurate SQL Code|url=https://books.google.com/books?id=Ew06OZtjuJEC&pg=PA83|year=2011|publisher=O'Reilly Media, Inc.|isbn=978-1-4493-1640-2|page=83}}</ref><ref>ISO/IEC 9075-2:2011 §4.5</ref>

The Boolean type has been subject of criticism, particularly because of the mandated behavior of the UNKNOWN literal, which is never equal to itself because of the identification with NULL.<ref name="Prigmore2007">{{cite book|author=Martyn Prigmore|title=Introduction to Databases With Web Applications|url=https://books.google.com/books?id=PKggKqIZnN0C&pg=PA197|year=2007|publisher=Pearson Education Canada|isbn=978-0-321-26359-9|page=197}}</ref>

As discussed above, in the [[PostgreSQL]] implementation of [[SQL]], Null is used to represent all UNKNOWN results, including the UNKNOWN BOOLEAN. PostgreSQL does not implement the UNKNOWN literal (although it does implement the IS UNKNOWN operator, which is an orthogonal feature.) Most other major vendors do not support the Boolean type (as defined in T031) as of 2012.<ref>Troels Arvin, [http://troels.arvin.dk/db/rdbms/#data_types-boolean Survey of BOOLEAN data type implementation]</ref> The procedural part of Oracle's [[PL/SQL]] however supports BOOLEAN variables; these can also be assigned NULL and the value is considered the same as UNKNOWN.<ref name="FeuersteinPribyl2009">{{cite book|author1=Steven Feuerstein|author2=Bill Pribyl|title=Oracle PL/SQL Programming|year=2009|publisher=O'Reilly Media, Inc.|isbn=978-0-596-51446-4|pages=74, 91}}</ref>

==Controversy==
===Common mistakes===
Misunderstanding of how Null works is the cause of a great number of errors in SQL code, both in ISO standard SQL statements and in the specific SQL dialects supported by real-world database management systems. These mistakes are usually the result of confusion between Null and either 0 (zero) or an empty string (a string value with a length of zero, represented in SQL as <code><nowiki>''</nowiki></code>).  Null is defined by the SQL standard as different from both an empty string and the numerical value <code>0</code>, however. While Null indicates the absence of any value, the empty string and numerical zero both represent actual values.

A classic error is the attempt to use the equals operator <code>=</code> in combination with the keyword <code>NULL</code> to find rows with Nulls. According to the SQL standard this is an invalid syntax and shall lead to an error message or an exception. But most implementations accept the syntax and evaluate such expressions to <code>UNKNOWN</code>. The consequence is that no rows are found{{snd}} regardless of whether rows with Nulls exist or not. The proposed way to retrieve rows with Nulls is the use of the predicate <code>IS NULL</code> instead of <code>= NULL</code>.

<syntaxhighlight lang="sql">
SELECT *
FROM sometable
WHERE num = NULL;  -- Should be "WHERE num IS NULL"
</syntaxhighlight>

In a related, but more subtle example, a <code>WHERE</code> clause or conditional statement might compare a column's value with a constant.  It is often incorrectly assumed that a missing value would be "less than" or "not equal to" a constant if that field contains Null, but, in fact, such expressions return Unknown. An example is below:

<syntaxhighlight lang="sql">
SELECT *
FROM sometable
WHERE num <> 1;  -- Rows where num is NULL will not be returned,
                 -- contrary to many users' expectations.
</syntaxhighlight>

These confusions arise because the [[Law of Identity]] is restricted in SQL's logic. When dealing with equality comparisons using the <code>NULL</code> literal or the <code>UNKNOWN</code> truth-value, SQL will always return <code>UNKNOWN</code> as the result of the expression. This is a [[partial equivalence relation]] and makes SQL an example of a ''Non-Reflexive logic''.<ref>{{citation|title=Classical Logic or Non-Reflexive Logic? A case of Semantic Underdetermination|journal=Revista Portuguesa de Filosofia|volume=68|issue=1/2|last=Arenhart, Krause|year=2012|pages=73–86|jstor=41955624|doi=10.17990/RPF/2012_68_1_0073}}.</ref>

Similarly, Nulls are often confused with empty strings.  Consider the <code>LENGTH</code> function, which returns the number of characters in a string.  When a Null is passed into this function, the function returns Null.  This can lead to unexpected results, if users are not well versed in 3-value logic. An example is below:

<syntaxhighlight lang="sql">
SELECT *
FROM sometable
WHERE LENGTH(string) < 20; -- Rows where string is NULL will not be returned.
</syntaxhighlight>

This is complicated by the fact that in some database interface programs (or even database implementations like Oracle's), NULL is reported as an empty string, and empty strings may be incorrectly stored as NULL.

===Criticisms===
The ISO SQL implementation of Null is the subject of criticism, debate and calls for change.  In ''The Relational Model for Database Management: Version 2'', Codd suggested that the SQL implementation of Null was flawed and should be replaced by two distinct Null-type markers.  The markers he proposed were to stand for ''"Missing but Applicable"'' and ''"Missing but Inapplicable"'', known as ''A-values'' and ''I-values'', respectively.  Codd's recommendation, if accepted, would have required the implementation of a four-valued logic in SQL.<ref name="isbn0201141922">{{cite book|last=Codd|first=E.F.|year=1990|title=The Relational Model for Database Management|edition=Version 2|publisher=[[Pearson PLC|Addison Wesley Publishing Company]]|isbn=978-0-201-14192-4}}</ref>  Others have suggested adding additional Null-type markers to Codd's recommendation to indicate even more reasons that a data value might be "Missing", increasing the complexity of SQL's logic system.  At various times, proposals have also been put forth to implement multiple user-defined Null markers in SQL.  Because of the complexity of the Null-handling and logic systems required to support multiple Null markers, none of these proposals have gained widespread acceptance.

[[Chris Date]] and [[Hugh Darwen]], authors of ''The Third Manifesto'', have suggested that the SQL Null implementation is inherently flawed and should be eliminated altogether,<ref name="3rdmanifesto">
{{cite web
  | last =Darwen
  | first =Hugh
  |author2=Chris Date
   | title =The Third Manifesto
  | url =http://www.thethirdmanifesto.com/
  | access-date = May 29, 2007
}}</ref> pointing to inconsistencies and flaws in the implementation of SQL Null-handling (particularly in aggregate functions) as proof that the entire concept of Null is flawed and should be removed from the relational model.<ref name="askew-wall">
{{cite web
  | last =Darwen
  | first =Hugh
  | title =The Askew Wall
  | url =http://www.dcs.warwick.ac.uk/~hugh/TTM/TTM-TheAskewWall-printable.pdf
  | access-date = May 29, 2007
}}</ref> Others, like author [[Fabian Pascal]], have stated a belief that "how the function calculation should treat missing values is not governed by the relational model."{{citation needed|date=November 2012}}

===Closed-world assumption===
Another point of conflict concerning Nulls is that they violate the [[closed-world assumption]] model of relational databases by introducing an [[open-world assumption]] into it.<ref name="isbn0596100124">{{cite book
  | last =Date
  | first =Chris
  | title =Database in Depth: Relational Theory for Practitioners
  | publisher =O'Reilly Media, Inc.
  |date=May 2005
  | isbn = 978-0-596-10012-4
  | page = 73
}}</ref>  The closed world assumption, as it pertains to databases, states that "Everything stated by the database, either explicitly or implicitly, is true; everything else is false."<ref name="cwa">{{cite web
  | last =Date
  | first =Chris
  | title =Abstract: The Closed World Assumption
  | publisher =[[Data Management Association]], San Francisco Bay Area Chapter
  | url =http://www.sfdama.org/ChrisDate_20070110.htm
  | access-date = May 29, 2007
  | archive-url = https://web.archive.org/web/20070519134146/http://www.sfdama.org/ChrisDate_20070110.htm
  | archive-date = 2007-05-19
}}</ref>  This view assumes that the knowledge of the world stored within a database is complete.  Nulls, however, operate under the open world assumption, in which some items stored in the database are considered unknown, making the database's stored knowledge of the world incomplete.

==See also==
{{portal|Computer programming}}
* [[SQL]]
* [[b:Structured Query Language/NULLs and the Three Valued Logic|NULLs in: Wikibook SQL]]
* [[Three-valued logic]]
* [[Data manipulation language]]
* [[Codd's 12 rules]]
* [[Check constraint]]
* [[Relational Model/Tasmania]]
* [[RDBMS|Relational database management system]]
* [[Join (SQL)]]

==References==
{{Reflist|45em}}

==Further reading==
* E. F. Codd. Understanding relations (installment #7). FDT Bulletin of ACM-SIGMOD, 7(3-4):23–28, 1975.
* {{Cite journal | last1 = Codd | first1 = E. F. | title = Extending the database relational model to capture more meaning | doi = 10.1145/320107.320109 | journal = ACM Transactions on Database Systems | volume = 4 | issue = 4 | pages = 397–434 | year = 1979 | citeseerx = 10.1.1.508.5701 | s2cid = 17517212 }} Especially §2.3.
* {{cite book|author-link=C.J. Date|last=Date|first=C.J.|year=2000|title=The Database Relational Model: A Retrospective Review and Analysis: A Historical Account and Assessment of E. F. Codd's Contribution to the Field of Database Technology|publisher=[[Pearson PLC|Addison Wesley Longman]]|isbn=978-0-201-61294-3|url=https://archive.org/details/databaserelation00date}}
* {{cite journal | last1 = Klein | first1 = Hans-Joachim | year = 1994 | title = How to modify SQL queries in order to guarantee sure answers | journal = ACM SIGMOD Record | volume = 23 | issue = 3| pages = 14–20 | doi=10.1145/187436.187445| s2cid = 17354724 | doi-access = free }}
* Claude Rubinson, [http://www.u.arizona.edu/~rubinson/scrawl/Rubinson.2007.Nulls_Three-Valued_Logic_and_Ambiguity_in_SQL.pdf Nulls, Three-Valued Logic, and Ambiguity in SQL: Critiquing Date's Critique] {{Webarchive|url=https://web.archive.org/web/20160305071445/http://www.u.arizona.edu/~rubinson/scrawl/Rubinson.2007.Nulls_Three-Valued_Logic_and_Ambiguity_in_SQL.pdf |date=2016-03-05 }}, SIGMOD Record, December 2007 (Vol. 36, No. 4)
* John Grant, [http://www09.sigmod.org/sigmod/record/issues/0809/p23.grant.pdf Null Values in SQL]. SIGMOD Record, September 2008 (Vol. 37, No. 3)
* Waraporn, Narongrit, and Kriengkrai Porkaew. "[http://www.iaeng.org/IJCS/issues_v35/issue_3/IJCS_35_3_08.pdf Null semantics for subqueries and atomic predicates]". [[IAENG]] International Journal of Computer Science 35.3 (2008): 305-313.
* {{cite journal|author=Bernhard Thalheim |author2=Klaus-Dieter Schewe |title=NULL 'Value' Algebras and Logics|journal=Frontiers in Artificial Intelligence and Applications|volume=225|issue=Information Modelling and Knowledge Bases XXII|url=https://zenodo.org/record/1038419|doi=10.3233/978-1-60750-690-4-354|year=2011}}
* Enrico Franconi and Sergio Tessaris, [http://ceur-ws.org/Vol-866/paper8.pdf On the Logic of SQL Nulls],  Proceedings of the 6th Alberto Mendelzon International Workshop on Foundations of Data Management, Ouro Preto, Brazil, June 27–30, 2012. pp.&nbsp;114–128

==External links==
*[http://www.psoug.org/reference/null.html Oracle NULLs] {{Webarchive|url=https://web.archive.org/web/20130412031441/http://psoug.org/reference/null.html |date=2013-04-12 }}
*[http://www.thethirdmanifesto.com/ The Third Manifesto]
*[https://web.archive.org/web/20130405060544/http://www.sqlexpert.co.uk/2006/05/treatment-of-nulls-by-oracle-sql.html Implications of NULLs in sequencing of data]
*[https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4032732 Java bug report about jdbc not distinguishing null and empty string, which Sun closed as "not a bug"]

{{SQL}}
{{nulls}}

{{DEFAULTSORT:Null (Sql)}}
[[Category:SQL keywords]]
[[Category:Articles with example SQL code]]
[[Category:Unknown content]]