В наиболее известных критических замечаниях Дейта используется простая табличная база данных, проиллюстрированная на рис. 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-ориентированная база данных
В [, стр. 54] Дейт стремится показать, что использование в SQL трехзначной логики приводит к получению ошибочных результатов:
Главным образом, я хочу показать, что некоторые булевские выражения – и, следовательно, некоторые запросы – приводят к получению результатов, корректным в соответствии с трехзначной логикой, но не корректным с точки зрения реального мира.
Для этого он формулирует на SQL следующий запрос: «Выдать пары SNO-PNO, для которых либо поставщик и деталь располагаются в разных городах, либо город, в котором располагается деталь, не является Парижем (или выполняются оба эти условия)» [, стр. 54], получая следующий текст:
SELECT S.SNO, P.PNO FROM S, P WHERE S.CITY <> P.CITY OR P.CITY <> ‘Paris’