Классика баз данных - статьи
На самом деле, отказ от
На самом деле, отказ от полного запрета дублирующих
строк вызывает очень далеко идущие последствия.
Например, по этой причине пришлось переопределить семантику
теоретико-множественных операций над таблицами. В SQL имеются
операции UNION ALL (расширенное объединение), INTERSECT ALL
(расширенное пересечение) и EXCEPT ALL (расширенное вычитание),
выполнение которых не уничтожает строки-дубликаты в результате.
Если такая операция выполняется над таблицами T1 и T2, и
некоторый кортеж C входит в обе таблицы, причем содержит n
дубликатов в таблице T1 и m дубликатов в таблице T2, то в
результате операции T1 UNION ALL T2 будет содержаться n+m
дубликатов C, в результате операции T1 INTERSECT ALL T2 -
min(n, m) дубликатов С, а в результате T1 EXCEPT ALL T2 - max((n-m), 0)
дубликатов C. Похоже, что такая трактовка
"теоретико-мультимножественных" операций введена исключительно
для определенности и не подкрепляется какими-либо здравыми
доводами.
Но это, конечно, далеко не все последствия, которые вызвал отказ
от запрета дубликатов.
Возможные и первичные ключи
Когда читаешь описание языка SQL (например, стандарт SQL/92),
как-то не сразу обращаешь внимание, что при определении схемы
таблицы (оператор CREATE TABLE) разделы PRIMARY KEY и UNIQUE
являются необязательными. Зато сразу бросается в глаза
определение таблицы, в которой не задан первичный ключ. Лично я
впервые в своей практике столкнулся с такими таблицами в
демонстрационной базе данных pubs, поставляемой вместе с
Microsoft SQL Server. В этих таблицах, естественно, нет
дубликатов, и немного позже мы обсудим реальные причины того, что
в них не существует ни одного возможного ключа. Но сам факт
наличия подобных таблиц заставил меня по-новому оценить
необязательность разделов PRIMARY KEY и UNIQUE в определении
таблицы.
На самом деле, как мы увидим ниже, компания Microsoft могла
немного по-другому спроектировать схему базы данных pubs,
добившись того, чтобы у каждой таблицы существовал хотя бы один
