Проблема представления в базах данных отсутствующей (missing) информации настолько же стара, как и сами базы данных. Решение, которое принято в SQL, обладает массой недостатков, которые описаны в разнообразных источниках, в том числе, в многочисленных статьях Криса Дейта и его сподвижников. В свое время к этому анализу приложил свою руку и я. Здесь стоит лишь дополнительно заметить, что ситуация с трехзначной логикой в SQL, на мой взгляд, еще более ухудшилась после введения в стандарте SQL:1999 «булевского» типа данных, в котором NULL является третьим истинностным значением (сохраняя при этом смысл обозначения неопределенного значения).

Поэтому трудно предполагать, как это делает Клод Рубинсон в своей заметке «NULL, трехзначная логика и неопределенность в SQL: критика критики Дейта», что Дейт плохо понимает смысл трехзначной логики SQL. Скорее Рубинсон плохо понимает Дейта. Фактически, в своих последних критических замечаниях по поводу неопределенных значений и трехзначной логики в SQL Дейт приводит примеры запросов, при формальном вычислении которых в соответствии с прямолинейной трактовкой неопределенных значений получаются результаты, противоречащие смыслу. На мой взгляд, логика Дейта, в отличие от логики SQL, безупречна.

Если NULL используется в каком-то столбце таблицы для обозначения некоторого неизвестного значения, то, конечно, в этом столбце NULL обозначает какое-то значение типа данных этого столбца. Конечно, если сравнивать неизвестные значения одного и того же атрибута двух разных сущностей (одного столбца двух разных строк таблицы), то мы должны получить логическое значение unknown (или опять-таки NULL по странным правилам SQL). Но если сравнивать неизвестное значение некоторого атрибута некоторой сущности с ним же самим, то мы по смыслу получим true, поскольку это не зависит от реального значения атрибута, которое нам неизвестно. Т.е., на самом деле, поскольку NULL – это не значение, а обозначение значения, при сравнении «неопределенных значений» нужно учитывать, откуда они берутся. Обратимся еще раз к примерной базе данных, представленной на рис. 1 заметки Рубинсона:

S	SNO*	CITY	P	PNO*	CITY
	S1	London		P1	NULL

По отношению к своему второму примеру

SELECT P.PNO
FROM P
WHERE P.CITY = P.CITY

Дейт совершенно прав. Результатом этого запроса должно быть значение P1, поскольку так будет при любом допустимом значении столбца CITY. Можно сказать, что этот запрос является надуманным. Но вот немного более осмысленный запрос, который должен привести к тому же результату: «выдать номера всех деталей, располагающихся в том же городе, что и деталь P1». Вот возможная формулировка запроса на SQL:

SELECT P.PNO
FROM PARTS P, PARTS Q 
WHERE P.PNO = P1 AND P.CITY = Q.CITY

Понятно, что, поскольку мы не знаем города, в котором располагается деталь P1, для всех деталей, кроме P1, результат сравнения P.CITY = Q.CITY должен быть равен unknown, и ни одна деталь, кроме детали P1, в результат попасть не должна. Но деталь P1 заведомо всегда находится в том же городе, что она сама, и поэтому результатом запроса должно быть множество из одного значения P1. В соответствии с правилами SQL запрос должен произвести пустой результат, и это неправильно.

Первый пример Дейта

SELECT S.SNO, P.PNO
FROM S, P
WHERE S.CITY <> P.CITY
OR P.CITY <> ‘Paris’

немного более сложен. Но если посмотреть на разъяснение Дейта того, что условие по своему смыслу всегда принимает значение true, то можно заметить, что это, фактически, вытекает из наличия в обоих простых сравнениях имени столбца P.CITY. Т.е. снова мы имеем дело с обозначением неизвестного значения, происходящего из одного и того же места. И снова Дейт прав. Результатом этого запроса должно быть множество, состоящее из пары S1, P1. В SQL не учитывается происхождение неопределенных значений, и в результате выдается пустой результат, формально соответствующий правилам вычисления условий с неопределенными значениями, но противоречащий здравому смыслу. Заметим, что если бы в базе данных и столбец S.CITY содержал бы NULL, то условие действительно вычислялось бы в unknown, и результат должен был бы быть пустым.

Вот более интересный пример. Рассмотрим следующую примерную базу данных:

DEPT	DNO*	NAME	EMP	ENO*	DNO
	D1	NULL		E1	D1
				E2	D1

Предположим, что мы определяем представление

CREATE VIEW DEMP AS
(SELECT *
FROM DEPT, EMP
WHERE DEPT.DNO = EMP.DNO)

Очевидно, что это представление материализуется следующим образом:

DEMP	DNO*	NAME	ENO*
	D1	NULL	E1
	D1	NULL	E2

Тогда можно утверждать, что результатом запроса

SELECT DISTINCT *
FROM DEMP DE1, DEMP DE2
WHERE DE1.NAME = DE2.NAME

должна быть таблица, содержащая обе строки исходной таблицы DEMP, поскольку в обеих строках используется неизвестное имя одного и того же отдела.

В результате мы видим, что критика критики Дейта, приведенная в заметке Рубинсона, является несостоятельной. Нельзя пытаться заменять механистической трактовкой трехзначной логики логику здравого смысла, даже не пытаясь ее понять. Кроме того, как видно, сама трехзначная логика здесь совсем не виновата. Виновато неправильное понимание обозначения NULL. И здесь, как мне кажется, не совсем прав уже Дейт. По-моему, можно понять, в каких случаях неправильно работают SQL-запросы к базам данных, содержащим NULL в качестве обозначения неизвестных значений. Так происходит тогда (не берусь утверждать, что только тогда), когда известно, что сравнивается неизвестное значение одного и того же атрибута одной и той же сущности, т.е. NULL происходит из одного столбца одной и той же таблицы. Похоже, что соответствующую коррекцию поведения запросов можно было бы возложить на компиляторы SQL.

Другой вопрос, что NULL в языке SQL служит не только для обозначения неизвестных значений, но также и для выражения неприменимости атрибута к конкретному экземпляру сущности и т.д. Очевидно, что правила трехзначной логики, поддерживаемые в SQL, недостаточны для корректной формулировки запросов при использовании одного вида неопределенных значений во всех возможных ситуациях. Как и Клод Рубинсон, я воздержусь здесь от обсуждения нетривиальных последствий этого состояния дел.

В заключение замечу, что буду рад любой критике в адрес своей критики критики Рубинсона критики Дейта. Кто знает, может быть, в результате нам удастся совместными усилиями разобраться в том, что же все-таки следует делать с управлением в базах данных отсутствующей информацией.