Приведем краткие сведения о наиболее широко распространенных базах данных, используемых при реализации систем автоматизированного документооборота в различных отраслях экономики, в том числе в научно-исследовательских организациях и производственных фирмах. Материал данного обзора привяжем к фирмам-производителям соответствующих баз данных.
Решение компании IBM называется A Data Warehouse Plus. Целью компании является обеспечение интегрированного набора программных продуктов и сервисов, основанных на единой архитектуре. Основой хранилищ данных является семейство СУБД DB2. Преимуществом IBM является то, что данные, которые нужно извлечь из оперативной базы данных и поместить в хранилище данных, находятся в системах IBM. Поэтому естественная тесная интеграция программных продуктов.
Предлагаются три решения для хранилищ данных:
Компания Oracle заслуживает особого внимания, поэтому ее решения рассмотрим подробно. Более того, опыт этой компании может оказаться полезным при реализации автоматизированной системы формирования МОК.
Решение компании Oracle в области хранилищ данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области хранилищ данных базируются на следующих составляющих:
Управление распределенными транзакциями.
Переход к использованию Oracle Applications в распределенной среде требует времени и тщательного планирования.
В распределенной среде пользователи выполняют транзакции на двух или более свободно связанных базах данных, которые могут располагаться на одном или нескольких серверах. В качестве примера можно взять опыт перехода к распределенным приложениям компании Cisco Systems, сетевого лидера Internet. Проект перехода разделяется на несколько этапов — от выполнения Oracle Applications на одной базе данных к распределенной среде. В некоторых других случаях компании начинают с нескольких независимых баз данных и объединяют их для совместной работы. Но так или иначе организации могут воспользоваться преимуществами гибкого конфигурирования среды, лучшего распределения нагрузки и устранения сбоев.
Уникальные возможности, различные подходы.
Преимущества перехода к распределенной среде зависят от конкретной ситуации. Организации стремятся распределять приложения, поддерживающие их основной бизнес-процесс, либо по техническим, либо по оперативным причинам, либо по тем и другим одновременно. При этом компания может преследовать следующие цели: децентрализовать определенные бизнес-функции; дать возможность географически удаленным организациям выполнять большую часть бизнес-функций на их собственных базах данных (что может улучшить выполнение для локальных пользователей и дать возможность большего контроля за локальными информационными ресурсами); добиться более тесной интеграции автономных реализаций БД, которые поддерживают пользователей в различных видах деятельности или в разных географических регионах. Примеры — поддержка глобальных представлений, содержащих данные об имеющихся в наличии товарах; возможность отправки любого заказа или его части в какой-либо из источников поставки; включение новой бизнес-модуля в установленную среду с минимальным влиянием на существующие модули; распределение нагрузки, возложенной на одну систему, на несколько групп приложений, чтобы уменьшить риск сбоев; обеспечение возможности обновления приложений путем независимого обновления различных серверов приложений (с минимальным влиянием на другие серверы).
Диапазон опций конфигурации.
В распределенной среде конфигурировать приложения можно по-разному. Так, програмные приложения могут быть распределены по производственным функциям, по типу организации (по регионам или видам деятельности), либо могут сочетать оба способа. Решение, в конечном счете, зависит от общей структуры деятельности предприятия и от того, какие функции должны выполняться централизованно, а какие — нет. Единственным общим требованием является отделение функций управления (администрирования) от функций производства.
При выборе конфигурации для распределенной среды необходимо учитывать следующие моменты:
Рациональность поэтапного выполнения
Для распределенных приложений требуется сеть более сложной конфигурации, которая должна поддерживаться в течение длительного периода. Поскольку в настоящее время Oracle Applications без пользовательского программирования не может обеспечить поддержку распределенной среды, выполнение перехода потребует клиентского конфигурирования для отработки связи между базами данных. И как хорошо известно менеджерам IS, большой объем программирования по заказу клиента может осложнить поддержку и будущие обновления. Программирование по заказу клиента необходимо, когда стандартный открытый интерфейс Oracle Applications не удовлетворяет всем требованиям, например при извлечении информации из посылающей БД и при получении информации базой данных места назначения. Вероятно, возрастет и сетевой трафик за счет объединения трафика между клиентом и сервером пользователей, входящих в отдельную базу данных через WAN, и трафика программных сообщений между БД. Переход к новой конфигурации включает большой объем программирования по заказу клиента и адаптацию к новой технологии, что значительно увеличивает степень риска.
Уровни передачи данных.
Вне зависимости от того, с какой конфигурации компания начинает и к какому результату стремится, распределенная среда должна быть способна передавать информацию из одной базы данных в другую. Уровень передачи данных действует как система очередей и доставок (передача до востребования) между базами данных. Когда в какой-либо БД сети происходит определенное событие, срабатывает уровень передачи данных, выполняющей следующие шаги для завершения распределенной транзакции:
Аналогичные процессы применяются для выполнения сложных распределенных транзакций и передачи простых сущностей данных через серверы. В элементарных случаях нет необходимости хранить событие на исходном узле, потому что оно может быть направлено прямо в очередь передачи данных.
Основной критерий передачи данных.
Уровень передачи данных должен обеспечивать:
Репликация данных.
Oracle8 поддерживает метод передачи данных, называемый симметричной репликацией. Симметричная репликация работает в простой распределенной среде, но можно столкнуться с некоторыми ограничениями. Во-первых, симметричная репликация — это подход, ориентированный на строки: когда база данных выполняет вставку, обновление или удаление строки, это изменение распространяется на идентичные таблицы в других местах. Однако эта технология не поддерживает распределенных транзакций, состоящих из серии событий, которые должны производиться в различных базах данных. Кроме того, симметричные репликации не поддерживают обработку данных перед их копированием — данные передаются в том же виде, в каком они хранились на исходном узле. И наконец, симметричные репликации не обеспечивают динамическую адресацию и проверку корректности данных на удаленном узле; предполагается, что во всех узлах сети действуют одинаковые бизнес-правила. Для выполнения своей задачи уровень передачи данных должен учитывать основные критерии передачи данных, перечисленные выше. Oracle7 поддерживает большинство из них, но существуют определенные ограничения, затрудняющие выполнение некоторых распределенных транзакций. Oracle Services и Oracle Application Development создали инструментарий под названием DTS, Data Transport System («система передачи данных»), который работает без всех указанных ограничений. Сейчас DTS использует те же подчиненные (underlying) удаленные отложенные транзакции, которые применяются в симметричных репликациях (хотя в будущих версиях DTS это может измениться). К тому же сейчас DTS работает с удаленными отложенными транзакциями и использует возможности отложенной транзакции версии 7.1 Oracle и выше, которые позволяют задействовать удаленные вызовы процедур PL/SQL для связи между базами данных Oracle. Удаленный вызов процедуры (Remote Procedure Call, RPC) может быть поставлен в очередь на посылающем узле и затем передан по месту назначения или в несколько мест назначения. При программировании можно создавать удаленные вызовы процедур и в качестве параметров использовать все элементы данных, которые нужно передавать между БД. Удаленные вызовы процедур могут быть сгруппированы в транзакции, которые DTS передаст на удаленный узел и выполнит как часть одного цикла commit.
Распределенное планирование.
Другой необходимой частью инфраструктуры распределенной среды, кроме уровня передачи данных, является распределенное планирование работ. Чтобы создать программы, которые будут выполняться на нескольких базах данных в определенном порядке, разработчикам необходим инструмент, позволяющий планировать работы в распределенной среде. Хотя совершенного инструмента не существует, можно использовать Oracle Workflow с некоторыми небольшими изменениями по заказу клиента. Разработчики Cisco создали собственный планировщик распределенных задач, поскольку в их распоряжении не было Oracle Workflow. В простейшем случае инструмент планирования работ похож на параллельный управляющий и запрашивающий наборы (или параллельные запросы типа «предок-потомок») Oracle Application c возможностью запуска запросов на удаленных узлах базы данных. В более сложном случае он обеспечивает возможность последовательного выполнения действий (Workflow) в распределенной среде. Инструмент планирования работ должен как минимум определять процессы, состоящие из этапов, которые выполняются на распределенных базах данных (этапы могут быть хранимыми процедурами или параллельными программами). Кроме того, он должен контролировать выполнение процессов, сообщать об ошибках и позволять определять место назначения для каждого этапа в ходе выполнения программы. Инструментальное средство Oracle Workflow позволяет выполнять отдельные этапы в процессе работы, но при этом все этапы выполняются на одной базе данных. Oracle Workflow позволяет определять сложные бизнес-правила, контролирующие поток операций. Однако этот инструментарий плохо поддерживает распределенную среду. Например, Oracle Workflow не позволяет определять последовательность выполнения действий с указанием того, что определенные операции должны выполняться на удаленной базе данных. Он обеспечивает программную возможность расширения, что позволяет поддерживать распределенные транзакции. Кроме того, Oracle Workflow поддерживает возможность вызова клиентских процедур и имеет необходимые для этого дополнительные блоки.
Работы, связанные с хранилищами данных, выполняются в рамках программы OpenWarehouse. Выполнение этой программы должно обеспечить возможность построения хранилищ данных на основе мощных компьютеров HP, аппаратуры других производителей и программных компонентов. Основой подхода HP являются Unix-платформы и программный продукт Intelligent Warehouse, который предназначен для управления хранилищами данных. Основа построения хранилищ данных, предлагаемая HP, оставляет свободу выбора реляционной СУБД, средств реинжиниринга и т.д.
Решение компании направлено на решение проблем корпораций, у которых одинаково сильны потребности и в системах поддержки принятия решений, и в системах оперативной аналитической обработки данных. Предлагаемая архитектура называется Enterprise Information Factory и основывается на опыте использования системы управления базами данных Teradata и связанных с ней методах параллельной обработки.
Стратегия компании в отношение хранилищ данных направлена на расширение рынка для ее продукта On-Line Dinamic Parallel Server. Предлагаемая архитектура хранилища данных базируется на четырех технологиях: реляционные базы данных, программном обеспечении для управления хранилищем данных, средствах доступа к данным и платформе открытых систем. Три последние компонента разрабатываются партнерами компании. После выхода Универсального Сервера, основанного на объектно-реляционном подходе, можно ожидать, что и он будет использоваться для построения хранилищ данных.
Компания считает себя поставщиком полного решения для организации хранилища данных. Подход основан на следующем:
Стратегия компании в области хранилищ данных основывается на разработанной ей архитектуре Warehouse WORKS. В основе подхода находится реляционная СУБД Sybase System 11, средство для подключения и доступа к базам данных OmniCONNECT и средство разработки приложений PowerBuilder. Компания продолжает совершенствовать свою СУБД для лучшего удовлетворения потребностей хранилищ данных (например, введена побитная индексация).
Деятельность компании в области хранилищ данных происходит в рамках программы Open Data Warehouse Initiative. Программа базируется на основных продуктах компании ADABAS и Natural 4GL, собственных и приобретенных средствах извлечения и анализа данных, средстве управления хранилищем данных SourcePoint. SourcePoint позволяет автоматизировать процесс извлечения и пересылки данных, а также их загрузки в хранилище данных.
Компания InterSystems продвигает на рынок флагманский продукт постреляционную СУБД Cache’. Компания InterSystems для России — своего рода знакомый незнакомец. Дело в том, что изначально выпускаемые ею продукты базировались на разработках компании DEC, которые были популярны в СССР благодаря клонированию семейства компьютеров PDP-11, известных как СМ-4. За более чем двадцатилетнюю историю, пройдя ряд эволюционных этапов развития, несколько раз поменяв названия продуктов (DBMS, Open M), InterSystems выпустила последнюю версию СУБД, назвав ее Cache’. Это слово французского происхождения, в английском оно обозначает нечто ценное и престижное. Заметим, что в англоязычных компьютерных изданиях можно встретить и менее претенциозное название того же продукта Cach.
InterSystems определяет Cache’ как постреляционную СУБД. Традиционные реляционные СУБД представляют мир несколько упрощенно, в двух измерениях. Реляционная модель базы данных сложного современного приложения состоит из множества таблиц, имеющих сложнейшие взаимосвязи. Для приложений, в которых существенную роль играет скорость обработки транзакций, реляционные СУБД данных зачастую слишком громоздки и медленны. Постреляционная СУБД Cachе’ хранит информацию, используя многомерную модель: представьте себе «куб», у которого столько «граней», сколько нужно, чтобы полностью определить базу данных. В Cache’ все свойства классических СУБД сохранены. Скорость доступа к данным чрезвычайно высока, а так как лишняя информация не хранится, многомерная модель базы данных очень компактна. Cache’ представляет собой полностью интегрированную высокопроизводительную систему управления базами данных и среду быстрой разработки современных приложений, ориентированных на обработку транзакций. Эта постреляционная СУБД основана на транзакционной многомерной модели данных (TMDM). TMDM обеспечивает одновременную работу любого числа клиентов без потери производительности. Двумерные реляционные таблицы используют простую для понимания математическую модель, пригодную для достаточно простых приложений и запросов. Однако в реальной ситуации представляемая в базе данных информация многомерна. Попытки обрабатывать такую информацию в реляционных СУБД неизбежно ведут к неудовлетворительной производительности. В отличие от ранних многомерных СУБД, которые были оптимизированы для «складирования данных», транзакционная модель Cache’ оптимальна для обработки транзакций в системах с большими и сверхбольшими БД (объемы которых измеряются сотнями гигабайт и даже терабайтами) и большим количеством одновременно работающих пользователей. TMDM позволяет разработчикам получить великолепную производительность, отказавшись от хранения избыточных данных и таблиц.
Во многих случаях модели данных и отношений между ними очень сложны, а потому не подходят для использования в реляционной модели. В таких приложениях отчетливо видны все преимущества Cache’. Доступ к постреляционной базе данных Cache’ осуществляется любым из трех способов:
Cache’ Objects объектный доступ, для максимальной продуктивности разработки при использовании Java, ActiveX, C++ и других объектных технологий. Как показывают тесты, производительность Cache’ SQL как минимум в три раза выше, чем у традиционных реляционных СУБД, использующих реляционное ядро.