Целью данной статьи является описание приемов проектирования и создания приложений в таком специфическом случае, как программная система, предназначенная для работы под управлением монитора транзакций. Особый режим работы, в котором функционирует приложение, приводит к тому, что традиционные методы проектирования клиент-серверных приложений зачастую оказываются не самыми эффективными и вынуждают искать новые подходы. Столкнувшись с задачей создания трехуровневого приложения, нам пришлось многому учиться. Возможно, кому-то будет полезен наш опыт.
Введение
В статье рассматриваются различные аспекты создания сложной программной системы, в том числе разработка архитектуры системы, проектирование структуры приложений, вопросы коммуникаций и т.п. Акцент намеренно не смещен в сторону вопросов проектирования базы данных. Проблема проектирования базы данных далеко не единственная и даже не определяющая среди проблем создания сложных систем. Автор надеется, что в данной статье более-менее точно показано место проблемы проектирования базы данных среди остальных вопросов, возникающих при разработке современных сложных систем.
Термин клиент-сервер часто трактуется слишком широко. Под эту категорию на отечественном рынке попадают любые архитектуры, организующие взаимодействие компьютеров в сети. Под нее подходит и схема построения приложений с использованием менеджера записей Btrieve. И даже обычный вариант с файл-сервером и Clipper удовлетворяет этому широкому толкованию. Но в области "тяжелых" проектов архитектурой клиент-сервер принято называть схему построения приложений, обеспечивающую эффективное распределение логики программной системы между различными компьютерами в сети. Каждый элемент компьютерной сети имеет определенный набор параметров, важнейшими из которых являются аппаратные характеристики и набор системного программного обеспечения. Развитая архитектура клиент-сервер позволяет строить приложение так, чтобы у каждого компьютера максимально использовались именно сильные стороны специфических для него характеристик. Как правило, в финансовых системах это достигается трехуровневой схемой приложения (клиент-сервер-СУБД), когда клиентское приложение реализует только пользовательский интерфейс, а бизнес-логика обрабатывается сервером приложения.
Но реализовывать трехуровневую схему можно по-разному. Можно создавать полноценные серверные приложения, использующие для связи с клиентским приложением и с СУБД продукты типа мониторов транзакций. Часто применяется и другой подход, когда разработчики идут по пути использования технологии хранимых процедур в таких высококачественных СУБД, как Sybase, Oracle и др. Встроенные процедуры помогают небольшим приложениям эффективно распределять нагрузку в сети между приложением-клиентом и приложением-сервером. Встроенные процедуры представляют собой суррогат мониторов транзакций. Но именно суррогат, заменитель, не обеспечивающий необходимых средств создания и поддержания крупномасштабного проекта.
Кроме того, использование в программе встроенных в базу данных процедур не обеспечивает переносимость программы между различными СУБД.
Программисты-практики хорошо представляют, что такое встроенные процедуры, как сложно их создавать и отлаживать и как затруднена их поддержка. Вот комментарий специалиста. "Эксплуатировать мощные сетевые приложения без TP-монитора - это все равно, что переходить через высокоскоростную магистраль с закрытыми глазами... Встроенные процедуры, выполненные в виде модулей СУБД, имеют ограниченные возможности по распределению загрузки и контролю надежности. Они не могут использовать ресурсы вне базы данных, и, в конечном счете, пользователям приходится выполнять (большую) работу на компьютерах-клиентах, что сильно снижает производительность" (Линда Радосевич, "PCWEEK", 29 мая 1995 г., стр. 10).
К новой технологии активных агентов фирмы Oracle (неплохой в целом технологии) применимы примерно те же соображения, что и к хранимым процедурам.
Для реализации трехуровневой схемы мы использовали монитор транзакций, позволяющий наиболее полно и гибко строить системы типа клиент-сервер. Общее описание и характеристики такой технологии хорошо представлены в источнике [1]. Для ознакомления с квалифицированным мнением о практической ценности трехзвенной технологии клиент-сервер мы рекомендуем источник [3].
Актуальность этой темы кажется нам очевидной, так как автору статьи известны несколько отечественных крупных проектов в области трехзвенной архитектуры клиент-сервер, в ходе которых создаются особо ответственные приложения, предназначенные для эксплуатации в тяжелом режиме (7х24) сотнями и тысячами пользователями. Некоторые проекты уже успешно завершены, остальные находятся в процессе разработки.
Автор статьи имеет некоторое отношение к нескольким таким проектам, в частности, принимал участие в проектировании и создании автоматизированной банковской системы. Предлагаемые подходы иллюстрируются на примере именно этой разработки.
Описание проекта
В 1994 году достигнутый объем операций одного из московских банков заставил управление автоматизации этого банка искать пути к использованию современных способов организации обработки финансовых транзакций. Положение в банке было следующее. Банку-участнику прямых расчетов необходима была система автоматизации, позволяющая надежно работать в режиме реального времени со счетами клиентов в распределенной многофилиальной сети.
По нашему мнению, на российском рынке нет банковских систем, способных справиться с этой задачей. Поэтому, несмотря на очевидные трудности такого решения, банк был вынужден заказать группе разработчиков высококачественную программную систему, удовлетворяющую следующим требованиям.
1. Обеспечение максимальной надежности
Главной целью было создание "невидимой" системы. Хорошая банковская система должна быть незаметна в банке. Банковские работники просто должны знать, что она есть и что с ее помощью можно сделать все, что им нужно, причем в приемлемые сроки. Если бухгалтеры и операционисты должны учитывать в расписании своей работы возможные сбои системы и непонятные обычному человеку "особенности", это неправильное положение. Все-таки основная (и, наверное, единственная) задача банка - предоставление клиентам финансовых услуг, и выполнению этой задачи не должно мешать несовершенство в организации какой-либо вспомогательной службы, каковой, по большому счету, является управление автоматизации.
Двумя китами, на которые опирается создание такой системы, являются производительность и надежность. Они дают тот фундамент, на котором можно возводить здание сложной программной системы, не опасаясь, что при определенном уровне сложности этот фундамент "поплывет".
2. Обеспечение "прозрачного" выполнения всех корректных банковских операций
Имевшиеся в банке программы для ведения платежных операций, купленные у фирм-производителей банковских программ, требовали в некоторых нестандартных случаях совместной работы программистов и бухгалтеров по коррекции информации в базе данных. Некоторые вещи вообще невозможно было сделать по непонятной причине. Видимо, при разработке этих программ с успехом применялся принцип "если в вашей программе есть недостатки, подробно их опишите и назовите особенностями". Эта проблема тесно смыкается с проблемой "невидимости" программы. Все действия должны обрабатываться адекватно, и бухгалтер при работе не должен помнить о том, что в одном случае блокируется такая-то таблица базы данных, а в другом случае все пользователи должны выйти из программы, чтобы нормально отработала административная задача. Для решения этой проблемы необходима тщательная разработка структуры данных и алгоритмов их обработки.
3. Совместная работа валютного и рублевого управлений банка
В использовавшейся в банке старой системе функционирование этих управлений в техническом плане было искусственно разделено, так как обычно существуют раздельные версии коммерческих систем для валютной и рублевой частей и, как следствие, раздельные рублевые и валютные базы данных со сложной системой связи между ними. Это противоестественное положение было решено прекратить, в связи с чем пришлось решать массу проблем как программного, так и бухгалтерского характера.
4. Связь с филиалами
Сейчас в России имеется много банков, обладающих обширной сетью филиалов. Филиалам необходимо обмениваться информацией. Современные банки вынуждены идти навстречу клиенту и ускорять прохождение информации из филиала в филиал. Кроме того, жизнь требует усиливать контроль за деятельностью филиалов со стороны центрального отделения для постоянной корректировки финансовой политики банка в целом. Все это вызывает необходимость в непрерывной (on-line) связи между филиалами для мгновенного прохождения сумм и для контроля базы данных филиала. В идеале в каждом регионе у банка должна быть единая база данных для всех филиалов этого региона, и базы данных различных регионов должны быть связаны между собой (и очень желательно в режиме on-line). По мнению автора, при использовании программных комплексов, имеющихся на отечественном рынке банковских приложений, возможность построения такой банковской сети представляется чистой утопией. Единственным реальным средством собрать такую структуру и обеспечить ее функционирование является монитор транзакций или аналогичное программное обеспечение промежуточного слоя (middleware). При этом сама по себе проблема скоростной связи, например, в Москве, где, по разным оценкам, "крутится" от 60% до 70% российских денег, практически решена силами таких фирм, как "Голден Лайн", "Макомнет" и др. Тем более досадно, что ни одна известная автору отечественная банковская система не в состоянии использовать возможности, предоставляемые современной технологией связи. Уходящее поколение банковских систем просто создавалось в расчете на иные экономические и технические условия эксплуатации. И решения, заложенные в эти программные комплексы, не дают им вобрать в себя новые подходы к межфилиальному взаимодействию.
5. Открытость алгоритмов обработки данных
Если в случае необходимости изменить алгоритмы обработки данных приходится привлекать программиста, это является трудоемким, дорогостоящим и даже опасным способом совершенствования программы. По нашему мнению, хорошая система должна предоставлять инструментарий для создания банковского документооборота. Внедрение такой программы будет трудным процессом, но все это многократно окупится на этапе эксплуатации. Программисту желательно не задумываться о конкретных путях прохождения документа в банке, а администратор должен получить гибкую систему, в которой он опишет этот самый путь документа.
Извечная проблема банковского программиста - постоянно меняющийся список финансовой отчетности, к тому же в разных банках имеются разные стандарты. В одних банковских программах отчеты жестко вставляются в программный код, обеспечивая высокую производительность и отсутствие гибкости. Другие программы предоставляют генератор отчетов, но скорость выполнения таких отчетов оставляет желать лучшего. Перед разработчиками стояла задача использовать оба подхода для оптимизации системы получения отчетности.
6. Безопасность и контроль прав доступа
В системе, которая позволяет работать в одной базе данных нескольким филиалам, а также валютным и рублевым управлениям каждого из филиалов, необходима сильная подсистема контроля прав доступа и обеспечения логического разделения баз данных для пользователей с обычными полномочиями. При этом пользователи с высокими полномочиями должны иметь возможность получать любую информацию в системе.
Отдельным вопросом является защита от программиста-злоумышленника. В банке, распределенном по различным территориям и работающем в единой базе данных, среди работников могут оказаться разные люди. Выпускник ВМК МГУ или МФТИ, работающий операционистом в банке, теперь обычное явление. Принципиальным является требование невозможности создания злоумышленником программы на рабочем месте, получающей доступ к базе данных. Весь контроль обязан происходить в серверной части комплекса, и ни один пользователь не должен иметь прямого доступа к серверу или базе данных. Программист-злоумышленник, создавший программу для взлома системы, не должен иметь возможности доступа к информации без знания пользовательских паролей. Необходимо было также предусмотреть возможность установки стандартного программного обеспечения (например SunScreen фирмы Sun Microsystems), защищающего сеть от диверсий на уровне сетевых протоколов - от прослушивания сети и от попыток получить несанкционированный доступ под видом другого пользователя или даже драйвера. Эта проблема возникает в связи с тем, что финансовые центры все чаще становятся участниками всемирной сети Internet, что имеет и некоторые негативные последствия для них, а именно - возникновение вероятности проникновения злоумышленников в корпоративную сеть. Для борьбы со злоумышленниками используются возможности систем защиты корпоративных сетей.
Архитектура системы
1. Общее описание
Разработчиками проекта была выбрана архитектура клиент-сервер с использованием монитора транзакций. При этом общее распределение вычислительной нагрузки таково: сервер приложения занимается ответственными вычислительными задачами (быстрые транзакции, генерация отчетов, поддержка логической целостности базы данных, реализация алгоритмов обработки данных, баланс загрузки), а приложение-клиент нацелено на создание максимально дружественного интерфейса. При этом принципиально разделены интерфейс программы и алгоритмы обработки данных.
Сейчас на рынке средств быстрой разработки проектов (RAD) имеется множество языков четвертого поколения (4GL). Мы пришли к выводу о нецелесообразности использования такого средства в данном проекте по следующим причинам.
а. Ориентация большинства языков 4GL на совмещение в коде программы средств внешнего представления данных и их обработки. Этот подход хорош для создания двухуровневых приложений. В трехуровневой схеме визуальное представление данных и их обработка принципиально разделены, поэтому такое свойство языка просто не работает. Кроме того, мы считаем, что такое совмещение усложняет разделение труда между разработчиками, сопровождение и модификацию крупного проекта.
б. Известные автору средства разработки на языках четвертого поколения (Delphi, Power Builder, SQL Windows, OpenRoad, JAM, Oracle Forms, Informix 4GL) не могут сравниться с "ручным" программированием на языках третьего поколения в области эффективности конечного продукта разработки - откомпилированного кода программы. Под эффективностью автор понимает совокупность таких показателей, как скорость работы программы и объем используемой оперативной памяти. К серверу приложения обычно предъявляются очень строгие требования в области эффективности, поэтому для его разработки идеально подходит язык типа С или С++.
Что касается клиентского приложения, то здесь вполне допустимо использование языков четвертого поколения для ускорения процесса кодирования, если разработчики конкретного проекта уверены в таком ускорении. Даже при использовании языка третьего поколения для разработки клиентской программы мы считаем обязательным применение визуальных средств разработки графического интерфейса.
В описываемом проекте были предусмотрены жесткие ограничения на технические характеристики клиентских рабочих станций, поэтому разработчики были вынуждены, для экономии оперативной памяти компьютеров-клиентов, использовать язык С++, в сочетании с системой визуальной разработки графического интерфейса, для создания также и программы-клиента. Из известных автору "полновесных" языков четвертого поколения только система Delphi позволяет создавать крупные приложения, которые бы хоть как-то работали на компьютере с 8 Мбайт памяти, да и этой системы не существовало в законченном виде, когда начиналась работа над проектом.
в. По мнению автора, ускорение кодирования не вносит существенного вклада в скорость создания большого приложения. Собственно кодирование занимает максимум 10% времени работы над проектом, и сокращение этого времени пусть даже в 10 раз (что нереально) не становится решающим фактором. Остальные 90% времени у команды разработчиков занимает постановка задачи, создание проекта, обсуждение общей архитектуры, моделирование, отладка, написание спецификаций и документации. По нашему мнению, использование быстрого средства разработки не ускоряет темпа этих остальных 90% работы.
г. Автору лично не нравится также закрытость средств разработки четвертого поколения, отсутствие стандартов в этой области, преимущественная ориентация большинства таких средств на закрытую платформу MS Windows.
Причины, по которым разработчикам систем трехзвенной архитектуры часто приходится отказываться от систем RAD, хорошо описаны в [3].
Далее разработчики проекта все же использовали Delphi для некоторых вспомогательных модулей системы.
Общая схема системы RP/3.
На рис. 1 приводится планировавшаяся нами общая архитектура программной системы (итоговый вариант полностью совпадает с запланированным). В соответствии с трехуровневой моделью организации логики приложения, в обработке информации участвуют три программные подсистемы.
1. Программа-СУБД на компьютере-сервере.
2. Серверный программный комплекс, размещенный на компьютере-сервере. Причем в общем случае этот сервер может не совпадать с сервером, на котором работает СУБД. Серверный комплекс принимает и обрабатывает запросы клиентской программы. В такой схеме серверная программа берет на себя сложную обработку данных, а клиентская - управляет пользовательским интерфейсом. Серверы приложений работают на Unix-компьютере и связаны сетевым протоколом TCP/IP с клиентскими компьютерами, работающими под MS Windows 3.1 (имеется версия клиентской программы для Windows 95 и NT). Такая схема позволяет совместить высокую надежность и эффективность обработки данных, так как отвечающая за работу с данными серверная часть расположена на Unix-платформе, с простым и привычным клиентским местом под управлением Windows.
3. Клиентский комплекс, работающий на компьютере-клиенте. Программа-клиент оперирует объектами - например объектом-лицевой счет. Обращения к СУБД скрыты в методах классов и осуществляются путем посылки запроса серверной части банковского программного комплекса. На центральном компьютере монитор транзакций принимает запрос, определяет его адресата и передает для выполнения конкретному серверному процессу. Этот процесс для выполнения запроса может обращаться к СУБД, к любым системным ресурсам и к другим программам-серверам, в том числе находящимся, возможно, на других центральных машинах (в другом филиальном кластере, например).
В последнюю версию системы вошли отдельные модули, созданные с помощью Java-технологии, для реализации, например, системы клиент-банк. Мы считаем, что Java является очень перспективным направлением в банковских технологиях.
Мы полагаем, что серверную часть финансового приложения целесообразно разбить на следующие основные группы.
· Группа, предоставляющая конечному пользователю гибкую настраиваемую систему просмотра базы данных.
· "Машина проводок", объединенная с системой документооборота.
· Система жесткой (встроенной в программный код) основной финансовой отчетности.
· Система создания и выполнения произвольных отчетов и запросов.
· Система поддержки справочников.
· Система встроенной электронной почты.
· Контрольно-статистическая система.
В целом нам удалось в процессе разработки выдержать такую схему. Но серьезной настройке были подвергнуты внутренние составы каждой из групп. В основном изменения шли по линии снижения среднего времени отклика системы.
2. Используемая СУБД
Для реализации конкретного проекта, по совокупности качеств (общие возможности, соответствие промышленным стандартам, поддержка, ценовая политика, простота инсталляции и эксплуатации) разработчиками была выбрана новейшая реализация СУБД Ingres в версии OpenIngres 1.1. В целом такое решение себя оправдало. Но при создании системы было принято решение не использовать без особой необходимости специализированные функции OpenIngres для сохранения возможности переноса системы на другие СУБД (например Informix или Oracle).
3. Аппаратно-программная платформа
Приложение-клиент создавалось для среды MS Windows 3.1 с использованием всех возможностей этой графической оболочки по организации недорогого пользовательского интерфейса. Самая же ответственная часть, сервер приложения, реализовывалась с использованием мощных средств разработки операционной системы Unix. В качестве конкретного ее воплощения была выбрана платформа Sun, операционная система Solaris 2.x. Надежность и возможности ОС Unix нами были оценены очень высоко.
4. Монитор транзакций
Среди мониторов транзакций для Unix лидерство по числу установок и объему продаж удерживает TUXEDO, принадлежащий сейчас фирме BEA Systems. Кроме того, он обладает достаточно простым API-интерфейсом. Поэтому был выбран именно этот продукт.
TUXEDO поддерживает распределенные транзакции, прозрачное взаимодействие программ в разнородной сети, обмен сообщениями с гарантированной доставкой, программный интерфейс DCE RPC и множество других средств для облегчения жизни разработчику сложного программного продукта. В принципе, программист избавляется от необходимости обязательного знания и использования многочисленных сетевых и системных программных интерфейсов ОС Unix, так как TUXEDO содержит все средства для организации распределенной обработки данных.
5. Обработка данных
Хорошее банковское приложение должно включать в себя как подсистему оперативной обработки транзакций (OLTP), так и подсистему поддержки принятия решения (DSS). Например, движение платежных документов в организации - это сравнительно простые и быстрые транзакции, а расчет показателей деятельности банка за определенный период - это элемент системы поддержки принятия решения. Различные типы систем, как правило, требуют совершенно разных подходов к способам организации хранения данных. Производители современных "больших" СУБД утверждают, что их продукты одинаково хорошо поддерживают оба типа систем, но, по мнению автора, это пока не так. Вполне может быть, что реляционный подход является не лучшим для аналитической обработки. Единого мнения и метода пока нет. Фирмы-производители таких СУБД, как Informix, OpenIngres, Oracle, Sybase и др., создают или уже создали объектно-ориентированные расширения своих реляционных продуктов. Распространенные реляционные неспециализированные СУБД создавались в расчете на оперативную обработку и сейчас только начинают приспосабливаться к требованиям сложной аналитической обработки данных. Что касается специализированных СУБД (таких как Red Brick), они приспособлены (по крайней мере, пока) именно к аналитической обработке данных и слабо подходят к работе в режиме быстрых транзакций.
Весьма интересна модная сейчас технология разделения базы данных на сравнительно небольшое оперативное подмножество изменяемых данных (им управляет система типа OLTP) и большое квазинеизменное подмножество (над этими данными работает система типа DSS). Между подмножествами осуществляется однонаправленная репликация для поддержки актуальности данных. В таком случае можно в каждой подсистеме использовать наиболее подходящую для данной задачи СУБД и схему хранения данных. Например, в первой подсистеме можно использовать Informix, во второй - Red Brick (из реляционных СУБД) или какую-нибудь объектную СУБД. Разработчики данного проекта считают, что это вполне перспективное направление. Поэтому при разработке учитывалась возможность для приложения работать в такой архитектуре. Однако для конкретного описываемого в статье варианта этот подход не использовался.
Организация работы
Проектирование и создание больших систем имеет существенное отличие от создания небольших и средних систем. Оно заключается в том, что сложность большой системы становится самостоятельным фактором. Сложность большого проекта превосходит обычные человеческие возможности и вызывает необходимость применения особых приемов организации разработки программного продукта [2]. Ниже приведены основные принципы построения такой системы.
1. Наилучший результат получается при работе меньшего числа лучших людей. Если обеспечить соответствующими условиями работы небольшой коллектив высококвалифицированных специалистов и организовать взаимодействие между ними, то работать они будут существенно эффективнее, чем большое число средних программистов. При большом количестве работников сложность управления коллективом множится на сложность самого проекта и превышает мыслимые размеры. Могут позволить себе задействовать сотню и больше программистов в одном проекте лишь фирмы масштабов и опыта IBM, AT&T или Novell. При меньших возможностях фирмы попытка создать проект силами такого большого коллектива приведет к неуправляемости и неустойчивости проекта и к исчезающе малой производительности труда разработчиков.
Разработчики системы решили ограничиться небольшой (до 10 человек) группой профессионалов. Конечно, для обеспечения гладкого функционирования такой группы нужна поддержка работников иных специализаций - системных администраторов, например. Такая группа является самоорганизующейся и методами проб и ошибок, как показывает опыт, выдает нужный результат. Попытка увеличить группу хотя бы до 12-14 человек приведет к неизбежному разрастанию коллектива до 25-30 человек (за счет управленцев), из-за необходимости организовывать сложное взаимодействие между ними, при этом общая производительность труда группы разработки не повысится.
2. Важным является наличие хорошего постановщика задачи и архитектора проекта. Эти люди должны владеть приемами выделения основных задач проектов и сведения их к стандартным классам алгоритмов. Это позволяет организовать разработку больших проектов как поточное промышленное производство, без потери качества работы.
3. Строгая сегментация задачи позволяет сильно снизить общую сложность системы. При увеличении количества сильносвязанных компонентов в системе ее сложность растет экспоненциально, а при добавлении слабосвязанных - линейно. В процессе создания системы принимались специальные меры для того, чтобы части системы были максимально независимы и взаимодействовали по строго определенному протоколу. Была выбрана ориентация на использование принципов объектно-ориентированного проектирования. Однако эти принципы были использованы только на самом высоком уровне абстракции данной системы.
4. Существующие инструментальные средства создания приложений обычно выгодны для группы разработчиков. Вложенные средства с лихвой окупаются экономией затрат труда.
Многие существенные для программиста утилиты встроены в операционную систему Unix и часто полностью покрывают все запросы разработчика.
5. При создании системы применялась схема циклической разработки, когда в изменении находятся и постановка задачи, и проектирование, и программирование, и тестирование. Это привело к быстрой "оборачиваемости" информации в проекте. Ни на одном этапе информация не задерживалась и сразу становилась доступной заинтересованным лицам. По нашему мнению, скорость "прокрутки" информации является решающим фактором для скорости создания приложения.
Какие подходы использовались
1. Обеспечение максимальной надежности
Должную надежность и достаточную производительность серверной части системы ныне могут обеспечить две платформы: мэйнфрейм и "большой" Unix-сервер. Первый вариант из-за необходимых больших начальных затрат пришлось отвергнуть. Второй вариант вполне удовлетворил команду разработчиков, к тому же кроме надежности и производительности Unix на большинстве платформ дает масштабируемость и открытость.
Общий принцип состоял в том, чтобы критические участки комплекса использовали по возможности готовые решения. Так обстоит дело в обеспечении физической целостности базы данных (это задача СУБД) и в механизме передачи сообщений (тут работает монитор транзакций и протокол TCP/IP). К сожалению, пока у использовавшегося нами монитора транзакций отсутствует библиотека сопряжения со средой Java (хотя BEA SYSTEMS ведет работы над этой библиотекой), поэтому нам пришлось самим написать программные демоны для сопряжения программ на Java с сервером приложений и использовать эти демоны как временный вариант сопряжения.
Некоторое сомнение, с точки зрения надежности, у нас длительное время вызывала способность OpenIngres, в качестве опции, завершать транзакцию только в оперативной памяти и в журнале транзакций, откладывая реальную запись в область данных "до удобного случая" (режим FastCommit). Это примерно в 2 раза ускоряет работу быстрых транзакций (OLTP), но при внезапном отключении питания или сбое операционной системы (события, конечно, в нормальной конфигурации совершенно гипотетические), как мы подозревали, могло бы привести к потере последних завершенных транзакций или даже к нарушению целостности данных. Для исследования были искусственно вызваны многочисленные "падения" системы при различных условиях. Единственным следствием включенного режима FastCommit было несколько большее время, затрачиваемое системой при следующем после сбоя старте, так как при старте СУБД автоматически восстанавливает целостность баз данных, используя журнал транзакций, а в режиме FastCommit восстановление является более сложной задачей. В общем, мы пришли к выводу, что режим быстрых транзакций не ухудшает надежность системы.
Для постоянного контроля системы были написаны несколько тестовых приложений, которые в фоновом режиме в ночное время производят различную проверку хранимой информации. Целью этих программ является обнаружение нарушения логической целостности данных прежде, чем это скажется при работе. Также были созданы средства быстрого восстановления целостности.
Надо сказать, что при эксплуатации системы ни разу не произошли нарушения данных. Но серьезная система обязана считать себя ненадежной и производить постоянную самопроверку. Именно "параноидальность" системы бережет банк от простоев из-за неисправности его информационного "сердца".
На крайний случай, когда ничего не помогло и база данных непоправимо разрушена, обязана присутствовать страховая копия базы данных на независимом хранителе информации. Например на ленте. Система автоматически создает такую копию в ночное время. Мы считаем, что для коммерческого банка разумно иметь по отдельной копии на каждый день недели.
Что касается клиентского приложения, то, поскольку бесполезно добиваться надежной работы от программы, работающей под управлением MS Windows, вопрос надежности в этой области был решен радикально. Сбой клиентского приложения вообще не влияет на целостность базы данных и на работу остальных пользователей, так как клиентское приложение не взаимодействует напрямую с СУБД. Программа-клиент все необходимые манипуляции с данными осуществляет через "посредника" - сервер приложения. Контекст конкретного пользователя в СУБД не ведется, поэтому сбой в клиентском приложении никак не влияет на работу СУБД. В сервере приложения контекст клиента существует только в момент обработки запроса. Если клиентская программа перешла в ненормативный режим, следует просто осуществить ее перезагрузку.
Конечно, версии клиентского приложения для Win95 и, особенно, NT, работают заметно более стабильно. Значительно устойчивее клиентская программа работает и под управлением OS/2.
2. Обеспечение "прозрачного" выполнения всех корректных банковских операций
Для удовлетворения этого требования разработчикам пришлось погрузиться в детальный анализ алгоритмов бухгалтерии. Некоторые сложившиеся к тому времени стереотипы по поводу построения базы данных пришлось пересмотреть. Особые сложности возникли с внесением изменений в базу данных задним числом. Удалось построить структуру данных таким образом, чтобы подобные изменения корректно отрабатывались без всяких "откатов", что особенно важно в валютной части программы из-за усложнений, вносимых переоценками. Как следствие, система позволяет работать любому количеству пользователей в любом количестве операционных дней параллельно (конечно, "задним числом" могут работать только пользователи с достаточными полномочиями).
Необходимость исключить особые режимы работы и периоды технологических работ привела к построению сложной системы блокировок базы данных. Все действия в базе данных были разбиты на три крупные группы ("не требующие никаких блокировок", "требующие блокировки на чтение", "требующие блокировки на запись"), и в дальнейшем производилась настройка конкурентности запуска процессов из разных групп для исключения взаимного влияния. В результате все административные работы в СУБД выполняются на фоне обычной ежедневной работы.
CA-OpenIngres обладает развитыми системами блокировок, индексации и оптимизации. Имеется возможность для приложения динамически менять условия блокировки таблиц (уровень блокировки и ее степень, причем разные для разных таблиц), что позволяет программисту настраивать режимы работы приложения для обеспечения оптимальной конкурентности доступа. Кроме того, важным качеством является предоставление выбора наиболее оптимальных структур хранения данных для каждой из таблиц и для каждого вторичного индекса в базе данных: BTREE, ISAM, HASH или HEAP, а также средства прозрачного для приложения и для администратора сжатия хранимых на диске данных.
Недостаток использованной разработчиками СУБД - отсутствие средств для блокировки отдельной строки таблицы. Однако эта возможность на практике оказалась не очень нужна. Очень часто в банке различные пользователи блокируют на короткое время в исключительном режиме одни и те же данные. Например, при приеме документов от клиентов все операционисты одновременно переводят деньги со счетов клиентов на очень ограниченное множество промежуточных счетов (их не более, чем несколько). Поэтому часто различные операционисты пытаются заблокировать один и тот же счет. В таком случае попытка достичь конкурентности доступа путем блокирования на уровне строки не только ничего не дает, но и повышает вероятность создания условия для взаимной блокировки. Таких режимов работы в коммерческом банке большинство. Разработчики добивались конкурентности доступа путем особого проектирования сервера приложений. Однотипные запросы, которые, с большой вероятностью, будут мешать друг другу, выстраиваются сервером приложения в строгую очередь. Такие запросы максимально оптимизируются. Время их выполнения настолько мало, что для пользователей, например, вводящих документы, создается иллюзия одновременности обработки.
В ожидаемой в ближайшее время версии OpenIngres 2.0 возможность блокировки по строке уже будет реализована.
Ниже мы перечислим дополнительные приемы обеспечения максимальной независимости пользователей друг от друга.
а. Тщательное проектирование схемы данных. Это наиболее важный компонент. За счет совершенствования аппаратной платформы, СУБД, системного программного обеспечения можно добиться ускорения работы отдельных операций на десятки процентов, в лучшем случае - в несколько раз. А оптимизация структур данных может дать ускорение работы на порядок, а то и больше.
Для оптимизации времени выполнения операций разработчики сознательно отказались от нормализации таблиц данных. Дисковая память сейчас очень дешева и экономить ее нет особой причины. А рабочее время человека, наоборот, все дороже. Поэтому разработчики пожертвовали принципами строгого проектирования базы данных в пользу скорости работы и простоты приложения. Например, все документы в базе данных хранятся в единой таблице (не считая таблиц с дополнительными полями), несмотря на различный состав данных разных документов. Это сильно упрощает (и, как следствие, ускоряет) алгоритмы программы, и, кроме того, для администратора системы становится много проще писать новые отчеты.
Поясним это на примере. Возьмем таблицу, содержащую документы системы. При создании модели хранения данных было принято решение включить в таблицу документов все поля, необходимые для основных типов документов. Т.е. в одной таблице хранятся данные и для, например, простых мемориальных ордеров, и для документов по конвертации валют (но, конечно, с разными значениями в поле "класс документа"). Каковы плюсы данного подхода? Во-первых, для программиста упрощается реализация простых однотипных операций над документами (проведение документа, разноска, отмена, удаление и т.п.). Эти операции делают просто одни и те же участки кода (или, в объектной модели, одни и те же методы корневых классов). Во-вторых, и для администратора упрощается процесс создания новых классов (на уровне средств run-time). Ему не нужно создавать новую таблицу для каждого класса, с большой вероятностью необходимые для нового класса элементы (столбцы) уже присутствуют в основной таблице. В-третьих, более эффективным становится процесс создания отчетов, и вот почему. В реляционной модели процесс соединения больших таблиц отнимает огромные ресурсы компьютера. Конечно, с помощью первичных и вторичных индексов можно оптимизировать эту операцию. Но тогда на администратора системы ложится тяжелая задача оптимизации схемы индексирования таблиц для конкретного набора созданных и используемых отчетов, от чего создателям системы хотелось бы максимально избавить администратора по соображениям гуманности. Поэтому схема индексирования была один раз подобрана для одной большой таблицы, и администраторам системы предложено пользоваться ей. Кроме того, в таком ненормализированном подходе уменьшается сама необходимость использования запросов с соединением таблиц. Несмотря на накладные расходы, связанные с необходимостью поддерживать и просматривать избыточные поля (столбцы) в таблице, это все же небольшая плата за исключение во многих случаях операции соединения больших таблиц.
Вообще говоря, упрощается и процесс написания спецификации отчета, так как в этой спецификации будет всегда указываться одна и та же таблица, но с разным набором полей данных.
Конечно, не стоит любую идея доводить до абсурда. Если в большой таблице, содержащей миллионы записей, необходимо хранить всего лишь тысячу документов, имеющих одно уникальное поле, не стоит расширять этим полем огромную таблицу. В системе имеется механизм "присоединенных таблиц", с помощью которого администратор может создать таблицу, содержащую дополнительные поля для какого-либо нового типа документа. Фактически, серверная программа эмулирует таблицу с переменным набором полей для различных строк таблицы. Для реализации такой сложной структуры данных применялся аппарат объектного программирования.
Кроме того, первоначальная таблица документов все же не является единой, она разбита на две существенно разных по смысловой нагрузке таблицы - на таблицу проводок и таблицу собственно данных документов в узком смысле этого слова. Это позволило реализовывать сложные многопроводочные документы без изменения структуры хранения данных.
В общем, для определения структуры хранения данных было подобрано компромиссное решение, обеспечивающее, по нашему мнению, простоту, универсальность и эффективность.
Модель нижнего уровня хранения и обработки данных документооборота показана на рис. 2. Из рисунка видно, что программа-клиент и программа-сервер взаимодействуют с базой данных через интерпретатор модели документооборота (ИМД). Его работа базируется на определениях, записанных в специальных таблицах описаний классов документов (это таблицы классов, переходов, состояний, различных прав доступа, таблиц макросов и экранных форм). Этим достигается высокий уровень абстракции, позволяющий вынести конкретные правила поведения документов за пределы кода программы. Для такой модели естественно, что внешний вид различных документов тоже не "зашит" в код клиентской программы, она только использует спецификации, записанные в таблицы определений. Для работы с таким сложным механизмом у администратора системы имеется удобный графический инструментарий, позволяющий изменять содержимое таблиц определений классов и тестировать новые конфигурации.
Модель нижнего уровня хранения и обработки данных документооборота.
В состав функций ИМД входит и поддержание логической целостности таблиц документооборота. Здесь появилась возможность отказаться от использования триггеров СУБД в их классическом виде, поскольку интерпретатор документооборота имеет монопольное право на обращение к таблицам СУБД, связанным с хранимыми документами. Триггеры удобны в многопользовательской среде, здесь же имеется лишь один "пользователь" - ИМД, несущий в себе все правила взаимодействий таблиц данных. Фактически, аналоги триггеров содержатся в таблицах описания документооборота, средства манипулирования ими вынесены на уровень клиентского места администратора системы. При этом мы ни в коем случае не считаем, что такое решение обязательно подходит для каких-либо других задач. Просто для данной конкретной задачи, на наш взгляд, такой подход оптимален. Отказ от использования собственных триггеров СУБД для поддержания логической целостности данных в случае двухуровневой архитектуры клиент-сервер мы считаем безусловной ошибкой. Да и в случае трехуровневого клиент-сервера мы бы не рекомендовали кому-либо сразу отказываться от поддержания логической целостности базы данных средствами самой СУБД. Наш вариант усложняет разработку и повышает вероятность ошибок в конечном продукте. Мы пошли на такой вариант ради повышения скорости работы серверного комплекса и для упрощения администрирования системы. Но это потребовало тщательного тестирования программы для избавления от ошибок поддержания целостности.
С точки зрения программы-клиента и верхних уровней серверной программы, система поддержания целостности данного программного комплекса идентична таковой в СУБД, т.е. при попытке совершить недопустимую операцию интерпретатор документооборота выдает соответствующий код ошибки и текстовое сообщение.
Еще следует заметить, что название "интерпретатор" не следует воспринимать "интерпретатор программного кода". Это обычная программа на С++, откомпилированная в машинные коды, эффективно использующая многопроцессорные конфигурации и являющаяся интерпретатором в том же смысле, в каком программа DOOM является интерпретатором "методики уничтожения живой враждебной силы". Поэтому не возникает вопроса об эффективности работы такой программы.
На рис. 3 показана логическая модель организации документооборота. Фактически эта модель соответствует тому, как работа с документооборотом выглядит для клиентской программы и для администратора системы.
Модель верхнего уровня документооборота.
Как мы видим, для программы-клиента и программы-сервера эмулируется виртуальная объектная СУБД, в качестве интерфейса имеющая такие команды, как "создать объект такого-то класса", "совершить переход объекта из состояния в состояние", "удалить объект", "вернуть полное описание объекта по идентификатору", "вернуть список описаний объектов с такими-то общими характеристиками". Данная модель, по нашему мнению, очень удобна как для дальнейшего развития системы, так и для расширения системы силами работников управления автоматизации конкретного банка.
Все программные интерфейсы системы управления документооборотом открыты, все алгоритмы интерпретации документооборота доступны изменению силами работников, сопровождающих систему.
Методологическая основа такого построения системы дана в работе [4]. Мы просто применили описанные в этой работе концепции для системы платежного документооборота.
Для оптимизации и структуризации алгоритмов доступа к табличной информации все таблицы в СУБД были разбиты на три большие группы.
· Группа справочных таблиц. Включает в себя примерно 50 таблиц с настраиваемой справочной информацией. Это, как правило, небольшие таблицы (до 20 тыс. записей).
· Группа "больших" таблиц. Это таблицы проводок, документов, счетов и др. (примерно 10 таблиц). Количество записей в таких таблицах планируется до десятков и сотен миллионов.
· Группа избыточных таблиц. Содержит оперативно обновляемую информацию, не являющуюся необходимой для извлечения данных из СУБД, но ускоряющую такое извлечение на несколько порядков. Например, имеется таблица, содержащая в себе обороты и остатки по всем балансовым счетам второго порядка за все даты. Понятно, что при подсчете баланса использование этой таблицы многократно ускоряет отчет. Все эти таблицы обновляются в режиме on-line, что потребовало разработки сложных алгоритмов.
Для оптимизации работы СУБД с большими таблицами рекомендуется разбивать их на отдельные фрагменты, располагающиеся на физически различных дисковых пространствах. Это делается администратором системы, и такое разбиение является прозрачным для программ, работающих с подобными таблицами. Это означает, что, например, таблица документов может располагаться на 10 различных дисках, но SQL-запросы будут с этими данными работать как с единой таблицей. При этом многие операции над различными физическими пространствами СУБД выполняет параллельно, с использованием различных потоков ядра СУБД. Но следует заметить, что, по нашему мнению, основанному на практическом применении СУБД, реализация многопотоковости в OpenIngres 1.1 требует доработки. К моменту написания данной статьи мы еще не протестировали в полной мере версию 1.2 этой СУБД и не можем пока сказать, что этот недостаток устранен.
б. Передача SQL-запросов от приложения к СУБД происходит в оперативной памяти компьютера-сервера, а не по сети. Это сильно снижает накладные расходы системы на обмен информацией.
Составные (multistatement) транзакции требуют неоднократного обращения приложения к СУБД. Если такое приложение находится не на том же компьютере, на котором установлена СУБД, это вызывает необходимость неоднократного обращения к компьютерной сети в ходе обработки одной транзакции. Сетевое взаимодействие сильно уступает по скорости межпроцессному взаимодействию в современных операционных системах, даже если компьютеры соединены локальной (а не обычно медленной глобальной) сетью. Разработчики данного проекта предусматривали работу и в глобальной сети. В описываемой системе на каждую, даже сложную, транзакцию по сети передается только один небольшой пакет с данными от клиентского приложения к серверному. Сервер приложения, располагаясь на том же компьютере, что и СУБД, осуществляет весь обмен запросами с СУБД и отправляет клиентскому приложению конечный результат.
в. Широко применялось такое свойство СУБД, как возможность запоминать уже один раз "разобранные" и оптимизированные запросы, и при повторных вызовах однотипных запросов использовать эту информацию. Это повышает скорость выполнения OLTP-запросов в несколько раз.
г. Широко применялась всесторонняя индексация, с сильной избыточностью, больших таблиц базы данных. Большое количество индексов несколько снижает скорость выполнения OLTP- запросов, зато на порядки повышает скорость запросов анализа данных (DSS-запросы). Задача проектировщика - разработать оптимальную систему индексации таблиц приложения. Впоследствии, при доводке приложения, требуется тонкая ручная работа по окончательной настройке системы индексации.
3. Совместная работа валютного и рублевого управлений банка
Разработчики использовали схему многовалютной базы данных, при которой имеются независимые плоскости счетов для каждой из валют и все операции совершаются в рамках одной плоскости. Но такая общепринятая международная практика вступает в противоречие с используемыми в отечественной бухгалтерии алгоритмами, например, конвертации. Для решения этой проблемы нами было использовано понятие счетов-проекций для некоторых валютных счетов (например для группы 76-х счетов). В результате была получена возможность совершать любые требуемые операции, не нарушая при этом баланса по каждой отдельно взятой валюте.
4. Связь с филиалами
В системе были реализованы три различные стратегии обмена информацией между филиалами. Ниже мы их коротко опишем, в порядке убывания оперативности.
а. Филиалы, где возможна организация надежной связи в режиме on-line, имеют единую базу данных в одной территориальной точке и образуют некий "кластер", внутри которого информация циркулирует почти мгновенно. Для повышения надежности применяется дублирование линий связи. Нам представляется оптимальной для данного приложения конфигурация для каждого филиала с основной линией связи на 64 Кбит и линией-дублером на 19 Кбит.
б. В тех случаях, когда возможность соединения филиалов по протоколу TCP/IP есть, но надежность или скорость такой связи вызывает сомнения (слишком много теряется пакетов, часты разрывы или слишком узкая полоса пропускания сигнала), разумно держать в каждом филиале (или "кластере" филиалов из предыдущего примера) свою базу данных. Обмен информацией между такими филиалами будет происходить довольно редко, например для прохождения межфилиальных документов или для подсчета консолидированного баланса.
в. Если нет возможности установления связи между филиалами по протоколу TCP/IP, обмен информацией между филиалами происходит через электронную почту.
Нам представляется наиболее правильным разумное сочетание стратегий а и б, и по возможности исключение ситуаций типа в, когда качество обслуживания клиентов заметно ухудшается. На практике это может реализовываться организацией филиальных "кластеров" в крупных центрах и соединением этих "кластеров" между собой выделенными линиями.
Для того чтобы такое решение было возможно, необходимо минимизировать объем информации, передаваемый по глобальным (обычно - довольно медленным) линиям связи. Монитор транзакций позволяет достаточно просто организовать такое взаимодействие компьютеров в глобальной и локальной сетях, при котором трафик в сети будет минимален.
Организация обмена между клиентской и серверной частями программы через высокоуровневый протокол позволила свести трафик в сети к минимуму и осуществить прозрачную работу в глобальной сети. Проводившиеся нами опыты показали, что такой подход гораздо эффективнее (и проще), чем варианты с терминальным доступом по выделенной линии (например X-терминал или способы эмуляции удаленного доступа к MS Windows).
Программа-сервер является, с точки зрения программы-клиента, высокоуровневым сервером базы данных. Эта "СУБД" понимает и выполняет такие высокоуровневые команды, как "создать документ", "выполнить такой-то отчет" и т.п. В результате, например при вводе документа, по сети передается только один пакет, хотя в системе эта операция может вызвать сотни обращений к СУБД в случае сложной финансовой транзакции.
По предварительным расчетам, вычислительный центр в Москве на основе ЭВМ класса SPARCServer 6000 с процессорами UltraSPARC способен обеспечить работу в единой базе данных нескольких десятков филиалов и прохождение платежей из филиала в филиал в течение долей секунды. В нижней части спектра масштабируемости SPARCServer Ultra 2 обеспечивает работу 2-3 средних филиалов или 3-5 небольших отделений.
5. Открытость алгоритмов обработки данных
Для выполнения этой задачи применялись:
· схема объектной организации документооборота;
· настраиваемый план счетов;
· настраиваемые способы ведения счетов.
6. Безопасность и контроль прав доступа
Права доступа пользователя хранятся в специальной таблице в базе данных. Для каждого пользователя может быть предусмотрена гибкая система контроля прав в зависимости от выполняемых им действий. В общем случае каждый пользователь обладает уникальными, присущими только ему правами в системе, и таким образом настраиваются рабочие места пользователей в зависимости от их функций.
Каждое действие пользователя (каждое обращение к серверу) вызывает проверку его полномочий на данное конкретное действие. Эта проверка совершается оптимальным образом и не влияет на производительность системы. В случае, если пользователь не имеет полномочий на совершение действия, ему выдается соответствующее сообщение. Если же полномочия имеются, на время совершения действия пользователь получает "билет", в котором детально описаны особенности полномочий данного пользователя на данное действие (например имеет ли пользователь право создания валютных документов). Сразу после выполнения действия ·билет· уничтожается. По сети "билет" не передается, и его структура недоступна для прослушивания. Впрочем, знание этой структуры ничего не даст злоумышленнику. Но чем меньше информации ему доступно, тем лучше.
Поскольку все сервисы TUXEDO запускаются от имени одного системного пользователя, приложение не может прямо использовать присущую каждой конкретной СУБД систему секретности. Но это нетрудно обойти, используя механизмы ролей и схем и динамически, при обработке каждого запроса, подстраивая текущую роль или схему под конкретного пользователя.
Тот факт, что затруднено использование системы контроля СУБД, накладывает особую ответственность на приложение в области контроля прав пользователя.
Для настройки безопасности документооборота система позволяет определить положение пользователя в потоке документов и доступную ему информацию. В процессе своего существования документ фиксирует пользователей, совершавших над ним действия, а также даты и времена этих действий. Все удаленные документы хранятся в специальной таблице, и администратор всегда может проверить факт исчезновения важного документа, кто и когда его удалил.
Результат проекта
Проект, создававшийся и тестировавшийся в течение 1994 года, был введен в промышленную эксплуатацию 4 января 1995 года и получил название RP/3. Все фундаментальные алгоритмы (связанные с движением денежных сумм в банке) прошли серьезную и длительную проверку в реальных условиях. Время показало, что выбранная схема оправдала себя.
Внедрение системы RP/3 было сопряжено с трудностями, связанными с коренной перестройкой методов работы бухгалтерии банка в результате перехода на новые принципы организации труда. Теперь основным показателем качества и скорости выполнения работы являются интегральные показатели таковых, а не отдельно взятые операции. Поясним на примере. Ранее высокой скоростью работы программы называлась способность программы быстро ввести в базу данных платежный документ. Не принималось во внимание то, что потом на работу с этим документом и на обработку информации уйдет большое количество рабочего времени. Система RP/3 создавалась в расчете на сокращение общего количества времени и сил, затрачиваемых работниками банка на обработку платежных документов и связанных с ними отчетов.
Приведем наиболее важные, по нашему мнению, особенности программного комплекса.
1. Обеспечение надежной сохранности данных. За все время интенсивного тестирования комплекса и его полуторагодовой эксплуатации ни один байт информации не был искажен или потерян.
2. Повышенный уровень безопасности. Ведется учет всех важных изменений в базе данных. Данные различных филиалов, отделений и подразделений надежно защищены от доступа "чужих" пользователей. При этом главный бухгалтер (или другой наделенный особыми правами пользователь) имеет доступ к данным всех филиалов и отделений.
В системе принята следующая классификация. Филиал - это некоторая территория банка, имеющая свой замкнутый баланс, а отделение - территория, баланс которой является подмножеством баланса филиала.
3. Высокая общая скорость обработки банковской информации. Оказалось, что компьютер SPARCServer 20/712 (машина класса средней рабочей станции) может служить сервером приложения примерно для 80 активных пользователей. Мы считаем, что это очень неплохой результат.
4. Возможность организации работы нескольких (или всех) филиалов банка в едином пространстве данных, с использованием выделенных линий связи. При этом достаточной является скорость передачи 64 Кбит/сек. Объем пересылаемых данных, благодаря использованию технологии создания приложения с монитором транзакций, очень невелик, и уже при такой скорости передачи временные затраты на перекачку данных малозаметны для группы операционистов, подключенных к одной выделенной линии.
5. Общая рублевая и валютная база. Никакая проводка или счет валютного операционного дня не копируется в рублевый операционный день - это просто единое целое. Каждая проведенная валютная проводка мгновенно изменяет суммы в рублевом балансе. Нет понятия "отражение счета", банк работает над единым множеством счетов и проводок.
6. Система настройки документооборота, система гибких отчетов, система создания типовых запросов, система формирования одноразовых запросов позволяют оперативно реагировать на изменяющиеся потребности банка и организовывать сопровождение программного комплекса без непосредственного участия программистов.
7. Программные спецификации, прилагаемые к системе, дают возможность дорабатывать ее в соответствии с собственными представлениями программистов банка о том, что и как должна делать банковская программа. Спецификации позволяют создавать новые программные модули в таких системах, как DOS, MS Windows, Unix. Дополнительно прилагается С-подобный язык скриптов (командных файлов) и интерпретатор этого языка. Это средство позволяет организовывать сложную пакетную обработку данных (например связь с системой "клиент-банк").
Литература
- Ладыженский Г. М. СУБД - коротко о главном, раздел 4.2. - СУБД, N4, 1995.
- Гради Буч, Объектно-ориентированное проектирование. - Киев: "Диалектика" и М.: "И.В.К.", 1992.
- Как упростить переход к системам клиент/сервер нового поколения. - ComputerWeek-Москва, стр. 29, 20-26 июня, 1996.
- Салли Шлеер, Стефан Меллор. Объектно-ориентированный анализ: моделирование мира в состояниях. - Киев: "Диалектика", 1993.
Олег Михайлович Москаленко, АО "Инфосистемы Джет", тел.: 972-11-82