Целостность на уровне ссылок

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

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

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

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

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

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

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

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

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

В языке Tutorial D, который широко используется в данной книге, выбран такой же подход. Соображения по этому поводу изложены в [3.3].

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

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

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

Низкая производительность- один из самых существенных недостатков всех объектных систем. И снова процитируем, несколько перефразировав, Каттелла [24.11]: Различие производительности на порядок реально может привести к функциональному различию, поскольку для решения некоторых задач будет невозможно использовать данную систему, если ее производительность гораздо ниже фебуемого уровня .

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

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

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

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

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

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

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

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

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

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

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

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

Замечание относительно объектов BLOB. Хотя такой тип данных не включен в стандарт SQL/92, SQL-продукты традиционно предоставляют возможности обработки данных типа BLOB в качестве основы для работы с большими двоичными объектами (binary large object). Здесь объект понимается в общепринятом смысле, а не в том, который вкладывается в это понятие в объектных системах. Данные типа BLOB представляют собой по существу просто какую-то строку байтов произвольной длины, для которой в системе предоставляется поддержка с целью организации ее хранения и извлечения; этим вся поддержка и ограничивается. Физически такие данные часто хранятся в специально отведенной для них области, отдельно от основной области хранения данных тех отношений, которые логически содержат эти данные. Данные типа BLOB могут занимать (и часто занимают) огромные области дискового пространства.

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