Null(SQL)

그리스 소문자 오메가(Ω) 문자는 데이터베이스 이론에서 Null을 나타내기 위해 사용된다.

NULL 또는 NULL은 구조화된 질의 언어에서 데이터 값이 데이터베이스에 존재하지 않음을 나타내기 위해 사용되는 특수 마커다.관계형 데이터베이스 모델 E. F. Codd의 작성자에 의해 도입된 SQL Null은 모든 진정한 관계형 데이터베이스 관리 시스템(RDMS)이 "누락된 정보와 적용 불가능한 정보"의 표현을 지원해야 하는 요건을 충족시키는 역할을 한다.Codd는 또한 데이터베이스 이론에서 Null을 나타내기 위해 소문자 그리스 오메가(Ω) 기호를 사용했다고 소개했다.SQL에서는NULL이 마커를 식별하는 데 사용되는 예약된 단어 입니다.

Null은 0의값과혼동해서는 안 된다. null값은 0의값과 같지부족을 나타낸다 값의 않은.예를 들어, "아담은 몇 권의 책을 가지고 있는가?"라는 질문을 생각해 보자.정답은 "0"(우리는 그가 소유하지 않는다는 것을 알고 있다) 또는 "null"(우리는 그가 얼마나 많이 소유하고 있는지 모른다)일 수 있다.데이터베이스 테이블에서 이 대답을 보고하는 열은 아무런 값도 없이 시작되며(Null로 표시됨) 아담의 책이 없음을 확인할 때까지 "0" 값으로 업데이트되지 않을 것이다.

SQL null은 값이 아닌 상태임.이 사용법은 대부분의 프로그래밍 언어와 상당히 다르며, 여기서 참조의 null 값은 어떤 객체도 가리키지 않는다는 것을 의미한다.

역사

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 ACM-SIGMOD. Codd's paper that is most commonly cited in relation 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 M오델/타스마니아, 비록 후자 신문의 다른 제안들 중 많은 것들이 불명확하게 남아 있기는 하지만.1979년 논문 제2.3절에는 산술 연산에서 Null 전파의 의미론뿐만 아니라 null과 비교할 때 3차(3-값) 논리를 채택한 비교도 상세하게 기술되어 있다. 또한 다른 세트 연산에 대한 Null의 처리도 상세하게 기술되어 있다(후자 문제는 오늘날에도 여전히 논란이 되고 있다).데이터베이스 이론학계에서 Codd(1975, 1979년)의 원래 제안은 이제 "Codd tables"^[1]로 언급된다.Codd는 이후 1985년 ComputerWorld 잡지에 실린 2부 기사에서 모든 RDBMS가 결측 데이터를 표시하기 위해 Null을 지원해야 한다는 그의 요구사항을 강화했다.^[2][3]

1986년 SQL 표준은 기본적으로 IBM System R의 구현 프로토타입 이후에 Codd의 제안을 채택했다.돈 체임벌린은 SQL의 가장 논란이 많은 특징 중 하나로 nulls(중복 행과 함께)를 인식했지만, 누락된 정보에 대한 시스템 지원의 가장 비용이 적게 드는 형태라는 실용적 주장을 불러일으키면서 SQL의 Nulls 설계를 옹호함으로써 프로그래머를 많은 중복 애플리케이션 수준 점검으로부터 구했다(semip 참조).문제 수정) 동시에 데이터베이스 설계자가 원하는 경우 Null을 사용하지 않을 수 있는 선택사항을 데이터베이스 설계자에게 제공(예를 들어, 잘 알려진 이상 징후를 피하기 위해(이 기사의 의미론 섹션에서 설명됨)체임벌린은 또한 일부 누락된 가치 기능성을 제공하는 것 외에도, Nulls에 대한 실제 경험은 특정 그룹 구성이나 외부 조인과 같이 Nulls에 의존하는 다른 언어 특징으로 이어진다고 주장했다.마지막으로, 그는 실제로 Nulls는 또한 기존 스키마가 원래 취지를 벗어나 진화할 필요가 있을 때 기존 스키마를 패치하는 빠른 방법으로 사용됨으로써, 예를 들어, 누락된 것이 아니라 적용 불가능한 정보, 즉 갤런당 마일리지 칼럼을 가지고 있는 동안 전기 자동차를 신속하게 지원해야 하는 데이터베이스로 코딩하게 된다고 주장했다.^[4]

Codd는 1990년 저서 The Relational Model for Database Management 버전 2에서 SQL 표준이 요구하는 단일 Null이 부적절했으며, 데이터가 누락된 이유를 나타내기 위해 두 개의 별도의 Null 유형 마커로 교체해야 한다고 지적했다.Codd의 저서에서 이 두 개의 Null-type 마커는 'A-Values'와 'I-Values'로 각각 'Missing But Applicable'과 'Missing But Applicable'을 나타낸다.^[5]Codd의 권고는 SQL의 논리 시스템을 4개의 가치 논리 시스템을 수용할 수 있도록 확장하도록 요구했을 것이다.이러한 추가적인 복잡성 때문에, 서로 다른 정의를 가진 여러 Nulls의 아이디어는 데이터베이스 실무자들의 영역에서 널리 받아들여지지 않았다.그러나 그것은 여전히 많은 논문들이 발표되고 있는 등 여전히 활발한 연구 분야로 남아 있다.

과제들

Null은 관련 3가지 가치 논리(3VL), SQL 결합에 사용하기 위한 특별 요건, Aggregate 함수 및 SQL 그룹화 운영자가 요구하는 특별 취급 등으로 인해 논란의 초점이 되고 논쟁의 대상이 되어 왔다.컴퓨터 과학 교수님이라고 론 반 데르 Meyden:비록 여러 제안 이 문제가 해결을 위해 제작되었다고"SQL표준에 그 모순들은 nulls의 구조화 질의어에 치료에 어떤 직관적인 논리적 의미 탓으로 돌리는 것은 불가능하다."[1]대안이의 복잡성 예방하고 있고로서 다양한 문제 요약했다. 월널리 채택되다

Null 전파

산술 연산

Null은 데이터 값이 아니라 결측값에 대한 마커이기 때문에 Null에서 수학 연산자를 사용하면 알 수 없는 결과가 나오는데, Null로 표시된다.^[6]다음 예에서 10을 Null로 곱하면 Null이 된다.

10 * NULL          -- 결과가 NULL임 

이것은 예상치 못한 결과를 초래할 수 있다.예를 들어, Null을 0으로 나누려고 시도할 때 플랫폼은 예상된 "데이터 예외 - 0으로 나누기"^[6] 대신 Null을 반환할 수 있다.이 동작은 ISO SQL 표준에 의해 정의되지 않지만, 많은 DBMS 공급업체들은 이 작업을 유사하게 취급한다.예를 들어, 오라클, Postgre.SQL, MySQL Server 및 Microsoft SQL Server 플랫폼은 모두 다음 항목에 대해 Null 결과를 반환한다.

NULL / 0 

끈 연결

SQL에서 공통적으로 사용되는 문자열 연결 연산도 피연산자 중 하나가 Null이면 Null이 된다.^[7]다음 예제는 SQL과 함께 Null을 사용하여 반환된 Null 결과를 보여준다. 문자열 연결 연산자

'물고기.'    NULL    '칩스'   -- 결과가 NULL임 

이는 모든 데이터베이스 구현에 해당되지 않는다.Oracle RDBMS에서 예를 들어 NULL과 빈 문자열은 동일한 것으로 간주되므로 'Fish 'NULL '칩스'는 'Fish Chips'를 의미한다.

NULL 및 3-값 논리(3VL)와의 비교

Null은 데이터 도메인의 멤버가 아니기 때문에 "값"이 아니라 정의되지 않은 값을 나타내는 마커(또는 자리 표시자)로 간주된다.이 때문에, Null과의 비교는 결코 True 또는 False를 초래할 수 없지만, 항상 세 번째 논리 결과인 Unknown(알 수 없음)을 낳는다.^[8]값 10을 Null과 비교하는 아래 식의 논리적 결과는 알 수 없음:

선택 10 = NULL       -- 결과를 알 수 없음 

그러나 Null의 특정 연산은 결측값이 연산의 결과와 관련이 없는 경우 값을 반환할 수 있다.다음 예를 고려해 보십시오.

선택 NULL OR 진실의   -- 결과: True 

이 경우 OR 왼쪽의 값이 알 수 없는 것은 OR 조작의 결과가 왼쪽의 값과 상관없이 True가 되기 때문이다.

SQL은 세 가지 논리적 결과를 구현하므로 SQL 구현은 전문화된 3-값 논리(3VL)를 제공해야 한다.SQL 3-값 논리를 지배하는 규칙은 아래 표에 나타나 있다(p와 q는 논리적 상태를 나타냄).^[9]SQL이 AND, OR에 사용하는 진리표는 클렌과 우카시오에비치 3개 값 논리(의미적 의미 정의에 차이가 있지만 SQL은 그러한 연산을 정의하지 않는다)의 일반적인 파편과 대응하지 않는다.^[10]

WHERE 절에서 Unknown의 영향

SQL 3-값 로직은 DML 문과 쿼리의 비교 술어에서 DML(Data Manufaction Language)에서 만난다.그WHERE절은 술어가 True로 평가하는 행에만 DML 문을 작동하게 한다.술어가 False 또는 Unknown으로 평가하는 행은 다음에 의해 수행되지 않음INSERT,UPDATE또는DELETEDML 문 및 다음에서 폐기됨SELECT질의Unknown 및 False를 동일한 논리적 결과로 해석하는 것은 Nulls를 처리하는 동안 발생하는 일반적인 오류다.^[9]다음의 간단한 예는 이러한 오류를 보여준다.

선택 * From t 어디에 i = NULL; 

위의 예시 쿼리는 항상 논리적으로 0개의 행을 반환하는데, 이는 i 열을 Null로 비교하는 경우에도 항상 Unknown으로 반환되기 때문이다.알 수 없는 결과는SELECT각 행과 행을 모두 요약하여 삭제하라는 명령문(그러나 실제로 일부 SQL 도구는 Null과의 비교를 사용하여 행을 검색한다.)

null별 및 3VL별 비교 술어

기본 SQL 비교 연산자는 Null과 어떤 것을 비교할 때 항상 Unknown을 반환하므로 SQL 표준은 두 개의 특별한 Null별 비교 술어를 제공한다.그IS NULL그리고IS NOT NULL술어(postfix 구문을 사용하는)는 데이터가 Null인지 여부를 테스트한다.^[11]

SQL 표준은 3개의 추가적인 논리적 단항 연산자(사실상 그들의 구문의 일부인 부정을 계산하면 6개)를 도입하는 선택적 특징 F571 "진실값 시험"을 또한 포스트픽스 표기법을 사용하여 포함하고 있다.그들은 다음과 같은 진리표를 가지고 있다.^[12]

F571 특성은 SQL에 부울 데이터 유형이 존재하는 것과 직교하며(이 기사 뒷부분에서 설명함) 구문학적 유사성에도 불구하고 F571은 언어에 부울 또는 3값 리터럴을 도입하지 않는다.F571 기능은 부울 데이터 형식이 1999년에 표준에 도입되기 훨씬 전인 ^[13]SQL92에 실제로 존재했다.그러나 F571 기능은 소수의 시스템에 의해 구현된다; PostgreSQL은 그것을 구현하는 것 중 하나이다.

SQL의 3가지 가치 논리 연산자의 다른 연산자에 IS NUNNOWN을 추가하면 SQL의 3가지 가치 논리 연산자가 기능적으로 완전하게 되는데,^[14] 이는 그 논리 연산자가 상상할 수 있는 3가지 가치 논리 함수를 (결합으로) 표현할 수 있다는 것을 의미한다.

F571 기능을 지원하지 않는 시스템에서는 p를 Unknown(알 수 없음)으로 만들 수 있는 모든 인수를 검토하여 IS NULL 또는 기타 NULL 고유 기능으로 인수를 테스트하면 IS NULL p를 에뮬레이트할 수 있다.

제외된 4번째의 법칙(WHERE 절)

SQL의 3가지 가치 논리에서는 배제된 중간 법칙인 p OR NOT p가 더 이상 모든 p에 대해 true로 평가되지 않는다.보다 정확히 말하면, SQL의 3값 논리 p OR NOT p는 p가 알 수 없고 그렇지 않으면 진실일 때 정확히 알 수 없다.Null과의 직접 비교를 통해 알 수 없는 논리적 값이 발생하기 때문에 다음 쿼리를 수행하십시오.

선택 * From 속을 채우다 어디에 ( x = 10 ) OR NOT ( x = 10 ); 

다음 SQL과 동일하지 않음

선택 * From 속을 채우다; 

열 x에 Null이 포함된 경우, 두 번째 쿼리는 첫 번째 쿼리가 반환하지 않는 행, 즉 x가 Null인 행을 반환한다.고전적인 두 가지 가치 논리학에서, 배제된 중간 법칙은 WHERE 절 술어의 단순화를 허용하고, 사실상 그 제거를 허용한다.SQL의 3VL에 배제된 중간 법칙을 적용하려는 것은 사실상 잘못된 이분법이다.두 번째 쿼리는 실제로 다음 항목과 동일하다.

선택 * From 속을 채우다; -- (3VL로 인한)는 다음과 같다. 선택 * From 속을 채우다 어디에 ( x = 10 ) OR NOT ( x = 10 ) OR x IS NULL; 

따라서 SQL에서 첫 번째 문을 올바르게 단순화하려면 x가 null이 아닌 모든 행을 반환해야 한다.

선택 * From 속을 채우다 어디에 x IS NOT NULL; 

위와 같은 관점에서 SQL의 WHERE 조항의 경우 제외된 중간 법칙과 유사한 자동이 작성될 수 있음을 관찰한다.IS 무명 연산자가 존재한다고 가정하면 모든 술어 p에 대해 p OR(p not p) OR(p IS 무명)이 참이다.논리학자 중에서는 이것을 배제된 4의 법칙이라고 한다.

잘못된 딜레마가 발생하는 곳이 명확하지 않은 SQL 표현들이 있는데, 예를 들면 다음과 같다.

선택 'OK' 어디에 1 NOT 인 (선택 캐스트 (NULL AS 정수)) 유니온 선택 'OK' 어디에 1 인 (선택 캐스트 (NULL AS 정수)); 

로 인해 행이 생성되지 않는다.IN논거 세트와 1에 대한 동일성의 반복된 버전으로 번역하다.1=NULL이 Unknown인 것처럼 NULL은 Unknown이다.(이 예에서 CAST는 Postgre와 같은 일부 SQL 구현에서만 필요하다.SQL. 그렇지 않으면 형식 검사 오류가 발생하여 이를 거부함.많은 시스템에서 일반 선택 NULL은 하위 쿼리에서 작동한다.)위의 누락 사례는 물론 다음과 같다.

선택 'OK' 어디에 (1 인 (선택 캐스트 (NULL AS 정수))) IS 알 수 없는; 

다른 구조에서 Null 및 Unknown의 영향

가입하다

가입자는 WHERE 절과 동일한 비교 규칙을 사용하여 평가한다.따라서 SQL 조인 기준에서 무효 열을 사용할 때는 주의해야 한다.특히 null을 포함하는 테이블은 그 자체의 자연적인 자체 조인과 같지 않다. 즉, $R{\displaystyle }$ ${\displaystyle \bowtie }$ ${\displaystyle R}$= ${\displaystyle R}$ ${\displaystyle$ R$\bowtie R=R}$이 관계 대수에서 R에 대해 참인$$ 반면, SQL 자체 조인은 아무 곳이나 null을 포함하는 모든 행을 제외한다.^[15]이러한 행동의 예는 Nulls의 결측값 의미 분석 절에 제시되어 있다.

더 SQLCOALESCE기능 또는CASE식을 사용하여 조인 기준에서 Null 동등성을 "시뮬레이션"할 수 있으며IS NULL그리고IS NOT NULL술어는 조인 기준에도 사용될 수 있다.A와 B의 동일성에 대한 다음의 서술형 테스트와 Nulls를 동일하다고 취급한다.

(A = B) OR (A IS NULL AND B IS NULL) 

CASE 표현식

SQL은 조건부 표현식의 두 가지 맛을 제공한다.하나는 "단순 CASE"라고 불리며 스위치 문처럼 작동한다.다른 하나는 표준에서 "searched CASE"라고 불리며 if...elseif처럼 작동한다.

심플CASE표현식은 DML과 동일한 규칙에 따라 작동하는 암묵적 동등 비교를 사용한다.WHERENull에 대한 절 규칙.따라서 단순한 표현으로는 Null의 존재를 직접 확인할 수 없다.단순하게 Null에 대한 검사CASE표현식은 다음과 같이 항상 알 수 없음으로 귀결된다.

선택 케이스 i 언제 NULL 그럼 'Null인가'  - 이것은 절대 반환되지 않을 것이다.               언제    0 그럼 '제로인가'  - i = 0일 때 반환됨               언제    1 그럼 '하나'   -- i = 1일 때 반환됨               끝 From t; 

왜냐하면 그 표현은i = NULL어떤 값 열을 포함하든(Null이 포함된 경우에도) 알 수 없음으로 평가'Is Null'다시는 돌아오지 않을 것이다.

반면 '시어드'는 '시어드'CASE표현은 다음과 같은 술어를 사용할 수 있다.IS NULL그리고IS NOT NULL그 상태로는다음 예제는 검색된 사용 방법을 보여준다.CASENull을 제대로 검사하는 식:

선택 케이스 언제 i IS NULL 그럼 'Null 결과'  -- 이 항목은 내가 NULL일 때 반환됨             언제     i = 0 그럼 '제로'         - i = 0일 때 반환됨             언제     i = 1 그럼 '하나'          -- i = 1일 때 반환됨             끝 From t; 

검색된 항목CASE표현식, 문자열'Null Result'i가 Null인 모든 행에 대해 반환됨.

Oracle의 SQL 사투리가 내장 기능 제공DECODE단순한 CASE 표현식 대신 사용할 수 있으며, 두 개의 null이 같다고 간주한다.

선택 디코딩(i, NULL, 'Null 결과', 0, '제로', 1, '하나') From t; 

마지막으로, 이 모든 구성 요소는 일치하는 항목이 없으면 NULL을 반환하며, 기본값이 있음ELSE NULL조항의

절차적 확장의 IF 문

SQL/PSM(SQL Persistent Stored Modules)은 SQL에 대한 절차 확장(예:IF명세서그러나 주요 SQL 공급업체들은 역사적으로 독자적인 절차 확장을 포함했다.루프 및 비교를 위한 절차적 확장은 DML 문 및 질의와 유사한 Null 비교 규칙에서 작동한다.다음 코드 조각은 ISO SQL 표준 형식으로, Null 3VL의 사용을 보여준다.IF명세서

IF i = NULL 그럼       선택 '결과가 참이다' 엘시프 NOT(i = NULL) 그럼       선택 '결과가 거짓이다' 기타       선택 '결과가 알 수 없음'; 

그IF문은 참으로 평가되는 비교에 대해서만 작업을 수행한다.False 또는 Unknown으로 평가되는 문장의 경우IF에 대한 통제권을 넘겨주다.ELSEIF그리고 마침내ELSE조항의위의 코드의 결과는 항상 메시지가 될 것이다.'Result is Unknown'Null과의 비교는 항상 Unknown으로 평가되기 때문에.

SQL Null 결측값 의미 분석

T의 기공작. 이미엘리우스키와 W. 립스키 주니어(1984)는 ^[16]'이미엘리우스키-립스키 알헤브라스'라고 불리는 결측가치 의미론을 구현하기 위한 다양한 제안의 의도된 의미론을 평가할 수 있는 틀을 제공했다.이 섹션은 대략 "앨리스" 교과서의 19장을 따른다.^[17]유사한 프레젠테이션이 론 반 데어 메이든의 리뷰, §10.4에도 나타난다.^[1]

선택 및 투영에서: 약한 표현

Codd 표와 같이 누락된 정보를 나타내는 구조는 실제로 매개변수의 가능한 인스턴스화마다 하나씩 일련의 관계를 나타내기 위한 것이다. Codd 표의 경우, 이것은 Nulls를 어떤 구체적인 가치로 대체하는 것을 의미한다.예를 들어,

구조(Codd 표 등)는 구조물에 대해 이루어진 질의에 대한 답변을 구체화하여 그것이 나타내는 관계에 대한 어떤 해당 질의에 대한 답변을 얻을 수 있다면 (누락된 정보의) 강력한 표현 시스템이라고 하며, 이는 구조물의 모델로 보여진다.더 정확히 말하면, q가 관계 대수("순수" 관계의)의 질의 공식이고 q가 누락된 정보를 나타내기 위한 구조로 들어 올리는 것이라면, 강한 표현은 어떤 질의 q와 (테이블) 구성 T에 대해, q는 구조에 대한 모든 답을 들어 올리는 속성을 갖는다. 즉,

${\displaystyle \mathop {\mathrm {Models}}{\bar {q}(T)=\{q(R)\, R\in \mathop {\mathrmathrm {Models}}}(T)\}}}$

(위의 내용은 임의의 수의 테이블을 인수로 간주하는 쿼리에 대해 보류해야 하지만, 하나의 테이블에 대한 제한은 이 논의를 위해 충분하다.선택과 투영을 쿼리 언어의 일부로 간주하는 경우 Codd 테이블에는 이러한 강력한 속성이 없다.예를 들어, 에 대한 모든 대답

선택 * From 엠프 어디에 나이 = 22; 

EmpH22와 같은 관계가 존재할 수 있는 가능성을 포함해야 한다.그러나 Codd 테이블은 "0 또는 1개의 행으로 결과" 분리를 나타낼 수 없다.그러나 대부분의 이론적 관심사가 있는 장치는 조건부 표(또는 c-table)라고 불리는 다음과 같은 대답을 나타낼 수 있다.

조건이 거짓인 경우 조건 열이 행이 존재하지 않는 것으로 해석되는 경우.c-table의 조건란에 있는 공식은 임의의 명제 논리 공식일 수 있기 때문에, c-table이 어떤 구체적인 관계를 나타내는지에 대한 문제의 알고리즘은 c-NP-완전한 복잡성을 가지고 있기 때문에 실질적인 가치가 거의 없는 것으로 나타났다.

그러므로 대표성의 약화는 바람직하다.이미엘린스키와 립스키는 본질적으로 어떤 구조에 대한 (변환된) 질의가 확실한 정보, 즉 그것이 그 구조의 모든 "가능성이 있는" 인스턴스화(모듈)에 유효하다면 표현만을 반환하도록 허용하는 약한 표현 개념을 도입했다.구체적으로는 다음과 같은 경우 구문은 약한 표현 체계다.

${\displaystyle \bigcap \mathop {\mathrm {Models}}}({q}(T)=\bigcap \{q(R)\, R\in \mathop {\mathrm {Models}}(T)\}}}}}$

위 방정식의 오른쪽은 확실한 정보, 즉 데이터베이스에서 Nulls를 대체하기 위해 어떤 값을 사용하든 상관없이 데이터베이스에서 확실히 추출할 수 있는 정보다.앞에서 살펴본 예에서, 쿼리 선택에서 가능한 모든 모델(즉, 확실한 정보)의 교차점을 쉽게 확인할 수 있다.WHERE Age = 22예를 들어, (변속되지 않은) 쿼리가 EmpH37 관계에 대해 행을 반환하지 않기 때문에 실제로 비어 있다.보다 일반적으로는 이미엘린스키와 립스키에 의해 쿼리 언어가 투영, 선택(및 칼럼의 명칭 변경)으로 제한될 경우 Codd 테이블은 취약한 표현 시스템임을 보여주었다.그러나 쿼리 언어에 조인이나 결합을 추가하면 바로 다음 절에서 증명된 바와 같이 이 약한 속성마저 잃게 된다.

결합 또는 결합을 고려할 경우: 심지어 약한 대표성 조차 고려되지 않음

동일한 Codd 테이블에 대해 다음 쿼리를 고려하십시오.이전 섹션의 내용:

선택 이름 From 엠프 어디에 나이 = 22 유니온 선택 이름 From 엠프 어디에 나이 <> 22; 

어떤 구체적인 가치를 선택하든NULL해리엇의 나이, 위의 질의가 엠프의 어떤 모델의 이름 열 전체를 돌려주겠지만, 엠프 자체에서 (lifted) 질의가 실행되면, 해리엇은 항상 실종될 것이다. 즉, 우리는 다음과 같은 것을 가지고 있다.

따라서 쿼리 언어에 조합이 추가될 때 Codd 테이블은 누락된 정보의 약한 표현 시스템도 아니며, 이는 이들에 대한 쿼리가 모든 확실한 정보를 보고하지도 않는다는 것을 의미한다.여기서 유의할 점은, 나중 섹션에서 논의되는, Nulls에 관한 유니온의 의미론들은 이 질의에서조차 실행되지 않았다는 것이다.위의 질의가 Codd 테이블 Emp에서 실행되었을 때 확실한 정보가 보고되지 않았다는 것을 보증하기 위해 두 서브쿼리의 "잊혀진" 성질은 그것이 전부였다.

자연 결합의 경우, 어떤 질의에 의해 정보가 보고되지 않을 수 있다는 것을 보여주는 데 필요한 예는 약간 더 복잡하다.표를 고려하십시오.

그리고 질의

선택 F1, F3 From      (선택 F1, F2 From J) AS F12      내추럴 가입하다      (선택 F2, F3 From J) AS F23; 

위에서 일어나는 일에 대한 직관은 서브쿼리의 투영을 나타내는 Codd 테이블이 F12 열의 Nulls를 추적하지 못한다는 것이다.F2와 F23.F2는 실제로 표 J에 있는 원고의 사본이다.이러한 관측은 Codd 테이블의 비교적 간단한 개선(이 예에서는 올바르게 작동)이 단일 NULL 기호 대신 skolem 상수(또한 상수함수인 Scolem 함수를 의미함)와 Ω을₁₂₂₂ 사용하는 것이 될 것임을 시사한다.v-tables 또는 Senginous tables라고 불리는 그러한 접근법은 위에서 논의한 c-tables보다 계산적으로 덜 비싸다.그러나 v-tables는 선택에서 부정(그리고 설정 차이를 사용하지 않음)을 사용하지 않는 쿼리에 대한 약한 표현일 뿐이라는 점에서 여전히 불완전한 정보에 대한 완전한 해결책은 아니다.이 절에서 고려한 첫 번째 예는 음의 선택 조항을 사용하는 것이다.WHERE Age <> 22따라서 v-properties 쿼리가 확실한 정보를 보고하지 않는 예도 된다.

제약 조건 및 외부 키 확인

SQL 3값 로직이 DDL(SQL Data Definition Language)과 교차하는 1차적인 장소는 체크 제약조건의 형태다.열에 배치된 체크 제약조건은 DML과 약간 다른 규칙 집합에서 작동한다.WHERE조항의DML 동안WHERE한 행에 대해 절은 True로 평가해야 하며, 체크 제약 조건은 False로 평가해서는 안 된다.(논리의 관점에서 지정된 값은 True 및 Unknown이다.)즉, 검사 결과가 True 또는 Unknown일 경우 체크 제약이 성공한다는 것을 의미한다.체크 제약 조건이 있는 다음 예제 표는 i열에 정수 값을 삽입하는 것을 금지하지만, 검사 결과가 항상 Null에 대해 Unknown으로 평가되기 때문에 Null을 삽입할 수 있다.^[18]

만들다 테이블 t (      i 정수,      구속조건 ck_i 체크 ( i < 0 AND i = 0 AND i > 0 ) ); 

WHERE 절에 상대적인 지정값의 변화로 인해 논리적인 관점에서 배제된 중간 법칙은 CHECK 제약조건에 대한 tautology를 의미하는 것이다.CHECK (p OR NOT p)항상 성공한다.또한 Nulls를 기존 값이지만 알 수 없는 값으로 해석한다고 가정하면 위의 값과 같은 일부 병리학적 CHECK에서는 Null이 아닌 값으로 절대 대체할 수 없는 Nulls를 삽입할 수 있다.

Null을 거부하도록 열을 제한하려면NOT NULL아래 예시와 같이 제약조건을 적용할 수 있다.그NOT NULL제약조건은 의미상 다음과 같은 체크 제약조건과 동일하다.IS NOT NULL술어를 붙이다

만들다 테이블 t ( i 정수 NOT NULL ); 

기본적으로 외래 키의 필드 중 하나가 Null인 경우 외래 키에 대한 제약 조건이 충족된다.예를 들어, 테이블

만들다 테이블 책들 ( 칭호를 붙이다 바카르(100),   저자_마지막 바카르(20),   저자_최초 바카르(20), 외국 키 (저자_마지막, 저자_최초)   참고 자료 작가들(last_name, first_name)); 

작성자_last 또는 작성자_first가 있는 행을 삽입할 수 있음NULL표의 작성자 정의 방법이나 표의 내용에 관계없이.더 정확히 말하면, 이러한 필드의 null은 작성자 표에서 찾을 수 없는 값이라도 다른 필드의 값을 허용한다.예를 들어, 작성자만 포함된 경우('Doe', 'John'), 그러면.('Smith', NULL)외부 키 제약 조건을 충족시킬 수 있을 겁니다SQL-92는 그러한 경우 경기 범위를 좁히기 위해 두 가지 추가 옵션을 추가했다.만약MATCH PARTIAL다음에 추가됨REFERENCES그러면 선언할 때 비-비-비-비-비-비-비-비-비-비-비-비-키와('Doe', NULL)여전히 일치하겠지만('Smith', NULL)그럴 리가 없다마지막으로, 만약MATCH FULL그때 추가된다.('Smith', NULL)제약조건과 일치하지 않을 수도 있다.(NULL, NULL)그래도 잘 어울릴 거야

외부 결합

결과 집합에서 Null 자리 표시자를 사용한 SQLouter 조인 쿼리 예.Null 마커는 단어로 표현된다.NULL결과의 데이터를 대신하여결과는 SQL Server Management Studio와 같이 Microsoft SQL Server에서 나온다.

왼쪽 바깥쪽 조인, 오른쪽 바깥쪽 조인, 전체 바깥쪽 조인 등 SQL 바깥쪽 조인은 관련 테이블에서 결측값에 대한 자리 표시자로 Nulls를 자동으로 생성한다.예를 들어, 왼쪽 외부 조인의 경우 테이블에서 누락된 행 대신 Null이 생성된다.LEFT OUTER JOIN교환원의다음의 간단한 예제는 두 개의 표를 사용하여 왼쪽 외부 조인에서 Null 자리 표시자 생성을 시연한다.

첫 번째 표(종업원)에는 직원 ID 번호와 이름이, 두 번째 표(폰 번호)에는 아래와 같이 관련 직원 ID 번호와 전화 번호가 수록되어 있다.

다음 샘플 SQL 쿼리는 이 두 테이블에서 왼쪽 외부 조인을 수행한다.

선택 e.아이디, e.성, e.이름, pn.숫자 From 직원 e 왼쪽 바깥쪽 가입하다 전화번호 pn 켜기 e.아이디 = pn.아이디; 

이 쿼리에 의해 생성된 결과 집합은 아래와 같이 SQL이 오른쪽(PhoneNumber) 테이블에서 누락된 값에 대해 Null을 자리 표시자로 사용하는 방법을 보여준다.

집계함수

SQL은 데이터에 대한 서버측 집계 계산을 단순화하기 위해 집계 함수를 정의한다.다음 항목만 제외하고COUNT(*)함수, 모든 Aggregate 함수는 Null-remination 단계를 수행하여 Nulls가 계산의 최종 결과에 포함되지 않도록 한다.^[19]

Null 제거는 Null을 0으로 대체하는 것과 같지 않다는 점에 유의하십시오.예를 들어, 다음 표에서AVG(i)(값의 평균)i)는 의 그것과는 다른 결과를 줄 것이다.AVG(j):

여기AVG(i)200(평균 150, 200, 250)이다.AVG(j)150(평균 150, 200, 250, 0)이다.이것의 잘 알려진 부작용은 SQL에 있다.AVG(z)와 같지 않다.SUM(z)/COUNT(*)그렇지만SUM(z)/COUNT(z).^[4]

집계 함수의 출력도 Null일 수 있다.예를 들면 다음과 같다.

선택 카운트(*), 분(e.임금), 맥스.(e.임금) From 직원 e 어디에 e.성 맘에 들다 '%Jones%'; 

이 쿼리는 항상 정확히 한 행을 출력하여 성이 "존"을 포함하는 직원 수를 계산하고 해당 직원들에 대해 발견된 최저 임금과 최고 임금을 제공한다.그러나 주어진 기준에 맞는 직원이 한 명도 없을 경우 어떻게 되는 것이다.빈 집합의 최소값이나 최대값을 계산하는 것은 불가능하므로 그 결과는 답이 없음을 나타내는 NULL이어야 한다.알 수 없는 값이 아니라 값이 없음을 나타내는 Null입니다.그 결과는 다음과 같다.

그룹화, 정렬 및 일부 설정된 작업의 두 Null이 동일한 경우

SQL:2003에서는 모든 Null 마커가 서로 동일하지 않다고 정의하기 때문에 특정 작업을 수행할 때 Null을 함께 그룹화하기 위해서는 특별한 정의가 필요했다.SQL은 "서로 동일한 두 개의 값 또는 두 개의 Null"을 "특이하지 않음"^[20]으로 정의한다.구별되지 않는다는 이 정의는 SQL이 Nulls를 그룹화하고 정렬할 때GROUP BY절(및 그룹화를 수행하는 기타 키워드)이 사용된다.

다른 SQL 연산, 절 및 키워드는 Null을 처리할 때 "별도가 없다"를 사용한다.여기에는 다음이 포함된다.

• PARTITION BY다음과 같은 순위 지정 및 창 기능 조항ROW_NUMBER
• UNION,INTERSECT그리고EXCEPT연산자(행 비교/제거를 위해 NULL을 동일한 것으로 취급함)
• DISTINCT에 사용된 키워드SELECT질의

Nulls가 서로 같지 않다는 원칙(보다 결과를 알 수 없음)은 SQL 사양에서 효과적으로 위반된다.UNION서로 null을 식별하는 연산자.^[1]따라서, 조합이나 차이와 같이 SQL에서 설정된 일부 운영은 NULL과의 명시적 비교(예: a의 운영)를 포함하는 운영과는 달리, 확실한 정보를 나타내지 않는 결과를 산출할 수 있다.WHERE위에서 논의한 조항).Codd의 1979년 제안(기본적으로 SQL92에 의해 채택된)에서, 세트 운영에서 중복의 제거는 "검색 운영의 평가에서 평등 시험보다 더 낮은 수준의 세부사항"^[10]에서 발생한다고 주장함으로써 이 의미론적 불일치를 합리화한다.

SQL 표준은 Nulls에 대한 기본 정렬 순서를 명시적으로 정의하지 않는다.대신 시스템 준수 시 Null을 사용하여 모든 데이터 값 앞 또는 뒤에 정렬할 수 있다.NULLS FIRST또는NULLS LAST의 조항들ORDER BY각각 열거하다그러나 모든 DBMS 벤더가 이 기능을 구현하는 것은 아니다.이 기능을 구현하지 않는 공급업체는 DBMS에서 Null 정렬에 대해 다른 처리를 지정할 수 있다.^[18]

인덱스 작업에 미치는 영향

일부 SQL 제품은 NULL을 포함하는 키를 인덱싱하지 않는다.예를 들어, Postgre.8.3 이전 버전의 SQL은 다음과 같이^[21] B-트리 인덱스에 대한 문서화되지 않았다.

B-tree는 일부 순서에 따라 정렬할 수 있는 데이터에 대한 동등성 및 범위 쿼리를 처리할 수 있다.특히 포스그렉은SQL 조회 플래너는 색인된 컬럼이 이러한 연산자 중 하나를 이용한 비교에 포함될 때마다 B-트리 인덱스 사용을 고려할 것이다.

B-tree 인덱스 검색으로 이러한 연산자의 조합에 상당하는 구성을 구현할 수 있다(그러나 IS NULL은 =와 동일하지 않고 인덱싱할 수 없다는 점에 유의한다).

지수의 고유성을 강제하는 경우, 지수에서 NULL은 제외되고, NULL 간 고유성은 강제되지 않는다.다시, Postgre에서 인용했다.SQL 설명서:^[22]

인덱스가 고유하다고 선언되면 인덱싱된 값이 동일한 여러 테이블 행이 허용되지 않는다.null은 동등하다고 간주되지 않는다.다중 콜럼 고유 인덱스는 인덱싱된 모든 열이 두 행으로 동일한 경우에만 거부한다.

이는 스칼라 Null 비교의 SQL:2003 정의 동작과 일치한다.

Nulls를 인덱싱하는 또 다른 방법에는 SQL:2003 정의 동작에 따라 구별되지 않는 것으로 처리하는 방법이 있다.예를 들어, 마이크로소프트 SQL 서버 설명서에는 다음과 같이 기술되어 있다.^[23]

인덱싱을 위해 NULL은 동일한 것으로 비교한다.따라서 키가 둘 이상의 행에서 NULL이면 고유 인덱스, 즉 UNIGN 제약조건을 생성할 수 없다.고유 인덱스 또는 고유 제약 조건의 열을 선택할 때 NOT NULL로 정의된 열을 선택하십시오.

이 두 가지 지수화 전략은 모두 Nulls의 SQL:2003 정의 동작과 일치한다.지수화 방법론은 SQL:2003 표준에 의해 명시적으로 정의되지 않기 때문에, Nulls에 대한 지수화 전략은 전적으로 벤더에 맡겨 설계와 구현을 한다.

Null 처리 기능

SQL은 Null을 명시적으로 처리하는 두 가지 기능을 정의한다.NULLIF그리고COALESCE. 두 함수는 모두 검색된 표현식의 약어다.^[24]

널리프

그NULLIF함수는 두 개의 파라미터를 허용한다.첫 번째 파라미터가 두 번째 파라미터와 같을 경우,NULLIFNull을 반환한다.그렇지 않으면 첫 번째 파라미터의 값이 반환된다.

널리프(값1, 값2) 

그러므로,NULLIF다음에 대한 줄임말이다.CASE표현식:

케이스 언제 값1 = 값2 그럼 NULL 기타 값1 끝 

코네체

그COALESCE함수는 파라미터 목록을 허용하고, 목록에서 Null이 아닌 첫 번째 값을 반환한다.

코네체(값1, 값2, 가치3, ...) 

COALESCE다음 SQL의 속기로 정의된다.CASE표현식:

케이스 언제 값1 IS NOT NULL 그럼 값1      언제 값2 IS NOT NULL 그럼 값2      언제 가치3 IS NOT NULL 그럼 가치3      ...      끝 

일부 SQL DBMS는 다음과 유사한 벤더별 기능을 구현함COALESCE. 일부 시스템(예: Transact-SQL)은ISNULL함수 또는 기능적으로 유사한 다른 유사한 함수COALESCE. (자세한 내용은 기능을 참조하십시오.ISTransact-SQL의 함수)

NVL

오라클NVL함수는 두 개의 파라미터를 허용한다.모든 파라미터가 NULL인 경우 첫 번째 비 NULL 파라미터 또는 NULL을 반환한다.

A COALESCE표현은 동등한 것으로 변환될 수 있다.NVL따라서 다음과 같은 표현:

코네체 ( val1, ... , 발랄하게 하다{n} ) 

다음 항목으로 전환:

NVL( val1 , NVL( val2 , NVL( val3 , … , NVL ( 발랄하게 하다{n-1} , 발랄하게 하다{n} ) … ))) 

이 함수의 사용 사례는 표현식에서 NULL을 다음과 같은 값으로 대체하는 것이다.NVL(SALARY, 0)'만약'이라는 말이 있다.SALARYNULL이므로 0' 값으로 대체하십시오.

그러나 한가지 주목할 만한 예외가 있다.대부분의 구현에서,COALESCENUL이 아닌 첫 번째 파라미터에 도달할 때까지 파라미터를 평가하는 동안NVL모든 매개변수를 평가한다.이것은 몇 가지 이유로 중요하다.첫 번째 NUL이 아닌 파라미터 이후의 파라미터는 함수가 될 수 있으며, 이는 계산상 비용이 많이 들거나, 유효하지 않거나, 예상치 못한 부작용을 일으킬 수 있다.

Null 및 알 수 없는 데이터 입력

그NULL 리터럴은 SQL에서 유형화되지 않았으며, 이는 정수, 문자 또는 기타 특정 데이터 유형으로 지정되지 않았다는 것을 의미한다.^[25]이 때문에 Null을 특정 데이터 유형으로 명시적으로 변환하는 것이 의무적이거나 바람직한 경우도 있다.예를들어 과부하 기능이 RDBMS에 의해 지원되는 경우, SQL은 Null이 전달되는 파라미터를 포함한 모든 파라미터의 데이터 유형을 알지 못한 채 정확한 기능으로 자동 해결하지 못할 수 있다.

변환 위치:NULL다음을 사용하여 특정 유형의 Null로 리터럴 가능CASTSQL-92에 도입되었다.예를 들면 다음과 같다.

캐스트 (NULL AS 정수) 

정수 유형의 결측값을 나타낸다.

알 수 없음(NULL 자체에서 간결하거나 그렇지 않음)의 실제 타이핑은 SQL 구현에 따라 다르다.예를 들면 다음과 같다.

선택 'OK' 어디에 (NULL <> 1) IS NULL; 

일부 환경(예: SQLite 또는 Postgre)에서 성공적으로 분석 및 실행알 수 없음으로 NULL 부울을 통합하지만 다른 부분(예: SQL Server Compact)에서는 구문 분석하지 못하는 SQL.MySQL은 Postgre와 비슷하게 동작함이와 관련하여 SQL(MySQL이 TRUE 및 FALSE를 일반 정수 1과 0과 다르지 않은 것으로 간주하는 사소한 예외는 제외)PostgreSQL에서 추가로 구현하는 기능IS UNKNOWN단지 통사당일 뿐이지만, 3-값 논리 결과가 알 수 없는 것인지 여부를 테스트하는 데 사용될 수 있는 술어.

BOOLAN 데이터 유형

ISO SQL:1999 표준은 SQL에 BOOLAN 데이터 유형을 도입했지만, 여전히 선택 사항인 비핵심 기능인 코드화된 T031에 불과하다.^[26]

에 의해 제한되는 경우NOT NULL제약조건, SQL BOOLAN은 다른 언어의 Boolean 유형과 같이 작동한다.그러나 BOOLAN 데이터 형식은 이름에도 불구하고 TrUE, FALSE 및 Unknown(알 수 없음)의 진실 값을 포함할 수 있으며, 모두 표준에 따라 부울 리터럴로 정의된다.이 표준은 또한 NULL과 Unknown은 "정확하게 동일한 것을 의미하기 위해 서로 교환하여 사용될 수 있다"^[27][28]고 주장한다.

부울타입은 특히 NULL과의 식별 때문에 자신과 결코 동등하지 않은, 알 수 없는 알 수 없는 리터럴의 의무적인 행동 때문에 비판의 대상이 되어 왔다.^[29]

위에서 논했듯이, Postgre에서SQL의 SQL 구현, Null은 UnUnknown BOOLN을 포함한 모든 Unknown 결과를 나타내기 위해 사용된다.PostgreSQL은 알 수 없는 리터럴을 구현하지 않는다(직교 기능인 IS 알 수 없는 연산자를 구현하지만).다른 대부분의 주요 공급업체는 2012년 현재 부울 유형(T031에서 정의됨)을 지원하지 않는다.^[30]Oracle PL/SQL의 절차적 부분은 BOOLIN을 지원하지만 변수 또한 NULL로 할당될 수 있으며 값은 Unknown과 동일한 것으로 간주된다.^[31]

논란

흔한 실수

Null의 작동 방식에 대한 오해는 ISO 표준 SQL 문장과 실제 데이터베이스 관리 시스템이 지원하는 특정 SQL 방언에서 모두 SQL 코드의 수많은 오류의 원인이다.이러한 실수는 대개 Null과 0(0) 또는 빈 문자열(길이 0의 문자열 값, SQL에 다음과 같이 표시됨)의 혼동의 결과물이다.'') Null은 SQL 표준에 의해 빈 문자열 및 숫자 값과 모두 다른 것으로 정의된다.0그러나.Null은 값이 없음을 나타내는 반면, 빈 문자열과 숫자 0은 모두 실제 값을 나타낸다.

전형적인 오류는 동등의 연산자를 사용하려는 시도다.=키워드와 결합하여NULLNull이 있는 행을 찾으십시오.SQL 표준에 따르면 이것은 잘못된 구문이며 오류 메시지 또는 예외로 이어질 것이다.그러나 대부분의 구현은 구문을 수용하고 다음과 같은 표현을 평가한다.UNKNOWN그 결과 Null이 있는 행의 존재 여부에 관계없이 행을 찾을 수 없다.Nulls가 있는 행을 검색하는 제안된 방법은 술어를 사용하는 것이다.IS NULL대신에= NULL.

선택 * From 가성 있는 어디에 숫자 = NULL;  - "Where num is NULL"이어야 함 

관련되긴 하지만 더욱 미묘한 예에서는 aWHERE절 또는 조건문은 열의 값을 상수와 비교할 수 있다.필드가 Null을 포함하는 경우 결측값이 상수보다 작거나 같지 않다고 잘못 가정하는 경우가 많지만, 실제로 그러한 표현은 Unknown으로 반환된다.예는 다음과 같다.

선택 * From 가성 있는 어디에 숫자 <> 1;  -- num이 NULL인 행은 반환되지 않는다.                  -- 많은 사용자들의 기대와는 달리. 

이러한 혼란은 SQL의 논리에서 정체성의 법칙이 제한되기 때문에 발생한다.를 사용하여 동등 비교를 처리할 때NULL글자 그대로든 아니든UNKNOWN진실의 가치, SQL은 항상 반환됨UNKNOWN그 표현으로이것은 부분적 동등성 관계로서 SQL을 비반복 논리의 예로 만든다.^[32]

마찬가지로 Nulls도 빈 문자열과 혼동되는 경우가 많다.고려하다LENGTH문자열의 문자 수를 반환하는 함수.Null이 이 함수에 전달되면 함수는 Null을 반환한다.이는 사용자가 3-값 논리에 조예가 깊지 못하면 예상치 못한 결과로 이어질 수 있다.예는 다음과 같다.

선택 * From 가성 있는 어디에 길이(끈을 매다) < 20; -- 문자열이 NULL인 행은 반환되지 않는다. 

이는 일부 데이터베이스 인터페이스 프로그램(또는 오라클과 같은 데이터베이스 구현)에서 NULL은 빈 문자열로 보고되고 빈 문자열은 NULL로 잘못 저장될 수 있다는 사실 때문에 복잡하다.

비평

Null의 ISO SQL 구현은 비판과 논쟁의 대상이며 변화를 요구하는 대상이다.데이터베이스 관리를 위한 관계 모델: 버전 2, Codd는 Null의 SQL 구현에 결함이 있으며 두 개의 뚜렷한 Null 유형 마커로 대체해야 한다고 제안했다.그가 제안한 마커는 각각 "Missing but Applicable"과 "Missing but Ipplicable"을 의미하는 것으로, A-값과 I-값으로 알려져 있다.Codd의 권고는 받아들여진다면 SQL에서 4가지 가치 논리의 구현이 요구되었을 것이다.^[5]다른 사람들은 데이터 값이 "누락"일 수 있는 더 많은 이유를 나타내기 위해 Codd의 권고에 Null-type 마커를 추가하여 SQL의 논리 시스템의 복잡성을 증가시킬 것을 제안했다.다양한 시기에 SQL에서 복수의 사용자 정의 Null 마커를 구현하기 위한 제안도 제시되어 왔다.여러 Null 마커를 지원하는 데 필요한 Null 처리 및 로직 시스템의 복잡성 때문에, 이러한 제안 중 어느 것도 널리 받아들여지지 않았다.

크리스 날짜 및 휴 Darwen, 제3선언의 저자들은 SQLNull구현은 본질 altogether,[33]SQLNull-handling(골재 기능 특히)의 구현의 모순점과 결점의 증거가 없으면 Null이고의 전체 컨셉은아야 하며 결함이 있는 것을 없애야 한다 흠잡을 곳이 제안했다.있다관계 모델에서 제거됨.^[34]저자인 파비안 파스칼과 같은 다른 사람들은 "함수 계산이 결측값을 어떻게 다루어야 하는가는 관계형 모델의 지배를 받지 않는다"^{[citation needed]}는 믿음을 표명했다.

폐쇄계 가정

Nulls와 관련된 또 다른 갈등의 요점은 그들이 관계형 데이터베이스의 폐쇄형 가정 모델을 그것에 도입함으로써 위반한다는 것이다.^[35]데이터베이스에 관련된 폐쇄적인 세계 가정은 "데이터베이스가 명시적이든 암시적이든 진술한 모든 것은 사실이며, 그 밖의 모든 것은 거짓이다"^[36]라고 말한다.이 견해는 데이터베이스 내에 저장된 세계에 대한 지식이 완전하다고 가정한다.그러나, Nulls는 데이터베이스에 저장된 일부 항목을 알 수 없는 것으로 간주되는 오픈 월드 가정 하에서 작동하여, 데이터베이스의 세계에 대한 저장된 지식이 불완전하게 된다.

참고 항목

• SQL
• NULLs in: Wikibook SQL
• 자습서 D
• 3차 논리학
• 데이터 조작 언어
• Codd의 12가지 규칙
• 체크 제약 조건
• 관계 모델/태스매니아
• 관계형 데이터베이스 관리 시스템
• 가입(SQL)
• 제3 선언문

참조

추가 읽기

• E. F. Codd.관계 이해(설치 #7)ACM-SGIMOD FDT 게시판, 7(3-4):23–28, 1975.
• Codd, E. F. (1979). "Extending the database relational model to capture more meaning". ACM Transactions on Database Systems. 4 (4): 397–434. CiteSeerX 10.1.1.508.5701. doi:10.1145/320107.320109. 특히 §2.3.
• Date, C.J. (2000). 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. Addison Wesley Longman. ISBN 978-0-201-61294-3.
• Klein, Hans-Joachim (1994). "How to modify SQL queries in order to guarantee sure answers". ACM SIGMOD Record. 23 (3): 14–20. doi:10.1145/187436.187445.
• Claude Rubinson, Nulls, 3-Value Logic 및 SQL에서의 모호성: Critiquing Date's Critique, SGIMOD Record, 2007년 12월 (Vol. 36, No. 4)
• 존 그랜트, SQL의 Null 값. SGIMOD Record, 2008년 9월 (Vol. 37, No. 3)
• 와라폰, 나롱리트, 크리엥크라이 포카에우."하위 쿼리와 원자 술어에 대한 Null 의미론".IAENG International Journal of Computer Science 35.3 (2008): 305-313.
• Bernhard Thalheim, Klaus-Dieter Schewe (2011). "NULL 'Value' Algebras and Logics". Frontiers in Artificial Intelligence and Applications. 225 (Information Modelling and Knowledge Bases XXII). doi:10.3233/978-1-60750-690-4-354.{{cite journal}}: CS1 maint: 작성자 매개변수 사용(링크)
• 2012년 6월 27~30일 브라질 오로 프레토 데이터 관리 기반에 관한 제6회 Alberto Mendelzon 국제 워크숍의 진행, Enrico Franconi 및 Sergio Tesaris. 페이지 114–128

외부 링크

• 2013-04-12년 Wayback Machine에 보관된 Oracle NULL
• 제3 선언문
• NULL이 데이터 시퀀싱에 미치는 영향
• Sun이 "버그가 아님"으로 닫은 null 문자열과 빈 문자열을 구분하지 않는 jdbc에 대한 Java 버그 보고서