Имеется целый ряд нетрадиционных для реляционных систем управления базами данных приложений, в которых эти системы уже более или менее успешно используются. К таким приложениям относятся системы автоматизации проектирования (САПР), картографические системы и т.д. Для определенности и всвязи с тем, что этому направлению уделяется наибольшее внимание в публикациях, в этом разделе под нетрадиционными приложениями мы будем иметь в виду САПР.
Управление данными - одна из существенных частей систем автоматизации проектирования. В большинстве пакетов САПР управление данными реализуется в каждой системе по-своему, без какой-либо стандартизации. Но управление данными - не главное в САПР. В этих системах приходится решать массу специфических проблем и понятно желание разработчиков САПР пользоваться какими-нибудь стандартными средствами управления данными, лишь бы они удовлетворяли потребностям САПР: требуются эффективный доступ, возможности манипулирования объектами сложной структуры, возможности работы с различными версиями объектов, возможности откатов к предыдущим версиям и т.д.
Появление достаточно эффективных реляционных систем управления базами данных естественно обратило на них внимание разработчиков САПР, которые стали пытаться использовать эти системы как стандартные средства управления данными. Но тогда выяснилось, что возможности систем баз данных, вполне достаточные в традиционных приложениях, не полностью удовлетворяют потребности САПР. К таким особенностям реляционных систем управления базами данных можно отнести следующие:
1. Существует возможность описывать сложные объекты за счет включения в отношения атрибутов соединений. Более того, можно извлечь из базы данных сложный объект (или его представление) за один запрос, но этот запрос при традиционной организации базы данных потребует выполнения нескольких операций соединения и не сможет быть выполнен с требуемой для САПР эффективностью. Кроме того, плоская форма сложного объекта, которую можно получить за счет реляционного запроса, не очень-то удобна для последующей обработки в оперативной памяти.
2. Существует возможность взаимодействовать с базой данных в пределах транзакции, которая является атомарной единицей изменения базы данных и результаты работы которой либо полностью отображаются в состоянии базы данных, либо полностью отсутствуют. Система баз данных гарантирует нормальный конец транзакции только в том случае, если транзакция не нарушила логическую целостность базы данных, причем критерии логической целостности достаточно жестки. Такой механизм транзакций и соответствующей синхронизации непригоден для САПР, критерии логической целостности баз данных которых изменчивы, и даже в соответствии с этими критериями базы данных могут долго находиться в нецелостных состояниях.
3. Система управления базами данных поддерживает информацию о предшествующих состояниях баз данных в форме журналов изменений. Журнал используются системой при восстановлениях баз данных после сбоев процессора или поломок внешних носителей, но пользователи не имеют возможности явного доступа к накопленной в журнале информациии. САПР нуждаются в таких возможностях. Более точно, САПР требуются средства доступа к предыдущим состояниям объектов базы данных.
Резюмируя отмеченные несогласованности между возможностями реляционных систем управления базами данных и потребностями САПР, подчеркнем, что использованию реляционных систем в САПР мешают нормализованность отношений, ограниченность понятия транзакций и отсутствие средств явной работы с предыдущими состояниями объектов. Вместе с тем, все традиционные возможности систем баз данных тоже полезны в САПР, и, следовательно, желательно появление систем управления базами данных, обладающих некоторыми новыми возможностями, но не утративших предыдущие. Работы над развитием традиционных СУБД в этом направлении интенсивно ведутся. В этом разделе мы рассмотрим развитие System R для обеспечения потребностей САПР и других нетрадиционных приложений.
Как мы неоднократно отмечали, System R получила развитие в нескольких направлениях. На базе этой системы возникли два коммерческих продукта фирмы IBM - SQL/DS и DB2, реляционные СУБД, оснащенные всеми необходимыми сервисными средствами. На протяжении ряда лет велись работы над распределенной СУБД System R* . Отдельным направлением является разработка прототипа СУБД для инженерных приложений XSQL [65], и именно на этой системе мы остановимся.
XSQL интересна своим комплексным подходом к решению проблем. Она предоставляет возможности работы со сложными объектами, в ней расширяется традиционное понятие транзакции и т.д. При этом разработчики стремятся в наибольшей степени использовать базовый подход System R, меняя в нем как можно меньше. В частности, базовым языком запросов XSQL остается известный язык SQL, в который добавлены конструкции для определения и манипулирования сложными объектами.
Мы рассмотрим следующие аспекты системы XSQL: подход к организации и управлению сложными объектами; управление транзакциями; управление версиями.
Назад | Содержание | Вперед
Виртуальные VPS серверы в РФ и ЕС
🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях
