Классика баз данных - статьи

       

в таблицах могут определяться первичный


Говорилось, что в таблицах могут определяться первичный и возможный ключи, и в этом случае СУБД должна поддерживать уникальность их значений. Некоторым образом требовалась поддержка ссылочной целостности. Наконец, в качестве «абстрактного» механизма манипулирования данными выступали средства самого языка SQL.

С другой стороны, только в стандарте SQL/92 были явно введены конструкции определения базовых таблиц, а тем самым, и возможности определения первичных и возможных ключей. Только в стандарте SQL:1999 был специфицирован полный набор параметризуемых, генерируемых и определяемых пользователями типов данных, значения которых могут присутствовать в столбцах таблиц SQL-ориентированных баз данных. По мере развития стандарта расширялись и уточнялись средства поддержки ссылочной целостности и манипулирования данными и т.д.

Наконец, начиная с SQL/89, определение хотя бы одного возможного ключа в таблице было необязательным, так что в таких таблицах могли присутствовать строки-дубликаты, они не являлись множествами строк; следовательно, они не были аналогами отношений реляционной модели данных. В заголовках таблиц присутствовал неявный порядок имен столбцов, следовательно, они не являлись аналогами заголовков отношений реляционной модели данных. В столбцах таблиц, наряду с типизированными значениями, могли храниться нетипизированные неопределенные значения, вызывающие необходимость в использовании трехзначной логики и приводящие к иногда парадоксальным ситуациям [17].

Трактовка стандарта SQL как спецификации некоторой особой модели данных (модели данных SQL) стала действительно актуальной после появления стандарта SQL:1999. До этого достаточно было говорить, что язык SQL во многом следует реляционной модели данных, но с некоторыми отклонениями, которые следует иметь в виду. Однако появление «объектных расширений» в SQL:1999 («объектность» этих расширений мы обсудим в следующем подразделе), в особенности, полной системы типов, во-первых, делает законченной собственную модель SQL, во-вторых, еще больше отдаляет модель SQL от классической реляционной модели данных Кодда и, в третьих, создает потребность в сопоставлении модели SQL с объектной моделью ODMG [15] и «истинно реляционной» моделью Кристофера Дейта и Хью Дарвена [18]*.

Понимание отличий модели данных SQL от реляционной модели данных очень важно для проектировщиков, администраторов и разработчиков приложений SQL-ориентированных баз данных. Похоже, что сегодняшняя модель данных SQL включает классическую реляционную модель данных [16], хотя расходится в части механизма типов данных с «истинно реляционной» моделью [18]. Очевидным преимуществом классической реляционной модели данных является ее собственная простота и следующая из нее простота баз данных и их приложений. Поэтому при использовании SQL нужно явно отдавать себе отчет в реальной потребности использования возможностей, выходящих за пределы классической реляционной модели данных.


Содержание  Назад  Вперед