Фуфаев - Разработка и эксплуатация удалённых БД (1084483), страница 41
Текст из файла (страница 41)
Можно сказать, что СУБД следующего поколения — это прямые наследники реляционных систем. Тем не менее различные направления развития систем третьего поколения стоит рассмотреть отдельно, поскольку они обладают разными характеристиками. Одним из основных положений реляционной модели данных является требование нормализации отношений. Это позволяет проектировать БД с предельно понятной структурой и экономить значительные ресурсы памяти компьютера.
В этом случае для обеспечения целостности информации используются соответствующие связи между таблицами. Однако реляционные СУБД стали применять не только в сфере бизнеса для решения управленческих задач, но и в сфере промышленного производства (СА1.5-технологии). Применение реляционных баз данных оказалось эффективным для разработки систем автоматизированного проектирования технологических процессов 206 (САПРТП), экспертных систем, а также для решения других задачах управления и технической подготовки производства. Такие системы обычно оперируют.
сложноструктурированными объектами — некоторым комплексом логически связанных таблиц, для анализа информации которых, а тем более для выбора рациональных технических решений приходится выполнять сложные запросы. В соответствии с такими задачами применения реляционных БД появилось новое направление их развития.
Суть этого направления сводится к тому, что в системах управления базами данных формируются сложные объекты, объединяющие в себе не только исходные таблицы БД, но и соответствующие запросы. При этом сохраняется четкая граница между логическим и физическим представлениями таких объектов. В,. стности, для любого сложного обьекта (произвольной сложно.ти) обеспечивается возможность перемещения или копирования его как единого целого из одной части базы данных в другую ее часть или даже в друтую базу данных.
Это очень обширная область исследований, в которой затрагиваются вопросы разработки моделей данных, структур данных, языков запросов, управления транзакциями, журнализации и т.д, Новое направление в разработке СУБД хотя и основывается на реляционной модели, но в ней не обязательно поддерживается требование полной нормализации отношений, С расширением области применения реляционного подхода для решения задач, особенно в направлении СААБ-технологий, стало очевидным, что применение принципа нормализации таблиц БД и создание отдельных транзакций и процедур при выполнении различных запросов <сводит на нет» все преимущества нормализованной схемы организации базы данных. В ненормализованных реляционных моделях данных допускается создание и хранение в качестве обьекта (исходного элемента системы) кортежей (запиеей), массивов (регулярных индексированных множеств данных), регулярных множеств элементарных данных, а также отношений.
Системы управления базами данных, в которых формируются такие сложные объекты, называют объектно-ориентированными базами Данных (ООБД ). Очевидно, что эти системы должны обязательно иметь в своем составе языки программирования для создания и управления такими объектами. Кроме того, они должны обрабатывать различные типы данных, в том числе формируемые пользователями. В 1995 г. компания Бцп М1сгозуз1ешз обьявила о выпуске нового продукта — языка из семейства интерпретаторов под названием 'зача. Язык зача является расширенным подмножеством языка Си н-, основное отличие которого состоит в том, что он является пооператорно интерпретируемым (в стиле языка Ваяс), а программы, 207 написанные на языке абаза, гарантированно безопасны (в частности, при выполнении любой программы не может быть поврежден интерпретатор).
Для этого из процедур языка удалены математические действия над указателями. В то же время )ача остается мощным объектно-ориентированным языком, включающим в себя развитые средства определения абстрактных типов данных. Компания Бцп М)сгозуяепзз продвигает язык )аха в целях расширения возможностей сети Интернет.
Основная идея состоит в том, что с %еЬ-сервера клиентам передаются не данные и не результаты обработки данных, а объекты, методы выполнения которых запрограммированы на языке Зауа и выполняются на стороне клиента. 14.2. Генерация систем баз данных, ориентированных на приложения Появление данного направления в развитии СУБД определяется тем, что невозможно создать универсальную систему управления базами данных, которая будет достаточна и не избыточна для применения в любом приложении.
Например, если посмотреть на использование существующих СУБД для решения практических задач в производстве и бизнесе, то можно утверждать, что в большинстве случаев применяется не более 30% возможностей системы. Тем не менее приложение несет большую часть информационной нагрузки поддерживавшей его СУБД, рассчитанной на использование в наиболее обших случаях.
Следовательно, очень заманчиво производить не законченные универсальные СУБД, а нечто вроде компиляторов (сотр(1ег согпр(1ег), позволяющих собрать систему баз данных, ориентированную на конкретное приложение (или класс приложений). Рассмотрим простые примеры.
Так, в системах резервирования проездных билетов запросы обычно настолько просты (например: лвыдать очередное место на рейс )Ч1 645»), что нет смысла производить широкомасштабную оптимизацию запросов. Однако информация, хранящаяся в базе данных, настолько критична (кто из нас не сталкивался с проблемой наличия двух или более билетов на одно место?), что особенно важны гарантированные синхронизация обновлений базы данных и ее восстановление после любого сбоя. В статистических системах запросы могут быть произвольно сложными (например: «выдать число холостых мужчин, проживаюших в России и имевших не менее трех зарегистрированных детейь), что вызывает необходимость использования развитых средств их оптимизации.
Однако поскольку речь идет о статистике, здесь не требуется поддержка строгой сериализации транзакций и точного восстановления базы данных после сбоев. (Когда 208 речь идет о статистической информации, потеря нескольких ее единиц обычно не существенна.) Из сказанного следует, что желательно уметь генерировать систему баз данных, возможности которой в достаточной степени соответствуют потребностям приложения.
На сегодняшний день на коммерческом рынке такие генерационные системы отсутствуют (например, при выборе сервера системы Огас)е при разработке конкретного приложения нельзя отказаться от каких-либо свойств системы). 14.3. Оптимизация запросов, управпяемых правилами Под оптимизацией запросов в реляционных СУБД обычно подразумевают такой способ их обработки, при котором по начальному представлению запроса в результате преобразований вырабатывается оптимальный процедурный план его выполнения.
Соответствующие преобразования начального представления запроса выполняются специальным компонентом СУБД вЂ” оптимизатором, и оптимальность производимого им плана выполнения запроса носит субъективный характер, поскольку критерий оптимальности заложен в него разработчиком. Основная неприятность, связанная с оптимизаторами запросов, заключается в том, что отсутствует принятая технология их программирования. Обычно оптимизатор представляет собой некоторый набор относительно независимых процедур, которые жестко связаны с другими компонентами компилятора. По этой причине очень трудно менять стратегии оптимизации или качественно их расширять (делать это приходится, поскольку оптимизация вообще и оптимизация запросов в частности отражает эмпирические зависимости, а хорошие эмпирические алгоритмы появляются только со временем).
Решают эту проблему с помощью компромиссных решений, не выходящих за пределы традиционной технологии производства компиляторов. В основном все они связаны с применением тех или иных инструментальных средств, обеспечивающих автоматизацию построения компиляторов. Такие инструментальные средства имеются, например, в системах РВ2, Огас)е, !пГогщ)х.
14.4. Поддержка динамической информации и темпорапьных запросов Обычные реляционные БД хранят мгновенный снимок модели предметной области. Любое изменение в момент времени г неко- 209 торого объекта приводит к недоступности состояния этого объекта в предыдущий момент времени. На самом деле в большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но возможности доступа к нему со стороны пользователя нет.
Конечно, можно ввести в хранимые отношения временной атрибут и поддерживать его значения на уровне приложений. В большинстве случаев так и поступают. Так, в стандарте Я.Н. появились специальные типы данных: Наге и голе. Но в таком подходе имеются недостатки: СУБД не знает семантики временного поля отношения и не может контролировать корректность его значений.
В связи с этим появляется дополнительная избыточность хранения (предыдущее состояние объекта хранится и в основной БД, и в журнале изменений). Сушествует отдельное направление исследований и разработок в области так называемых темпоральных БД, где исследуются вопросы моделирования данных, языки запросов, организация данных во внешней памяти и т.д. Основные темпоральные системы на том принципе, что для любого объекта данных, созданного в момент времени Г, и уничтоженного в момент времени гь в БД сохраняются (и доступны пользователям) все его состояния во временном интервале (гь Я.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
