Критика статьи Клода Рубинсона «NULL, трехзначная логика и неопределенность в SQL: критика критики Дейта»

К. Дж. Дейт
Перевод: Сергей Кузнецов

Оригинал: C. J. Date. A Critique of Claude Rubinson’s Paper Nulls, Three - Valued Logic, and Ambiguity in SQL: Critiquing Date’s Critique. SIGMOD Record, Vol. 37, No. 3, September 2008.

См. вступительную заметку Сергея Кузнецова «И снова о вечной проблеме отсутствующей информации»

Я хотел бы поблагодарить Клода Рубинсона за его содержательную критику [3] моих замечаний по поводу неопределенных значений и трехзначной логики (three-valued logic, 3VL), приведенных в [1]. Понятно, что мы единодушны по поводу основных вопросов; как говорит Рубинсон, «я согласен с Дейтом относительно того, что трехзначная логика несовместима с системами управления базами данных». Мы также единодушны в том, что null не является значением; как говорит Рубинсон, «в SQL null определяется не как какое-либо значение, а как некоторый флаг». Однако мне хотелось бы прокомментировать три конкретных вопроса, проистекающих из статьи Рубинсона. Замечание: все дальнейшие цитаты, для которых не указан источник, взяты из этой статьи. Также замечу, что я следую Рубинсону в использовании терминологии SQL (таблицы, столбцы и строки).

Исходный пример

База данных, которую я использовал в качестве основы своих примеров в [1], выглядела следующим образом (S = suppliers (поставщики), P = parts (детали)):

В этой базе для детали P1 «CITY есть null». Более того (как я говорил в [1]):

Заметим для точности, что пустое место на рисунке там, где должно было бы находиться значение CITY для детали P1, означает отсутствие чего бы то ни было; в этой позиции нет вообще ничего, ни строки пробелов, ни пустой строки (а это значит, что «кортеж» детали P1 на самом деле кортежем не является, и я вернусь к этому вопросу позже).

Затем я задаю запрос «получить пары SNO-PNO, для которых города поставщика и детали различны или городом детали не является Париж», и предлагаю следующую «очевидную формулировку этого запроса на языке SQL»:

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

Затем я показываю, что для показанной на рисунке базы данных результат этого SQL-выражения отличается от результата, которого мог бы ожидать пользователь от исходной формулировки запроса (на естественном языке).

Рубинсон говорит:

Проблема (примера Дейта) состоит не в том, что результат SQL не согласуется с реальностью, а в том, что Дейт плохо сформулировал свой исходный запрос… Формулировка на SQL в действительности не соответствует запросу [на естественном языке]; на самом деле, исходный запрос Дейта не может быть должным образом оттранслирован на SQL.

Но об этом я и говорил! Я согласен, что «сформулированный оператор SQL» не соответствует должным образом запросу на естественном языке; конечно, не соответствует, поскольку производит другой результат. В частности, с позволения Рубинсона, я совершенно точно не утверждал, что это положение дел «свидетельствует об ошибке в логике SQL». Логика SQL как таковая безошибочна (по крайней мере, допустим это в нашем обсуждении). Скорее, я утверждал, что «логика SQL отличается от логики, обычно используемой нами» в реальном мире. И это все.

В любом случае (и независимо от того, согласен ли Рубинсон со мной по этому поводу, или мы просто соглашаемся о различии наших точек зрения) я не думаю, что стоит тратить много времени на этот конкретный пример и на другие, ему подобные. Реальный вопрос состоит в том, как мы собираемся интерпретировать таблицы базы данных? И это приводит меня к следующему пункту.

Аспект интерпретации

В [1] я умышленно не разъяснял в деталях, какая интерпретация таблиц S и P имеется в виду. Если бы я это проделал достаточно тщательным образом, то бессмысленность null’ов стала бы абсолютно очевидной (и, помимо прочего, не было бы вообще никакого смысла обсуждать запрос, приведенный в примере). Но беда в том, что доводы, основанные на интерпретации, являются немного заумными, и некоторым читателям могло бы быть несколько трудно их понять; поэтому, правильно это или нет, я приводил доводы, которые, по моему мнению, было проще понять («более доступные» по выражению Рубинсона). Однако теперь позвольте мне привести доводы на основе интерпретации.

Прежде всего, на тот случай, если найдутся читатели, незнакомые с терминологией, позвольте мне объяснить, что:

1. Считается, что каждой таблице t соответствует некоторый предикат pred.
2. Если у таблицы имеется n столбцов, то у предиката pred – n параметров.
3. Каждая строка r таблицы t содержит значения в n столбцах. Считается, что каждая такая строка соответствует некоторому высказыванию prop: а именно, высказыванию, получаемому путем использования значений n столбцов для замены n параметров в pred (каждое такое высказывание является инстанциацией предиката pred).
4. Про каждое высказывание, полученное таким образом, т.е. про каждую инстанциацию предиката pred, мы полагаем или знаем, что оно истинно.

Как кажется, в [3] Рубинсон утверждает, что имеется логическое различие между тем, что (a) что-то является истинным, и (b) мы полагаем что-то истинным, и именно этот различие является основой трудностей в 3VL. Однако, на самом деле, мы должны обращать внимание на это различие даже при отсутствии null’ов и 3VL, хотя на практике, конечно, это часто не делается. Поэтому я полагаю, что здесь этот довод Рубинсона только уводит в сторону от сути вопроса. Более того, как я показываю в [2], даже в базе данных без null’ов и 3VL мы может получать ответы типа «не знаю». Но, возможно, здесь и это не существенно. Позвольте мне вернуться к сути проблемы.

Рассмотрим таблицу P. У этой таблицы два столбца – PNO и CITY, и поэтому у представляющего ее предиката должно быть два параметра. Что это за предикат? Очевидным кандидатом является следующий: деталь PNO хранится в городе CITY. Но нам следует быть более точными. На самом деле, в соответствии с приведенными выше замечаниями, более осмысленным кандидатом является такой предикат: мы знаем, что деталь PNO хранится в городе CITY.

Но допустим теперь, что мы не знаем, где хранится деталь P1. Тогда истинное высказывание вида «мы знаем, что деталь P1 хранится в городе CITY» просто не существует. Просто неверно то, что для какого-то конкретного значения CITY, каким бы оно не было, мы знаем, что деталь P1 хранится в городе CITY. (Замечание: по-видимому, мы знаем, что эта деталь где-то хранится, поскольку все детали где-то хранятся, но высказывание «мы знаем, что деталь P1 где-то хранится» является совершенно другим высказыванием.

Поскольку никакого истинного высказывания в требуемой форме не существует, не существует и соответствующая строка. И поэтому строка для детали P1 не может присутствовать в данной таблице.

Теперь допустим на мгновение, что строка для детали P1 все-таки присутствует в таблице (с null’ом в столбце CITY). Тогда должен иметься и соответствующий предикат. Вероятно, он должен быть следующим:

Должно быть истинным либо то, что (a) мы знаем, что деталь PNO хранится в городе CITY, либо то, что (b) мы не знаем города для детали PNO.

(Замечу, что OR, связывающее части (a) и (b), здесь должно быть исключающим, а не включающим. Мы не можем допустить, чтобы для одной и той же детали город был и известен, и не известен.)

Однако теперь обратим внимание на то, что у части (a) этого предиката имеются два параметра (PNO и CITY), а у части (b) – только один параметр (PNO). Следовательно, строки, представляющие истинную инстанциацию части (a), имеют два столбца, а строки, представляющие истинную инстанциацию части (b), – только один столбец. И эти два вида строк с логической точки зрения не могут присутствовать в одной и той же таблице. Таким образом, говорить о том, что некоторая строка r в некоторой таблице t «содержит null», бессмысленно, или, по крайней мере, логически противоречиво (на самом деле, последняя формулировка лучше)¹.

Возможно, мне следует добавить, что в схеме базы данных, которая точно соответствует ситуации и не вынуждает использовать null’ы, следовало бы иметь две отдельные таблицы: (a) таблицу P со столбцами PNO и CITY и предикатом «мы знаем, что деталь PNO хранится в городе CITY» и (b) таблицу P' с единственным столбцом PNO и предикатом «мы не знаем города для детали PNO».

Нарушают ли null’ы реляционную модель?

Соглашаясь со мной в нежелательности null’ов и 3VL, Рубинсон говорит, что «не убежден в том, что трехзначная логика нарушает реляционную модель». Но она действительно ее нарушает! Доводы предыдущего раздела, равно как и другие, которые здесь не используются, явным образом показывают, что таблица, «содержащая null’ы», не соответствует отношению в смысле реляционной модели, поскольку не удовлетворяет тому базовому реляционному требованию, что в каждой строке таблицы имеется значение для каждого столбца. Следовательно, фундаментальный объект в системе, поддерживающей null’ы, не является реляционной таблицей (я не знаю, чем она на самом деле является, но точно не реляционной таблицей). Повторю то, что говорится в [1] (и здесь я возвращаюсь к реляционной терминологии):

• «Тип», содержащий null, не является типом (поскольку типы содержат значения).


• «Кортеж», содержащий null, не является кортежем (поскольку кортежи содержат значения).


• «Отношение», содержащее null, не является отношением (поскольку отношения содержат кортежи, а кортежи не содержат null’ы).

Подводя итог, надеюсь, что эта краткая заметка послужит поддержкой моего утверждения в [1] о том, что при наличии null’ов нельзя говорить о реляционной модели. Другими словами, я остаюсь при той своей позиции, что null’ы (и 3VL) и реляционная модель взаимно несовместимы.

Литература

1. C. J. Date: Database in Depth: Relational Theory for Practitioners. Sebastopol, Calif.: O’Reilly Media, Inc. (2005).

2. C. J. Date: “The Closed World Assumption,” in Logic and Databases: The Roots of Relational Theory. Victoria, BC: Trafford Publishing (2007). See www.trafford.com/07-0690.

3. Claude Rubinson: “Nulls, Three-Valued Logic, and Ambiguity in SQL: Critiquing Date’s Critique,” ACM SIGMOD Record 36, No. 4, December 2007. См. также перевод: Клод Рубинсон. NULL, трехзначная логика и неопределенность в SQL: критика критики Дейта.

---

¹ Кстати, обратите внимание на последствия этого утверждения для внешнего соединения.