Среду хранения данных, управляемую ИПС, характеризует в основном следующее:

· отсутствие структуризации данных, известной ИПС; как правило, в таких системах хранятся полнотекстовые документы, структура которых (если речь идет о структурированных документах) известна соответствующим приложениям;

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

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

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

ИПС по естественным причинам никогда не претендовали на роль СУБД. Однако обратное неверно, и многие производители СУБД пытаются ввести в состав своих продуктов возможности, позволяющие использовать их в качестве систем информационного поиска. Нужно заметить, что особых успехов в этой деятельности не видно. Главным образом, это связано с реляционной спецификой современных серверов баз данных, с их ориентацией на обеспечение эффективного доступа к структурированной информации. С другой стороны, многие возможности серверов баз данных в действительности не требуются для поддержки полнотекстовой информации. К таким возможностям можно отнести развитые средства управления транзакциями, организацию развитых средств динамического обновления данных, реализацию структурированных языков запросов и т.д.

В дальнейшем в этом разделе курса мы не будем затрагивать специфические свойства ИПС. Это связано не с тем, что мы считаем это направление недостаточно существенным для организации информационных систем. Все дело в том, что в настоящее время основной областью применения ИПС являются распределенные информационные системы, базирующиеся на Web-технологии. Естественно, имеются смежные вопросы, касающиеся, например, возможностей доступа к традиционным базам данных в среде Internet. Тем не менее, однако, обе эти области достаточно широки по отдельности, чтобы можно было рассматривать их независимо.

6.1 Новые веяния в области серверов реляционных баз данных

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

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

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

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

Понятно, что ограничением ненормализованных реляционных баз данных является обязательность иерархической организации хранимой информации. Конечно, это совсем другой уровень построения информации, чем тот, который поддерживался в дореляционных иерархических системах. Между элементами данных отсутствуют явно проводимые физические ссылки. Упрощена процедура реструктуризации данных (в частности, в ненормализованной реляционной модели предполагается наличие пары операций nest/unnest, позволяющих сделать существующую таблицу элементом, хранимым в столбце другой таблицы, или "вытянуть" на верхний уровень некоторую вложенную таблицу). Тем не менее, общая структура остается иерархической. Во многих случаях этого достаточно (в частности, для решения проблемы, упоминавшегося выше примера Эстер Дайсон).

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

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

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

Что касается связи с предыдущими работами в области баз данных, то наиболее сильное влияние на работы в области ООБД оказали проработки реляционных СУБД и следующего хронологически за ними семейства БД, в которых поддерживалось управление сложными объектами. Эти работы обеспечили структурную основу организации OOБД.

Среди языков и систем программирования наибольшее первичное влияние на ООБД оказал Smalltalk. Этот язык сам по себе не являлся полностью пионерским, хотя в нем была введена новая терминология, являющаяся теперь наиболее распространенной в объектно-ориентированном программировании. На самом деле, Smalltalk основан на ряде ранее выдвинутых концепций.

В наиболее общей и классической постановке объектно-ориентированный подход базируется на следующих концепциях:

1. объекта и идентификатора объекта;

2. атрибутов и методов;

3. классов;

4. иерархии и наследования классов.

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

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

Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.

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

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

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

С точки зрения разработчиков информационных систем подход OOБД кажется очень заманчивым. Более того, на рынке программных продуктов управления базами данных сегодня существует около двух десятков коммерческих систем, которые более или менее успешно продаются (примерами таких систем являются O2 компании O2 Technology (www.o2tech.com), ObjectStore компании ObjectDesignInc., (www.odi.com), Objectivity/DB компании Objectivity, Inc., Versant компании VersantObjectTechnology (www.versant.com), ONTOSDB компании ONTOS, Inc., (www.ontos.com) и т.д.). Во всех этих системах поддерживается возможность распределенного хранения баз данных; имеется возможность написания приложений и/или методов объектов на одном или нескольких языках объектно-ориентированного программирования (как правило, в минимальный набор языков входят Си++ и Java); обеспечиваются удобные средства доступа к базам данных в среде Internet и т.д. Тем не менее, объектно-ориентированные системы оказались не в состоянии конкурировать с реляционными системами, поставляемыми ведущей шестеркой поставщиков программных средств управления базами данных.

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

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

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

Рис. 8.1. Ортогональность языков программирования и языков баз данных

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

Рис. 8.2. Сглаживание ортогональности средствами языка SQL

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

Заметим, что в последнее время ситуация изменилась. В результате деятельности международного консорциума ObjectDatabaseManagementGroup (ODMG) был выработан стандарт языка запросов (OQL - ObjectQueryLanguage) к ООБД (в июле 1997 г. опубликована его вторая версия). Этот язык ненавигационный и синтаксически близок к языку SQL. Но для текущего поколения объектно-ориентированных СУБД язык OQL появился слишком поздно, и с этим связана вторая причина неудачи объектно-ориентированных СУБД на рынке.

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

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

6.1.1 Обзор современного состояния рынка серверов баз данных

Естественно, мы не можем в этом подразделе достаточно детально представить даже наиболее известных производителей серверных продуктов реляционных баз данных и собственно эти продукты. Это связано и с тем, что по поводу каждой компании можно сказать очень много, и с тем, что серверные продукты управления базами данных являются, по всей видимости наиболее сложными программными продуктами, присутствующими на рынке, и с тем, что компании-производители серверных продуктов очень не любят открывать технические детали реализации (это считается частью "know-how" компании). Мы постараемся охарактеризовать деятельность и продукты ведущей шестерки производителей (компаний Oracle (www.oracle.com), Informix (www.informix.com), Sybase (www.sybase.com), ComputerAssociates (www.cai.com), IBM (www.ibm.com) и Microsoft (www.microsoft.com)), касаясь только особенностей серверов баз данных и не затрагивая возможности громадного числа сопутствующих программных продуктов. Кроме того, мы не будем обсуждать продукты компаний "второго эшелона", хотя зачастую они обладают оригинальными и специфическими возможностями.

6.1.1.1 История и серверные продукты компании Oracle

Первая доступная заказчикам версия СУБД Oracle (OracleV.2) была выпущена компанией RelationalSoftwareInc. в 1979 г. Эта версия была ориентирована на использование в среде ОС RSX-11 для семейства миникомпьютеров PDP-11. Система была написана большей частью на языке ассемблера PDP-11, но включала также тексты на новом для того времени языке Си. СУБД могла функционировать не только в среде ОС RSX-11, но и в других операционных средах, поддерживаемых на PDP-11: IAS, RSTS и UNIX. Тогда же было принято решение о переносе Oracle в 32-разрядную операционную среду VAXVMS, что на долгие годы определило судьбу СУБД Oracle как ведущей системы управления базами данных на миникомпьютерах.

Наиболее сильное впечатление на пользователей Oracle производила возможность манипулирования базами данных на основе непроцедурного реляционного языка SQL, для которого в то время существовал только фирменный стандарт компании IBM. СУБД OracleV.2 обладала ограниченными возможностями; в частности, в системе отсутствовали средства управления транзакциями, что заставляло пользователей постоянно прибегать к использованию утомительной процедуры резервного копирования.

СУБД OracleV.3 была выпущена в свет в 1983 г. Она была полностью переписана на языке программирования Си, что в дальнейшем позволило решить проблему переноса системы на большое число аппаратно-программных платформ. Функции, доступные через SQL-интерфейс, были расширены. В обиход пользователей системы было введено понятие транзакции. В это же время компания RelationalSoftwareInc. была переименована в OracleCorp.

В 1985 г. на рынке появилась СУБД OracleV.5. В этой системе использовалась архитектура "клиент-сервер" и впервые появилась (ограниченная) возможность одновременного использования баз данных, расположенных в разных узлах сети.

Шестая версия системы представляла из себя инструмент построения корпоративных информационных приложений, выполняющихся в режиме OLTP. В системе были реализованы система блокировок на уровне записей (заметим, что хотя этот уровень блокировок кажется наиболее естественным, переход к его использованию происходил и происходит непросто; в частности, в очень развитых последних по времени продуктах компании Sybase до сих пор используются блокировки на уровне страниц), а также механизм непротиворечивых чтений из базы данных без потребности блокировок (это легко реализуемое оригинальное изобретение Oracle пока не воспроизведено в продуктах других компаний и, естественно, не стандартизовано). СУБД OracleV.6 была перенесена на ряд новых платформ, в том числе, OS/2 и Macintosh.

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

Седьмой выпуск СУБД Oracle появился на рынке в середине 1994 г. Это один из наиболее серьезных серверных продуктов, предназначенных для управления реляционными базами данных. В OracleV.7 используется ряд новых архитектурных решений, направленных на повышение эффективности сервера, в том числе буферизация откомпилированных SQL-операторов на сервере баз данных, использование общего пула серверных процессов и нитей для выполнения операторов SQL, поступающих от разных транзакций, использование разнообразной статистической информации для оптимизации запросов и т.д. Заметим, что именно в седьмой версии начался переход от использования оптимизатора запросов, управляемого правилами, к применению более прогрессивной техники оптимизации запросов на основе статистических оценок.

Существенно расширены возможности использования языка PL/SQL. В OracleV.7 этот язык можно использовать для определения триггеров, хранимых процедур, вызываемых сервером автоматически при возникновении специфицированных событий (например, выполнении операций модификации таблицы в целом или обновлении конкретной строки таблицы). Функции PL/SQL могут вызываться как обычные встроенные функции в операторах SQL. Заметим, что относительным, но существенным недостатком языка PL/SQL является то, что он не входит в состав международного стандарта SQL, хотя многие его свойства нашли отражение в вышедшем в этом году стандарте языка хранимых модулей, являющемся частью будущего стандарта SQL-3.

В распределенном варианте OracleV.7 поддерживаются возможности репликации данных и имеется возможность асинхронного вызова удаленных процедур.

Летом 1997 г. был объявлен выпуск восьмой версии системы, которая должна обладать целым рядом новых возможностей: встроенными средствами для использования в Internet/Intranet, поддержкой хранения мультимедийной информации, приближением реализованного варианта языка SQL к разрабатываемому стандарту языка SQL-3 и т.д. Поскольку эта версия (Oracle 8.1) является переходной от реляционного к объектно-реляционному подходу.

6.1.1.2 История и серверные продукты компании Informix

24 сентября 1996 г. компания Informix отметила десятилетие своей официальной деятельности. За эти годы компания увеличила объем своих доходов в 33 раза и уверенно занимает второе место на мировом рынке продуктов, связанных с управлением реляционными базами данных. С самого начала своего существования компания ориентировалась на создание серверов баз данных и сопутствующих программных продуктов, функционирующих в среде ОС UNIX. В число основных стратегических партнеров Informix входят компании Sequent, HewlettPaсkard, SunMicrosystems, IBM, SiemensNixdorf, NCR, для продуктов которых в первую очередь обеспечиваются новые работоспособные версии систем Informix. Помимо UNIX-платформ продукты компании Informix могут работать в операционных средах DOS, NetWare, Windows и WindowsNT.

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

Самым простым серверным продуктом является сервер баз данных Informix-SE. Он предназначен для использования в информационных системах со средним (или малым) объемом хранимой информации. Хранение данных поддерживается на уровне файловой системы, и на этом же уровне осуществляется синхронизация доступа со стороны параллельно выполняемых транзакций. На самом деле, в Informix-SE для каждой пользовательской транзакции образуется отдельный серверный процесс, и эти процессы взаимодействуют только при доступе к общим файлам базы данных. (Заметим, что это сильно напоминает организацию систем управления базами данных для персональных компьютеров.) Клиент и сервер могут располагаться в одном компьютере, но могут быть и разнесены на разные компьютеры, связанные сетью. Естественно, что при наличии выделенной аппаратуры, поддерживающей деятельность сервера, общая эффективность системы возрастает. Связь между клиентами и серверами поддерживается специальным модулем Informix-NET.

Базовым продуктом компании Informix является система Informix-OnLine, выпускаемая ныне в двух основных модификациях - Informix-OnLineDynamicServer и Informix-OnLineExtendedParallelServer. Эти серверы работают напрямую с дисковой памятью, обеспечивают выполнение транзакций в распределенной среде баз данных, поддерживают возможности хранения неструктурированных полей таблиц сверхбольшого размера (BLOBs - BinaryLargeObjects) и т.д.

Informix-OnLineDynamicServer ориентирован на применение симметричных мультипроцессорных компьютеров и опирается на параллельное использование процессоров с общей основной памятью. Поэтому в этом сервере широко используются приемы программирования, основанные на использование параллельных потоков управления, или нитей.

Informix-OnLineExtendedParallelServer может работать как в симметричных, так в несимметричных (sharingnothing) компьютерных архитектурах. При использовании несимметричных архитектур обещается наличие почти линейной масштабируемости.

В конце 1996 г. компания Informix объявила о выпуске объектно-реляционного сервера InformixUniversalServer. Поскольку этот продукт относится к новому поколению систем управления базами данных, отложим его обсуждение до п.10.1.4.

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

6.1.1.3 Серверные продукты компании Sybase

Компания Sybase является сравнительно новой на рынке конкурирующих производителей современных реляционных СУБД. Это одновременно дает компании ряд преимуществ и усложняет ее работу, хотя, несмотря на некоторые временные неудачи, продукты Sybase находятся на третьем месте в мире по числу продаж. Преимущества компании состоят в том, что она не настолько обремлена грузом предыдущих разработок и необходимостью их постоянной поддержки. Преимуществом является и то, что Sybase с меньшими потерями переходит к использованию новых архитектурных и технологических решений. Усложняет же работу компании тот факт, что при выпуске каждого очередного варианта сервера БД ей приходится решать множество новых архитектурных и технологических проблем (никуда не денешься: если компания провозглашает себя лидером в области архитектур и технологий серверов баз данных, то она должна поддерживать марку).

До выпуска в 1994 г. полномасштабного серверного продукта SybaseV.10 компания Sybase уверенно зарекомендовала себя в качестве ведущего производителя современных СУБД для применения в средних и малых информационных приложениях. Полностью основанная на архитектуре "клиент-сервер" SybaseV.10 могла использоваться на большинстве аппаратно-программных платформ: Sun, HP, IBMRS/6000, DigitalVAX/VMS, DigitalAlphaOpenVMS и AlphaOSF, NCR, NEC, Sequent, SiliconGraphics, NetWare, WindowsNT, OS/2, SCO и т.д. Архитектура SybaseV.10 обладала следующими характерными чертами:

· компонентная структура системы позволяла изменять отдельные компоненты, не нарушая работу других компонентов;

· в системе поддерживалось большинство принятых международных стандартов;

· поддерживалась работа как с другими реляционными источниками данных, так и с источниками данных унаследованных систем;

· обеспечивалась простая переносимость системы;

· система хорошо оптимизировалась для использования в данной предметной области, поскольку отдельные функциональные компоненты могли настраиваться независимо один от другого;

· гарантировалась высокая надежность системы: изменения, вносимые в один компонент не влияли на надежность других компонентов; были реализованы и расширены такие средства стандарта языка SQL-92, как хранимые процедуры, триггеры, средства поддержания ссылочной целостности, определяемые пользователем типы данных и т.д.;

· поддерживалось специфицированное X/Open управление распределенными транзакциями;

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

В общем, по своим идеям система была правильной. К сожалению, как это свойственно компаниям, имеющим серьезных конкурентов, Sybase слишком поторопилась с выпуском на рынок SybaseV.10. Система появилась на рынке не вполне отлаженной, и это привело к тому, что в 1995-1996 гг. многие потенциальные и реальные покупатели перестали иметь с ней дело. Такого эффекта очень легко добиться, но его трудно устранить. В начале 1996 г. компания объявила о выпуске нового продукта, SybaseV.11.

В основной состав серверных продуктов SybaseV.11 входит следующее:

· Базовый сервер SybaseSQLServer - современная высокопроизводительная СУБД (более подробно по поводу этого продукта см. ниже);

· SybaseMPP - расширение архитектуры SybaseSQLServer, предназначенного для эффективного использования в массивно параллельных компьютерных архитектурах с поддержкой сверхбольших баз данных (VeryLargeDataBases - VLDB);

· SybaseIQ - серверное средство построения битовых индексов для высокоскоростного выполнения запросов к большим источникам информации;

· SybaseSQLAnywhere - полнофункциональная "облегченная" СУБД, приобретенная от компании Watcom и предназначенная для производства индивидуальных и групповых информационных систем на платформах Intel;

· SybaseReplicationServer - серверный продукт, поддерживающий репликацию данных;

· SybaseOmniServer - сервер, обеспечивающий "прозрачную" работу клиентов с несколькими серверами баз данных, вообще говоря, различных производителей: Sybase, Oracle, DB2 и т.д.

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

В соответствии с утверждениями представителей компании Sybase, продукт SybaseSQLServer 11 обладает следующими основными возможностями:

1. Масштабируемость и эффективность SQLServer 11 основываются на тщательно проверенной технологии:

· сервер может работать на большом числе платформ, начиная от персональных компьютеров и заканчивая мощными мультипроцессорными серверами;

· на каждой платформе обеспечивается очень высокая эффективность (без настройки на конкретную платформу обойтись нельзя!) благодаря тесному взаимодействию с производителями аппаратуры и базового программного обеспечения;

· в ядре СУБД используется полностью симметричная многопотоковая архитектура, позволяющая использовать возможности аппаратуры и поддерживающая большое число пользователей.

2. SQLServer 11 обеспечивает надежность хранения и целостность данных:

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

· как и полагается SQL-ориентированной СУБД, SQLServer 11 поддерживает уровень безопасности данных C2 в соответствии с требованиями Оранжевой Книги Министерства обороны США.

3. Обеспечивается повышенная доступность данных:

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

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

4. В SQLServer 11 обеспечивается соответствие основным принятым формально или фактически стандартам:

· реализованный в системе вариант языка SQL полностью соответствует стандарту SQL-89, а также ядерному уровню (entrylevel) стандарта SQL-92;

· поддерживается выполнение приложений, выполненных в стандартах ODBC и X/OpenXA;

· применяются различные сетевые протоколы, что позволяет соединить клиента и сервера практически на любой платформе.

5. Гарантируется простота управления системой и ее поддержки:

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

· при использовании симметричной мультипроцессорной аппаратной организации можно указывать количество процессоров, которые должны использоваться для целей СУБД;

· можно управлять распределением областей внешней памяти, контролировать доступ пользователей к БД и т.д. в масштабах индивидуальной системы, масштабах ограниченного предприятия или масштабах реальной корпоративной сети.

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

В сентябре 1997 г. компания Sybase выпустила на рынок продукт под новым названием - SybaseAdaptiveServer, который на самом деле является пятым выпуском версии 11. В этом продукте еще более развита компонентная организация, улучшены возможности организации распределенных баз данных, внедрены более развитые средства интеграции с технологией Internet и т. д. Пока неизвестны какие-либо планы компании по переходу к объектно-реля- ционным архитектурам.

6.1.1.4 Линия серверных продуктов CA-OpenIngres компании ComputerAssociates

Проект и экспериментальный вариант СУБД Ingres были разработаны в университете Беркли под руководством одного из наиболее известных в мире ученых и специалистов в области баз данных Майкла Стоунбрейкера (MichaelStonebraker). С самого начала СУБД Ingres разрабатывалась как мобильная система, функционирующая в среде ОС UNIX. Первая версия Ingres была рассчитана на 16-разрядные компьютеры и работала главным образом на машинах серии PDP. Это была первая СУБД, распространяемая бесплатно для использования в университетах. Впоследствии группа Стоунбрейкера перенесла Ingres в среду ОС UNIXBSD, которая также была разработана в университете Беркли. Семейство СУБД Ingres из университета Беркли принято называть "университетской Ingres" (соответствующие программные продукты вместе с исходными текстами и документацией до сих пор доступны в секторе publicdomainInternet).

В начале 80-х была образована компания RTI (RelationalTechnologyInc.) для сведения университетских прототипов до уровня коммерческих продуктов. С этого момента стали различать университетскую и коммерческую СУБД Ingres. В настоящее время коммерческая Ingres поддерживается, развивается и продается компанией ComputerAssociates. Сейчас это одна из наиболее развитых коммерческих реляционных СУБД.

Мы коснемся главным образом особенностей базового серверного продукта компании ComputerAssociates линии CA-OpenIngres - CA-OpenIngres/Server. Сервер базируется на следующих пяти ключевых архитектурных принципах компании ComputerAssociates:

· использование многопоточной и мультипроцессорной организации сервера для систем оперативной обработки транзакций (OLTP - OnLineTransactionProcessing);

· применение более развитых методов обработки данных для систем уровня OLAP (OnLineAnalyticalProcessing);

· безопасное и надежное управление данными информационных приложений;

· обеспечение расширенных инструментальных средств администрирования серверной части системы (это вообще конек компании; у них больше всего внимания обращается на администрирование и управление систем);

· возможность гибкой настройки сервера в соответствии с конкретными потребностями корпорации.

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

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

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

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

В CA-OpenIngres поддерживаются стандарты SQL-89 и ядерный уровень языка SQL-92. (Обратите внимание, что никто из ведущих производителей не гарантирует полной совместимости с SQL-92. Это очень плохо, поскольку уже на протяжении более чем 4 лет, ни одна компания не может или не хочет произвести продукт, полностью соответствующий требованиям хорошего международного стандарта. Правда, и стандарт несколько сложноват.)

Очень интересным направлением развития линии CA-OpenIngres явилось приобретение японской объектно-ориентированной СУБД Jasmin. Это оригинальная объектно-ориентированная система, модель данных которой основывается одновременно на идеях Smalltalk и Си++. Компания ComputerAssociates считает, что в принципе невозможно сочетать в одной системе объектно-ориентированный и реляционный подходы (в частности, отметим по-прежнему существующую проблему потери соответствия объектных и реляционных операций, присущую объектно-реляционным системам).

Поэтому в ближайших планах компании содержатся намерения одновременного поддержания объектно-ориентированного и реляционного интерфейсов доступа к базам данных, среда хранения которых будет поддерживаться OpenIngres. Сама же СУБД OpenIngres поддерживает возможности шлюзования для доступа к унаследованным системам баз данных (в частности, IDMS), что обеспечивает полную преемственность по отношению к ранее разработанным и накопленным хранилищам данных. К сожалению, в текстах, распространяемых компанией CA, содержится слишком мало технической информации относительно Jasmin. Однако достоверно известно, что объектно-ориентированные возможности управления данными широко используются в новом продукте компании, предназначенном для управления и администрирования глобально распределенных корпоративных приложений и называемом TNG (TheNextGenerationofUniCenter).

В июне 1997 г. компания CA объявила о выпуске новой версии OpenIngres 2.0. Кроме улучшенных возможностей репликации и наличия развитых средств интеграции с Internet, в OpenIngres появились следующие новые возможности:

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

2. поддержка правил (триггеров) уровня оператора со срабатыванием правила для данного оператора один раз независимо от числа затрагиваемых им строк;

3. реализация всех четырех уровней изоляции транзакций, специфицированных в стандарте языка SQL (READCOMMITTED, REPEATABLEREAD, SERIALIZABLE и READUNCOMMITTED);

4. наличие средств параллельного копирования базы данных, хранимых на дисковых накопителях с разными контроллерами;

5. улучшенные средства управления пространственными данными, включая индексацию на основе R-деревьев;

6. возможность выбора размера страницы для хранения индивидуальной таблицы;

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

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

О конкретных работах, связанных с интеграцией с объектно-ориентированной СУБД Jasmine, пока не сообщается.

6.1.1.5 Серверные продукты линии DB2 компании IBM

Серьезные практические исследования в области систем управления реляционными базами данных компания IBM начала с проекта экспериментальной системы SystemR, которая разрабатывалась в исследовательской лаборатории фирмы IBM в 1975-1979 г.г. Эта работа оказала революционизирующее влияние на развитие теории и практики реляционных систем во всем мире. Именно SystemR практически доказала жизнеспособность реляционного подхода к управлению базами данных.

После успешного завершения работ по созданию этой системы и получения экспериментальных результатов ее использования был разработан целый ряд коммерчески доступных реляционных систем, в том числе и на основе непосредственного развития SystemR (возможности одной из коммерчески доступных реляционных систем - DB2 описываются в переведенной на русский язык книге К. Дейта "Руководство по реляционной СУБД DB2", хотя книга существенно отстала от практики; ее прекрасный перевод на русский язык вышел в свет в 1988 г.). Исключительно важен опыт, приобретенный при разработке этой системы. Практически во всех более поздних реляционных СУБД в той или иной степени используются методы, примененные в SystemR.

На наш взгляд, компания IBM много потеряла, ориентируя DB2 только на использование своих аппаратно-программных платформ. Первый вариант DB2 работал на IBM/370 в операционной среде OS/370. В связи с развитием аппаратуры и программного обеспечения мейнфреймов система была перенесена в операционную среду MVS. Программное обеспечение специализированного аппаратно-программного комплекса AS/400 также во многом основано на DB2. После разработки операционной системы OS/2 появился вариант DB2, пригодный для использования на персональных компьютерах. СУБД DB2 всегда представляла собой развитый программный продукт управления реляционными базами данных. В ней всегда присутствовали, в частности, такие возможности как управление транзакциями, журнализация изменений и восстановление согласованного состояния базы данных после сбоев программного обеспечения и/или аппаратуры. Заметим, что именно IBM выпустила первый корпоративный стандарт языка SQL.

Развитие системы и сферы ее применений ограничивало то, что отсутствовал мобильный текст системы. Ориентируясь на использование DB2 на своих аппаратных платформах, компания IBM исторически использовала для программирования DB2 смесь языка ассемблера и языка PL/1. Прорывом как для DB2, так и для IBM в целом стало появление Unix-ориентированной серии серверов и рабочих станций RS/6000. Именно при создании варианта системы DB2/6000 компания была вынуждена переписать систему на языке Си. После этого появилась очевидная возможность простого переноса СУБД на другие аппаратные платформы. В последнее время IBM объявила выпуск DB2 для аппаратно-программных платформ Sun и HP. По мнению автора курса, этот шаг означает появление на рынке независимых серверных продуктов управления реляционными базами данных очень серьезного и достойного конкурента. Коротко охарактеризуем основные возможности наиболее распространенной в настоящее время версии DB2 Version 2: