Всегда приятно дать почитать людям что-нибудь веселенькое. А что может быть веселее попытки критики известного критикана Кристофера Дейта. Поэтому я с удовольствием представляю вашему вниманию пересказ заметки Клода Рубинсона. С другой стороны, я категорически не согласен с основной частью этой заметки и вместо развернутого предисловия к своему пересказу публикую отдельную заметку с критикой критики Рубинсона.
Сергей Кузнецов
Аннотация
Широко известная критика Дейта (C.J. Date) трехзначной логики языка SQL [4, 3] направлена на то, чтобы показать, что SQL-запросы могут приводить к ошибочным результатам, если в базе данных присутствуют неопределенные значения. В данной статье утверждается, что эта критика ошибочна, поскольку Дейт неправильно понимает смысл запросов, используемых в своих примерах. На самом деле, SQL возвращает на эти запросы правильные ответы, просто Дейт полагает, что он задавал другие вопросы. Хотя критика Дейта ошибочна, автор согласен с его общим заключением: использование в SQL неопределенных значений и трехзначной логики исключительно усложняет простые на вид запросы.
1. Введение
Распространенная критика языка SQL состоит в том, что поддержка в языке неопределенных значений разрушает реляционную модель. Дейт приводит ряд доводов в пользу этой позиции. Наиболее фундаментальным является тот довод Дейта, что поскольку в SQL NULL определяется не как значение, а как некоторый флаг, означающий отсутствие значения в некотором атрибуте, домены не могут должным образом содержать неопределенные значения, поскольку, по определению, домены являются множествами значений. Следовательно, отношения, включающие неопределенные значения, отношениями, по существу, не являются, что подрывает самые глубинные основы реляционной модели [3]. Дейт также приводит более доступный аргумент, в котором он утверждает, что трехзначная логика, вытекающая из наличия неопределенных значений, может приводить к появлению абсурдных результатов. В этой заметке критикуется этот второй аргумент и демонстрируется, что Дейт неправильно использует трехзначную логику SQL. Поэтому критика Дейта является логически ошибочной и в действительности не может служить обвинением в адрес SQL, как это полагает Дейт. Однако следует заметить, что эта критика критики Дейта не направлена на защиту неопределенных значений или трехзначной логики в SQL. Скорее она призвана подчеркнуть, что трехзначная логика действительно может сбивать людей с толку. Использование неопределенных значений меняет смысл простых на вид запросов и, по всей вероятности, может приводить к многочисленным ошибкам, которые зачастую могут не опознаваться.
2. Критика Дейта
В наиболее известных критических замечаниях Дейта используется простая табличная база данных, проиллюстрированная на рис. 1. Она состоит из двух таблиц. В таблице Suppliers (S, «поставщики») имеются два столбца: номер поставщика (SNO, первичный ключ) и город, в котором располагается поставщик (CITY). В таблице Parts (P, «детали») также имеются два столбца: номер детали (PNO, первичный ключ) и город, в котором располагается данная деталь (CITY). В примере на рис. 1 каждая из таблиц содержит по одной записи. Поставщик S1 располагается в Лондоне, а город, в котором располагается деталь, неизвестен P1.
Неопределенные значения часто вносят путаницу, когда неизвестны причины отсутствия информации в базе данных. К наиболее распространенным причинам неполноты данных является (временная) неизвестность значения некоторого атрибута и неприменимость данного атрибута к представляемой в базе данных сущности. Из обсуждения Дейта базы данных, представленной на рис. 1, очевидно следует, что NULL в таблице P означает (временную) неизвестность города, ассоциированного с деталью P1. В заключительном разделе данной заметки обсуждаются дополнительные сложности, вытекающие из неоднозначности смысла неопределенных значений.
| S |
SNO* |
CITY |
P |
PNO* |
CITY |
| |
S1 |
London |
|
P1 |
NULL |
Рис. 1. SQL-ориентированная база данных
В [4, стр. 54] Дейт стремится показать, что использование в SQL трехзначной логики приводит к получению ошибочных результатов:
Главным образом, я хочу показать, что некоторые булевские выражения – и, следовательно, некоторые запросы – приводят к получению результатов, корректным в соответствии с трехзначной логикой, но не корректным с точки зрения реального мира.
Для этого он формулирует на SQL следующий запрос: «Выдать пары SNO-PNO, для которых либо поставщик и деталь располагаются в разных городах, либо город, в котором располагается деталь, не является Парижем (или выполняются оба эти условия)» [4, стр. 54], получая следующий текст:
SELECT S.SNO, P.PNO
FROM S, P
WHERE S.CITY <> P.CITY
OR P.CITY <> ‘Paris’
После подстановки данных из примерной базы данных условие S.CITY <> P.CITY OR P.CITY <> ‘Paris’ принимает вид (‘London’ <> NULL) OR (NULL <> ‘Paris’), при вычислении которого в соответствии с правилами трехзначной логики SQL получается NULL. Следовательно, в ответ на этот запрос не возвращается ни одного кортежа.
В [4, стр. 55] Дейт утверждает, что этот результат демонстрирует ошибку в трехзначной логике SQL, аргументируя это следующим образом:
Но, конечно, в реальном мире детали P1 в действительности соответствует некоторый город; другими словами, «неопределенное значение атрибута CITY» детали P1 на самом деле обозначает некоторое реальное значение, скажем xyz. Очевидно, что xyz либо равняется значению ‘Paris’, либо не равняется этому значению.
Затем Дейт демонстрирует, что условное выражение раздела WHERE будет всегда вычисляться в TRUE независимо от того, где располагается деталь P1. По существу, имеются три возможности: город xyz является Парижем, Лондоном или еще каким-нибудь городом. Если город xyz является Парижем, то выражение раздела WHERE принимает вид (‘London’ <> ‘Paris’) OR (‘Paris’ <> ‘Paris’). Это выражение приводится к (TRUE OR FALSE), что, в свою очередь, вычисляется в TRUE. Если город xyz является Лондоном, то выражение раздела WHERE принимает вид (‘London’ <> ‘London’) OR (‘London’ <> ‘Paris’), это выражение приводится к (FALSE OR TRUE), что вычисляется в TRUE. Если город xyz является каким-либо другим городом, например, Нью-Йорком, то выражение раздела WHERE принимает вид (‘London’ <> ‘Нью-Йорк’) OR (‘Нью-Йорк’ <> ‘Paris’). Это выражение приводится к (TRUE OR TRUE), что опять-таки вычисляется в TRUE.
В соответствии с Дейтом, если бы в SQL правильно принимался во внимание реальный мир – в данном случае тот факт, что деталь ассоциирована с некоторым городом, несмотря на то, что этот факт отсутствует в базе данных, – то в ответ на приведенный выше запрос должна была бы выдаваться пара S1-P1. То, что SQL возвращает пустой результат, свидетельствует об ошибке в его логике: «Другими словами, результат, корректный в соответствии с логикой (т.е. 3VL), отличается от результата, корректного в соответствии с представлениями реального мира».
3. Критика критики
Но Дейт ошибается. Проблема состоит не в том, согласуются ли с реальностью результаты SQL, а в том, что Дейт неудачно формулирует свой исходный запрос «Выдать пары SNO-PNO, для которых либо поставщик и деталь располагаются в разных городах, либо город, в котором располагается деталь, не является Парижем (или выполняются оба эти условия)». Формулировка на SQL на самом деле не соответствует этому запросу. В действительности, запрос Дейта не может быть правильно транслирован на SQL, поскольку он предполагает наличие традиционной двухзначной логики, а SQL имеет дело с трехзначной логикой.
В традиционной логике высказывания бывают истинными или ложными. Т.е. деталь P1 располагается в Париже или не располагается. В трехзначной логике, используемой в SQL, высказывания бывают истинными, ложными или неизвестными (unknown). После появления возможности неизвестных высказываний деталь P1 не обязана располагаться или не располагаться в Париже. Теперь мы можем знать, что деталь P1 располагается в Париже, что деталь P1 не располагается в Париже, а можем не знать, где располагается деталь P1.
Запросы необходимо формулировать в соответствии с требованиями используемой в языке запросов логической системы. В традиционной двухзначной логической системе должна иметься возможность классификации утверждений на «истинные» и «ложные». При использовании трехзначной логической системы должны также допускаться «неизвестные» утверждения. В исходном запросе Дейта подразумевается двухзначная логика. Рассмотрим первую часть запроса: «Выдать пары SNO-PNO, для которых … поставщик и деталь располагаются в разных городах». В этом запросе подразумевается, что города, в которых располагается поставщик и деталь, либо различны, либо совпадают. Но в трехзначной логической системе SQL города поставщика и детали могут совпадать, могут не совпадать, а может быть просто неизвестно, различны они или совпадают. Аналогично обстоит дело со второй частью запроса: ««Выдать пары SNO-PNO, для которых … город, в котором располагается деталь, не является Парижем». И в этом запросе подразумевается, что город, в котором располагается деталь, либо является, либо не является Парижем. Однако в контексте SQL этот город может быть Парижем, может не быть Парижем, а может быть просто неизвестен. И в действительности неопределенное значение в базе данных показывает, что мы не знаем, с каким городом ассоциирована деталь P1.
Дейт утверждает, что «в реальном мире» город, в котором располагается деталь P1, либо является, либо не является Парижем. Конечно, это верно. Но также верно и то, что «в реальном мире» мы можем не знать, какой город ассоциирован с деталью P1. Это два разных высказывания. Города, которым соответствуют детали, представляют собой множество фактов, которое существует независимо от того, знаем ли мы, какие города соответствует каким фактам. В SQL запросы всегда подразумевают знание подобной взаимосвязи, а не просто ее существование. Поэтому исходный запрос Дейта можно переформулировать следующим образом: «Выдать пары SNO-PNO, для которых известно, что либо поставщик и деталь располагаются в разных городах, либо город, в котором располагается деталь, не является Парижем (или выполняются оба эти условия)». Теперь результаты SQL-запроса имеют смысл. Возвращается пустой результат, поскольку, хотя детали P1 «в реальном мире в действительности соответствует некоторый город», неизвестно, какому городу соответствует данная деталь.
Это понимание различий между двухзначной и трехзначной логикой становится более отчетливым после анализа второго примера Дейта. Дейт [4, стр. 55] демонстрирует следующий оператор SQL:
SELECT P.PNO
FROM P
WHERE P.CITY = P.CITY
и утверждает, что «в реальном мире результатом этого запроса, очевидно, являлось бы все множество номеров деталей, содержащихся в P». Но, на самом деле, очевидно то, что Дейт считает приведенный SQL-запрос функционально эквивалентным следующему: «Выдать номера PNO для деталей, ассоциированных с городами». На основании того, что «в реальном мире» каждая деталь должна ассоциироваться с некоторым городом, Дейт заключает, что этот запрос должен полное множество номеров деталей. Но Дейт снова неправильно читает запрос. Поскольку в SQL используется трехзначная логика, этот оператор SQL выражает совсем другой запрос: «Выдать номера PNO для деталей, про которые известно, что они ассоциированы с городами». И SQL совершенно справедливо возвращает пустой результат, поскольку, как показывает таблица P, мы не знаем, с каким городом ассоциирована деталь P1.
В [4, стр. 55] Дейт утверждает, что его примеры демонстрируют полную несостоятельность SQL:
Подводя итоги, следует заметить, что если в вашей базе имеются неопределенные значения, вы будет получать на некоторые запросы неправильные ответы. Хуже того, нет никакого способа узнать, какие запросы будут выдавать неправильные результаты; все результаты становятся подозрительными. Никогда нельзя доверять ответам, которые получаются из базы данных с неопределенными значениями. По моему мнению, это состояние дел свидетельствует о невозможности использования SQL. (Курсив К. Дж. Дейта.)
Как полагает автор данной заметки, Дейту не удалось продемонстрировать несостоятельность SQL. Для сформулированных Дейтом запросов SQL возвращает корректные ответы, но не те, на которые он рассчитывал. Эта путаница вполне объяснима. Трехзначная логика SQL не является интуитивной. При использовании двухзначной логики высказывания могут быть истинными или ложными. Но в трехзначной логике возможны еще и неизвестные высказывания. При работе с SQL-ориентированными базами обязательно требуется корректная формулировка запросов; в противном случае имеется риск совершения ошибок, подобных тем, которые делает Дейт.
4. Обсуждение
Использование в SQL трехзначной логики и маркера неопределенных значений приводит к требованию учета при формулировке запросов возможности того, что связи между сущностями являются неизвестными. Если это сделать не удается, возникает риск формулировки не того вопроса, который предполагался. Нужно помнить, что логика SQL не является интуитивной. Редко удается прямо отобразить в SQL вопросы, используемые людьми при обычном общении. Нельзя просто спросить про «пары SNO-PNO, для которых города поставщика и детали не совпадают», а требуется задавать вопрос относительно «пары SNO-PNO, для которых известно, что города поставщика и детали не совпадают». Еще более важно то, что нужно понимать, в чем состоит различие этих формулировок.
Проблема усугубляется тем фактом, что информация может отсутствовать в базе данных по ряду разных причин. В [1] Дейт указывает семь распространенных причин неполноты данных: значение не применимо, значение неизвестно, значение не существует, значение не определено, значение не достоверно, значение не предоставлено и значением является пустое множество. Если значение может отсутствовать, например, из-за неприменимости некоторого атрибута, запросы должны формулироваться и интерпретироваться с учетом потенциального обстоятельства. Если маркеры неопределенных значений нагружаются разным смыслом, построение запросов быстро становится очень сложной задачей: «выдать пары SNO-PNO, для которых атрибут города детали является применимым, и для которых известно, что поставщик и деталь располагаются в разных городах, или городом детали не является Париж» (или выполняются все три условия). Для решения этой проблемы некоторые практики выступают в пользу описательных истинностных значений [5, 7]. Эти решения, основывающиеся на реальных значениях, а не на маркерах неопределенных значений, позволяют проектировать базы данных без неопределенных значений, запросы к которым могут основываться на традиционной двухзначной логике.
Полезно также заметить, что любой запрос, опирающийся на трехзначную логику, можно декомпозировать в два связанных запроса, опирающихся на двухзначную логику. Например, как обсуждалось выше, запрос «выдать пары SNO-PNO, для которых известно, что городом детали не является Париж» предполагает использование трехзначной логики, поскольку город, в котором располагается деталь, может быть Парижем, может быть не Парижем, а может быть не известен. Этот запрос может быть декомпозирован в составной запрос «выдать пары SNO-PNO, для которых известен город, в котором располагается деталь, и выдать из результирующего множества пары SNO-PNO, для которых городом детали не является Париж». Выполнение такой декомпозиции часто оказывается полезным, особенно при построении сложных запросов.
В конечном счете, автор заметки согласен с Дейтом в том, что трехзначная логика не сочетается с системами управления базами данных. Хотя он не убежден в том, что трехзначная логика нарушает реляционную модель по существу, он согласен с Макговераном (McGoveran) [6, стр. 355] в том, что переход к использованию многозначной логики вынуждает проектировщиков, разработчиков и пользователей баз данных осваивать совершенно новый способ мышления. Трудно оценить практически требуемые затраты, но, конечно, потребность в них противоречит целям, для достижения которых существуют SQL-ориентированные СУБД.
То, что сам Дейт неправильно понимает смысл своих SQL-запросов, подчеркивает серьезность этой проблемы.
5. Заключение
Базы данных разрабатываются для организации и лучшего понимания информации. Проблема состоит в том, что мир сложен. Одним из проявлений этой сложности является то, что иногда отсутствует полная информация. Автор согласен с теми людьми, которые считают, что практикам SQL следует избегать неопределенных значений везде, где это возможно. По умолчанию, проектировщики баз данных должны запрещать наличие в столбцах неопределенных значений. По мере возможности, следует избегать использования операций, таких как внешние соединения, производящих неопределенные значения, в особенности при определении представлений и подзапросов. Поскольку по определению появление неопределенных значений свидетельствует о наличии исключительных обстоятельств, присутствие в таблицах базы данных столбцов, допускающих неопределенные значения, часто означает, что конструкцию базы данных можно было бы усовершенствовать.
Использование в SQL неопределенных значений – это не самая важная проблема, с которой приходится сталкиваться при наличии базы данных, показанной на рис. 1. Скорее проблема звучит так: «Где же эта чертова деталь P1?». Если деталь P1 везут в Париж, эту информацию требуется сохранить в базе данных. Если деталь P1 потеряется, нужно уметь отразить в базе данных и эту информацию. В частности, включение такой информации в базу данных повышает ценность базы данных и способствует поддержанию ее целостности за счет наличия возможности удалять из нее проблематичных записей.
Применение должных методов проектирования позволяет естественным образом минимизировать число неопределенных значений в базе данных. Схема базы данных – это модель конкретной предметной области и ее можно точно построить только на основе полного обследования этой предметной области – описания ее границ, определения входящих в нее компонентов, выяснения их взаимосвязей. Конечно, целью проектирования базы данных является достижение представления не идеального предметной области, а лишь тех ее аспектов, которые наиболее существенны для конкретной проблемы. Если деталь P1 находится в грузовике, движущемся в сторону Парижа, то ожидаемое время его прибытия, вероятно, является существенным, а то, что водитель грузовика недавно поссорился с женой, скорее всего, не существенно. Неопределенные значения позволяют упрощать модели за счет приведения к общей форме всех аномалий, порождающих отсутствующие данные и неизвестные связи. Но ценой этого упрощенного представления является трехзначная логика и соответствующее увеличение сложности запросов.
Редко удается гарантировать полное отсутствие неопределенных значений в базе данных. Даже если бы удалось убедить компании-производители СУБД выступить против неопределенных значений и трехзначной логики, мы остались бы обременены этим наследством в обозримом будущем. И поскольку присутствие единственного неопределенного значения влияет на всю базу данных [6], в общем случае необходимо подразумевать наличие трехзначной логики. Поэтому требуется тщательно проверять запросы, чтобы быть уверенными, что они означают в точности то, что предполагалось.
Литература
[1] C. J. Date. Not is not ‘not’! (notes on three-valued logic and related matters). In Relational Database Writings, 1985–1989. Addison Wesley, 1990.
[2] C. J. Date. Relational Database Writings, 1994–1997. Addison Wesley Longman, 1998.
[3] C. J. Date. An Introduction to Database Systems. Addison Wesley Longman, Reading, MA, seventh edition, 2000.
[4] C.J. Date. Database in Depth: Relational Theory for Practitioners. O’Reilly, Sebastopol, CA, 2005.
[5] G. H. Gessert. Handling missing data by using stored truth values. SIGMOD Record, 20(3):30–42, Summer 1991.
[6] David McGoveran. Nothing from nothing (part 2 of 4) classical logic: Nothing compares 2 u. In Relational Database Writings, 1994–1997 [2], chapter 6, pages 347–365.
[7] David McGoveran. Nothing from nothing (part 4 of 4): It’s in the way that you use it. In Relational Database Writings, 1994–1997 [2], chapter 8, pages 377–394.
