Классика баз данных - статьи
возможный ключ. Более того, можно
возможный ключ. Более того, можно было бы потребовать
использовать только такие базовые таблицы, у которых возможный
ключ существует. Но все дело в том, что это противоречило бы
принципам ортогональности компонентов языка SQL. В описании языка
утверждается, что базовые таблицы, динамически создаваемые
таблицы (хранимые таблицы, порождаемые при выполнении оператора
выборки) и представляемые таблицы (таблицы, материализуемые
только при выполнении адресованного к ним оператора языка SQL)
могут использоваться равноправно. Даже если мы потребуем, чтобы в
таблицах, входящих в основную схему базы данных, отсутствовали
дубликаты, а тем самым существовал хотя бы один возможный ключ,
мы никогда не сможем гарантировать отсутствие дубликатов (а
следовательно, наличие возможного ключа) в порождаемых (хранимых
и представляемых) таблицах. Поскольку все виды таблиц
равноправны, неразумно требовать наличия возможного ключа у
базовых таблиц. Все это звучит логично, и в некоторой степени
оправдывает необязательность разделов PRIMARY KEY и UNIQUE.
Но с другой стороны, возможность существования таблицы без
первичного ключа в достаточной степени противоречит здравому
смыслу. Базы данных существуют для хранения информации о реально
существующих или воображаемых объектах окружающей
действительности. В классическом реляционном подходе принято
считать, что каждый кортеж каждого отношения описывает свойства,
присущие некоторой сущности реального мира. В реальном мире не
бывает двух полностью одинаковых объектов, поэтому и любые два
кортежа любого отношения должны различаться. Как мы уже видели,
из этого следует существование возможного (и первичного) ключа.
Можно взглянуть на это и с другой точки зрения. Первичный ключ
является своего рода адресом кортежа отношения. Используя
соответствующее значение (может быть, составное) мы можем сказать
системе управления базами данных, информация о каком объекте нас
интересует. Конечно, все эти здравые соображения становятся
