Главная » SQL, Базы данных » ПРЕИМУЩЕСТВА ПОДЛИННОГО СБЛИЖЕНИЯ ТЕХНОЛОГИЙ

0

В [26.41] Стоунбрейкер (Stonebraker) представил матрицу классификации для СУБД (рис. 26.4). Квадрант 1 этой матрицы представляет приложения, в которых применяются только относительно простые данные и не предъявляются  требования по выполнению произвольных  запросов  (хорошим  примером  подобного  приложения  может  служить обычный текстовой процессор). Такие  приложения в действительности вообще нельзя назвать приложениями базы данных в обычном смысле этого термина; так сказать,

Рис. 26.4. Матрица классификации СУБД, предложенная Стоунбрейкером

"СУБД", которая наилучшим образом обслуживает их потребности, представляет собой просто встроенный диспетчер файлов, предоставляемый в составе базовой операционной системы.

В квадранте 2 представлены приложения, в которых предъявляются  требования по выполнению произвольных запросов, но используются все еще  относительно простые данные. В этот квадрант попадает большинство современных производственных приложений, и эти приложения вполне успешно поддерживаются традиционными реляционными СУБД (или, по крайней мере, системами SQL).

В квадранте 3 представлены приложения, в которых требуются сложные  данные и алгоритмы обработки, но нет необходимости в использовании произвольных запросов. Например, к этому квадранту могут относиться приложения систем автоматизированного проектирования и производства. Современные объектные СУБД в основном предназначены для использования в  этом сегменте рынка (традиционные программные продукты

SQL, как правило, плохо подходят для приложений, которые относятся к квадранту 3).

Наконец, в квадранте 4 представлены приложения, для которых требуются одновременно и сложные данные, и произвольные запросы к этим данным. Стоунбрейкер приводит пример базы данных, содержащей оцифрованные  35-миллиметровые слайды, в которой типичный запрос выглядит так: "Найти снимки солнечных закатов, полученные в 20 милях от Сакраменто, штат Калифорния". Затем он приводит доводы в поддержку

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

В конечном итоге Стоунбрейкер утверждает (с чем автор полностью  согласен),  что "объектно-реляционные  системы  в  будущем  затронут  буквально  каждого"; их  нельзя рассматривать просто как модное увлечение, которое вскоре  сменится какой-то другой темой, овладевшей на время вниманием публики. Но автор должен напомнить, что если дело касается специалистов в области баз данных, то настоящая объектно-реляционная система — это не больше и не меньше, чем настоящая реляционная система. В частности, это — такая система, в которой нет следов ни одного из двух серьезных заблуждений! По-видимому, Стоунбрейкер не полностью соглашается с изложенной здесь позицией автора; по крайней мере, в [26.41] не выражена явно ее поддержка и фактически из

сказанного в этой работе следует, что смешивание указателей и отношений не только приемлемо, но и желательно (и, в действительности, якобы даже требуется).

Как бы то ни было, автор настоящей книги утверждает, что подлинная  объектнореляционная система позволит решить все те проблемы, которые (как было указано в предыдущей главе) на самом деле возникают из-за недостатков  таких систем, которые

являются лишь чисто объектными системами, а не объектно-реляционными. Для уточнения этой позиции отметим, что такая система должна обладать способностью поддерживать все описанные ниже требования без особых сложностей.

■     Произвольные запросы, определения представлений и декларативные ограниче ния целостности.

■     Методы, которые охватывают целые классы (т.е. не требуют различимых целевых фактических параметров).

■     Динамически определяемые классы (для результатов произвольных запросов).

■     Двухрежимный доступ (см. главу 4; эта мысль в главе 25 не подчеркивалась, но объектные системы обычно не поддерживают принцип двухрежимности — вместо этого в них используются разные языки для программируемого и интерактивного доступа к базе данных).

■     Переходные ограничения.

■     Семантическая оптимизация.

■     Связи со степенью больше двух.

■     Правила внешних ключей (ON DELETE CASCADE И Т.Д.).

■     Оптимизируемость.

•I

Можно также назвать и другие требования. Кроме того, можно привести изложенные ниже соображения в пользу позиции автора.

■     Идентификаторы объектов и цепочки указателей теперь полностью "включены в реализацию" и скрыты от пользователя.

■     Устраняются "сложные" объектные проблемы (например, не приходится искать ответ на вопрос о том, что подразумевается под соединением двух объектов).

Преимущества инкапсуляции как таковые все еще сохраняются, но распростра]     няются на скалярные значения в отношениях, а не на сами отношения.

■     Как было указано выше, реляционные системы теперь способны поддерживать такие "сложные" прикладные области, как системы автоматизированного проек тирования и производства.

Кроме того, предлагаемый подход полностью обоснован теоретически.

26.3.СРЕДСТВА SQL

Наиболее очевидные и существенные различия между спецификацией SQL: 1999 и предшествующей ей спецификацией SQL: 1992 заключаются в том, что в новой спецификации рассматриваются объектно-реляционные средства. Многие из этих средств, которые кратко перечислены ниже, были уже описаны и  проанализированы в предыдущих главах.

■    В главе 5 было показано, что язык SQL поддерживает две разные категории опре деляемых пользователем типов, типы DISTINCT и структурированные типы. Обе эти разновидности могут использоваться (кроме всего прочего) в качестве основы для определения столбцов в базовых таблицах.

■    В главе 6 было показано, что в языке SQL специально предусмотрена возможность использовать структурированные типы в качестве основы для определения струк тур, которые в спецификации SQL: 1999 были названы типизированными таблица ми (typed table).

■    В главе 20 было отмечено, что в языке SQL поддерживается также определенная форма наследования типов, хотя и только для структурированных типов.

Но кроме этих средств, в языке SQL поддерживаются также, во-первых, генератор типа RE  7, и, во-вторых, подтаблицы и супертаблицы. Отметим также,  что эти дополнительные конструкции в очень значительной степени связаны с уже указанными (особенно со структурированными типами). Хотя и не совсем ясно, почему они должны были быть настолько связанными (в принципе, понятия, лежащие в их основе, полностью ортогональны), но, возможно, все равно это не  имеет большого значения, поскольку, по мнению автора, указанные в начале этого абзаца дополнительные конструкции вообще не очень-то нужны, как будет показано ниже.

Типы REF

Начнем с простого примера (ненужные подробности здесь не показаны).

CREATE TYPE DEPT_TYPE AS ( DEPT#  CHAR(3),

DNAME  CHAR(25), BUDGET MONEY ) …

REF IS SYSTEM GENERATED ;

CREATE TABLE DEPT OF DEPT_TYPE

( REF IS DEPT_ID SYSTEM GENERATED, PRIMARY KEY ( DEPT# ) ) … ;

Пояснение (частично здесь повторяется материал, приведенный в главе 6).

1.   Вначале  напомним,  что  (как  было  сказано  в  главе  5)  при  создании  каждого структурированного типа ST система автоматически формирует  соответствующий  ссылочный  тип  ("тип  REF"), называемый  REF(ST),  поэтому  в  данном примере автоматически формируется ссылочный тип  REF(DEPT_TYPE) . Типы REF могут использоваться везде, где допустимо применение типа данных любого рода; но они могут формироваться только неявно в качестве побочного эффекта создания структурированного типа.

7   Ключевое слово REF является сокращением от reference (ссылка), но типы REF не имеют  ничего общего ни с привилегиями REFERENCES (см. главу 17), ни с теми ссылками, под  которыми подразумеваются внешние ключи. Кстати, следует отметить, что типы REF являются скалярными, поэтому генератор типа REF представляет собой пример генератора скалярного типа.

2.    Значения типа REF (ST) представляют собой ссылки на строки (иными словами, указатели на строки или адреса строк) в некоторой базовой таблице8, которая была определена (с помощью ключевого слова "OF") как относящаяся к типу ST (см. п. 4). Поэтому в данном примере значения типа REF (DEPT_TYPE) представляют собой указатели на строки в базовой таблице DEPT. (Здесь предполагается, что DEPT — это единственная таблица, которая определена с помощью ключевого слова "OF" как относящаяся к типу DEPT_TYPE, хотя это предположение не всегда будет дей ствительным.)

Примечание. Структурированный тип ST, разумеется, может  использоваться  и в других контекстах (например, в качестве  объявленного типа для некоторого столбца или некоторой локальной  переменной), но с этими другими областями применения не ассоциируется значение REF (ST).

3.    Спецификация REF IS  SYSTEM GENERATED в предложении CREATE  TYPE ука зывает, что значения соответствующего типа REF предоставляются системой. (Есть и другие опции, например, REF  IS   USER  GENERATED, но сведения о них выходят за рамки данной книги.)

Примечание. В действительности, опция REF IS SYSTEM GENERATED применяется по умолчанию; поэтому в данном примере можно было бы полностью исключить эту спецификацию из определения типаОЕРТ_ТУРЕ.

4.    Базовая таблица может быть определена (в предложении CREATE   TABLE) как относящаяся к некоторому структурированному типу с помощью ключевого слова "OF"; такая таблица называется типизированной таблицей (typed table) или указываемой в ссылках таблицей (referenceable table). Но в действительности ключевое слово OF в данном случае не совсем подходит, поскольку (как описано в главе 6) данная таблица фактически не относится к рассматриваемому типу (что обычно выражает предлог "of); к этому типу не относятся и ее строки. На самом деле в этой таблице предусмотрено по одному столбцу для каждого атрибута рассматриваемого структурированного типа, а также один дополнитель ный столбец (а именно, столбец применимого типа REF), хотя синтаксис для оп ределения данного дополнительного столбца не напоминает обычный синтаксис определения столбца, а вместо этого выглядит примерно следующим образом.

REF IS  <column name>  SYSTEM GENERATED

Этот лишний ссылающийся на самого себя столбец с именем <column  name>, который является первым в упорядочении столбцов таблицы слева направо, используется для хранения уникальных идентификаторов (ссылок) на строки рассматриваемой базовой таблицы (из этого следует также, что он имеет спецификации UNIQUE и NOT   NULL). Идентификатор для данной конкретной строки

8 Или, возможно, в некотором представлении. Описание того случая, когда значения типа REF ссылаются на строки представления, выходит за рамки данной книги.

присваивается во время вставки этой строки и остается связанным со строкой9 до тех пор, пока она не будет удалена.

5.    Структурированный тип, при его использовании в качестве основы для определе ния базовой таблицы, не рассматривается как инкапсулированный (хотя он в большей или меньшей степени и рассматривается как таковой в других контек стах). Поэтому в данном примере базовая таблица DEPT имеет четыре столбца, DEPT_ID, DEPT#, DNAME и BUDGET (в указанном порядке), а не просто два, как было бы в том случае, если бы тип DEPT_TYPE был инкапсулированным.

6.    Значением, применяемым по умолчанию для столбца DEPT_ID, является NULL (как фактически и предусмотрено для всех столбцов, которые определены как от носящиеся к некоторому типу REF, хотя это заданное по умолчанию значение в основном теряет смысл, если для рассматриваемого столбца дополнительно задана спецификация NOT NULL).

Теперь дополним рассматриваемый пример, чтобы ввести в него базовую таблицу ЕМР,

следующим образом10.

CREATE TABLE EMP

( ЕМР#   CHAR(5) NOT NOLL, ENAME CHAR(25) NOT NOLL, SALARY MONEY

NOT NOLL, DEPT_ID REF ( DEPT_TYPE )

SCOPE DEPT REFERENCES ARE CHECKED ON DELETE CASCADE

NOT

NOLL, PRIMARY KEY ( EMP# )

) ;

При обычных условиях базовая таблица ЕМР включала бы столбец внешнего ключа DEPT#, который ссылался бы на отделы с помощью номеров отделов. Но здесь имеется справочный столбец DEPT_ID (причем заслуживает внимания то, что он не обозначен явно именно как столбец внешнего ключа), который вместо этого указывает на отделы с помощью ссылок на строки с данными об этих  отделах. В опции SCOPE DEPT задана соответствующая упоминаемая в ссылках  таблица. Спецификация REFERENCES ARE CHECKED означает, что должна поддерживаться ссылочная целостность (при использовании опции REFERENCES  ARE NOT CHECKED появилась бы возможность создания зависших  ссылок,  поэтому непонятно, зачем вообще могло бы потребоваться задавать опцию NOT   CHECKED)11 Конструкция ON  DELETE. . . указывает правило удаления,

9  На первый взгляд может даже показаться, что здесь возникает какая-то цикличность: выражение "эта строка" может означать только "строку, которая имеет данный конкретный рассматриваемый идентификатор". В частности, обратите внимание на путаницу между значением и переменной! Если "эта строка" должна иметь адрес, то "эта строка" должна и быть переменной строки (см. раздел 26.3).

10  Обратите внимание на спецификации NOT NOLL в столбцах таблицы ЕМР. Указать, что в таблице DEPT также не разрешается иметь столбцы, содержащие неопределенные значения, не так уж просто! Анализ дополнительных сведений по этому вопросу оставляем читателю в качестве упражнения.

1    И тем не менее, велика вероятность того, что в окончательной редакции стандарта SQL:2003 спе цификация REFERENCES. . . будет изъята; из этого следует, что (по умолчанию) всегда будет задана ОПЦИЯ REFERENCES  ARE  NOT  CHECKED.

аналогичное обычным правилам удаления внешнего ключа (поддерживаются такие же опции). Аналогичная спецификация ON UPDATE. . . не предусмотрена.

Использование ссылок

Теперь рассмотрим несколько примеров запросов и обновлений  применительно к только что объявленной базе данных отделов и служащих. Вначале рассмотрим приведенную ниже формулировку на языке SQL: "Определить номер отдела служащегоЕ1".

SELECT DEPT_ID -> DEPT# AS DEPT# FROM EMP

WHERE EMP# = ‘El’ ;

Обратите  внимание  на  оператор  разадресации12   "->"  в  конструкции   SELECT (выражение DEPT_ID -> DEPT# извлекает значение DEPT# из строки DEPT, на которую указывает рассматриваемое значение DEPT_ID). Обратите также внимание на необходимость задавать конструкцию AS; если бы эта конструкция была опущена, то соответствующий столбец результата по существу остался  бы  безымянным. Наконец, следует отметить противоречащий здравому смыслу  характер конструкции FROM — значение DEPT#, подлежащее выборке, поступает из таблицы DEPT, а не ЕМР, а значения DEPT_ID поступают из таблицы ЕМР, а не DEPT.

Кстати, трудно преодолеть искушение и не отметить, что производительность этого первого запроса, скорее всего, будет ниже по сравнению с его аналогом, сформулированным с помощью обычных средств SQL (который обращался бы только к одной таблице, а не к двум). Автор привел это замечание потому, что обычно в пользу ссылок приводят такой довод, будто бы они способствуют повышению производительности (что "следуя по указателю, можно быстрее получить данные, чем выполняя соединение"). Безусловно, недостатком подобных доводов является и то, что в них перепутаны логические и физические проблемы.

В качестве второго примера предположим, что первоначальный запрос был сформулирован следующим образом: "Определить отдел (а не просто номер отдела) служащего Е1".

Теперь операция разадресации выглядит совсем иначе, как показано ниже.

SELECT DEREF ( DEPT_ID ) AS DEPT FROM EMP

WHERE EMP# = ‘El’ ;

Более того, в данном случае вызов оператора DEREF приводит к получению не значения строки DEPT (как можно было бы ожидать), а, вместо этого, к получению инкапсулированного (скалярного) значения. Это значение относится к типу DEPT_TYPE И поэтому

12   В большинстве языков, в которых поддерживается разадресация (dereferencing),  поддерживается также оператор адресации (см., например, описание оператора PTR_TO а  разделе 26.3), но в языке SQL такая поддержка не предусмотрена. Более того, обычно в  результате разадресации возвращается переменная, но в языке SQL соответствующая операция вместо этого возвращает значение.

имеет только три  атрибута,  DEPT#, DNAME  И  BUDGET (ОНО не  включает атрибут

DEPT_ID)13.

Примечание. Повторяя замечание, сделанное в главе 6, отметим, что если объявленным типом некоторого формального параметра Р некоторого  оператора Ор является DEPT_TYPE, то нельзя передавать строку из таблицы DEPT в качестве соответствующего фактического параметра в вызове этого оператора Ор. Но теперь очевидно, что вместо этого можно передавать результат выражения DEREF(DEPT_ID) , если DEPT_ID содержит ссылку на строку таблицы DEPT.

Ниже приведен еще один пример запроса: "Определить номера служащих отдела

D1".

SELECT EMP# FROM EMP

WHERE DEPT_ID -> DEPT# = ‘Dl’ ;

Обратите внимание на использование в данном примере разадресации в конструкции WHERE. Теперь рассмотрим следующий пример предложения INSERT (вставка данных о служащем).

INSERT INTO EMP ( ЕМР#, DEPT_ID )

VALUES ( ‘E5′, ( SELECT DEPT_ID FROM DEPT WHERE DEPT# = ‘ D2 ‘

) ) ;

Отметим, что сторонники рассматриваемых конструкций (типов REF и т.д.)  подчеркивают такую мысль, будто не о чем беспокоиться, поскольку "все эти конструкции фактически являются просто сокращениями". Например, они утверждают, что выражение SQL.

SELECT DEPT_ID -> DEPT# AS DEPT# FROM EMP

WHERE EMP# = ‘El’ ;

("Определить номер отдела служащего Е1"; первый из примеров,  рассматриваемых в данном подразделе) является сокращенным обозначением для приведенного ниже предложения.

SELECT ( SELECT DEPT# FROM DEPT

WHERE DEPT.DEPT_ID = EMP.DEPT_ID ) AS DEPT# FROM EMP WHERE EMP# = ‘El’ ;

Но в действительности утверждение о том, что это — сокращение, не выдерживает никакой критики, поскольку применяемый здесь новый синтаксис (в частности, для разадресации) может использоваться только в сочетании с данными, которые были определены с

13  Из семантики оператора DEREF следует, что в системе необходимо также хранить информацию о том, что столбцы DEPT#, DNAME и BUDGET таблицы DEPT происходят от  структурированного типа DEPT_TYPE (хотя для большинства назначений они могут рассматриваться просто как обычные столбцы). Иными словами, использую терминологию типов и заголовков из главы 6, можно утверждать, что таблица DEPT имеет заголовок (и  поэтому тип) с четырьмя компонентами в одних контекстах, но принимает заголовок (и поэтому тип) только с двумя компонентами в других. Возможно, "типизированные таблицы" лучше было бы назвать таблицами "с раздвоением личности"?

помощью специального нового способа, с использованием якобы "принципиально нового" генератора типа (REF). Кроме того, в этих определениях данных широко применяется также новый синтаксис. К тому же, рассматриваемые функциональные возможности предоставляются в высшей степени в неортогональной форме (кроме всего прочего, они распространяются только на те таблицы, которые определены с помощью данного специального нового способа, а не на все таблицы).

Более того, даже если считать правильным утверждение о том, что это — сокращение,

остается без ответа вопрос, для чего вообще нужны такие сокращения. Какая проблема намечена для решения с их помощью? Почему соответствующая поддержка является такой неортогональной? При каких условиях мы должны  использовать "старомодный" способ, а при каких — этот странный новый способ? И это — далеко не исчерпывающий список вопросов.

Примечание. В этой связи см. [26.15] и аннотацию к [26.21].

Подтаблицы и супертаблицы

В языке SQL разрешено определять базовую таблицу в как подтаблицу базовой таблицы А, только если в и А обе являются типизированными таблицами, а структурированный тип STB, с помощью которого определена таблица в, является подтипом структурированного типа STA, с помощью которого определена таблица А. В качестве примера рассмотрим следующие определения структурированных типов.

CREATE TYPE EMP_TYPE /* служащие

*/ AS ( ЕМР# …, DEPT# … ) REF IS SYSTEM GENERATED ;

CREATE TYPE PGMR_TYPE UNDER EMP_TYPE /*

программисты */ AS ( LANG … ) ;

Обратите внимание на то, что в предложении PGMR_TYPE нет конструкции REF IS. ..; вместо этого данный тип фактически наследует указанную конструкцию от своего непосредственного (прямого) супертипа EMP_TYPE. Иными словами,  значение типа REF (EMP_TYPE) теперь может ссылаться на строку в таблице, которая определена как относящаяся к типу PGMR_TYPE, а не К типу ЕМР_ТУРЕ.

Теперь рассмотрим приведенные ниже определения базовой таблицы.

CREATE TABLE EMP OF EMP_TYPE

( REF IS EMP_ID SYSTEM GENERATED, PRIMARY KEY ( EMP# ) ) … ;

CREATE TABLE PGMR OF PGMR_TYPE UNDER EMP ;

Здесь заслуживает внимания спецификация UNDER EMP после определения базовой таблицы PGMR (следует отметить также отсутствие спецификаций REF  is и PRIMARY KEY для этой базовой таблицы). Базовые таблицы PGMR и ЕМР называются, соответственно, подтаблицей и относящейся к ней непосредственной (прямой) супертаблицей; в таблице PGMR унаследованы столбцы (и т.д.) от ЕМР и введен один собственный дополнительный столбец LANG. На интуитивном уровне этот пример можно понять таким образом, что для служащих, не являющихся программистами, предусмотрена строка только в таблице ЕМР, а для программистов имеются строки в обеих таблицах, поэтому каждая строка

в таблице PGMR имеет свой аналог в таблице ЕМР, но обратное утверждение не является истинным.

Операции манипулирования данными в этих таблицах осуществляются, как описано ниже.

■     Операция SELECT. Выборка данных с помощью операции SELECT из таблицы ЕМР осуществляется обычным образом. Операция SELECT на таблице PGMR выполня ется так, как если бы PGMR фактически содержала столбцы таблицы ЕМР, а также столбец LANG.

■     Операция INSERT. Операция вставки данных с помощью оператора INSERT в таб лицу ЕМР осуществляется обычным образом. Выполнение операции INSERT с таб лицей PGMR фактически приводит к появлению новых строк и в таблице ЕМР, и в таблице PGMR.

■     Операция DELETE. Выполнение операции DELETE с таблицей ЕМР влечет за собой исчезновение строк из таблицы ЕМР, а также (если оказалось, что рассматривае мые строки относятся к программистам) из таблицы PGMR. Удаление данных с по мощью оператора DELETE из таблицы PGMR вызывает исчезновение строк и из таблицы ЕМР, и из таблицы PGMR.

■     Операция UPDATE. Обновление атрибута LANG, которое должно осуществляться обязательно через таблицу PGMR, приводит к обновлению только таблицы PGMR; обновление других столбцов (в принципе) приводит к обновлению обоих таблиц, независимо от того, осуществляется ли оно с помощью либо таблицы ЕМР, либо таблицы PGMR.

В частности, следует отметить, что из этого анализа операций манипулирования данными следуют приведенные ниже выводы.

■     Предположим, что некоторый существующий служащий Джо стал программи стом. Если мы просто попытаемся вставить строку с данными о Джо в таблицу PGMR, то система попытается вставить строку, касающуюся Джо, также и в табли цу ЕМР, но такая попытка, безусловно, окончится неудачей. Вместо этого необхо димо удалить строку Джо из таблицы ЕМР, а затем вставить соответствующую строку в таблицу PGMR.

■     Напротив, предположим, что некоторый существующий служащий Джо перестал быть программистом. На этот раз необходимо удалить строку Джо либо из ЕМР, либо из PGMR (какая бы таблица ни была задана, в конечном итоге происходит уда ление из обеих таблиц), а затем вставить соответствующую строку в таблицу ЕМР.

Кстати, следует отметить, что в языке SQL предусмотрено средство ONLY,  которое действительно  позволяет проводить манипуляции  только  с такими  строками  данной конкретной таблицы, которые не имеют аналогов в какой-либо подтаблице этой таблицы. Например, выражение SELECT * FROM ONLY (ЕМР) позволяет осуществить выборку только тех строк таблицы ЕМР, которые не имеют аналогов в таблице PGMR; аналогичным образом, с помощью выражения DELETE FROM ONLY (ЕМР) можно удалить только те строки ЕМР, которые не имеют аналогов в PGMR, и подобная конструкция может применяться в сочетании с оператором UPDATE (версия оператора INSERT с ключевым

словом ONLY не предусмотрена). Но заслуживает внимание то, что это средство ONLY не может помочь в решении проблем, описанных выше, когда приходится обновлять базу данных с учетом того, что некоторый существующий служащий Джо стал программистом или перестал им быть.

Итак, что общего имеют только что описанные подтаблицы и супертаблицы с истинным наследованием типов? Насколько мы можем судить, ответом является — НИЧЕГО. Таблицы — это не типы! Безусловно, здесь и речи не может быть о какой-либо заменяемости, а в главе 20 было показано, что если заменяемость не  предусмотрена, то нет и подлинного наследования типов. Поэтому, если даже предположить, что подтаблицы и супертаблицы способны предоставить какие-либо полезные средства, все равно не совсем понятно, почему язык SQL должен требовать, чтобы для получения доступа к этим средствам рассматриваемые подтаблицы и их непосредственные (прямые) супертаблицы были объявлены в терминах типов, которые являются, соответственно, подтипом и его непосредственным (прямым) супертипом.

Более фундаментальный вопрос состоит в том, каковы же здесь возможные положительные средства. Чем могут нас подкупить подтаблицы и супертаблицы? По-видимому, ответ состоит в том, что "пользы от них очень мало", по крайней мере, на уровне модели14. Верно то, что может быть достигнута некоторая экономия в реализации, если подтаблица и ее супертаблица физически хранятся на диске в виде одной таблицы, но, безусловно,  нельзя  допускать, чтобы  подобные  соображения оказывали хоть какое-либо влияние на саму модель как таковую. Иными словами, как было отмечено в предыдущем абзаце, не только не ясно, почему "под-" и "супер-" таблицы должны создаваться на основе структурированных "под-" и "супер-" типов, но также совершенно не понятно, для чего вообще должно поддерживаться это средство.

Язык SQL и два серьезных заблуждения

Итак, позволяют ли описанные выше функциональные средства SQL достичь важной цели — предоставление качественной объектно-реляционной поддержки? Прежде всего, если даже в языке SQL не в полной мере проявляются два серьезных заблуждения, безусловно, в нем обнаруживаются весьма заметные их признаки.  И как уже было сказано, причины такого положения дел не совсем понятны, по  крайней мере, автору данной книги; по-видимому, в основном они следуют лишь из смутного представления, что указанные  средства,  являющиеся  следствием  непреодоленных  серьезных  заблуждений, должны в какой-то степени позволить языку SQL стать более "похожим на объектный" (да, по-видимому, эти средства как раз и способствуют достижению именно этой цели).

Что касается первого серьезного заблуждения, то создается впечатление, что идея привязки типизированных таблиц к структурированным типам имеет определенное касательство к идее приравнивания таблиц и классов. Точнее, представляется вполне вероятным, что если типизированная таблица тт определена с помощью ключевого слова "OF" как относящаяся к структурированному типу ST, то предполагается, что тт должна содержать то, что иногда называют экстентом типа ST (под этим подразумевается множество

14   Можно было бы предположить, что ответ на этот вопрос имеет нечто общее с проблемой подтипов и супертипов сущностей, которые рассматривались в главе 14. Но в этой связи автор хотел бы отметить, что для решения и этой проблемы он предпочитает использовать подход,  основанный на применении представлений. См. пример в самом конце раздела 14.5.

всех существующих в настоящее время экземпляров типа ST)15. Если дело обстоит иначе,

то для чего нужна тесная связь между TT и ST?

Если это действительно так, то опять возникают некоторые проблемы. Одна из них состоит в том, что не исключена возможность иметь две или несколько типизированных таблиц одного и того же структурированного типа; какие последствия повлечет за собой такое решение, не совсем ясно (если не считать того, что в число этих последствий почти наверняка будет входить нарушение принципа ортогонального проектирования). Другие проблемы описаны в разделе 6.6.

Что касается второго серьезного заблуждения, то должно быть очевидно, что язык

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

(адреса), то эти строки по определению являются переменными строк. В частности, язык

SQL страдает от проблемы, описанной в подразделе "Несовместимость указателей и качественной модели наследования" раздела 26.3. Здесь подробные сведения по этой теме не приведены, поскольку они являются довольно сложными;  достаточно сказать, что значение REF, которое предположительно должно  ссылаться на строку, описывающую окружность, может фактически ссылаться вместо этого на строку, содержащую эллипс, отличный от окружности.

26.4. РЕЗЮМЕ

В настоящей главе кратко рассматривалась проблемная область объектно-реляционных систем. Такие системы являются (или должны быть), по  сути, просто реляционными системами, которые должным образом поддерживают реляционное понятие доменов (т.е. типов). Иными словами, объектно-реляционные системы — это подлинно реляционные системы, отличительной особенностью которых является то, что они позволяют пользователям определять их  собственные типы. Реляционная модель не требует никаких дополнений для  достижения объектно-реляционных функциональных возможностей; достаточно лишь полностью ее реализовать.

Затем в этой главе рассматривались два серьезных заблуждения. Первое из них состоит в том, что проводится знак равенства между классами объектов и переменными отношения (к сожалению, это уравнение все же слишком привлекательно, по крайней мере, если не проводится его глубокий анализ). Автор сделал предположение, что источником этого заблуждения становится путаница между двумя совершенно  различными интерпретациями термина объект. Было подробно описано, как  может выглядеть система, в которой обнаруживаются следы первого серьезного заблуждения, и показаны некоторые последствия этой ошибки. Одним из важных последствий, по-видимому, является то, что

первое заблуждение приводит непосредственно к возникновению также второго серьезного заблуждения! Оно заключается именно в смешивании указателей и  отношений (хотя фактически второе заблуждение может проявляться и без  первого, и, к сожалению, его "следы" можно обнаружить почти в любой системе, представленной на рынке). По мнению автора, второе серьезное заблуждение во многом подрывает концептуальную

15 Но этот экстент не сопровождается автоматически; вместо этого экземпляры типа ST появляются в таблице ТТ и исчезают из нее только в результате выполнения явных операций  обновления на этой таблице.

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

После этого были кратко рассмотрены некоторые проблемы реализации. При  этом наиболее важная мысль состояла в том, что введение нового пакета типов  оказывает

воздействие, по меньшей мере, на такие компоненты системы, как компилятор, оптимизатор и диспетчер памяти. Вследствие этого объектно-реляционная  система не может быть реализована (по крайней мере, достаточно качественно) просто путем наложения

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

В дальнейшем в этой главе рассматривалась матрица классификации СУБД  Стоунбрейкера и были кратко описаны преимущества, которые могут быть достигнуты благодаря истинному сближению между объектной и реляционной технологиями (здесь под

словом "истинное", кроме всего прочего, подразумевается, что рассматриваемая система не должна носить следы ни одного из двух серьезных заблуждений). Наконец, проанализирована предусмотренная в языке SQL поддержка типов REF, а также подтаблиц и супертаблиц.

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии