Основные категории пользователей

Пользователей СУБД можно разбить на три категории:


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

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


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

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

Можно провести аналогию между пользователем ingres и администраторами баз данных с одной
стороны, и суперпользователем операционной системы (root в случае ОС UNIX) и служебными
пользователями (в ОС UNIX это могут быть bin, lp, uucp и т.д.) с другой стороны. Введение
служебных пользователей позволяет администрировать функциональные подсистемы, не получая
привилегий суперпользователя. Точно так же информацию, хранящуюся на сервере баз данных,
можно разделить на отсеки, так что компрометация администратора одного отсека не означает
обязательной компрометации другого.

Управление транзакциями

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

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

Фрагментация выполнения

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


t

	write
	sort
	merge
	scan
	abc

Генерация кодов программ.

Включает следующие стадии:

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

Поддержание копий данных в нескольких узлах сети

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

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

Виды привилегий

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

3.3.1. Привилегии безопасности

Привилегии безопасности всегда выделяются конкретному пользователю (а не группе, роли или
всем) во время его создания (оператором CREATE USER) или изменения характеристик
(оператором ALTER USER). Таких привилегий пять:


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


знающим пользователям при анализе сложных, непонятных ситуаций.

3.3.2. Привилегии доступа

Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора
GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает
владелец соответствующих объектов (он же - администратор базы данных) или обладатель
привилегии security (обычно администратор сервера баз данных).

Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с
помощью операторов CREATE GROUP и CREATE ROLE.

Для изменения состава группы служит оператор ALTER GROUP.

Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен
список членов группы.

Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления
ролей.

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

Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они
относятся. В СУБД INGRES таких видов пять:


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

Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем
виде оператор GRANT имеет следующий формат:

GRANT привилегии

ON объекты

TO кому;

Применительно к таблицам и представлениям можно управлять следующими правами доступа:

SELECT	- право на выборку данных
INSERT	- право на добавление данных
DELETE	- право на удаление данных
UPDATE	- право на обновление данных (можно указать определенные столбцы, разрешенные для обновления)
REFERENCES	- право на использование внешних ключей, ссылающихся на данную таблицу (можно указать определенные столбцы)

По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям - их


необходимо передать с помощью операторов GRANT.

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

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

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

Привилегии (которые в данном случае точнее было бы назвать ограничениями)
QUERY_IO_LIMIT и QUERY_ROW_LIMIT проверяются на основании оценок, выданных
оптимизатором запросов. Если оптимизатор предсказывает, что запрос превысит отведенный
лимит числа операций ввода вывода или возвращаемых строк, он (запрос) отвергается. Наложение
подобных количественных ограничений препятствует монополизации сервера одним клиентом и
может использоваться как один из инструментов поддержания высокой готовности.

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


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

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

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

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

Механизм событий подробно рассмотрен в . Здесь мы отметим лишь, что по
отношению к событиям имеются две привилегии - RAISE и REGISTER. Первая позволяет
возбуждать события, вторая - регистрироваться для их получения.

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

GRANT ...

...

WITH GRANT OPTION;

Подобный оператор GRANT передает не только указанные в нем привилегии, но и права на


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

Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит
оператор REVOKE.

3.3.3. Получение информации о привилегиях

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

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

Таблицы iiusergroup, iirole и iidbprivileges базы данных iidbdb содержат соответственно, список
групп и их состав, перечень ролей вместе с зашифрованными паролями и сведения о привилегиях
доступа к базам данных. Так, таблица iiusergroup состоит из трех столбцов:


groupid - имя группы,
groupmem - имя члена группы,
reserve - резервный столбец.

Средствами SQL из этих таблиц можно извлечь необходимую информацию.

Фрагментация объектов БД

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

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

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

Использование представлений для управления доступом

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

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

CREATE VIEW empview AS

SELECT name, dept

FROM employee

WHERE dept = 'shoe';

Предоставим всем право на выборку из этого представления:

GRANT SELECT

ON empview

TO PUBLIC;

Субъекты, осуществляющие доступ к представлению empview, могут пытаться запросить
сведения об отделах, отличных от shoe, например:

SELECT *

FROM empview

WHERE dept = 'toy';

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

Сборка программы.

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

Алгоритмы выполнения реляционных операций

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

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

Иерархия прав доступа

Оператор GRANT и другие средства управления доступом СУБД позволяют реализовать
следующие виды ограничения доступа:


операционные ограничения (за счет прав доступа SELECT, INSERT,
UPDATE, DELETE, применимых ко всем или только некоторым столбцам
таблицы);
ограничения по значениям (за счет механизма представлений);
ограничения на ресурсы (за счет привилегий доступа к базам данных).

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

На иерархию привилегий можно посмотреть и с другой точки зрения. Каждый пользователь,
помимо, собственных, имеет привилегии PUBLIC. Кроме этого, он может входить в различные
группы и запускать приложения с определенными ролями. Как соотносятся между собой права,
предоставленные различным именованным носителям привилегий?

Иерархия авторизации выглядит для СУБД INGRES следующим образом:


роль (высший приоритет)
пользователь
группа
PUBLIC (низший приоритет)

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

Рассмотрим подробнее трактовку ограничений на ресурсы. Пусть, например, на всех четырех


уровнях иерархии специфицированы свои ограничения на число результирующих строк запроса
(привилегия QUERY_ROW_LIMIT):

роль	1700
пользователь	1500
группа	2000
PUBLIC	1000

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

Обычно используемая роль и группа задаются, соответственно, как аргументы опций -R и -G в
командной строке запуска приложения. Пример:

QBF -Gaccounting company_db

Если опция -G отсутствует, применяется подразумеваемая группа пользователя, если таковая
имеется.

Наконец, если в командной строке sql задана опция

-uпользователь

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

Метки безопасности и принудительный контроль доступа

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

В "Критериях оценки надежных компьютерных систем", применительно к системам уровня
безопасности B, описан механизм меток безопасности, реализованный в версии INGRES/Enhanced
Security (INGRES с повышенной безопасностью). Применять эту версию на практике имеет смысл
только в сочетании с операционной системой и другими программными компонентами того же
уровня безопасности. Тем не менее, рассмотрение реализации меточной безопасности в СУБД
INGRES интересно с познавательной точки зрения, а сам подход, основанный на разделении
данных по уровням секретности и категориям доступа, может оказаться полезным при
проектировании системы привилегий многочисленных пользователей по отношению к большим
массивам данных.

В СУБД INGRES/Enhanced Security к каждой реляционной таблице неявно добавляется столбец,
содержащий метки безопасности строк таблицы. Метка безопасности состоит из трех
компонентов:


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

Каждый пользователь СУБД INGRES/Enhanced Security характеризуется степенью
благонадежности, которая также определяется меткой безопасности, присвоенной данному
пользователю. Пользователь может получить доступ к данным, если степень его благонадежности
удовлетворяет требованиям соответствующей метки безопасности. Более точно:


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

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

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



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

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

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

Представляется естественным, что СУБД INGRES/Enhanced Security допускает не только скрытое,
но и явное включение меток безопасности в реляционные таблицы. Появился новый тип данных,
security label, поддерживающий соответствующие операции сравнения.

INGRES/Enhanced Security - первая СУБД, получившая сертификат, эквивалентный аттестации на
класс безопасности B1. Вероятно, метки безопасности постепенно войдут в стандартный репертуар
систем управления базами данных.

Функции СУБД

Описание объектных средств Illustra:


Типы данных.
Типы, определяемые пользователем. Множества, массивы и конструкторы
типов. Наследование типов. Преобразования типов.
Функции.
Определяемые пользователем функции. SQL и С- функции. Клиентские и
серверные функции. Переопределение функций при наследовании.
Поддержка сервером механизмов правил и алертеров.
Система правил для поддержки целостности данных. Концепция активного
ядра базы данных в механизме алертеров.
Управление хранением данных.
Хранение элементов данных внутри записей (in row) и в виде больших
объектов (large object). Прозрачность механизма для пользователя.
Возможности time travel.
Хранение всех версий записей. Поддержка запросов "time travel".

Итерационная спиральная модель жизненного цикла ИС.

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

Жизненный цикл ИС, определяемый методологией, приведен на рис.1. Он включает стадии
анализа, проектирования, разработки, тестирования и интеграции, внедрения, сопровождения и
развития ИС. На рисунке приведены также перечень основных этапов для каждой стадии ЖЦ и
процессы, выполняемые на протяжении всего ЖЦ - процессы управления и интегральные
процессы. Эти процессы в той или иной степени присутствуют на каждом из этапов.


Процессы организации и управления проектом: планирование,
управление, контрольАнализПроектированиеРазработкаИнтеграция и
тестированиеВнедрениеСопровождениеИнтегральные процессы: управление конфигурацией,
документирование, проверки, интеграция

* Обследование и создание моделей деятельности организации *Анализ (моделей) существующих ИС *Анализ моделей и формирование требований к ИС *разработка плана создания ИС	*Концептуальное проектирование *Разработка архитектуры ИС *Проектирование общей модели данных *Формирование требований к приложениям	*Разработка, прототипирование и тестирование приложений *Разработка интеграционных тестов *Разработка пользовательской документации	*Интеграция и тестирование приложений в составе системы *Оптимизация приложений и баз данных *Подготовка эксплуатационной документации *Тестирование системы	*Обучение пользователей *Развертывание системы на месте эксплуатации *Инсталляция баз данных *Эксплуатация *Проведение ПСИ	*Регистрация, диагностика и локализация ошибок *Внесение изменений и тестирование *Управление режимами работы ИС

<
Рис. 1. Жизненный цикл ИС

Процесс создания ИС представляет из себя процесс построения и последовательного
преобразования согласованных моделей на всех этапах ЖЦ. Эти модели сохраняются и
накапливаются в репозитории проекта. С помощью CASE-средств модели создаются,
преобразуются и контролируются. Основными результатами на каждом этапе ЖЦ являются
модели определяемых на данном этапе объектов (организации, требований к ИС, проекта ИС,
требований к приложениям и т.д.).

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

ЖЦ ИС, предлагаемый в новой методологии определяется следующими особенностями.


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

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

Работа Progress в гетерогенной сети

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

Приведем некоторые стартовые параметры.


cpinternal позволяет установить кодовую страницу, используемую
PROGRESS для внутренних операций.
cpstream позволяет определить кодовые страницы, используемые при
импорте и экспорте файлов, а также для дополнительных потоков.
cpterm позволяет вам установить кодовую страницу для алфавитных
терминалов, использующих кодовую страницу отличную от внутренней.
cpprint позволяет определить кодовую страницу для принтера.
cpcoll позволяет определить кодовую страницу для клиентского процесса.

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

Progress приложения могут работать не только с базами данных Progress, но и с другими базами
данных Oraclе, SYBASE. В некоторых случаях разные поставщики используют разные
наименования для одной и той же кодовой страницы, как например, SYBASE использует
наименование ISO-1 вместо ISO8859-1. В этом случае вам необходимо позаботиться о правильном
определении таблиц перекодировок в файле convmap.cp.

Распределенные СУБД

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

Реляционные базы данных

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

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

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

Связь - это функциональная зависимость между сущностями. Например, "служащий" совершает
"продажи".

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

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

Управление доступом

Для иллюстрации вопросов, связанных с управлением доступом, будет использоваться СУБД
INGRES.

VantageTeam Builder для программиста.

Рассмотрим основные действия программиста, осуществляющего разработку проекта с
использованием VantageTeam Builder.

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

Проектирование комплексной по предметной направленности, интегрированной и, обычно,
большой по размеру БД стало сложной задачей. Наличие целостной методологии проектирования
позволило позаботиться о "сапожнике-проектировщике" и начать шить ему сапоги в виде систем
автоматизации проектирования БД. Этому способствовало наличие технологического опыта в
организации и компьютерной поддержке систем разработки программного обеспечения и, с
другой стороны, использование активных интегрированных словарей-справочников данных
(DD/D, Data Dictionary/Directory). Так возникли системы CASE (Computer Aided System
Engineering) - системы для структурного проектирования БД и связанных с ними ИС,
ориентированные на модели данных, реализованные в различных СУБД. Наибольшую
популярность получили CASE-системы для реляционных СУБД с SQL-моделями данных, а DD/D
переименовался в CASE-репозиторий проектируемой ИС.

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

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

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

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

Аварийное переключение ко-серверов Informix- OXPS

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

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

Личные библиотеки модулей программы.

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

Первая, это создание библиотеки стандартных (непараметризуемых) фрагментов текста, например:

INPUT BY NAME p_record.*
--начало библиотечного модуля
ON KEY (ESC)
LET INT_FLAG = true
EXIT INPUT
--конец библиотечного модуля
Вторая - это создание библиотеки шаблонов, используемых для генерации параметризуемых
фрагментов текста, например (имя таблицы и имена полей определяются в данном примере
параметрически):

--начало библиотечного модуля
INPUT BY NAME p_{имя таблицы}.*
ON KEY (ESC)
LET inf_flag = true
EXIT INPUT
ON KEY(CONTROL-U)
--для всех импортированных полей
IF INFIELD({имя поля}) THEN
CALL find_{имя таблицы}(p_{имя таблицы}.{имя поля})
RETURNING p_{имя таблицы}.*
END IF
END INPUT
--конец библиотечного модуля
Соответственно дизайнер может использовать один и тот же библиотечный модуль на различных
схемах, а программист один раз пишет необходимый код или шаблон. Шаблоны представляют собой
текст программы, содержащий вызовы специальных функций, написанных на языке Tool Command
Language (TCL), и обеспечивающих чтение информации из формируемых с помощью VantageTeam
Builder моделей (диаграмм) и запись сформированного текста в соответствующие разделы
генеримого файла с кодом программы или SQL-скрипта. Например, шаблон для приведенного
выше примера выглядит следующим образом:

--начало шаблона
INPUT BY NAME p_~${current_table}.*
ON KEY (ESC)
LET inf_flag = true
EXIT INPUT
ON KEY(CONTROL-U)
~[ foreach col [gen_col_list $current_table "FKEY"] {
set master_table [get_master $col]
set col_name [get_uniq_name $col]
expand_text $current_section {


IF INFIELD(~$col_name) THEN
CALL find_~${master_table}()
returning p_~$current_table.~$col_name
END IF
END INPUT
--конец шаблона
Здесь:
current_table - переменная, в которой хранится имя текущей таблицы;
foreach - команда цикла по всем импортированным из других таблиц полям
текущей таблицы;
get_master и get_uniq_name - функции, обеспечивающие чтение имени
связанной таблицы и импортированного поля;
expand_text $current_section - команда, обеспечивающая запись сгенеренного
текста в программный файл.
Имя таблицы, для которой необходимо сгенерить соответствующий фрагмент кода, может
определяться по диаграмме содержания экранной формы. При этом нетрудно обеспечить, чтобы
указанный фрагмент кода генерился для каждой из присутствующих на диаграмме таблиц, только для
базовых таблиц, либо только для "словарей".

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

Ограничения

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

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

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

CREATE TABLE dept (

dname char(10),

budget money,

expenses money,

CONSTRAINT check_amount CHECK (budget > 0 and expenses
);

{Бюджет должен быть положительным, а расходы не должны выходить за рамки
бюджета}

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

Приведем пример ссылочного ограничения:

CREATE TABLE emp (

ename char(10),

edept char(10) references dept(dname)

);

{Ни один работник не должен числиться в неизвестном отделе}

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

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

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

CREATE TABLE dept (

name char(10) NOT NULL,

location char(20),

CONSTRAINT dept_unique UNIQUE(name)

);

CREATE TABLE emp (

name char(10),



salary decimal(10,2),

edept char(10) CONSTRAINT empref REFERENCES dept(name)

);

Если требуется удалить ограничение dept_unique, можно воспользоваться следующим
оператором:

ALTER TABLE dept

DROP CONSTRAINT dept_unique cascade;

Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно
зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade
указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД
зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений.

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

Использование стандартной библиотеки модулей программы.

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

Шаг1. Разработка структуры базы данных с использованием диаграмм отношений
сущностей.

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

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

Шаг4. К формам-меню привязывается структурная схема, основным элементом которой
является библиотечный модуль "MENU". К формам, предназначенным для работы с таблицами
привязывается стандартная структурная схема, обеспечивающая выполнение стандартных действий
(insert, update, delete, find).

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

Правила

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

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

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

SET NORULES;

Оператор

SET RULES;

позволит затем восстановить работу механизма правил. По умолчанию этот механизм
включен.

Для удаления правил служит оператор

DROP RULE правило;

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

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

Зеркалирование дисковых областей

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

Проблемы практического применения стандартной технологии.

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

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

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

Тиражирование данных

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

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

Игнорирование недоступных данных

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

Администрирование баз данных в оперативном режиме

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

Факторы, влияющие на производительность объектно- реляционной СУБД Illustra:

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

Комплекс развивающихся систем согласованных моделей

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

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

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

Одновременная поддержка нескольких языков

Все более актуальной становится возможность использования одного и того же приложения в
различных странах на разных языках с учетом национальных традиций и особенностей. В России
ряд разработчик также столкнулся с такого же рода задачей. Российские приложения хотят
эксплуатировать на Украине, в Казахстане, в других странах бывшего Советского Союза. При
этом встает вопрос поддержки национальных алфавитов каждой из этих стран. Progress Software
разработала специальный продукт Translation Manager 2 для решения этих вопросов. В его состав
входят две основные компоненты - Translation Manager и Visual Translator.

Описание процесса перевода приложения

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

Руководитель проекта определяет те процедуры, которые должны быть переведены на другой
язык. После этого он указывает фильтр для типов сообщений, которые необходимо перевести в
каждой процедуре. Такими типами могут быть: меню, метки, наименования кнопок и т.д. После
этого происходит формирование задания на перевод для переводчиков. В задание могут быть
включены стандартные словари, содержащие перевод основных терминов, при этом допускается
использование стандартных словарей фирмы Microsoft, которые использовались для перевода
Word и Excel. При этом выдается вся статистика, позволяющая оценить трудоемкость работы и
возможные сроки ее окончания. Переводчику передается только информация, необходимая для
перевода без логики самого приложения. Задание может посылаться по почте, на дискете или иным
способом.

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

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

_prowin.exe -p _desk.p -lng Russian

Особо - о временных характеристиках и транзакциях

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


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

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

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

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

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

Поддержание целостности данных в СУБД

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

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

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

Сервер Informix - среда высокой доступности данных

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

Системы БД с многоуровневой защитой

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

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

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

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

[]
[]
[]

Средства ускорения разработки приложений

Как видно из предыдущего описания, VantageTeam Builder позволяет вести разработку проектов
весьма высокой сложности. Графические редакторы и средства контроля существенно упрощают
анализ задачи и проектирование приложения, упрощая и ускоряя работу аналитиков и
проектировщиков. Программист же получает на первый взгляд не так уж много:

удобный инструмент создания базы данных с генерацией полезных
хранимых процедур;
несколько более удобный, чем опция Forms в стандартной среде разработки
Informix-4GL, инструмент генерации экранных форм, который сразу формирует
экранные массивы и нужные пользователю названия полей, в том числе, на
русском языке;
возможность придерживаться классического структурного подхода,
поскольку программирование теперь выглядит как "вписывание" необходимых
операторов в соответствующие элементы структурной схемы программы.
Нередко от программистов на этой стадии знакомства с CASE-технологией можно услышать: "Ну в
фазах анализа и архитектуры мне просто нечего делать, а программу написать я могу и не по
квадратикам. Я их уже столько написал. Возьму нужный фрагмент из какой-нибудь старой
программы, изменю имена полей и таблиц и готово". Однако более детальное знакомство с
VantageTeam Builder показывает, что он может оказывать программисту очень большую помощь в
решении именно этой задачи - написании новой программы по старому образцу.

Сущности и атрибуты в реляционной модели

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

Предположим, в базе данных хранится информация о служащих. Таблица "покупатель" содержит 3
колонки и 4 строки:

Имя
Адрес
Идент. карты

Сидоров	1 улица 8 марта	444444
Иванов	2 улица 8 марта	222222
Петров	3 улица 8 марта	333333
Павлов	4 улица 8 марта	111111

Имя таблицы и имена ее колонок составляют структуру таблицы: customer (name,
address, card_id). В реляционной модели все значения данных являются атомарными, т.е. нельзя в
клетке таблицы хранить список значений.

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

Эталонный интерфейс для произвольной таблицы БД.

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

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

форма ввода и модификации информации - add_form (она же
используется для просмотра записей при удалении - delete_form);
форма формирования запроса на поиск - find_form;
форма списка с двумя подрежимами :
а список с отметками, в котором можно отметить одну или более
записей для проведения с ними определенной операцией - list_form;
а список с выбором единственной - choose_form (для выбора
записей из словарей при экспорте ссылок или значений в вышестоящую
таблицу).
Для выбора начальной операции с таблицей и операций с выбранной записью (записями) из
списка используются вертикальные меню (реализуемые специальной функцией). При начале
работы с таблицей можно выбрать режим ввода новой записи, либо поиска всех записей по
введенному запросу с формированием списка найденных записей. После ввода новой записи
пользователь также получает список, хотя и состоящий из одной этой записи. Отметив одну или
несколько записей в списке вы попадаете в меню выбора операции. Среди них ввод новой записи
по образцу (введенная запись добавляется в список), модернизация или удаление отмеченных
записей.

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


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

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

Хотя это является явным "ограничением общности", принятое решение представляется нам весьма
разумным, ибо приучает пользователя к единообразному представлению записи, где бы она не
появилась.

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

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

В настоящем разделе будет рассмотрена разработка компании Sun Microsystems, Inc -
SPARCcluster PDB Server (параллельный сервер баз данных на основе SPARC-кластера).

5.1.1. Аппаратная организация SPARCcluster PDB Server

В минимальной конфигурации SPARCcluster PDB Server состоит из двух узлов SPARCserver 1000,
двух дисковых подсистем SPARCstorage Array и консоли кластера (SPARCclassic). Узлы-
компьютеры соединяются между собой посредством быстрого Ethernet (100 Мбит/с), дисковые
подсистемы подключаются через оптоволоконные каналы. В более мощной конфигурации вместо
SPARCserver 1000 может использоваться SPARCcenter 2000, а число дисковых подсистем способно
достигать 32 (до 1 Тб дискового пространства). Каждый узел кластера - это многопроцессорный
компьютер, к которому, помимо прочих, подключены накопители на DAT-лентах (или
автозагрузчики кассет с такими лентами). Все связи с компьютерами и дисковыми подсистемами
продублированы.

Следующий рисунок поясняет аппаратную организацию SPARCcluster PDB Server.


Рис. 1. Аппаратная организация SPARCcluster PDB Server (на
рисунке не показаны связи кластера с внешним миром)

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

Вся аппаратура устроена так, что допускает замену в горячем режиме, без остановки других


компонентов кластера.

5.1.2. Программная организация SPARCcluster PDB Server

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

Рассмотрим компоненты программного обеспечения SPARCcluster PDB Server.

Устойчивый к отказам распределенный менеджер блокировок (Fault Tolerant Distributed Lock
Manager, FT-DLM) управляет параллельным доступом к базам данных, устанавливая и снимая
блокировки. Кроме того, FT-DLM нейтрализует последствия отказов, снимая блокировки,
установленные вышедшим из строя узлом. FT-DLM взаимодействует с сервером Oracle для
поддержки неблокируемых операций чтения и для блокировки на уровне строк при записи в
таблицы. В результате обеспечивается целостность и сериализация транзакций в сочетании с
параллельной работой узлов кластера и с параллельным доступом к нескольким дисковым
подсистемам.


Рис. 2. Программная организация SPARCcluster PDB Server
(узлы кластера работают под управлением ОС Solaris версии 2.4 или
выше)

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

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

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


изолирующий вышедший из строя компонент при сохранении работоспособности кластера в
целом (с выходом из строя диска справляется менеджер томов).

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

5.1.3. Нейтрализация отказа узла

Рассмотрим, как в SPARCcluster PDB Server реализована нейтрализация самого неприятного из
отказов - отказа узла. Программное обеспечение предпринимает при этом следующие
действия:


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

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


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

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

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

Атрибуты и генерация эталонного интерфейса.

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

Отсутствие в CASE'е версии 3.1 инструментов генерации сложных экранных форм привело к
необходимости построения собственного генератора экранных форм, генерящего для каждой
таблицы формы для ввода/модификации информации и для формирования запросов, который также
вошел в состав GRINDERY One-Step 4GL.

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

Тиражирование данных

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

Развитые возможности тиражирования предоставляет СУБД INGRES. Им посвящена статья href="#lit">[2]. Здесь мы рассмотрим возможности другого популярного сервера СУБД -
Informix OnLine Dynamic Server (OnLine-DS) 7.1. В отличие от предыдущего раздела, речь пойдет
об обычных (а не кластерных) конфигурациях.

В Informix OnLine-DS 7.1 поддерживается модель тиражирования, состоящая в полном
отображении данных с основного сервера на вторичные.

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

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

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


вторичном, даже в случае сбоя основного сервера. Асинхронный режим не обеспечивает
абсолютной согласованности, но улучшает рабочие характеристики системы.

	Тиражирование
Основной сервер	Вторичный сервер

Рис. 3. Тиражирование. Основной сервер доступен на
чтение и запись, вторичный - только на чтение.

Основной сервер	Стандартный сервер

Рис. 4. Когда основной сервер выходит из строя,
вторичный переводится в режим доступа и на чтение, и на запись.

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

Применение и перспективы развития GRINDERY One-Step 4GL.

Написанный нами кодогенератор прошел серьезную практическую проверку как основной инструмент
написания кода при разработке системы автоматизации коммерческой и производственной
деятельности нашей фирмы. С его помощью было сгенерено не менее 80% общего объема приложения
(около 2 Мб исходных текстов программ) и почти все экранные формы. В целом он, по нашим
оценкам, сократил в несколько раз время написания кода по сравнению с проектами, выполнявшимися
вручную. Существенно упростилась отладка и тестирование приложения, поскольку из автоматически
сгенеренного кода для работы с примерно полусотней таблиц достаточно проверить один-два
стандартных варианта. Тщательного тестирования требуют лишь те 20% кода, которые написаны
полностью или частично вручную.

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

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

Генератор GRINDERY On-Step 4GL

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

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

Illustra DataBlades

Описание, основные рынки приложений и преимущества использования модулей DataBlades:


Text
Вводит новый тип doc и функции для работы с содержимым
документов, включая сравнение документов и проверку на содержание слов.
Определяет новый метод доступа для документов - D-tree.
TimeSeries
Вводит новые типы: calendar и timeseries, возможности определения
календарей и функции для работы с данными временных рядов.
Производительность работы с данными временных рядов
повышается в сотни раз по сравнению с РСУБД.
Типичные приложения: управление финансовыми портфелями,
анализ экспериментальных результатов, анализ видеопоследовательностей.
2D & 3D Spatial:
Добавляет десятки новых типов данных, представляющие собой
двумерные и трехмерные графические объекты, а также более 100 функций
для работы с такими объектами.
Новый метод доступа, наиболее эффективный для таких данных, -
R-tree.
Типичные приложения: геоинформационные системы.
Web
Добавляет новый тип данных anchor. Позволяет легко использовать
новые типы данных и функции преобразования и поиска информации.
Позволяет получать прямые ссылки (URLs) на объекты внутри базы
данных.
SQL обеспечивает дополнительный уровень безопасности
информации в сети.
Типичные приложения: сетевые публикации, каталоги.
Image
Вводит новый тип image, поддерживая 49 форматов изображений, и
продвинутые функции для работы с изображениями.
Позволяет простое расширение для поддержки новых графических
форматов.
Типичные приложения: графические библиотеки.

Интегральные средства управления

Программное обеспечение Informix-OXPS тесно интегрировано с развитой средой системного
управления Tivoli Management Environment (TME), разработанной компанией Tivoli Systems Inc.
(Начиная с версии 8 аналогичные средства системного управления будут реализованы и для
Informix ODS.) Среда управления скрывает от администраторов внутреннюю сложность
аппаратных конфигураций кластерных архитектур и систем MPP, предоставляя единую точку
обзора объектов баз данных, независимо от их физического местоположения.

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

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


Управление, конфигурирование, слежение за текущим состоянием;
Резервирование журналов транзакций, архивирование, восстановление;
Мониторинг характеристик производительности;
Анализ, экспертная помощь в физическом конфигурировании данных;
Параллельная загрузка баз данных;
Управление тиражированием для распределенных баз данных;
Управление реляционными объектами.

Методология анализа ИС на основе бизнес-процессов

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

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

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


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

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

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

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

Оценка достигнутого состояния

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

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

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

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

Выше шрифтом выделена цитата из []. С тех пор СУБД, методы проектирования БД и
соответствующие инструменты значительно прибавили в возможностях. Но остальной мир тоже не
стоял на месте, существенно усложнились стоящие перед разработчиками ИС и БД задачи. И надо
признать: формулировки Цикритзиса и Лоховски не устарели.

Средства поддержания высокой готовности

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

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

---

---