ОРСУБД и стандарт языка SQL

В процессе стандартизации языка баз данных SQL можно выделить, по моему мнению, три основных этапа. Первый этап начался в середине 1980;х гг. и завершился принятием международного стандарта SQL/89, наиболее важным достижением которого явилась языковая спецификация базовых средств запросов и механизмов ссылочной целостности. Результатом второго этапа явилось принятие стандарта SQL/92, в котором были полностью специфицированы средства определения и эволюции схемы базы данных, поддержки ссылочной целостности, манипулирования данными, связывания SQL с языками программирования и ряд других возможностей, позволяющих использовать стандарт SQL для реализации полнофункциональной РСУБД.

С точки зрения основной темы данной статьи для нас основной интерес представляет третий этап, важным промежуточным финишем которого явилось появление стандарта SQL:1999, развитого и уточненного в стандарте SQL:2003. Сейчас (в феврале 2007 г.) трудно сказать, закончился ли этот этап и происходит ли новый этап, связанный с интеграцией в SQL средств управления XML-данными. Ответ на этот вопрос можно будет дать только после принятия следующего стандарта.

В этой статье в стандартах SQL:1999 и SQL:2003 (на которые далее я буду обобщенно ссылаться, как настандарт SQL) меня, главным образом, интересуют система типов SQL, возможности определения типов пользователями и средства определения и использования так называемых типизированных таблиц (typed tables), составляющие, по мнению разработчиков стандарта, объектную модель SQL.

SQL как модель данных.

Конечно, любой вариант стандарта языка SQL можно было трактовать как определение модели данных в соответствии с критериями Эдгара Кодда. Для полноты картины напомню, что по Кодду модель данных представляет собой некий абстрактный эталон, которому должны соответствовать все реализации, претендующие на соответствие общей модели. В спецификации модели данных Кодд выделял структурную, целостную и манипуляционную составляющие, определяющие, соответственно:

• · структуры данных, которые могут существовать в базах данных, отвечающих модели;
• · базовые ограничения целостности, определение и поддержка которых должны обеспечиваться в системах баз данных, поддерживающих эту модель;
• · средства манипулирования данными, задающие критерий выразительной мощности любого конкретного языка баз данных, который может поддерживаться в соответствующих СУБД.

Для реляционной модели данных в структурной части модели говорится, что единственной «родовой» структурой данных является n-арное отношение, атрибуты которого содержат атомарные значения. В целостной части требуется поддержка целостности сущности (наличие у любого отношения хотя бы одного возможного ключа) и целостности ссылок (недопущение внешних ключей, содержащих не неопределенное значение, для которого отсутствует совпадающее с ним значение возможного ключа в отношении, в которое ведет ссылка). Наконец, в манипуляционной составляющей реляционной модели данных специфицировались эквивалентные механизмы реляционной алгебры и реляционного исчисления.

Достаточно очевидно, что:

• · любой из перечисленных выше стандартов языка SQL определяет некоторую модель данных;
• · с появлением каждого следующего варианта стандарта языка SQL соответствующая модель данных дополняется и уточняется;
• · наконец (и это самое важное!), модель данных, определяемая языком SQL, никогда (!) не была и не является реляционной.

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

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

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

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

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