Корпоративные сети

1. Возможности, соответствующие требованиям реляционной модели данных:

· Поддерживаются почти соответствующие полному стандарту SQL-92 средства обеспечения ссылочной целостности. Для таблицы-предка можно объявить правила удаления строк Restrict, NoAction, Cascade или SetNulls, в соответствии с которыми будут обрабатываться соответствующие строки таблицы-потомка. (При применении правила Restrict будет запрещено удаление строки таблицы-предка, если на эту строку ссылается хотя бы одна строка таблицы-потомка; задание правила Cascade приводит к автоматическому удалению ссылающихся строк таблицы-потомка; при указании правила SetNulls в поле ссылки ссылающихся строк автоматически устанавливаются неопределенные значения; правило NoAction, которое действует подобно правилу Restricted, но с другим диагностическим сообщением, устанавливается при определении ограничений ссылочной целостности по умолчанию).

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

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

2. Объекты базы данных:

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

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

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

3. Возможности запросов:

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

· Поддерживаются все разновидности соединений, определенные в SQL-92, но синтаксис соответствующих конструкций отличается от стандартного.

4. Поддержка доступа из Internet:

· Специальный шлюз, встроенный в сервер, обеспечивает доступ к данным DB2, транслируя команды HTML в операторы языка SQL.

IBM активно ведет работу по созданию собственного универсального сервера. С августа 1997 г. доступна бета-версия DB2 UniversalDatabase. Этот продукт относится к категории объектно-реляционных, и мы кратко обсудим его возможности позже.

6.1.1.6 Серверные продукты управления базами данных компании Microsoft

Первые работы компании Microsoft, относящиеся к области баз данных, проводились совместно с компанией Sybase, причем Microsoft поддерживала линию OS/2, а Sybase - UNIX. Так продолжалось до 1992 г., когда компания Microsoft приняла решение о переносе SQL-сервера на платформу WindowsNT. (Заметим, кстати, что недаром серверные продукты Sybase и Microsoft называются SybaseSQLServer и MicrosoftSQLServer соответственно; у этих продуктов общие корни.) Перенос SQL сервера в среду NT сопровождался существенными переделками ядра системы и в основном был выполнен специалистами Microsoft. Первая по-настоящему работоспособная версия сервера (MSSQLServer 4.21) вышла в свет в 1994 г. для использования в среде NT 3.5. Особое внимание обращалось на развитие средств администрирования, внедрение (в час- тности, и для собственного использования) механизма хранимых процедур и т.д. В 1995 г. была выпущена версия 6.0, в которой был внедрен ряд средств, обеспечивающих удобные взаимодействия с другими продуктами Microsoft. Наконец, в 1996 г. появилась наиболее современная версия 6.5.

Перечислим основные возможности MicrosoftSQLServer 6.5:

1. в ядре сервера может выполняться несколько нитей, что позволяет эффективно использовать симметричные мультипроцессорные компьютеры (SMP - SymmetricMultiprocessorProcessors);

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

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

4. при оптимизации запросов используется статистическая информация;

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

6. поддерживается автоматическая репликация данных на основе журнальной информации или мгновенных снимков, включая доступность репликации в базы данных, доступные через интерфейс ODBC, и репликации "массивных" данных (типов TEXT и IMAGE);

7. обеспечивается двухфазная фиксация распределенных транзакций;

8. реализованы операции CUBE и ROLLUP для работы с многомерными данными в системах оперативной аналитической обработки (OnLineAnalyticalProcessing - OLAP);

9. доступны средства интеграции с системами электронной почты, в частности, с MicrosoftExchangeServer;

10. имеются средства, обеспечивающие доступ к SQL-серверу из Web-серверов и формирование результатов запросов в формате HTML (WebConnector и WebAssistant);

11. развиты возможности администрирования баз данных: SQLEnterpriseManager позволяет с одного терминала управлять произвольным числом SQL-серверов; дополнительные административные процедуры могут разрабатываться на VisualBasic со встроенным SQL;

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

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

Microsoft не объявляет о планах перехода к использованию объектно-реляционного подхода. Пока развитие SQL-сервера происходит в рамках все большего внедрения в этот продукт компонентов, основанных на общей объектной архитектуре COM (ComponentObjectArchitecture - компонентная объектная архитектура). Основываясь на спецификациях OLE (ObjectLinkingandEmbedding - связывание и встраивание объектов), которые обеспечивают объектное представление различных сервисов операционной системы, а также развитие OLE - OLEDB, компания Microsoft пытается обеспечить пользователям общую объектную среду компонентов (включая данные, поддерживаемые SQL-сервером, которые могут разнообразным образом комбинироваться).

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

Как мы отмечали в вводной части этого раздела, реляционные базы данных обладают достоинствами и недостатками. Для некоторых приложений перевешивают достоинства, для других - недостатки. Можно сказать, что современные серверы реляционных баз данных (такие как Infor- mixOnLine версии 6 и выше, Oracle 7.x, SybaseV.11) обладают качествами, близкими к предельно возможным при использовании традиционной технологии. Еще возможны совершенствование оптимизации запросов, применение более эффективных методов распараллеливания, реализация более высоких уровней стандарта SQL и т.д., но принципиально при этом ничего не изменится. Реляционные СУБД могут управлять очень большими базами данных; эффективно используют возможности симметричных и массивно параллельных компьютеров; позволяют хранить в таблицах текстовую и графическую информацию произвольного размера; поддерживают достаточно развитое подмножество языка SQL; обеспечивают возможности частичного переноса логики приложений на сторону сервера за счет использования ограничений целостности, триггеров и хранимых процедур.

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

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

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

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

6.1.3 Преобразование реляционного подхода к организации баз данных в объектно-реляционный подход

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

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

Объектно-реляционный подход возник как эволюционная альтернатива революционному объектно-ориентированному подходу. Заметим, что термин "объектно-реляционные СУБД" вошел в обиход далеко не сразу, и даже сейчас системы соответствующего класса часто характеризуются другими терминами. Точкой отсчета можно считать опубликование в 1990 г. "Манифеста систем баз данных третьего поколения" (перевод на русский язык опубликован в журнале "СУБД", N 2, 1995 г.). В этом манифесте выдвигалась идея и обосновывались преимущества эволюционного развития возможностей СУБД без коренной ломки предыдущих подходов и с сохранением преемственности с системами предыдущего поколения. Частично требования к системам следующего поколения включали просто необходимость реализации давно известных свойств, которые отсутствовали в большинстве текущих реляционных СУБД (ограничения целостности общего вида, триггеры, модификация БД через представления и т.д.). В число новых требований входили полнота системы типов, поддерживаемых в СУБД; поддержка иерархии и наследования типов; возможность управления сложными объектами и т.д.

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

Термин "объектно-реляционная СУБД" был внедрен в обиход Майклом Стоунбрейкером, идейным руководителем проектов свободно распространяемых систем Ingres и Postgres и основателем компании Illustra, выпустившей одноименный коммерческий продукт. (На самом деле, система Illustra является хорошо отлаженным и документированным вариантом Postgres). В Postgres были реализованы многие интересные средства, свойственные системам третьего поколения: поддерживалась темпоральная модель хранения и доступа к данным и в связи с этим был абсолютно пересмотрен механизм журнализации изменений, откатов транзакций и восстановления БД после сбоев; обеспечивался мощный механизм ограничений целостности; имелась возможность хранения в столбцах таблицы вложенных таблиц. Допускалось хранение в полях таблицы данных абстрактных, определяемых пользователями типов, что обеспечивало возможность внедрения в базу данных поведенческого аспекта.

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

6.1.4 Первые серверные продукты, поддерживающие объектно-реляционный подход

С конца 1996 г. три компании объявили о выпуске серверных продуктов, соответствующих названию "универсальный сервер": Oracle с продуктом Oracle 8, Informix с продуктом InformixUniversalServer и IBM с продуктом DB2 UniversalDatabase. Далее мы приведем краткие характеристики этих систем.

6.1.4.1 Oracle 8

Компания Oracle заявляла, что Oracle 8 будет уметь делать с объектами все, что умеет делать InformixUniversalServer, и даже больше. Однако это не так в первом выпуске Oracle 8 (этот выпуск был официально объявлен 24 июня 1997 г.). В фокусе Oracle 8 находятся расширенная система типов и поддержка бизнес-объектов; появление других возможностей расширяемости ожидается в версии 8.1. Oracle концентрируется на реализации своей сетевой вычислительной архитектуры (NCA - NetworkComputingArchitecture), и в Oracle 8 вносятся улучшенные возможности производительности, масштабируемости, доступности, репликации, разделения дан- ных и т.д.

NCA - это трехзвенная архитектурная структура, основанная на CORBA (CommonObjectRequestBrokerArchitecture - Общая архитектура брокера объектных заявок). В NCA используются расширяющие компоненты, называемые "картриджами", которые могут разрабатываться Oracle или сторонними поставщиками. Впервые использование картриджей приложений и картриджей баз данных потребовалось в OracleWebApplicationServer для организации связи на основе CORBA. В контексте расширяемой среды данных Oracle обеспечивает компоненты на уровне промежуточного программного обеспечения приложений (например, компонент управления транзакциями в WebApplicationServer) и на уровне универсального сервера (Oracle 8). На объектном уровне Oracle 8 поддерживает объектные представления данных с использованием новых объектных типов и существующих реляционных данных. Кроме того, Oracle 8 поддерживает объектный кэш на стороне клиентов и навигацию между объектами по ссылкам. Транслятор объектных типов отображает объекты базы данных в соответствующие конструкции языка Си.

Далее приводится сводка свойств, имеющихся в Oracle 8 и ожидаемых в версии 8.1:

· Расширяемая система типов. Поддерживаются объектные типы, типы коллекций (массивы переменного размера и вложенные таблицы) и ссылочные типы. Объектный тип может применяться либо к столбцу, либо к строке и может быть семантически эквивалентен именованному строчному типу SQL-3. Кроме того, Oracle 8 явно связывает с объектными типами методы. Пока поддерживается только один уровень вложенности таблиц (в 8.0) и не реализована полная инкапсуляция определяемых пользователями типов данных. В версии 8.1 будет поддерживаться одиночное наследование. Не предполагается возможность репликации расширенных данных.

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

· Расширяемая система индексации. Поддержка определяемых пользователями индексных структур и индексов на выражениях появится вместе с компонентом DatabaseExtensibilityServices.

· Расширяемый оптимизатор. Возможность указывать стоимость выполнения определенных пользователями функций и обеспечивать статистику об использовании определенных пользователями данных ожидается с появлением компонента DatabaseExtensibilityServices. К расширенным типам пока не применяются параллельные операции.

· Большие объекты и внешние данные. LOB могут храниться внутри базы данных или во внешних файлах. Oracle 8 не поддерживает доступа по записи к внешним данным и не гарантирует их целостность. Большие объекты могут быть реплицированы, но таблицы с LOB реплицировать нельзя.

· Расширяемая языковая поддержка. Определяемые пользователями типы данных и хранимые процедуры пишутся на PL/SQL или Си/Си++, причем подпрограммы на Си/Си++ выполняются вне адресного пространства сервера. Поддержка Java в сервере будет обеспечиваться в DatabaseExtensibilityServices (версия 8.1).

· Предопределенные расширения. Сервер Oracle 8 поддерживает хранение текстовых, пространственных и видео данных; ожидается появление нового типа данных для хранения графической информации. Компания работает также с несколькими партнерами для тестирования и формализации API для DatabaseExtensibilityServices и разработки картриджей данных.

Как видно, в Oracle 8 компания главным образом сосредоточилась на реализации собственных расширений, которых может оказаться достаточно для начала моделирования бизнес-объектов. Возможности реализации расширений сторонними компаниями менее развиты, чем в продуктах Informix и IBM. Это означает, что пользователи Oracle будут вынуждены более долго ожидать наличия полных наборов строительных блоков для построения новых или улучшения существующих приложений. С другой стороны, развитие продуктов Oracle происходит на основе единой архитектуры NCA, которая закладывает базу расширяемости.

6.1.4.2 InformixUniversalServer

Компания InformixSoftware приобрела реальные шансы стать лидером сектора объектно-реляционных систем после приобретения компании Illustra в начале 1996 г. (Заметим, что сотрудниками компании стали все основные разработчики СУБД Illustra, включая М.Стоунбрейкера.) Многие авторитетные специалисты компьютерной индустрии скептически относились к решению компании произвести слияние продуктов Informix-OnLine 7.2 и IllustraServer к концу того же года. Однако компания Informix действительно смогла выпустить в конце декабря устойчивую версию InformixUniversalServer, работающую на трех платформах. К лету 1997 г. UniversalServer был доступен на 10 платформах.

Компания сконцентрировалась прежде всего на общей архитектуре универсального сервера. Внимание обращается на средства, обеспечивающие интеграцию с технологией Internet/Web (с применением продукта WebConnect). Затрагиваются вопросы поддержки сложных данных в средствах разработки и приложениях с использованием недавно объявленного продукта DataDirector (приобретенного вместе с компанией CenterViewSoftware в начале этого года). Этот продукт обеспечивает возможность использования развитых сред разработки (Java, PowerBuilder, VisualBasic и др.), доступ к расширениям в духе SQL-3 и, кроме того, доступ к новым типам данных и функциям UniversalServer.

В своем первом выпуске UniversalServer объединяет средства сервера InformixOnLine 7.2 с расширениями, обеспечиваемыми механизмом DataBlade сервера, и языковыми расширениями, основанными на идеях SQL-3. Новые возможности включают следующее:

· Расширяемую систему типов для интеграции определяемых пользователями типов данных, уточненных типов, абстрактных типов данных, строчных типов и типов коллекций, включая возможность неограниченной вложенности таблиц. Поддерживается простое наследование в иерархии именованных строчных типов. Каждая таблица, основанная на строчном типе, становится типизированной таблицей и может использоваться в этой иерархии. В будущем ожидается появление ссылочных типов и абстрактных типов данных в стиле SQL-3, а также средств репликации данных определяемых пользователями типов.

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

· Расширяемую систему индексирования - R-деревья, применение индексов на основе B-деревьев к определяемым пользователями типам данных, определяемые пользователями индексные структуры.

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

· Возможность хранения больших объектов (LOB - LargeObjects) внутри базы данных или во внешних файлах. Пока UniversalServer не гарантирует целостность данных, хранимых во внешних файлах, но Informix имеет на этот счет планы. Интерфейс виртуальной таблицы позволяет регистрировать внешние данные в каталогах базы данных и обращаться к ним таким же образом как если бы они были таблицами, непосредственно поддерживаемыми универсальным сервером.

· Наличие предопределенных расширений: Informix подрядил много сторонних поставщиков для написания DataBlades - упакованных наборов расширений, относящихся к некоторым прикладным областям (текстовому поиску, управлению графической информацией, финансовому анализу и т.д.). DataBlade интегрируется с ядром IUS на основе специального интерфейса уровня вызовов (DataBladeAPI). К июню 1997 г. планировалось иметь в поставке 20 DataBlade, еще 10 находятся в стадии бета-тестирования, к концу года ожидается иметь около 50 готовых к поставке DataBlade. В настоящее время имеется два режима выполнения DataBlade - в адресном пространстве ядра (это дает наибольшую эффективность) и в отдельном виртуальном процессоре (более безопасный режим).

· Расширенный набор языков приложений - в дополнение к поддержке разработки пользовательских типов данных на основе собственной среды NewEraInformix теперь обеспечивает новое средство разработки клиентских приложений DataDirector, которое дает возможность связи между данными, контролируемыми приложением, и данными, хранимыми в среде UniversalServer. В этом средстве используются собственные интерфейсы с универсальным сервером (JavaAPI и Си++ API), а не ODBC. Кроме того, DataDirector поддерживает языковые расширения в духе SQL-3.

Одной из проблем компании Informix, связанной с форсированным внедрением объектно-реляционных средств, является сохранение позиции на бизнес-рынке, которую компании удалось занять на основе InformixOnLine 7.x. До слияния с Illustra основное внимание уделялось производительности и масштабируемости на основе разных видов параллелизма, и именно это определяло лицо Informix на рынке. С появлением UniversalServer эти важные качества продуктов отошли на второй план. Кроме того, компания должна принимать во внимание наличие трех разных серверов баз данных - UniversalServer, OnLine и ExtendedParallelServer.

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

6.1.4.3 IBMDB2 UniversalDatabase

Компания IBM ведет исследования в области инфраструктуры расширяемых реляционных баз данных в течение более чем десяти лет. Компания была первой из основных поставщиков, выпустившим на рынок реляционный сервер баз данных с объектными расширениями: DB2 CommonServer 2 (в июле 1995 г.). Теперь IBM готова начать поставки обновленного продукта с новым названием - DB2 UniversalDatabase, представляющего собой слияние начальных объектно-реляционных свойств DB2 CommonServer 2.1 с возможностями параллельной обработки DB2 ParallelEdition 1.2 и доступного на разнообразных мультипроцессорных платформах (симметричных, кластерных и массивно-параллельных). Ключевым моментом является то, что продукты IBM основаны на едином исходном тексте сервера. Это обеспечивает основу новых разработок, тем более что расширения с самого начала базируются на полностью параллельных средах.

Стратегия IBM в области объектно-реляционных баз данных включает четыре основных компонента. Во-первых, универсальная база данных DB2 (UniversalDatabase) находится в стадии бета-тестирования и должна начать поставляться в третьем квартале 1997 г. Во-вторых, разновидность определяемых пользователями типов данных - сильные связи с файлами (robustfilelinks) позволяет DB2 UniversalDatabase активно управлять внешне хранимыми данными с соблюдением требований безопасности и целостности. Реализация этой возможности ожидается к концу 1997 г. Третий компонент стратегии компании - DataJoiner - промежуточное программное обеспечение для доступа к неоднородным базам данных. Этот компонент включает все функциональные возможности сервера DB2, глобальный оптимизатор с расширяемыми знаниями о поддерживаемых источниках данных, возможность компенсировать функциональные различия между этими источниками. В планы компании входит расширение возможностей DataJoiner для работы с объектно-реляционными расширениями. Наконец, IBM разрабатывает компонент объектного слоя, называемый ClientObjectSupport, который обеспечит единое логическое представление всех доступных данных, а также их транзакционную согласованность, управление кэшами клиентов и интеграцию с объектно-ориентированными языками.

Вот сводка расширенных возможностей DB2 UniversalDatabase и средств, которые планируется включить в будущие выпуски:

· Расширяемая система типов - уточненные типы, абстрактные типы данных и объекты OLE с поддержкой в будущем абстрактных типов данных в стиле SQL-3, строчных типов, типов коллекций, ссылок, множественного наследования и репликации данных.

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

· Расширяемая система индексации. IBM обеспечивает свои собственные индексы специального назначения для типов данных, поддерживаемых расширителями DB2 (DB2 RelationalExtenders). В будущих версиях будут поддерживаться определяемые пользователями индексные структуры, навигационный доступ через ссылки и возможность строить индексы на выражениях, на результатах вызовов функций и на атрибутах абстрактных типов данных.

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

· Большие объекты и внешние данные. LOB может храниться внутри базы данных или во внешних файлах. На сегодняшний день DB2 обеспечивает доступ к данным, хранимым вне сервера; в будущих выпусках (к концу 1997 г.) будет гарантироваться и целостность на основе механизма сильных связей с файлами.

· Расширяемая языковая поддержка. Определяемые пользователем функции могут быть написаны на языках Си, Си++, VisualBasic или Java; хранимые процедуры могут писаться на языках третьего и четвертого поколения и Java. Ожидается появление языковых расширений в стиле SQL-3 для обеих целей.

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

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

6.1.5 Решения ведущих производителей серверов баз данных для их интеграции с технологией Internet/Intranet

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

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

6.1.5.1 Решения компании Oracle

Компания Oracle предлагает семейство продуктов WebSystem, предназначенных для облегчения разработки приложений, в которых используются средства Web и базы данных. Семейство включает следующие продукты: OracleWebServer, OracleWebServerOption и OraclePowerBrowser. Продукты основаны на стандартах Web-технологии (HTML, HTTP, SHTTP - SecureHypertextTransferProtocol), сетевых стандартах (TCP/IP, ISDN и т.д.) и стандартах объектных технологий (OLE, CORBA, OpenDoc).

WebServer объединяет сервер баз данных, сервер HTTP и OracleWebAgent. Для поддержки мультимедийной информации WebServer имеет интерфейсы с OracleTextServer и OracleMediaServer. В совокупности эти продукты создают полную среду мультимедиа для построения корпоративных Web-приложений.

Ключевой частью OracleWebServer является WebAgent, который дает возможность Web-клиентам вызывать хранимые процедуры и создавать "на лету" динамические HTML-страницы. Фактически, WebAgent представляет собой шлюз, подключаемый к Web-серверу через CGI (CommonGatewayInterface) и обеспечивающий расширяемые возможности формирования страниц HTML.

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

WebServerOption содержит только сервер HTTP и WebAgent и предназначен для тех заказчиков, у которых уже имеется сервер баз данных и которые желают пользоваться Web-техно- логией.

Наконец, OraclePowerBrowser представляет собой среду разработки Web-приложений на рабочих станциях. Пакет включает развитый браузер, реляционную СУБД Blaze, средства разработки HTML-страниц, локальный Web-сервер и другие средства. Доступны версии PowerBrowser для платформ Microsoft, Macintosh, OS/2 и Motif/UNIX.

6.1.5.2 Решения компании Informix

Компания Informix предлагает продукт UniversalWebConnect, обеспечивающий возможность разработки Web-приложений, которые могут иметь доступ к любой информации, хранимой в базах данных Informix. Для разработки приложений на стороне клиента или сервера промежуточного уровня могут использоваться различные языки: Си, Си++, Java, ActiveX и т.д. Кроме того, WebConnect позволяет обеспечивать широковещательную рассылку информации подписавшимся на нее пользователям.

Для построения интеллектуальных Web-приложений WebConnect обеспечивает следующие сервисы:

· URL-интерфейс (UniversalResourceLocator). Этот интерфейс дает разработчикам Web-приложений единую точку доступа к логике приложения и информации, содержащейся в базе данных. Такая информация может включать динамически конструируемые или статические HTML-страницы и соответствующие мультимедийные данные. Для быстрой и персонализированной доставки пользователям этой информации WebConnect передает URL серверу баз данных.

· Страницы приложений (AppPages). AppPage - это HTML-страница со встроенными операторами SQL, на основании которой конструируется документ, отображаемый браузером. AppPage может включать скрипты JavaScript и апплеты Java.

· Программный интерфейс. Набор соответствующих средств позволяет просто переносить приложения "клиент-сервер" в среду Web или разрабатывать новые такие приложения. С помощью этого интерфейса обеспечивается стыковка с объектными брокерами (в частности, основанными на CORBA).

· Подписка и оповещение. Этот сервис дает возможность посетителям Web-узла подписаться на конкретную информацию, в частности, пользователи смогут получать электронные сообщения об изменениях базы данных.

· Безопасность. Обеспечивается возможность авторизации и аутентификации на уровне сервера баз данных. Это дает возможность распространить систему безопасности баз данных на Web-сервер.

6.1.5.3 Решения компании Sybase

Компания Sybase и ее дочерняя компания Powersoft поставляют несколько продуктов, предназначенных для производства Web-приложений, которые имеют доступ к базам данных. Кратко охарактеризуем некоторые из них. (Заметим, что в силу общей ориентации Sybase на компонентную архитектуру, в большинстве случаев эти продукты представляют собой компоненты, которые могут встраиваться в разные продукты.)

NetImpactDynamo - компонент, содержащий средства для построения сложных, динамических, связанных с базами данных Web-узлов. В настоящее время этот компонент поставляется в составе продукта SybaseSQLAnywhereProfessional.

jConnect - полная реализация на языке Java стандарта JDBC. Продукт дает возможность непосредственного доступа к базам данных (без использования промежуточного Web-сервера) из Java-приложений.

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

Продукт Sybaseweb.sql дает возможность встраивать операторы SQL и скрипты, написанные на языке Perl, в HTML-страницы, что позволяет создавать персонализированные и кастомизированные страницы.

6.1.5.4 Решения компании IBM

Для интеграции технологии баз данных и Web-технологии компания IBM предлагает продукт DB2 WorldWideWebConnection. Этот продукт представляет собой шлюз с Internet и предназначен для работы с семейством серверов реляционных баз данных DB2 и семейством Web-серверов и защитных экранов (firewall). Кроме того, DB2 WWWConnection работает с продуктами IBM категории промежуточного программного обеспечения, что дает возможность Web-доступа к другим источникам данных.

Web-приложения для DB2, построенные с помощью DB2 WWWConnection, позволяют пользователю использовать для доступа к базам данных из стандартного браузера без потребности в каких бы то ни было изменениях в существующих структурах данных. На основе стандартных языков HTML и SQL строятся приложения, которые взаимодействуют с DB2 с помощью обычных операторов SQL.

Возможно построение двух- или трехзвенных архитектур "клиент-сервер". При двухзвенной организации используются клиентские рабочие места с Web-браузерами и Web-сервер, на котором и производится доступ к DB2. В трехзвенной среде Web-сервер обращается к другим серверам баз данных. Связующие возможности обеспечиваются средствами DistributedDatabaseConnectionServices (DDCS), ClientApplicationEnabler (CAE) и DistributedRelationalDatabaseArchitectureApplicationRequester (DRDAAR).

В трехзвенной организации допускается использование продукта DataJoiner, при применении которого обеспечивается возможность Web-доступа к базам данных Oracle, Sybase, MicrosoftSQLServer и другим реляционным и нереляционным источникам данных. Для повышения уровня безопасности приложений используется криптография.

В настоящее время продукт DB2 WWWConnection доступен на платформах OS/2, AIX, OS/400, MVS/ESA, WindowsNT, Solaris, HP/UX.

6.1.5.5 Решения компании ComputerAssociates

Компания ComputerAssociatesInternational включила средства интеграции с Web-технологией в новый выпуск OpenIngres 2.0. В дополнение к существовавшей в предыдущих версиях системы возможности устанавливать связь между Web-сервером и сервером баз данных на основе CGI, в выпуске 2.0 реализованы встроенные интерфейсные средства для связи с Web-серверами компаний Microsoft, Netscape и Spyglass. Новый макропроцессор позволяет встраивать операторы SQL прямо в HTML-страницы. Во время работы Web-сервер обращается с такими операторами к OpenIngres.

8.1.5.6. Решения компании Microsoft

Компания Microsoft поставляет целый ряд продуктов, предназначенных для разработки Web-приложений, работающих с базами данных. Большая часть этих продуктов входит в состав крупных серверных средств.

В состав MicrosoftSQLServer входит средство SQLServerWebAssistant. Основное назначение этого средства - формировать динамическую HTML-страницу на основе результата SQL-оператора выборки из базы данных.

Внутренним компонентом MicrosoftInternetInformationServer является InternetDatabaseConnector (IDC). Фактически, этот компонент является встроенным шлюзом с SQL-сервером. Получая от браузера HTML-страницу (например, заполненную форму), IDC обращается к SQL-серверу с соответствующим запросом. После получения результатов IDC формирует возвращаемую пользователю HTML-страницу. Другим ключевым компонентом InformationServer является ActiveServerPages (ASP). Это средство позволяет встраивать в HTML-страницы скрипты, написанные на языках VisualBasicScriptingLanguage и Jscript, которые могут производить доступ к ресурсам (приложениям, базам данных и т.д.), расположенным на локальном InformationServer или на других серверах.

6.2 Склады данных и системы оперативной аналитической обработки

В этом разделе мы рассмотрим вопросы организации специального класса информационных приложений, ориентированных не на оперативную обработку транзакций (onLineTransactionProcessing - OLTP), а на оперативную аналитическую обработку (OnLineAnalyticalProcessing - OLAP). Значимость аналитических систем непрерывно возрастает. Любая серьезная компания независимо от вида ее бизнеса нуждается не только в непрерывной оперативной транзакционной поддержке, но и в средствах анализа и прогнозирования как своей собственной деятельности, так и деятельности своих поставщиков, потребителей, партнеров и конкурентов.

6.2.1 Чем отличаются системы оперативной обработки транзакций и системы оперативной аналитической обработки?

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

Система оперативной аналитической обработки данных отличается от статической системы поддержки принятия решений (DecisionSupportSystem - DSS) тем, что OLAP-система позволяет аналитику динамически формировать класс вопросов, который требуется для решаемой им текущей аналитической задачи. DSS обеспечивает выдачу отчетов в соответствии с заранее сформулированными правилами. Для удовлетворения нового запроса нужно формально его описать, запрограммировать и только потом выполнить.

Тематика OLAP-систем очень широка и специальна. Мы не будем обсуждать соответствующие вопросы на глубоком уровне, а в основном (и тоже не очень глубоко) сосредоточимся на проблемах обеспечения OLAP-системы данными. Мы будем говорить о складах данных (Datawarehouse).

6.2.2 Что вызвало появление понятия склада данных?

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

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

Итак, в основе концепции склада данных лежат две основные идеи:

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

2. Разделение наборов данных, используемых для оперативной обработки, и наборов данных, применяемых для решения задач анализа.

6.2.3 Необходимые свойства склада данных

Обычно выделяют следующие основные свойства, которыми должен обладать склад данных:

· неоднородность программной среды;

· распределенный характер организации;

· повышенные требования к безопасности данных;

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

· потребность в эффективном хранении и обработке очень больших объемов информации.

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

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

Собранная вместе согласованная информация об истории развития корпорации, ее успехах и неудачах, о взаимоотношениях с поставщиками и заказчиками, об истории и состоянии рынка дает возможность анализа прошлой и текущей деятельности корпорации и построения прогнозов для будущего. Эта информация настолько ценна для корпорации, что нельзя допустить возможности ее утечки (на самом деле, если склад данных одной корпорации попадет в руки аналитиков другой корпорации, то все аналитические прогнозы первой корпорации сразу станут неверными). В системах, основанных на складах данных, оказывается недостаточной защита данных в стиле языка SQL, которую обеспечивают обычные коммерческие СУБД (этот уровень защиты соответствует классу C2 в соответствии с классификацией Оранжевой Книги Министерства обороны США). Для обеспечения должного уровня защиты доступ к данным должен контролироваться не только на уровне таблиц и их столбцов, но и на уровне отдельных строк (это уже соответствует классу B1 Оранжевой Книги). Приходится также решать вопросы аутентификации пользователей, защиты данных при их перемещении в склад данных из оперативных баз данных и внешних источников, защиты данных при их передаче по сети.

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

· Описания структур данных, их взаимосвязей.

· Информация о хранимых на складе данных и поддерживаемых им агрегатах данных.

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

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

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

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

Уже сейчас известны примеры складов данных, содержащих терабайты информации. По данным консалтинговой компании MetaGroup, около половины корпораций, использующих или планирующих использовать склады данных предполагает довести их объем до сотен гигабайт. Проблемой таких больших хранилищ является то, что накладные расходы на внешнюю память возрастают нелинейно при возрастании объема хранилища. Исследования, проведенные на основе тестового набора TPC-D, показали, что для баз данных объемом в 100 гигабайт потребуется внешняя память объемом в 4.87 раза большая, чем нужно собственно для полезных данных. При дальнейшем росте баз данных этот коэффициент увеличивается.

Последнее, на чем мы остановимся в этом разделе, - это рынки данных (DataMart; кстати ведущий специалист Московского отделения компании Informix Ховард Залкин предпочитает называть их "лавками данных"). Рынок данных по своему исходному определению - это набор тематически связанных баз данных, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации. По сути дела, рынок данных - это облегченный вариант склада данных, содержащий только тематически объединенные данные. Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Рынок данных, естественно, существенно меньше по объему, чем корпоративный склад данных, и для его реализации не требуется особо мощная вычислительная техника.