Классика баз данных - статьи
Дейт совершенно прав. Результатом этого
| 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, и результат должен был бы быть пустым.
