Динамическая масштабируемая архитектура

Архитектура сервера Informix-ODS получила название "динамическая масштабируемая
архитектура" (DSA). Суть ее заключается в том, что одновременно выполняется относительно
небольшое число серверных процессов (виртуальных процессоров, ВП), которые разделяют между
собой работу по обслуживанию множества клиентов. По сравнению с более ранними моделями
сервера INFORMIX, где для каждого клиента создавался индивидуальный серверный процесс,
новая модель обладает рядом преимуществ:


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

для многопроцессорных платформ:


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


на нескольких процессорах.

Архитектуру Informix-ODS называют также многопотоковой. Для каждого клиента создается один
или несколько потоков, т.е. подзадач, выполняемых в рамках одного из ВП. Потоки создаются
также для выполнения внутренних задач сервера - ввода-вывода, журнализации,
администрирования и др.

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

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

Определение Дэйта.

Лучшее, на мой взгляд, определение распределенных баз данных (DDB) предложил Дэйт (C.J. Date)
в . Он установил 12 свойств или качеств идеальной DDB:


Локальная автономия (local autonomy)
Независимость узлов (no reliance on central site)
Непрерывные операции (continuous operation)
Прозрачность расположения (location independence)
Прозрачная фрагментация (fragmentation independence)
Прозрачное тиражирование (replication independence)
Обработка распределенных запросов (distributed query processing)
Обработка распределенных транзакций (distributed transaction processing)
Независимость от оборудования (hardware independence)
Независимость от операционных систем (operationg system independence)
Прозрачность сети (network independence)
Независимость от баз данных (database independence)

Локальная автономия

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

Независимость от центрального узла

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

Непрерывные операции

Это качество можно трактовать как возможность непрерывного доступа к данным (известное "24
часа в сутки, семь дней в неделю") в рамках DDB вне зависимости от их расположения и вне
зависимости от операций, выполняемых на локальных узлах. Это качество можно выразить
лозунгом "данные доступны всегда, а операции над ними выполняются непрерывно".

Прозрачность расположения

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

Прозрачная фрагментация

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

Рассмотрим пример, иллюстрирующий оба типа фрагментации. Имеется таблица employee
(emp_id, emp_name, phone), определенная в базе данных на узле в Фениксе. Имеется точно такая же
таблица, определенная в базе данных на узле в Денвере. Обе таблицы хранят информацию о
сотрудниках компании. Кроме того, в базе данных на узле в Далласе определена таблица
emp_salary (emp_id, salary). Тогда запрос "получить информацию о сотрудниках компании" может
быть сформулирован так:

SELECT * FROM employee@phoenix, employee@denver ORDER BY
emp_id

В то же время запрос "получить информацию о заработной плате сотрудников компании"
будет выглядеть следующим образом:

SELECT employee.emp_id, emp_name, salary FROM employee@denver,
employee@phoenix, emp_salary@dallas ORDER BY emp_id

Прозрачность тиражирования

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



Обработка распределенных запросов

Это свойство DDB трактуется как возможность выполнения операций выборки над
распределенной базой данных, сформулированных в рамках обычного запроса на языке SQL. То
есть операцию выборки из DDB можно сформулировать с помощью тех же языковых средств, что
и операцию над локальной базой данных. Например,

SELECT customer.name, customer.address, order.number, order.date FROM
customer@london, order@paris WHERE customer.cust_number = order.cust_number

Обработка распределенных транзакций

Это качество DDB можно трактовать как возможность выполнения операций обновления
распределенной базы данных (INSERT, UPDATE, DELETE), не разрушающее целостность и
согласованность данных. Эта цель достигается применением двухфазового или двухфазного
протокола фиксации транзакций (two-phase commit protocol), ставшего фактическим стандартом
обработки распределенных транзакций. Его применение гарантирует согласованное изменение
данных на нескольких узлах в рамках распределенной (или, как ее еще называют, глобальной)
транзакции.

Независимость от оборудования

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

Независимость от операционных систем

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

Прозрачность сети

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

Независимость от баз данных

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

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

Посмотрим, во что выливается некоторые наиболее важные свойства DDB, если рассматривать их
практически.

Стандартизация языка SQL

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

В 1992 г. был принят новый стандарт SQL-92. Этот язык существенно более сложен, чем SQL-89, а
конструкции SQL-92 специфицированы в стандарте существенно более полно. Первой компанией,
которая объявила о соответствии своего продукта новому стандарту, была компания Oracle со
своей седьмой версией (это произошло прямо в 1992 г.). Теперь и все остальные компании обещают
вскоре выпустить продукты, соответствующие стандарту SQL-92.

Кроме того, как это бывает всегда, производители стремятся добавить к своим продуктам
качества, превышающие требования стандарта. Например, современные версии Oracle и Ingres
содержат возможности определения тригеров (подробнее об этом см. ниже), в системе uniVerse
компании VMark поддерживается расширенная ненормализованная реляционная модель и т.д.
Другими словами, компании стремятся смотреть в будущее, предвидя требования следующего
стандарта SQL (его условно называют SQL-3; ожидалось принятие этого стандарта в 1995 г., но
теперь уже говорят про 1997 г.).

Целостность данных

В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой
сложную проблему. Ее решение - синхронное и согласованное изменение данных в нескольких
локальных базах данных, составляющих DDB - достигается применением протокола двухфазной
фиксации транзакций. Если DDB однородна - то есть на всех узлах данные хранятся в формате
одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм
двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для
обеспечения согласованных изменений в нескольких базах данных используют менеджеры
распределенных транзакций. Это, однако, возможно, если участники обработки распределенной
транзакции - СУБД, функционирующие на узлах системы, поддерживают XA-интерфейс,
определенный в спецификации DTP консорциума X/Open. В настоящее время XA-интерфейс имеют
CA-OpenIngres, Informix, Microsoft SQL Server, Oracle, Sybase.

Если в DDB предусмотрено тиражирование данных, то это сразу предъявляет дополнительные
жесткие требования к дисциплине поддержки целостности данных на узлах, куда направлены
потоки тиражируемых данных. Проблема в том, что изменения в данных инициируются как
локально - на данном узле - так и извне, посредством тиражирования. Неизбежно возникают
конфликты по изменениям, которые необходимо отслеживать и разрешать.

Использование мультипроцессорных организаций

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

Однако с появлением на рынке мультипроцессорных симметричных аппаратных архитектур,
производители СУБД были вынуждены пересмотреть организацию своих серверов, допустив в них
внутреннюю параллельность. Естественно, это требует очень основательного перепроектирования
системы с ее существенным усложнением. Заметим, что в большинстве случаев компании пошли на
это после появления в ОС UNIX механизма "легковесных" процессов (threads).

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

Разделяемая память

Разделяемая память - это механизм операционной системы, на котором основано разделение
данных между виртуальными процессорами и потоками сервера. Разделение данных
позволяет:


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

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

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

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

Интеграция и интероперабильность

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

В большинстве случаев предлагаемые решения основываются на использовании индустриальных
стандартов распределенных объектных систем (например, стандарта CORBA, разработанного
OMG). Тем не менее производители СУБД вынуждены решать многочисленные проблемы для
вхождения их систем в новые интегрированные среды.

Оптимизация дисковых операций

Операции ввода-вывода, как правило, образуют наиболее медленную компоненту обработки баз
данных. Поэтому от их реализации существенно зависит общая продуктивность

сервера. Для В сервере Informix-ODS применяются следующие механизмы, которые способствуют
оптимизации ввода-вывода и повышению надежности:


Собственное управление дисковой памятью;
Асинхронный ввод-вывод;
Опережающее чтение.

Прозрачность расположения

Это качество DDB в реальных продуктах должно поддерживаться соответствующими
механизмами. Разработчики СУБД придерживаются различных подходов. Рассмотрим пример из
Oracle. Допустим, что DDB включает локальную базу данных, которая размещена на узле в
Лондоне. Создадим вначале ссылку (database link), связав ее с символическим именем
(london_unix), транслируемым в IP-адрес узла в Лондоне.

CREATE PUBLIC DATABASE LINK london.com CONNECT TO london_unix
USING oracle_user_ID;

Теперь мы можем явно обращаться к базе данных на этом узле, запрашивая, например, в
операторе SELECT таблицу, хранящуюся в этой базе:

SELECT customer.cust_name, order.order_date FROM customer@london.com,
order WHERE customer.cust_number = order.cust_number;

Очевидно, однако, что мы написали запрос, зависящий от расположения базы данных,
поскольку явно использовали в нем ссылку. Определим customer и customer@london.com как
синонимы:

CREATE SYNONYM customer FOR customer@london.com;

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

SELECT customer.cust_name, order.order_date FROM customer, order WHERE
customer.cust_number = order.cust_number

Задача решается с помощью оператора SQL CREATE SYNONYM, который позволяет
создавать новые имена для существующих таблиц. При этом оказывается возможным обращаться
к другим базам данных и к другим компьютерам. Так, запись в СУБД Informix

CREATE SYNONYM customer FOR client@central:smith.customer

означает, что любое обращение к таблице customer в открытой базе данных будет
автоматически переадресовано на компьютер central в базу данных client к таблице customer.
Оказывается возможным переместить таблицу из одной базы данных в другую, оставив в первой
базе ссылку на ее новое местонахождение, при этом все необходимые действия для доступа к
содержимому таблицы будут сделаны автоматически.

Мы уже говорили выше о горизонтальной фрагментации. Рассмотрим пример иерархически
организованной DDB, на каждом из узлов которой содержится некоторое подмножество записей
таблицы customer:


С помощью CREATE SYNONYM можно определить, например, таблицу структуры customer,
в которой хранятся строки с записями о клиентах компании, находящихся в Японии:

CREATE SYNONYM japan_customer FOR customer@hq.sales.asia.japan

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

Обработка распределенных запросов

Выше уже упоминалось это качество DDB. Обработка распределенных запросов (Distributed Query
-DQ) - задача, более сложная, нежели обработка локальных и она требует интеллектуального
решения с помощью особого компонента - оптимизатора DQ. Обратимся к базе данных,
распределенной по двум узлам сети. Таблица detail хранится на одном узле, таблица supplier - на
другом. Размер первой таблицы - 10000 строк, размер второй - 100 строк (множество деталей
поставляется небольшим числом поставщиков). Допустим, что выполняется запрос:

SELECT detail_name, supplier_name, supplier_address
FROM detail, supplier
WHERE detail.supplier_number = supplier.supplier_number;

Результирующая таблица представляет собой объединение таблиц detail и supplier,
выполненное по столбцу detail.supplier_number (внешний ключ) и supplier.supplier_number
(первичный ключ).

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

Межоперабельность

В контексте DDB межоперабельность означает две вещи. Во-первых, - это качество, позволяющее
обмениваться данными между базами данных различных поставщиков. Как, например,
тиражировать данные из базы данных Informix в Oracle и наоборот? Известно, что штатные
средства тиражирования в составе данной конкретной СУБД позволяют переносить данные в
однородную базу. Так, средствами CA-Ingres/Replicator можно тиражировать данные только из
Ingres в Ingres. Как быть в неоднородной DDB? Ответом стало появление продуктов,
выполняющих тиражирование между разнородными базами данных.

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

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

Технология тиражирования данных

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

Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных в
базы, принадлежащим различным узлам распределенной системы. Функции DR выполняет, как
правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором
(так устроены СУБД CA-OpenIngres и Sybase). В Informix-OnLine Dynamic Server репликатор
встроен в сервер, в Oracle 7 для использования DR необходимо приобрести дополнительно к
Oracle7 DBMS опцию Replication Option.

Специфика механизмов DR зависит от используемой СУБД. Простейший вариант DR -
использование "моментальных снимков" (snapshot). Рассмотрим пример из Oracle:

CREATE SNAPSHOT unfilled_orders
REFRASH COMPLETE
START WITH TO_DATE ('DD-MON-YY HH23:MI:55')
NEXT SYSDATE + 7
AS SELECT customer_name, customer_address, order_date
FROM customer@paris, order@london
WHERE customer.cust_name = order.customer_number AND
order_complete_flag = "N";

"Моментальный снимок" в виде горизонтальной проекции объединения таблиц customer и
order будет выполнен в 23:55 и будет повторятся каждые 7 дней. Каждый раз будут выбираться
только завершенные заказы.

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

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


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

Синхронное обновление DDB и DR-технология - в определенном смысле антиподы. Краеугольный
камень первой - синхронное завершение транзакций одновременно на нескольких узлах
распределенной системы, то есть синхронная фиксация изменений в DDB. Ee "Ахиллесова пята" -
жесткие требования к производительности и надежности каналов связи. Если база данных
распределена по нескольким территориально удаленным узлам, объединенным медленными и
ненадежными каналами связи, а число одновременно работающих пользователей составляет сотни
и выше, то вероятность того, что распределенная транзакция будет зафиксирована в обозримом
временном интервале, становится чрезвычайно малой. В таких условиях (характерных, кстати, для
большинства отечественных организаций) обработка распределенных данных практически
невозможна.

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

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


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

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

Архитектура клиент-сервер, традиционные решения

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


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


На рисунке 2 мы видим традиционное решение в архитектуре клиент-сервер. Клиентские
приложения обращаются к серверу БД (например, InterBase, Oracle, Informix, Sybase, MS SQL через
родные линки или другие (уже через ODBC)). Логика клиентского приложения может быть
написана на Paradox, dBase, Delphi или С/С++. Cледует еще раз отметить, что при этом все
взаимодействие с БД ведется через родные линки компаний-производителей, инкапсулированные
механизмом IDAPI - универсальным механизмом доступа к данным, который предлагает компания
Borland. При этом клиентское приложение может напрямую запрашивать у сервера данные и
оперирует понятиями запросов, транзакций и таблиц. Только в Delphi 2.0 появилась возможность
работы не напрямую, а через монитор транзакций (Taxedo, Encina - см. Рисунок 3).

Что такое объектно-реляционная СУБД?

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

В настоящее время существуют две преобладающие архитектуры: РСУБД и ОСУБД, лишь
частично решающие проблемы управления сложными данными:

РСУБД: нет сложных типов данных.

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

ОСУБД: нет стандартного языка запросов.

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

Интегрированная база данных - констатация идеи

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

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

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

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

Национальные алфавиты и таблицы кодировок

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

В России известно несколько Таблиц Кодировок альтернативная, основная, дополнительная. В
операционных системах DOS, MS-WINDOWS, UNIX также используются различные Таблицы
Кодировок. Рассмотрим как в Progress осуществляется описание, настройка и динамическое
преобразование Таблиц Кодировок для различных операционных систем и оборудования.
Описанный ниже алгоритм позволяет освободить разработчика от задач, связанных с
локализацией продуктов и настройкой их на работу в конкретном операционном окружении, что
значительно облегчает его работу и экономит время, необходимое на разработку и сопровождение
программного продукта.

Вся информация необходимая для настройки Таблиц Кодировок, в PROGRESS они называются
кодовыми страницами, содержится в файле convmap.cp. Этот файл хранится во внутреннем
формате PROGRESS, и создается специальной утилитой из обычного текстового файла
convmap.dat.

В данном файле хранится несколько специальных таблиц, двух типов - определения кодовых
страниц и правил сортировки.


Для каждой кодовой страницы определяется таблица букв - ISALPHA, в которой указывается
является ли символ буквой или нет (знак пунктуации, цифра и т.д.). Progress использует эту
таблицу для проверки символов при вводе с определением формата. Таблица ISALPHA состоит из
256 полей, пронумерованных от 0 до 255. Каждое поле соответствует одному символу кодовой
таблицы. Если символ является буквой, то в соответствующем ему поле стоит значение 001. В
противном случае значение поля равняется 000.

Для каждого символа от 0 до 255, является ли он буквой или нет.
В случае, если символ является
буквой, в таблице 1 на соответствующему ему месте стоит код 001. В противном случае - 000. Тип
таблицы указывает используется ли данная таблица для однобайтовой кодировки или нет.
Значение TYPE 1 указывает, что данная таблица используется для однобайтовых кодировок.

====

CodePAGE

CODEPAGE-NAME "NEW1"

TYPE "1"

ISALPHA

/*000-015*/ 000 000 000 000 000 000 000 000 000 000 000 000 000 000
000 000

/*016-031*/ 000 000 000 000 000 000 000 000 000 000 000 000 000 000
000 000

.

.

/*128-143*/ 001 001 001 001 001 001 001 001 001 001 001 001 001 001
001 001

.

.

/*240-255*/ 000 000 000 000 000 000 000 000 000 000 000 000 000 000
000 000

ENDTABLE

ENDCODEPAGE

Следующие две таблицы - UPPERCASE-MAP и LOWERCASE-MAP, определяют правила
преобразования прописных букв в заглавные и наоборот. Для каждой кодовой страницы
возможно задание нескольких пар таких таблиц. Как правило, используется пара под названием
BASIC. Эти таблицы используются как при вводе информации, так и при выполнении операторов
LowerCase, CAPS и др.

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

Для задания правил сортировки используется две таблицы CASE-SENSITIVE-SORT и CASE-
INSENSITIVE-SORT. В первом случае вначале идут все заглавные буквы, а затем все прописные.
Во втором случае порядок следования символов будет следующим "A", "a", "Б", "б" и т.д.

После определения все этих таблиц необходимо запустить утилиту преобразования получившегося
файла (convmap.dat) во внутренний формат Progress (convmap.cp).

Proutil -C codepage-compiler ....\convmap.dat ....\convmap.cp

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

Общая характеристика CADRE VantageTeam Builder

CASE-технология (Computer Aided Software/System Engineering), как это и следует из названия,
предполагает использование вычислительных средств в качестве инструмента для разработки и
реализации крупных проектов информационных систем. В основе CASE - средств заложена, как
правило, одна из традиционных (по крайней мере на Западе) методологий проектирования. Входящие
в состав CASE - средств инструменты позволяют с той или иной степенью полноты реализовать
соответствующие методы разработки и в той или иной степени контролируют правильность
применения этих методов.

VantageTeam Builder фирмы CADRE позволяет использовать метод структурного проектирования
Yourdon'а с некоторыми дополнительными инструментами. В целом метод
представляется весьма естественным и достаточно прост в освоении как разработчиком, так и
заказчиком (предполагается ознакомление заказчика не только с готовой системой, но и с
предварительными результатами проектирования на разных стадиях проекта) в силу ориентации на
графическое представление всех результатов разработки.

Общие сведения о современном состоянии

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

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


Не первая нормальная форма (NF2 - Non-First Normal Form)


Эта модель данных (рис. 1)традиционна для ADABAS с 1969 года,
когда он впервые вышел на рынок систем обработки данных, по ней большинство пользователей и
знает эту СУБД. Его сегодняшнее название ADABAS C.


Запись базы данных ADABAS C

	Простая группа		Периодическая группа
	Множественное поле
	Множественное поле периодической группы

Распределенные базы данных

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

Реляционные системы

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

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

Цель методологии создания информационных систем

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


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

Методология должна обеспечивать снижение сложности процесса создания ИС за счет полного и
точного описания этого процесса и применения современных методов и технологий создания ИС
на всем жизненном цикле ИС - от замысла до реализации.

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


требований в процессе разработки с тем, чтобы система отвечала требованиям организации на
момент конца разработки, а не на момент начала.

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

Практика показывает, что для успешного создания сложных системы, к которым относятся
корпоративные ИС, недостаточно иметь только современные платформы и средства, а прежние
методологии создания ИС, созданные в 70 - 80-е годы и ориентированные на мэйнфрэймы и
однородную среду, устарели и оказались непригодны в новых условиях. Согласно статистическим
данным, собранным Standish Group (США), из 8380 проектов, обследованных в США в 1994г,
неудачными оказались более 30% проектов общей стоимостью более чем 80 миллиардов долларов.
При этом оказались выполненными в срок лишь 16% от общего числа проектов, а перерасход
средств составил 189% от запланированного бюджета. Анализ показал, что большинство неудач
было связано с отсутствием или неправильным применением методологии проектирования ИС.

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


создания корпоративных ИС. В этой области работают многие ведущие специалисты во всем мире.
В 1994г в Великобритании был создан международный консорциум DSDM (Dynamic Systems
Development Method), объединяющий более 100 ведущих фирм мира, который на постоянной
основе разрабатывает проекты стандартов, методы и методологию быстрого создания приложений
(ИС). В консорциуме участвуют и российские компании.

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

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

Анализ - постановка задачи, общие принципы решения.

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

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

Базы сложных объектов, реляционная модель с отказом от первой нормальной формы

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

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

Фрагментация управления. Неразделение данных

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

На каждом ко-сервере выполняются также компоненты, отвечающие за разбиение запроса на
подзадачи и их распределение между ко-серверами:


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

Для каждого запроса МЗ одного из узлов (того, на который поступил запрос) выступает в роли
координатора. При обработке запроса компоненты взаимодействуют друг с другом: МЗ
обращается к оптимизатору для выработки оптимального плана, оптимизатор обращается к ММД
за информацией о местонахождении данных, готовый план передается планировщику и т. д.

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

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

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

Активные базы данных

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

Легко видеть, что основа этой идеи содержалась в языке SQL времени System R. На самом деле,
что есть определение триггера или условного воздействия как не введение в БД правила, в
соответствии с которым СУБД должна производить дополнительные действия? Плохо лишь то,
что на самом деле триггеры не были полностью реализованы ни в одной из известных систем, даже
и в System R. И это не случайно, потому что реализация такого аппарата в СУБД очень сложна,
накладна и не полностью понятна.

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

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

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

Архитектура - общие принципы решения задачи.

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

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

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

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

Принцип передачи функций

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

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

Дедуктивные базы данных

По определению, дедуктивная БД состоит из двух частей: экстенсиональной, содержащей факты, и
интенсиональной, содержащей правила для логического вывода новых фактов на основе
экстенсиональной части и запроса пользователя.

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

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

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

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

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

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

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

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

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

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

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

Структурные схемы программ - универсальное средство описания функциональных возможностей
приложения. Они позволяют описать любую программу с произвольной точностью (до функции,
до группы операторов, до отдельного оператора, до отдельных составляющих оператора типа
структуры AFTER FIELD в операторе INPUT). Основными элементами структурных схем являются
заголовок или вызов функции, хэт-модуль ("модуль со шляпой", что соответствует используемому для
него обозначению), позволяющий записать произвольные конструкции на языке программирования и
указания относительно их размещения в программном файле (например, из любого хет модуля
можно добавить определение еще одной переменной в секцию описания глобальных, модульных
или локальных переменных, добавить в файл описание еще одной функции и т. п.), операторы выбора
(MENU, IF, IF ... ELSE, CASE), операторы повтора (WHILE, FOR) и библиотечные
(предопределенные или стандартные модули), представляющие собой, как будет показано ниже,
весьма мощный инструмент быстрой разработки приложений.

Темпоральные базы данных

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

Конечно, можно явно ввести в хранимые отношения явный временной атрибут и поддерживать его
значения на уровне приложений. Более того, в большинстве случаев так и поступают. Недаром в
стандарте SQL появились специальные типы данных date и time. Но в таком подходе имеются
несколько недостатков: СУБД не знает семантики временного поля отношения и не может
контролировать корректность его значений; появляется дополнительная избыточность хранения
(предыдущее состояние объекта данных хранится и в основной БД, и в журнале изменений); языки
запросов реляционных СУБД не приспособлены для работы со временем.

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

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

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


эксперименты.

Главными особенностями системы управления памятью в Postgres является, во-первых, то, что в
ней не ведется обычная журнализация изменений базы данных и мгновенно обеспечивается
корректное состояние базы данных после перевызова системы с утратой состояния оперативной
памяти. Во-вторых, система управления памятью поддерживает исторические данные. Запросы
могут содержать временные характеристики интересующих объектов. Реализационно эти два
аспекта связаны.

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

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

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

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

Интегрированные или федеративные системы и мультибазы данных

Направление интегрированных или федеративных систем неоднородных БД и мульти-БД
появилось в связи с необходимостью комплексирования систем БД, основанных на разных моделях
данных и управляемых разными СУБД.

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

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

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

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

СУБД следующего поколения

Термин "системы следующего (или третьего) поколения" вошел в жизнь после опубликования
группой известных специалистов в области БД "Манифеста систем баз данных третьего
поколения". Сторонники этого направления придерживаются принципа эволюционного развития
возможностей СУБД без коренной ломки предыдущих подходов и с сохранением преемственности
с системами предыдущего поколения.

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

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

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

Хотя отнесение СУБД к тому или иному классу в настоящее время может быть выполнено только


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


Направление Postgres. Основная характеристика: максимальное следование (насколько это
возможно с учетом новых требований) известным принципам организации СУБД (если не считать
упоминавшейся коренной переделки системы управления внешней памятью).
Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а
генератора систем, наиболее полно соответствующих потребностям приложений. Решение
достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея
распространяется вплоть до самых базисных слоев системы.
Направление Starburst. Основная характеристика: достижение расширяемости системы и ее
приспосабливаемости к нуждам конкретных приложений путем использования стандартного
механизма управления правилами. По сути дела, система представляет собой некоторый
интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими
правилами. Можно изменять наборы правил (существует специальный язык задания правил) или
изменять действия, подставляя другие модули с тем же интерфейсом.
В целом можно сказать, что СУБД следующего поколения - это прямые наследники реляционных
систем.

Объектно-ориентированные базы данных

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

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

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

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

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

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

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

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

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

ADABAS в корпоративных информационных системах

По классификации Gartner Group (рис. 2)peализация концепции
клиент/сервер в распределенной неоднородной вычислительной среде возможна в следующих
конфигурациях:


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


Модели клиент-сервер
Источник:Gartner GroupКлиент
Сервер

Распределенное отображение данных	Удаленное отображение данных	Распределенное приложение	Доступ к удаленной базе данных	Доступ к распределенной базе данных

Архитектура Illustra

Сравнение архитектур реляционных и объектно-ориентированных СУБД.

Недостатки объектно-ориентированной архитектуры:


Функции СУБД запускаются в пространстве памяти клиента. Отсюда -
высокие требования к клиентской станции.
Нет стандартного языка запросов. Все обращения к базе данных с
помощью библиотек С/С++ или SmallTalk.
Жесткая привязка к языку 3GL.
Негибкость. Для того, чтобы изменить запрос к базе данных, необходимо
переписать и перекомпилировать программу.

Недостатки реляционной архитектуры.


Ограниченная поддержка типов данных.
Компоненты архитектуры предопределены и жестко связаны друг с другом.
Object wrappers чрезвычайно неэффективны.

Архитектура Illustra - основная особенность - расширяемость сервера:


Компоненты сервера управляются системными таблицами.
Сервер можно расширять определяемыми пользователем типами данных,
функциями, новыми методами доступами.
Возможность создавать функциональные индексы для быстрого доступа к
данным.
Модули DataBlade добавляют новые домены данных.

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

Архитектура "клиент-сервер"

Распределенные системы - это системы "клиент-сервер". Существует по меньшей мере три модели
"клиент-сервер" (подробно о них рассказано в ):


Модель доступа к удаленным данным (RDA-модель)
Модель сервера базы данных (DBS-модель)
Модель сервера приложений (AS-модель)

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


Компонент интерфейса с пользователем
Компонент управления данными (и базами данных в том числе)
а между ними расположено программное обеспечение промежуточного слоя (middleware),
выполняющее функции управления транзакциями и коммуникациями, транспортировки запросов,
управления именами и множество других. Middleware - это ГЛАВНЫЙ компонент распределенных
систем и, в частности, DDB-систем. Главная ошибка, которую мы совершаем на нынешнем этапе -
полное игнорирование middleware и использование двухзвенных моделей "клиент-сервер" для
реализации распределенных систем.

Существует фундаментальное различие между технологией "SQL-клиент - SQL-сервер" и
технологией продуктов класса middleware (например, менеджера распределенных транзакций
Tuxedo System). В первом случае клиент явным образом запрашивает данные, зная структуру базы
данных (имеет место так называемый data shipping, то есть "поставка данных" клиенту). Клиент
передает СУБД SQL-запрос, в ответ получает данные. Имеет место жесткая связь типа "точка-
точка", для реализации которой все СУБД используют закрытый SQL-канал (например, Oracle
SQL*Net). Он строится двумя процессами: SQL/Net на компьютере - клиенте и SQL/Net на
компьютере-сервере и порождается по инициативе клиента оператором CONNECT. Канал закрыт
в том смысле, что невозможно, например, написать программу, которая будет шифровать SQL-


запросы по специальному алгоритму (стандартные алгоритмы шифрования, используемые,
например, в Oracle SQL*Net, вряд ли будут сертифицированы ФАПСИ).

В случае трехзвенной схемы клиент явно запрашивает один из сервисов (предоставляемых
прикладным компонентом), передавая ему некоторое сообщение (например) и получает ответ
также в виде сообщения. Клиент направляет запрос в информационную шину (которую строит
Tuxedo System), ничего не зная о месте расположения сервиса. Имеет место так называемый
function shipping (то есть "поставка функций" клиенту). Важно, что для Клиента база данных (в том
числе и DDB) закрыта слоем Сервисов. Более того, он вообще ничего не знает о ее существовании,
так как все операции над базой данных выполняются внутри сервисов.

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

Таким образом, речь идет о двух принципиально разных подходах к построению информационных
систем "клиент-сервер". Первый из них устарел и явно уходит в прошлое. Дело в том, что SQL
(ставший фактическим стандартом общения с реляционными СУБД) был задуман и реализован как
декларативный язык запросов, но отнюдь не как средство взаимодействия "клиент-сервер" (об этой
технологии тогда речи не было). Только потом он был "притянут за уши" разработчиками СУБД в
качестве такого средства. На волне успеха реляционных СУБД в последние годы появилось
множество систем быстрой разработки приложений для реляционных баз данных (VisualBasic,
PowerBuilder, SQL Windows, JAM и т.д.). Все они опирались на принцип генерации кода
приложения на основе связывания элементов интерфейса с пользователем (форм, меню и т.д.) с
таблицами баз данных. И если для быстрого создания несложных приложений с небольшим числом
пользователей этот метод подходит как нельзя лучше, то для создания корпоративных
распределенных информационных систем он абсолютно непригоден.

Для этих задач необходимо применение существенно более гибких систем класса middleware
(Tuxedo System, Teknekron), которые и составляют предмет нашей профессиональной деятельности
и базовый инструментарий при реализации больших проектов.

Идентификация и проверка подлинности пользователей

Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо
соответствующие механизмы операционной системы, либо SQL-оператор CONNECT. Например, в
случае СУБД Oracle оператор CONNECT имеет следующий вид:

CONNECT пользователь[/пароль] [@база_данных];

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

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

Информационное моделирование

В данной статье мы рассмотрим некоторые аспекты информационного моделирования и его
автоматизации с использованием CASE-средства ERwin 2.5 фирмы LogicWorks.

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

Предыдущие версии ERwin - 1.5 и 2.1 - завоевали все возможные призы среди программ своего
класса, в том числе DBMS Readers' Choice в 1992, 1993, 1994, 1995 годах, Software Development
Productivity Award 1993, Data Based Advisor Readers' choice 1992 и 1994. Текущая версия продукта -
2.5.

Реализация моделирования в ERwin базируется на теории реляционных баз данных и на методологии
IDEF1X.

Методология IDEF1X была разработана для ВВС США и теперь используется, в частности, в
правительственных, аэрокосмических и финансовых учреждениях, а также в большом числе частных
компаний.

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

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

Основные составляющие методологии

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

Таким образом, фундамент предлагаемой методологии составляют:


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

Постреляционные системы

В этом разделе очень кратко рассматриваются основные направления исследований и разработок в
области так называемых постреляционных систем, т.е. систем, относящихся к следующему
поколению (хотя термин next-generation DBMS зарезервирован для некоторого подкласса
современных систем).

Сервер Informix-Online EXtended Parallel Server

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

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

Для приложений DSS, имеющих сложный аналитический характер и предполагающих обработку
очень больших массивов данных, критичной может оказаться способность платформы к
наращиванию мощности параллельных вычислений. Число процессоров, которые реально
способны поддерживать сегодняшние системы SMP, ограничено пропускной способностью
системной шины; их практическая масштабируемость обеспечивается лишь с ростом количества
процессоров до 32.

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

Informix-OXPS доступен в настоящее время для платформ IBM SP2, ICL Goldrush, AT&T 5100;
планируются реализации для платформ Pyramid/SNI Reliant RM1000, а также кластерных
платформ Sun Microsystems Inc., Hewlett-Packard Co., Sequent Computer Systems Inc., Silicon
Graphics Inc., Intel. Предполагается, что в перспективе будет обеспечена поддержка всех платформ
этих типов, работающих под управлением ОС UNIX.

Системные сообщения

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

VantageTeam Builder как инструмент аналитика и дизайнера

В соответствии с реализованным в VantageTeam Builder методом работа над проектом разбивается на
четыре фазы: Анализ, Архитектура (в соответствии с отечественными традициями Глобальное
проектирование), Дизайн (соответственно, Детальное проектирование) и Программирование.

За идеей - классическая методология проектирования

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


сбор сведений о ПрО (анализ потребностей и описание ПрО с
использованием так называемых "процессного" или UP, "usage perspective"
подхода и "непроцессного" или ISP, "information structure perspective" подхода);
выбор языка представления т.н. "семантической" модели для фиксации
сведений о ПрО, их последующего анализа и синтеза модели БД;
анализ собранных сведений о ПрО: классификация, формализация и
интеграция структурных элементов описания ПрО, формализация как
структурных, так и процедурных ограничений целостности элементов в
будущей модели ПрО, определение динамики экземпляров объектов ПрО;
синтез концептуальной модели БД: проектирование целостной
концептуальной схемы БД на выбранном языке семантического
моделирования;
выбор конкретной модели данных и СУБД для реализации БД;
проектирование логической схемы БД для выбранной СУБД
(называющееся также "проектирование реализации");
разработка физической структуры БД ("физической" или "внутренней"
схемы, она же - "схема размещения"), включая размещение БД по узлам;
разработка технологии и процедур начального создания и заполнения БД;
разработка технологии и процедур сопровождения БД;
разработка универсальных программ доступа к БД и соответствующих
интерфейсов пользователей;
информационное обеспечение разработки конкретных программ обработки
данных: обеспечение метаинформацией, данными контрольных примеров и
др.;
получение обратной связи от разработчиков прикладных программ и
пользователей Информационной Системы (ИС) о полноте и эффективности


организации БД;
тестирование БД, ее развитие и улучшение (настройка) ее структуры.

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

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

Масштабируемость и фрагментация

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

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

Основные понятия

Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта
передает права доступа к нему (чаще говорят - привилегии) по своему усмотрению. Привилегии
могут передаваться субъектам (отдельным пользователям), группам, ролям или всем
пользователям.

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

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

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

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

Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC -
удобный способ задать подразумеваемые права доступа.

Синхронизация доступа к данным

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

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

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

Создание базы данных.

SQL-скрипт для создания базы со всеми необходимыми операторами CREATE TABLE (с указанием
необходимых ограничений), ADD FOREIGN KEY и CREATE PROCEDURE генерится
автоматически. При этом для каждой таблицы создается описание трех хранимых процедур,
обеспечивающих выполнение функций INSERT, UPDATE и DELETE. Использование процедур в
приложении позволяет обеспечить выполнение требуемых политик поддержания целостности базы
по ссылкам.

Скрипт выполняется с помощью DBACCESS.

Фрагментация данных

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

Благодаря фрагментации:


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

Генерация экранных форм.

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

---

---