Главная » SQL, Базы данных » ДОПОЛНИТЕЛЬНЫЕ АСПЕКТЫ объектного подхода

0

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

■     Произвольные запросы и связанные с этим проблемы.

■     Целостность базы данных.

■     Реализация связей.

■    Языки программирования баз данных.

■     Повышение производительности.

■     Возможность рассматривать объектную СУБД как обычную СУБД.

Произвольные запросы и связанные с этим проблемы

До сих пор мы намеренно не подчеркивали, что если для манипулирования объектами заданы только заранее определенные методы, то произвольные запросы (не предусмотренные этими методами) просто невозможны, если только классы и методы не разработаны в соответствии со специальными правилами. Например, если для объекта класса DEPT определены только методы HIRE_EMP (нанять сотрудника), FIRE_EMP (уволить сотрудника) и CUT_BUDGET (урезать бюджет) (как описано в разделе 25.2), то невозможно будет выполнить даже такой простой запрос: "Кто является руководителем отдела программирования?".

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

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

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

2.           Надлежащим образом внедрить объекты в реляционную структуру. Эта часть ре шения подробно обсуждается в следующей главе.

Но разработчики объектных систем обычно не придерживаются таких рекомендаций

(вернее, не совсем их придерживаются). Вместо этого они поступают, как описано ниже13.

1.         Обычно определяются операторы, которые предоставляют доступ не к некоторым возможным представлениям, а скорее к физическим представлениям (см. описа ние открытых переменных экземпляра в разделе 25.2). Приведем цитату из [25.31]: "В настоящее время для всех продуктов объектных СУБД требуется, чтобы [переменные экземпляра], которые упоминаются в… запросах, были открытыми".

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

В связи с выполнением произвольных запросов возникает еще один важный вопрос, а именно: какой класс является результатом? Предположим, например,  что  необходимо выполнить запрос: "Определить имена и заработную плату всех  служащих из отдела программирования" по базе данных отделов и служащих из раздела 25.3. Предположительно результат будет содержать (открытые) переменные экземпляра ENAME и SALARY. Однако в базе данных нет класса, который имеет такую структуру. Нужно ли предварительно определять такой класс, прежде чем  выполнять запрос? (Обратите внимание на последствия: если бы было необходимо определить такой класс, то для класса с п переменными экземпляра, потребовалось бы иметь по крайней мере 2n  таких заранее определенных классов только для поддержки операций выборки!) А если есть какой-либо класс результатов, то какие методы к нему применимы?

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

Возможно, из-за того, что на такие вопросы нелегко ответить, опираясь на чисто объектную структуру, в некоторых объектных системах поддерживаются операции отслеживания пути (см. [25.38]), а не просто операции соединения как таковые. Для базы данных OPAL из раздела 25.4, например, допустимо следующее выражение пути.

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

ENROLLMENT . OFFERING . COURSE

Оно означает14 следующее: "Получить доступ к уникальному объекту COURSE, на который указывает уникальный объект OFFERING, указанный с помощью заданного объекта ENROLLMENT". Реляционный аналог этого выражения обычно включает две операции соединения и одну операцию проекции. Иными словами, в результате отслеживания пути предоставляется доступ только по предварительно определенным путям (фактически, как в дореляционных системах) и только к объектам предварительно определенных классов (опять же, как в дореляционных системах).

Целостность базы данных

В главе 9 утверждалось, что целостность данных в базе имеет абсолютно фундаментальное значение. Тем не менее, даже те объектные системы, которые поддерживают произвольные запросы, обычно не поддерживают декларативные  ограничения целостности. Выполнение подобных ограничений достигается с помощью процедурного кода, т.е. методов или, возможно, прикладных программ. Рассмотрим, например, следующее ограничение (или "бизнес-правило") из раздела 9.1: "Ни один поставщик со статусом меньше 20 не может поставлять какие-либо детали в количестве больше 500". Для того чтобы обеспечить выполнение этого  ограничения, процедурный код его поддержки должен быть включен, по меньшей мере, во все перечисленные ниже методы:

‘■  метод для создан ия объекта поставки;

■      метод для изменения количества поставляемых деталей;

■      метод для изменения статуса поставщика;

■      метод для переназначения некоторой поставки другому поставщику.

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

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

1.     Как убедиться в том, что все необходимый методы содержат необходимый для поддержки целостности базы данных код?

2.     Как исключить для пользователя возможность (например) обойти метод "создать поставку" и непосредственно воспользоваться встроенным методом NEW класса объектов поставки, тем самым исключив проверку целостности?

3.     Как при изменении ограничений целостности найти и внести соответствующие изменения во все методы, в которых они были определены?

4.     Как гарантировать правильность кода, с помощью которого поддерживаются ог раничения целостности?

5.     Как поступить, если ограничения необходимо ввести лишь на время, а затем от менить?

14   На самом деле это выражение не является допустимым путем для базы данных, в том виде, как мы ее  определили, поскольку  указатели  определяют неверное  направление! Например,  объекты  класса OFFERING не ссылаются на объекты класса COURSE; наоборот, объекты класса COURSE ссылаются на них.

6.    Как передать системе запрос для поиска всех ограничений, которые применяются к указанному объекту или к комбинации объектов?

7.    Будут ли ограничения целостности приводиться в действие во время загрузки и при выполнении других служебных функций?

8.    Можно ли осуществить семантическую оптимизацию (т.е. упростить запросы с помощью ограничений целостности, как описано в главе 18)?

Как отражаются все перечисленные выше недостатки на производительность работы во время создания приложения и при последующем его сопровождении?

Реализация связей

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

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

2.          Каждый объект отдела может включать множество указателей на соответствующие объекты сотрудников. Эта возможность аналогична подходу, основанному на ие рархии вложения и описанному в разделе 25.3.

3.          Кроме того, указанные выше подходы могут объединяться следующим образом.

CLASS ЕМР …

( … DEPT OID ( DEPT ) INVERSE DEPT.EMPS )

… CLASS DEPT …

( … EMPS

OID( SET ( OID ( EMP ) ) ) INVERSE EMP.DEPT ) … ;

Отметим, что ключевое слово INVERSE ОТНОСИТСЯ к двум переменным экземпляра: EMP.DEPT и DEPT.EMPS. Говорят, что эти две переменные  экземпляра являются обратными по отношению друг к другу. Переменная ЕМР . DEPT — это ссылочная переменная экземпляра, a DEPT. EMPS —  переменная набора ссылок экземпляра. (Если бы обе переменные были переменными набора ссылок, то связь имела бы тип "многие ко многим", а не "один ко многим".)

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

класса SPJ. Причем каждый объект класса будет обладать связями,  реализованными с помощью обратных переменных, с соответствующим поставщиком, соответствующей деталью и соответствующим проектом. Но в таком случае, если создание нового объектного класса на основе трех объектов является наилучшим подходом к описанию связей со степенью больше двух, то возникает очевидный вопрос: почему таким же образом не реализуются связи со степенью два?

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

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

SP.P# WHERE SP.S# = S#(‘S1′)

SP.S# WHERE SP.P# = P#(‘P1′)

Их объектные аналоги выглядят следующим образом.

S.PARTS.P# WHERE S.S# = S#(‘S1′) P.SUPPS.S# WHERE P.P# = P#(‘P1′)

Здесь использован некий гипотетический синтаксис, выбранный специально  таким образом, чтобы избежать несущественных в данном случае различий (например, использования двух разных имен связей PARTS И SUPPS) И  предотвратить создание двусмысленных выражений.

Ссылочная целостность

Рассмотрим уже упомянутую ранее объектную поддержку ссылочной  целостности, которая, кстати, как часто утверждают, является сильной стороной  объектных систем. Уровни такой  поддержки  могут  быть  самыми  разными;  например,  ниже  приводится классификация таких уровней, предложенная в работе Каттелла (Cattell) [25.10].

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

■     Проверка указателей. В системе выполняется проверка того, относятся ли все ука затели к существующим объектам правильного типа. Но удаление объектов может быть не разрешено (вместо этого, как в языке OPAL, может быть предусмотрено уничтожение объектов, на которые нет больше ссылок, с помощью сбора мусора). Как уже объяснялось в разделе 25.4, этот уровень поддержки приблизительно эквивалентен (но лишь весьма приблизительно) правилу каскадного удаления ON DELETE CASCADE в иерархии для подчиненных объектов без возможности сииместного доступа и контролируемого удаления (ON DELETE RESTRICT) ДЛЯ других объектов (но только если "указатели указывают на правильный объект").

■     Системная поддержка. На этом уровне отслеживание и обновление ссылок проис ходит в системе автоматически (например, с помощью установки значения nil для ссылок на удаленные объекты). Этот уровень в некоторой степени подобен правилу удаления ON DELETE SET NULL.

■     "Определяемая пользователем семантика". Правило каскадного удаления ON DELETE CASCADE (применяемое за пределами иерархии вложения) может рассматриваться как пример "определяемой пользователем семантики". Такие возможности обычно

не поддерживаются объектными системами непосредственно; скорее, они должны быть реализованы в коде, написанном пользователем.

Языки программирования баз данных

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

Такой подход, безусловно, обладает определенными преимуществами  (именно  поэтому он принят в языке Tutorial D). Одно из самых существенных — возможность осуществления усовершенствованной проверки типов [25.2]. В приведенной ниже цитате из [25.38] отмечено еще одно важное достоинство.

"В едином унифицированном языке нет несоответствия типов данных между процедурным языком программирования и встроенным языком манипулирования данными с декларативной семантикой ".

Термин несоответствие типов данных (impedance mismatch) используется для описания различий между типичными современными языками программирования, функционирующими на основе последовательной обработки записей, и реляционными языками наподобие SQL, функционирующими на основе последовательной обработки множеств. Очевидно, что такие различия на  практике  приводят к возникновению разнообразных проблем при использовании программных продуктов SQL. Но для их решения не нужно переводить язык,  ориентированный на работу с базами данных, на уровень последовательной обработки отдельных записей (как это принято в объектных системах!). Необходимо вместо этого в языках программирования ввести инструменты для перехода к последовательной обработке множеств записей. Применение последовательной обработки отдельных записей в объектных языках (т.е. процедурный подход)  отбрасывает нас к временам, когда использовались такие дореляционные системы, как IMS и IDMS.

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

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

Повышение производительности

Низкая производительность — один из самых существенных недостатков всех  объектных систем. Снова приведем цитату из [25.10]: "Различие производительности на порядок реально может привести к возникновению функциональных различий, поскольку для решения некоторых задач будет невозможно использовать данную систему, если ее

производительность гораздо ниже требуемого уровня" (автор согласен с этим замечанием,

которое он лишь немного перефразировал).

Среди многочисленных факторов, влияющих на общую производительность системы,

можно отметить перечисленные ниже15.

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

■     Кэширование.  Объектные системы обычно предназначены для использования в среде "клиент/сервер", в которой пользователи копируют на свои рабочие стан ции информацию из базы данных на сервере и хранят ее на этих рабочих станциях в течение некоторого времени. Очевидно, что в такой системе было бы полезно кэшировать логически связанные данные на рабочем месте клиента.

■     Подстановка. Термин подстановка указателей (swizzling) означает процесс замены указателей, организованный по принципу замены идентификаторов объектов

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

■     Выполнение методов на сервере. В качестве примера рассмотрим запрос: "Найти все книги, в которых содержится больше 20 глав". В традиционной системе SQL книги могут быть представлены в виде объектов типа CLOB или BLOB (см. гла ву 15), и в клиентском приложении может потребоваться выполнить выборку каж дой книги по очереди и просмотреть ее для определения того, имеется ли в ней больше 20 глав. В отличие от этого, в объектной системе оператор "определения количества глав" мог быть выполнен на сервере и клиенту переданы только те книги, которые фактически требуются. Поэтому выполнение методов на сервере указанным образом способствует снижению издержек, связанных с передачей данных16.

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

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

Примечание. Указанное выше на самом деле служит доводом не в пользу объектов, а в пользу хранимых процедур (см. главу 21). Традиционная система SQL с хранимыми процедурами будет обладать в этом случае  такими же преимуществами с точки зрения производительности, как и объектная система с методами.

В [25.12] обсуждается эталонный тест 001 для измерения производительности системы на основе базы данных, содержащей информацию о счетах-фактурах. Такой эталонный тест предусматривает выполнение описанных ниже действий.

1.  Случайная выборка 1000 деталей с применением заданного пользователем метода для каждой детали.

2.  Случайная вставка 1000 деталей с присоединением каждой к трем другим.

3.  Случайное разузлование деталей (вплоть до седьмого уровня) с применением за данного пользователем метода для каждой детали, подсчитывающего соответст вующие вхождения в узлы.

Согласно данным, опубликованным в [25.12], производительность некоторой (не сказано, какой) объектной системы на два порядка выше производительности некоторой (не сказано, какой) современной системы SQL, особенно при условии, что кэш уже заполнен данными (так называемый теплый доступ). Однако в той  же  работе [25.12] приведено следующее справедливое утверждение.

"Это различие… не следует приписывать различию между собственно реляционной и объектной моделями… В основном эти различия обусловлены [особенностями реализации]".

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

Аналогичный, но более полный эталонный тест, ОО7, описан в [25.9].

Действительно ли можно рассматривать объектную СУБД как обычную СУБД

Примечание. В данном подразделе излагаются суждения и наблюдения, которые в основном заимствованы из [25.16]. В этой работе, помимо всего прочего, сказано, что различия между объектными и реляционными системами гораздо  существеннее, чем это обычно представляется. Ниже приведена цитата из этой работы.

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

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

1.          Совместный доступ к данным со стороны нескольких приложений.

2.          Физическая независимость от данных.

3.          Возможность выполнения произвольных запросов.

4.          Поддержка представлений и логической независимости от данных.

5.          Поддержка декларативных ограничений целостности, независимых от прило жений.

6.          Поддержка прав владения данными и гибкий механизм обеспечения их защиты.

7.          Управление параллельной работой.

8.          Каталог общего назначения.

9.          Возможность проектирования базы данных независимо от приложений.

Впоследствии, после представления основной идеи хранения объектов в базе данных, эти возможности были рассмотрены и реализованы как усовершенствования  и дополнения к исходной объектной модели… Один из важных выводов… заключается в том, что объектная СУБД и реляционная СУБД — системы, которые различны по сути. На самом деле, можно доказать, что объектная СУБД фактически вовсе не является СУБД, по крайней мере, в том смысле, в котором это применимо к реляционной СУБД.

Для сравнения рассмотрим приведенные ниже замечания.

■    Реляционные СУБД поступают от изготовителя готовыми к использованию. Иными словами, как только система установлена, пользователи… могут ■ начать строить базы данных, разрабатывать приложения, запускать запросы и т.д.

■  Объектную же СУБД можно считать лишь  некоторого рода набором средств построения СУБД. После исходной установки объектная СУБД  не готова к немедленному использованию… Сначала она должна быть приспособлена к определенной области применения опытными  специалистами, которые определят необходимые классы, методы и т.п. Для этого в системе предоставляется набор строительных блоков — средства для сопровождения библиотеки классов, компиляторы методов и т.д. Только после завершения такой подготовки систему  можно  передать  в  эксплуатацию  прикладным  программистам  и пользователям. Иными словами, результат такой подготовки уже  будет больше напоминать СУБД в привычном смысле этого термина.

Кроме того, отметим, что результат подготовки такой базы будет зависеть от конкретного приложения. Эта система может подходить, например, для приложений САПР/АСУП, но быть совершенно непригодной, например, для медицинских приложений. Иначе говоря, она все еще не стала СУБД общего назначения в том смысле, в котором реляционная СУБД является СУБД общего назначения.

В той же статье [25.16] оспаривается идея (часто называемая перманентностью, ортогональной типу [25.2]), в соответствии с которой в базу данных можно включать (изменяемые) объекты произвольной сложности17. Ниже приведена

еще одна цитата, взятая из [25.16].

Для    объектной    модели    требуется    поддержка    [большого    количества] генераторов типа… В качестве примера можно указать  такие типы, как структура  (STRUCT),  кортеж  (TUPLE),  список   (LIST),  массив  (ARRAY), множество     (SET),     мультимножество     (BAG)     и     т.д….     Вместе     с идентификаторами объектов наличие  таких генераторов типов фактически означает, что любая структура  данных, которая может быть создана в прикладной программе, может быть также создана как объект в объектной базе  данных,  и,  кроме  того,  такая  структура  объектов  доступна  пользователю.  Например,  рассмотрим  объект  (допустим,  ЕХ),  который  является коллекцией служащих в отделе (или, скорее, обозначает такую  коллекцию). Тогда  объект  ЕХ  может  быть  реализован  как  связанный  список  или  как массив, и пользователи должны  будут  знать,  как  именно реализован  этот объект, поскольку при этом используются разные операторы доступа.

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

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

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

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

17 См. также [25.19].

25.1. РЕЗЮМЕ

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

■     Классы объектов (т.е. типы). Классы объектов соответствуют типам данных и, без условно, очень важны. По существу, это наиболее фундаментальная концепция из всех.

■     Объекты. Сами объекты, изменяемые и неизменяемые, очевидно, составляют основу объектных систем, хотя мы предпочли бы их называть просто переменными и зна чениями, соответственно.

■     Идентификаторы объектов. Не нужны и даже вредны (на уровне модели), посколь ку по существу это указатели. Этот вопрос подробно рассматривается в [25.19].

■     Инкапсуляция. Как уже отмечалось в разделе 25.2, инкапсулированный означает просто скалярный, и мы бы предпочли именно такой термин, всегда помня при этом, что некоторые объекты, тем не менее, не являются скалярами.

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

■     Иерархия вложения. Как уже отмечалось в разделе 25.3, мы считаем, что понятие иерархий вложения вводит в заблуждение и на самом деле является неверным, по скольку такие иерархии включают идентификаторы, а не объекты.

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

■     Методы. Это, конечно, важное понятие, хотя мы предпочли бы более привычный термин операторы. Но объединение методов с операторами не является обязатель ным и приводит к некоторым проблемам [3.3]. Раздельное определение классов (типов) и методов (операторов), как было показано в главе 6, позволяет обойтись без использования понятия объекта-получателя.

Существуют  некоторые  операторы,  на  включении  которых  мы  бы  настаивали:

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

Примечание. Однако мы бы отказались от функций-конструкторов. Конструкторы создают переменные. А поскольку для нас единственными необходимыми

переменными  в  базе  данных  являются  переменные  отношения,  единственный конструктор, который нам нужен, — это оператор создания переменной отношения, т.е. CREATE TABLE или CREATE VIEW (по терминологии языка SQL). Операторы выборки,  наоборот, выбирают  значения.  Конечно, есть  и дополнительное различие в том, что конструкторы возвращают указатели на созданные переменные, в то время как операторы выборки возвращают сами выбранные значения.

■     Сообщения. Это также одно из основных понятий, хотя мы предпочли бы более привычный термин вызов. Опять же, можно обойтись без использования понятия объекта-получателя, если отказаться от требования непосредственного обращения к некоторому объекту-получателю, а считать все фактические параметры равно правными.

■     Иерархия классов. С иерархией классов связаны такие понятия, как наследование, полиморфизм, перегрузка, переопределение и т.д. Считаем, что понятие иерархии классов — нужное, но производное. Мы рассматриваем поддержку иерархии клас сов как составляющую поддержки самих классов.

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

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

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

Теперь перечислим возможности, которые в "объектных моделях" обычно не поддерживаются или поддерживаются не в полной мере.

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

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

Примечание. В некоторых объектных системах поддерживаются  производные  или

виртуальные переменные экземпляра (обязательно открытые).  Например,  переменная экземпляра AGE (Возраст) может наследоваться с помощью вычитания значения переменной экземпляра BIRTHDATE (Дата  рождения) из текущей даты. Однако такая возможность еще очень далека от возможностей, которые

предоставляются с помощью механизма представлений; и кроме того, мы уже о

тказались от понятия открытой переменной экземпляра.

■  Декларативные ограничения целостности. Обычно не поддерживаются (в основном по тем же причинам, что и представления и обработка  произвольных запросов). Более  того,  они обычно  не  поддерживаются  даже  теми  системами,  которые  поддерживают произвольные запросы.

■     Внешние ключи. В "объектной модели" предусмотрено несколько разных

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

реляционной модели.

Такие понятия, как ограниченное (ON   DELETE   RESTRICT) И каскадное (ON

DELETE CASCADE) удаления, обычно реализуются с помощью процедурного кода

(размещенного либо в методах, либо в коде приложений).

■     Замкнутость. Сложно найти объектный аналог реляционному свойству замкнутости.

Каталог. Где же каталог в объектной системе? Как он выглядит? Есть ли какиелибо стандарты?

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

Подытожив сказанное выше, можно отметить приведенные в табл. 25.1  полезные (существенные, фундаментальные) понятия и концепции "объектной  модели" (такие, которые желательно поддерживать).

Таблица 25.1. Полезные понятия и концепции "объектной модели"

Более кратко можно сказать, что единственная хорошая идея объектных систем в целом — это надлежащая поддержка типов данных18 (все остальное, включая понятия операторов, определяемых пользователем, следует из этой идеи). Но данную идею вряд ли можно назвать новой!

18  Кое-кто может возразить, что наследование типа — также хорошая идея. Автор против  этого не возражает, а лишь настаивает на том, что поддержка наследования не связана с поддержкой объектов как таковых.

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

По теме:

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