CC BY
78
ПРИМЕНЕНИЕ СА8Е-ТЕХНОЛОГИИ ПРИ ПРОЕКТИРОВАНИИ БАНКОВСКИХ СИСТЕМ БУХГАЛТЕРСКОГО УЧЕТА
К. МАРКОВ
Концепция СА8Е-технологий в приложении к проектированию систем бухгалтерского учета
Успешная работа любого коммерческого банка напрямую зависит от качества функционирования автоматизированной системы бухгалтерского учета (АС БУ). За внедрение информационных технологий в банке отвечает отдел автоматизации (управление информатизации и др.). Часто в силу своей малочисленности и сложности АС БУ этот отдел не может самостоятельно разработать всю систему бухгалтерского учета "с нуля". Поэтому банки, как правило, покупают требуемые автоматизированные системы у фирм, кото-
рые специализируются на разработке банковских систем (табл. 1). За 1993-1997 годы число российских банков, использующих покупные (внешние) АС БУ, возросло более чем на 70%. За тот же период количество банков, которые используют только собственные разработки АС БУ, уменьшилось с 32,8% до 29,0%'. И эта тенденция сохраняется.
Однако, каждый коммерческий банк имеет специфические особенности работы, для многих специалистов требуется более "дружественный" интерфейс, чем тот, который предлагается фирмой-изготовителем АС БУ. Следовательно, перед отделом автоматизации возникает задача адапта-
1 Маркелов К. Время ответов на вопросы // Computerworld Россия. - М., 1999. - № 10. - С. 9-10.
Таблица 1
Системы бухгалтерского учета, разработанные специальными фирмами
Наименование системы (фирма-изготовитель) Назначение системы Среда функцион ирован ия Возможность доработки пилотного проекта системы силами отдела автоматизации банка с помощью САБЕ-средстп
01а5оЛВАМК 4x4 (Диасофт 4x4) Комплексная система автоматизации банковской деятельности СУБД: Btrieve, Pervasive SQL, DB2 for AS/400, Informix Да
КавойОЛЕМТ 4x4 (Диасофт 4x4) Система электронных расчет в между банком и клиентом Clarion for Windows с использованием СУБД Btrieve Нет
КавоЛЯЕТАИ. 4x4 ЭВ (Диасофт 4x4) Система обслуживания частных лиц (кредиты, депозиты) СУБД: Btrieve, Pervasive SQL, DB2 for AS/400, Informix Да
КзбоЛЕХСНА^Е 4x4 (Диасофт 4x4) Система автоматизации валютного обменного пункта Clarion for DOS 3.1 с использованием СУБД Btrieve. Нет
01а5ойС11Е01Т 51МТ (Диасофт 5НТ) Система автоматизации кредитной деятельности банков СУБД: Microsoft SQL Server и Sybase SQL Server Нет
КавойСШТОБУ 5МТ (Диасофт 5НТ) Система автоматизации деятельности банка на фондовой бирже СУБД: Microsoft SQL Server и Sybase SQL Server. Нет
01а5оЛОЕА1Л!ЧО 51МТ (Диасофт 5НТ) Система управления ресурсами банка СУБД: Microsoft SQL Server и Sybase SQL Server Нет
НОВАЯ АФИНА (совместный продукт компаний "Диасофт" и "ПрограмБанк) Система управления банковской деятельностью СУБД: Oracle Да
Продолжение табл. /
Наименование системы (фирма-изготовитель) Назначение системы Среда функционирования Возможность доработки пилотного проекта системы силами отдела автоматизации банка с помощью СА8Е-средств
Ва-Банк, Ва-Банк ПЛЮС/ SYMBOLS-R (Форс) Интегрированные системы автоматизации банковской деятельности СУБД: Oracle Да
Центавр или DOS-комплекс (Програмбанк) Автоматизированная банковская система СУБД: Clipper Нет
Гефест (Програмбанк) Автоматизация бухгалтерского учета в коммерческих банках СУБД: Cache Нет
RS-Bankv. 5.0 (R-Style) Автоматизированная банковская система СУБД: Pervasive SQL, MS SQL, Sybase и DB400 Да
GLOBUS (Temenos) Интегрированная банковская система СУБД: universe Да
БИСквит (БИС) Банковская интегрированная система СУБД: Progress Да
БАНК XXI ВЕК (Инверсия) Автоматизированная банковская система СУБД: Oracle Да
МОДЕЛЬ-ПРОТОТИП (LVS Corporation) Автоматизированная банковская система СУБД: Oracle Да
ции купленной системы к требованиям конкретного банка. Более того, в процессе эксплуатации системы требуется постоянно вносить изменения в программное обеспечение. Они связаны с вновь поступающими нормативными документами: инструкциями и приказами ЦБ России, а также с изменениями в технологии работы банка.
Учитывая это, многие фирмы-изготовители как бы "погружают" свои продукты в среду САБЕ-средств (в табл. 1 они отмечены словом "да" в 4-м столбце). Отдел автоматизации банка может использовать эти САБЕ-средства после покупки продукта, чтобы быстро доработать АС БУ. На рис. 1 представлена предлагаемая в работе схема разработки автоматизированной системы бухгалтерского учета с использованием САБЕ-технологий. Эта схема относится к классу спиральных моделей проектирования информационных систем.
На рисунке показано, что до момента времени ^разработку ведет фирма-изготовитель АС БУ. Она выполняет декомпозицию системы на подсистемы ("Многовалютный операционный день", "Кредитное и депозитное обслуживание", "Ценные бумаги" и др.) и создает пилотный проект (макет, модель-прототип). Далее отдел автомати-
' Вендров A.M. CASE-технологии. Современные методы и средства проектирования информационных систем. - М: Финансы и статистика, 1998.
Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). М.: Издательство "ЛОРИ", 1996.
зации банка с помощью САБЕ-средств выполняет доработку этого пилотного проекта. Каждый виток разработки или доработки системы (рис. 2) включает шесть этапов (1-6).
На этапе разработки архитектуры АС БУ (первый этап) решаются следующие задачи: выбирается модель доступа к данным; осуществляется выбор структуры комплекса технических средств (КТС) подсистем АС БУ;
определяется состав общесистемных пакетов (ОС, СУБД и др.).
На втором этапе на основе анализа предметной области строится функциональный граф, связывающий функции будущих подсистем с входными и выходными данными. Выходные данные одной функции могут служить в качестве входных для других. Этот граф часто называют диаграммой потоков данных.
На третьем этапе данные структурируются в виде концептуальной схемы (КС) базы данных (БД), а функции объединяются в задачи будущих подсистем АС БУ. При разработке концептуальной схемы проектировщик руководствуется следующими абстракциями: агрегацией, обобщением, ассоциацией. КС базы данных изображается с помощью диаграммы "сущность-связь'". На этом этапе также разрабатываются спецификации задач будущих подсистем, то есть определяются входные и выходные данные каждой задачи и алгоритмы связей между ними. Следует отметить, что концептуальный проект не зависит от реал и-
К следующему витку спирали
1 - выбор архитектуры ,
2 - выявление информационных потребностей,
3 - концептуальное проектирование,
4 - логическое проектирование,
5 - отладка, тестирование, анализ,
6 - использование и сопровождение.
Рис. /. Схема разработки АС БУ с использованием CASE-технологий
зации и отражает содержательную сторону будущей системы бухгалтерского учета.
На этапе логического проектирования (четвертый этап) выполняется отображение концептуальной схемы базы данных и спецификаций прикладных задач в СУБД-ориентированную среду. При этом КС базы данных преобразуется в логическую схему БД, а спецификации задач - в прикладные программы на конкретном языке.
На пятом этапе выполняется отладка подсистем, а на шестом этапе - их сопровождение.
Следует отметить, что разделение работ на 6 этапов (см. рис. 2) является условным. Схема организации работ должна планироваться как адаптивная, а не как каскадная1. То есть все работы могут входить в глобальные проектные итерации и выполняться параллельно.
На рис. 2 представлены данные, поясняющие содержание шести этапов проектирования АС. В
1 Вендров A.M. CASE-технологии. Современные методы и средства проектирования информационных систем. — М: Финансы и статистика, 1998.
2Спортак М. Высокопроизводительные сети. Энциклопедия пользователя. - К.: Издательство "ДиаСофт", 1998.
прямоугольниках схематично изображены примеры решений, получаемых на каждом из этапов.
В настоящее время в банках используются, как правило, локальные вычислительные сети на витой паре2. Серверы (S) и рабочие станции (WS), подключенные к концентратору (Hub), образуют сегмент сети. Таких сегментов может быть несколько. Для связи с РКЦ и системой международных банковских расчетов SWIFT локальная сеть банка подключается через маршрутизатор (R) к средствам телекоммуникаций.
Диаграмма потоков данных включает в себя обозначения процессов подсистем АС БУ (на рис. 2 - прямоугольник) и хранилищ данных (специальные фигуры, отмеченные на рисунке цифрами). Хранилища часто используют для обозначения сущностей, используемых при концептуальном проектировании, а дуги -для обозначения тех атрибутов сущностей, которые являются входными или выходными данными процессов.
Сущности и их атрибуты используются для разработки концептуальной схемы базы данных, а для процессов разрабатываются спецификации задач на структурированном естественном языке.
Далее на основании концептуальной схемы базы данных генерируется логическая схема БД. Она представляет собой текст на языке описания данных (ЯОД) конкретной СУБД. Спецификации задач используются для разработки прикладных программ АС БУ (приложений, бизнес-правил). Для этой цели, как правило, используются языки 4GL (Fourth Generation Languages). С помощью этих языков разрабатывают экранные формы и тексты программ (триггеров, скриптов), обрабатывающих те или иные события, связанные с взаимодействием сотрудника банка с АС БУ.
Согласно обзору передовых технологий (Survey of Advanced Technology), составленному фирмой Systems Development Inc. в 1996 году по результатам анкетирования более 1000 американских фирм, CASE-технология в настоящее время попала в разряд наиболее стабильных информационных технологий (ее использовала половина всех опрошенных пользователей более чем в трети своих проектов, из них 85% завершились успешно). Однако, несмотря на все потенциальные возможности CASE-средств, существует множество примеров их неудачного внедрения, в результате которых CASE-средства становятся "по-
1. Выбор архитектуры АС БУ
Hub
-R^
S - сервер,
WS- рабочие станции,
R - маршрутизатор
2. Разработка диаграммы потоков данных
3. Разработка концептуальной схемы БД
4 -------
k........J
"Ü
Если нажата клавиша PgDn, то
Сохранить платёжный документ (4) ■Иначе
Если нажата клавиша Alt+M, то
Сформировать рейс (макет) в РКЦ (5) Иначе
Если нажата клавиша F8, то
Провести документ или удалить проводки (6,7)
4. Разработка логаче-ской схемы БД
4. Разработка прикладных программ
Рис. 2. Содержание этапов проектирования подсистем АС БУ
лочным" ПО (shelfware). В связи с этим A.M. Вен-дров, сотрудник ЦБ России, отмечает следующее1:
CASE-средства не обязательно дают немедленный эффект, он может быть получен только спустя какое-то время;
реальные затраты на внедрение CASE-средств обычно намного превышают затраты на их приобретение;
CASE-средства обеспечивают возможности для получения существенной выгоды только после успешного завершения процесса их внедрения.
' Вендров A.M. Современные CASE-технологии/УКорпоратив-ные базы данных '97: Материалы технической конференции. - М.: Центр информационных технологий, 1997.
2Fisher A.S. CASE: Using Software Development Tools. N.Y.: J. Wiley & Sons Inc., 1988.
Gibson M.L. The CASE Philosophy//BYTE. 1989, April, p. 209-218. McClure C. CASE in Software Automation. N.Y.: Prentice Hall, 1989.
Ввиду разнообразной природы СА5Е-средств2 было бы ошибочно делать какие-либо безоговорочные утверждения относительно реального удовлетворения тех или иных ожиданий от их внедрения. Доступная информация о реальных внедрениях ее в банках крайне ограничена и противоречива. Она зависит от типа средств, характеристик проектов, уровня сопровождения и опыта сотрудников отдела автоматизации. Отдельные аналитики полагают, что реальная выгода от использования некоторых типов САБЕ-средств может быть получена только после одно- или двухлетнего опыта. Другие полагают, что воздействие может реально проявиться в фазе эксплуатации жизненного цикла АС БУ, когда технологические улучшения могут привести к снижению эксплуатационных затрат.
Ключом к успешному внедрению СА8Е-средств является готовность к этому банка. Готовность включает следующие аспекты:
технология. Понимание ограниченности существующих возможностей и способность принять новую технологию;
культура. Готовность к внедрению новых процессов и культура взаимоотношений между сотрудниками отдела автоматизации и других подразделений банка;
управление. Четкое руководство и организованность по отношению к наиболее важным этапам и процессам внедрения. Статус руководителя, ответственного за создание банковской системы, должен быть достаточно высок. Его основной задачей является автоматизация деятельности всего банка, а не написание двух программ для кредитного отдела и трех программ для фондового отдела. Его статус должен быть не ниже начальника управления, а еще лучше - вице-президента.
В случае отсутствия готовности по данным аспектам внедрение САБЕ-средств скорее всего закончится неудачей независимо от степени тщательности следования различным рекомендациям по внедрению.
Руководство банка, где используются САБЕ-средства должно быть готово к необходимости долгосрочных затрат на эксплуатацию, частому появлению новых версий и возможному быстрому моральному старению средств, а также постоянным затратам на обучение нового персонала и повышение квалификации действующего персонала.
5. Отладка
Сопровождение
Несмотря на все высказанные предостережения, грамотный и разумный подход к использованию CASE-средств может преодолеть все перечисленные трудности. Успешное внедрение CASE-средств должно обеспечить такие выгоды, как:
высокий уровень технологической поддержки процессов разработки и сопровождения программного обеспечения АС БУ, а поэтому существенное уменьшение времени цикла разработки системы (рис. 2.1);
положительное воздействие на некоторые или все из перечисленных ниже факторов: производительность, качество обслуживания клиентов банка, соблюдение инструкций и приказов ЦБ России, документирование;
приемлемый уровень отдачи от инвестиций в CASE-средства;
повышение внимания руководства банка к планированию деятельности, связанной с информационной технологией.
Ниже представлена методика реализации 1-4 этапов проектирования подсистем АС БУ на основе CASE-технологий. Она может быть использована коммерческими банками при доработке пилотного проекта АС БУ или при разработке собственной автоматизированной системы, а также фирмами-разработчиками АС БУ.
Наиболее часто и эффективно применяются CASE-средства для описания:
диаграмм потоков данных совместно со словарями данных и спецификациями процессов (Data Flow Diagrams - DFD);
диаграмм "сущность-связь" (Entity-Relationship Diagrams - ERD).
Компоненты логической модели какой-либо подсистемы АС БУ представлены на рис. 3. DFD показывает внешние по отношению к системе источники и стоки (адресаты) данных, идентифицирует логические функции (процессы) и группы элементов данных, связывающие одну функцию с другой (потоки), а также определяет хранилища (накопители) данных, к которым осуществляется доступ. Каждая логическая функция (процесс) может быть детализирована с помощью DFD нижнего уровня. Когда дальнейшая детализация перестает быть полезной, переходят к выражению логики функции при помощи спецификации процесса (задачи). Со-
DFD
Процесс 1
Процесс 2
Внешняя сущность
Процесс 3
Поток данных
Детализация DFD для процесса 3
Процесс 1
7---
Детализация DFD для процесса 3.1
Спецификации программы процесса 3.2
Анализ архитектуры АС БУ
Г
и
Рис. 3. Компоненты логической модели подсистемы АС БУ
держимое каждого хранилища хранится в словаре данных. Модель данных хранилища затем раскрывается с помощью сущностей ERD. Структуры потоков данных и описания их компонентов также хранятся и анализируются в словаре данных. Наименования потоков данных затем используются для описания атрибутов сущностей ERD.
В отличие от традиционной схемы применения СА8Е-средств (ОРО и ERD) предлагается использовать средство для анализа архитектуры АС БУ. Это особенно важно для банков, имеющих многофилиальную структуру.
Методика, которая может быть использована при проектировании подсистем АС БУ включает методические материалы, необходимые для: разработки диаграммы потоков данных подсистемы бухгалтерского учета,
разработки концептуальной схемы базы данных банковских информационных подсистем; описания спецификаций приложений; разработки логической схемы базы данных; разработки прикладных программ; выбора архитектуры информационной системы коммерческого банка.
Разработка диаграммы потоков данных подсистем бухгалтерского учета
Основным средством моделирования функциональных требований проектируемой подсистемы АС БУ выступает диаграмма потоков данных (ОРО). С ее помощью эти требования разбиваются на функциональные компоненты (процессы) и представляются в виде сети, связанной потоками данных. Главная цель этих средств - продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
С помощью CASE-средств диаграмму потоков данных можно описать двумя способами1:
с помощью диаграммы на основе модели SADT (Structured Analysis and Design Technique);
с использованием диаграммы на основе собственно модели DFD (Data Flow Diagrams).
Эти диаграммы используются в таких CASE-средствах, как Disgner/2000 (Oracle), BPwin (Logic Works) и др.
1 Marka D.A., McGovan K.L. SADT: Structured Analysis and Design Technique. N.Y.: McGraw Hill, 1988. Вендров A.M. CASE-тех-нологии. Современные методы и средства проектирования информационных систем. - М: Финансы и статистика, 1998. Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). М.: Издательство "ЛОРИ", 1996.
2Yourdon Е. Modem Structured Analysis. N.J.: Yourdon Press/ Prentice Hall, 1989.
3Gane C., Sarson T. Structured System Analysis. - Prentice-Hall, 1979.
На рис. 4 представлен пример 8АОТ-диаграм-мы обработки платежных документов. Место соединения дуги (на рисунке - это стрелка) с блоком (на рисунке - это прямоугольник) определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм или человек, который осуществляет операцию, представляется дугой, входящей в блок снизу. Каждый родительский блок может быть детализирован с помощью двух или более дочерних блоков.
БАВТ-диаграммы могут использоваться для моделирования документооборота в банке, но из них трудно понять (см. рис. 4), какие функции выполняет сотрудник банка, а какие система бухгалтерского учета.
Анализ показывает, что для моделирования процессов, выполняемых собственно в АС БУ, более всего подходит модель ОРО. Для изображения ОРО традиционно используются две различные нотации (нотация -это язык описания): Йордана (Уоигдоп)2 и Гейна-Сарсона (Сапе-Загвоп)3. Основные символы ОРО изображены в табл. 2.
Потоки данных являются механизмами, которые используются для моделирования передачи информации из одной части системы в другую. Потоки на диаграммах обычно изображаются именованными стрелками, ориентация которых указывает направление движения информации. Иногда информация может двигаться в одном направлении, обрабатываться и возвращаться назад в ее источник. Такая ситуация может моделироваться либо двумя различными потоками, либо одним - двунаправленным. Далее при проектировании базы данных АС БУ имена потоков данных трансформируются в идентификаторы атрибутов сущностей.
Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Каждый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диаграммы для получения уникального индекса процесса во всей модели.
ALFTKOR: PBCUECr: 1
UOTES: UMS4T46»
Платёжные документы
Образцы подписей
0ДТЕ:1}Д2Л0 | KEY:
Остаток на счёте
4EADER СМГЕ С
ЗЕСОИЦЕЧРЕО " 'blBLlMT-юч
Бумажная копия клиенту -Э-
Проверка платёжных документов
Подписанные платёжные документы
Ответственный исполнитель
Регистрация платёжный документов
Операционист банка
АО
Рис. 4. Пример построения SADT-диаграммы обработки платежных документов
Основные символы диаграммы потоков данных
Поток данных (атрибуты сущностей Е1Ш)
Процесс
Хранилище (сущности Е1Ш)
Внешняя сущность
Нотация Йордана
имя
( имя \ V номер J
имя
имя
Нотация Гейна-Сарсона
имя
номер
имя
БД,
имя
имя
AUTHOR: PROJECT: 2
HOTES: 123450739 10
Хранилище (накопитель) данных позволяет на определенных участках определить данные, которые будут сохраняться в базе данных между процессами. Фактически хранилище представляет "срезы" потоков данных во времени. Информация, которую, оно содержит, может использоваться в любое время после ее определения, при этом данные могут выбираться в любом порядке. Имя хранилища должно идентифицировать его содержимое. В случае, когда поток данных входит или выходит из хранилища и его структура соответствует структуре хранилища, он должен иметь то же самое имя, которое нет необходимости отражать на диаграмме. Часто хранилища являются прототипами сущностей концептуальной схемы базы данных АС БУ.
Внешняя сущность (терминатор) представляет сущность (это не сущность схемы базы данных) вне контекста системы бухгалтерского учета, являющуюся источником или приемником системных данных (например, "Клиент банка"). Предполагается, что объекты, представленные такими узлами, не должны участвовать ни в какой обработке.
На рис. 5-8 представлены примеры описания диаграмм потоков данных фрагмента подсистемы "Многовалютный операционный день" АС БУ с помощью СА5Е-средства ВР\¥т.
Здесь каждая диаграмма следующего уровня является детализацией какого-либо процесса на
Таблица 2 диаграмме более высокого уровня.
Так, диаграмма на рис. 6 детализирует процесс "Многовалютный операционный день" (рис. 5), диаграмма на рис. 7 описывает процесс "Ввод", обозначенный на рис. 6, и т. д. То есть можно говорить об иерархии диаграмм потоков данных. Входные и выходные потоки данных какого-либо процесса изображаются на соответствующей дочерней диаграмме в виде дуг, один конец которых остается неприсоединенным. Например, входной поток данных "Ввод данных" на рис. 5 представлен на рис. 6 стрелкой со свободным концом.
Если поток данных, исходящий из какой-либо дуги (т. е. одним концом присоединенный к этой дуге), не имеет имени, то его имя совпадает с идентификатором дуги. Например, потоки данных на рис. 7, исходящие из дуги "Ввод данных", имеют то же имя. Для "расщепления" потоков данных используют процессы без имени. Например, поток "Ввод данных" на рис. 8 преобразуется в несколько потоков: "Реквизиты п/п", "Признак наличия" и др.
Диаграммы потоков данных используются в дальнейшем для:
разработки концептуальной схемы базы данных подсистем АБС;
описания спецификаций задач; разработки документации на подсистемы.
DATE: UÛ2.» REV:
RECOMMENDED
PUBLCATIÛH
СОЫТЕ^Т:
ТОР
Сотрудники банка
Справочные данные
Запуск
сервисных
фуню^й
ÛOJ
Многовалютный операционный день
ОД-О
Многовалютный операционный день
Рис. 5. Контекстная диаграмма потоков данных подсистемы операционный день "
"Многовалютный
Рис. 6. Детализация процесса "Многовалютный операционный день " (см. рис. 5)
Рис. 7. Детализация процесса "Ввод" (см. рис. 6)
Рис. 8. Детализация процесса "Платежи в национальной валюте " (см. рис. 7)
Разработка концептуальной схемы базы данных банковских информационных подсистем
Концептуальная схема (КС) базы данных, как правило, описывается с помощью диаграммы "сущность-связь" (ERD, ER-диаграмма), предназначенной для разработки модели данных и обеспечивающей стандартный способ определения данных и отношений между ними1. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой подсистемы, а также описываются сущности подсистемы и способы их взаимодействия, включая идентификацию объектов (сущностей), свойств этих объектов (атрибутов) и отношений с другими объектами (связей).
ER-диаграммы были введены Ченом (Chen)2 и получили дальнейшее развитие в работах Баркера (Barker)3. Для машинного проектирования ER-диа-грамм используют, в основном, две нотации:
Баркера - применяется в CASE-средстве Designer/2000 фирмы Oracle4;
IDEF1X (Icam DEFinition IX) - применяется в CASE-средстве ERwin фирмы Logic Works5. Сначала рассмотрим нотацию ER-диаграммы, предложенную Баркером.
1. Сущность (Entity).
Сущность на ER-диаграмме представляется прямоугольником любого размера, содержащим внутри себя имя сущности, список имен атрибутов (возможно неполный) и указатели ключевых атрибутов (знак # перед именем атрибута). Пример обозначения сущности показан на рис. 9.
2.Связь (Relationship).
Связь в нотации Баркера является бинарной, т. е. представляет собой линию, соединяющую две
'March С. (ed.) Entity-Relationship Approach. N.Y.: North Holland, 1988.
2 Chen P.P. The entity-relationship model: toward a unified view of data. - ACM Trans, on Database Systems, 1:1, 1976. ^Barker R. CASE*Method. Entity-Relationship Modeling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.
Barker R. CASE*Method. Function and Process Modeling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990.
"Горчинская О.Ю. DESIGNER/2000 - новое поколение CASE-продуктов фирмы Oracle // Системы управления базами данных. - М., 1995. - № 3. - С. 9-25.
5Горин С.В., Тандоев А.Ю. Применение CASE-средства Erwin 2.0 для информационного моделирования в системах обработки данных // Системы управления базами данных. - М., 1995. - № 3. - С. 26-40.
Горин С.В. Применение CASE-средства Erwin 2.5 для информационного моделирования в системах обработки данных // Корпоративные базы данных "96: Материалы технической конференции. - М.: Центр информационных технологий, 1996.
Код счёта
#Номер счёта Тип счёта (А,П) Дополнительные признаки Признак блокировки Дата открытия Дата закрытия
Признак отслеживания соответствия А/П Признак учёта курсовой разницы Курс
Л/с учёта курсовой разницы Наименование клиента Наименование счёта Валюта
Ответственный исполнитель Остаток по балансу Тип остатка
Дата последнего движения по счёту Директор (клиента) Глав, бухгалтер (клиента)
Рис. 9. Пример обозначения сущности на ЕЯ-диаграмме в нотации Баркера
сущности (А и В). Для связи должны быть определены:
1. Имя связи со стороны сущности А и сущности В.
2. Обязательность связи. Если любой экземпляр сущности А обязательно должен быть связан с каким-либо экземпляром сущности В, то прилегающая к прямоугольнику А половина линии - сплошная, в противном случае она - пунктирная.
3. Множественность связи. Для множественной связи (М) линия присоединяется к прямоугольнику сущности в трех точках, для одиночной связи - в одной точке.
На рис. 10 приведен пример обозначения связи.
Из имени связи следует, что "код счета имеет обороты по счету", а "обороты по счету связаны с кодом счета". При включении в базу данных (БД) записи "Код счета" этот счет может и не иметь обороты (связь является необязательной -может быть). При включении в БД записи "Обороты по счету" она должна быть связана с каким-либо счетом (связь является обязательной -должна быть).
При установлении связи, показанной на рис. 10, многие САБЕ-средства автоматически добавляют в сущность "Обороты по счету" ключ сущности "Код счета". Это обеспечивает при включении в БД записи "Обороты по счету" ее связь с
Код счёта Обороты по счёту
#Номер счёта 1 Тип счёта Дополн. признаки Признак блокировки Дата открытия .................................< Имеет Связаны с > #Номер счёта #Дата Дебет Кредит Актив Пассив Признак пересчёта баланса
Рис. 10. Пример обозначения связи на ЕЯ-диаграмме в нотации Баркера
записью "Код счета" по атрибуту "Номер счета", а также правильное соединение соответствующих таблиц при выполнении запросов к базе данных1.
Каждый счет может иметь одну или несколько записей, описывающих обороты по этому счету (связь 1:М). Каждая такая запись соответствует
■Ульман Дж. Основы систем баз данных. - М.: Финансы и статистика, 1983.
Основные
дате, когда со счетом совершались какие-либо действия. Атрибуты "Номер счета" и "Дата" образуют составной ключ сущности "Обороты по счету". При этом каждая запись "Обороты по счету" должна быть связана только с одним счетом (связь М:1). В табл. 3 перечислены основные типы связей в нотации Баркера, которые можно использовать при описании концептуальной схемы подсистем АС БУ.
Таблица 3
ты связей
Связь Описание
1-1 должен Ш. ---- 1-1 может В Запись А может быть связана с одной или несколькими записями В. Каждая запись В должна быть связана только с одной записью А.
т. . • может<Гв] 1-1 может 1-1 Запись А может быть связана с одной или несколькими записями В. Запись В может быть связана только с одной записью А.
г——| может г-1 ГА]-• ^ в 1 1 гтппжен 1 1 Каждая запись А должна быть связана с одной или несколькими записями В. Запись В может быть связана только с одной записью А.
А должен -—-< должен в Каждая запись А должна быть связана с одной или несколькими записями В. Каждая запись В должна быть связана только с одной записью А.
гх>. ■ может<ПГ| 1-'может 1-1 Запись А может быть связана с одной или несколькими записями В. Запись В может быть связана с одной или несколькими записями А.
А может г-1 >— • ■ в должен 1 1 Каждая запись А должна быть связана с одной или несколькими записями В. Запись В может быть связана с одной или несколькими записями А.
А 1 должен >-< должен в Этот тип связи не является допустимым.
А может должен в Каждая запись А должна быть связана только с одной записью В. Запись В может быть связана только с одной записью А.
А может может в Запись А может быть связана только с одной записью В. Запись В может быть связана только с одной записью А.
А должен должен в Каждая запись А должна быть связана только с одной записью В. Каждая запись В должна быть связана только с одной записью А.
Клиент банка
N.
#Цифровой код клиента
Наименование клиента
Признак резидента
Вид отношений
Первое обращение
Телефон
Телекс
Телефакс
Почтовый адрес
Категория клиента
Атрибуты клиента для SWIFT (на англ. яз.)
Юридическое лицо ^
# Цифровой код клиента
Юридический адрес
Код ОКПО
Идентиф. код налогоплательщика
Код СОАТО
Номер и почт, адрес налог, инспекции
Наимен. и почт, адрес Пенс, фонда
Данные фонда медицин, страхования
Директор
Главный бухгалтер
Физическое лицо х
# Цифровой код клиента
Документ, удостоверяющий личность
Подтип
Подтип
Рис. // Пример супертипа и подтипов
Клиент банка
#Цифроаой код клиента Наименование клиента Признак резидента Вид отношений Первое обращение Телефон Телекс Телефакс Почтовый адрес Категория клиента
Атрибуты клиента для SWIFT (на англ. яз.)
Юридическое лицо
# Цифровой код клиента Юридический адрес Код ОКПО
Идентиф. код налогоплательщика Код СОАТО
Номер и почт, адрес налог, инспекции Маимен. и почт, адрес Пенс, фонда Данные фонда медицин, страхования Директор
Главный бухгалтер
Физическое лицо
# Цифровой код клиента Документ, удостоверяющий личность
Имеет
Связан с
Код счета
#Номер счета Тип счета (А,П) Дополнительные признаки Признак блокировки Дата открытия Дата закрытия
Признак отслеживания соответствия А/П Признак учета курсовой разницы Курс
Л/с учета курсовой разницы Наименование клиента Наименование счета Валюта
Ответственный исполнитель Остаток по балансу Тип остатка
Дата последнего движения по счету Цифровой код клиента Директор (клиента) Глав, бухгалтер (клиента)
Обороты по счёту
#Номер счета #Дата Дебет Кредит Актив Пассив
Признак пересчёта баланса
>
Имеет
Связаны с
3. Супертип (БиреЛуре) и подтип (БиЬТуре) сущности (категоризация).
Часто сущности имеют пересекающийся набор атрибутов. В этом случае общую часть атрибутов помещают в сущность-супертип, а отличающиеся части атрибутов помещают в сущности-подтипы (рис. 11).
Здесь сущности "Физическое лицо" и "Юридическое лицо" имеют общие атрибуты "Цифровой код", "Наименование клиента", "Признак резидента" и др. Поэтому эти атрибуты можно объединить в сущность-супертип "Клиент банка". Остальные атрибуты можно описать в сущнос-тях-подтипах. В БД будут храниться три сущности: "Клиент банка", "Физическое лицо", "Юридическое лицо". Основное преимущество использования супертипов и подтипов заключается в том, что СУБД автоматически обеспечивает ссылочную целостность (с помощью триггеров):
после удаления записи-супертипа удаляются все связанные с ней записи-подтипов;
после обновления ключа записи-супертипа обновляются ключи всех связанных с ней запи-сей-подтипов;
после включения записи-подтипа проверяется, есть ли запись-супертип с соответствующим ключом;
после обновления ключа записи-под-типа проверяется, есть ли запись-супертип с тем же ключом.
На рис. 12 представлен пример описания в нотации Баркера фрагмента ЕЯ-диаграммы для подсистемы "Многовалютный операционный день" АС БУ.
Следует отметить, что разработка концептуальной схемы (КС) БД носит творческий характер. Автоматизировать эту работу практически невозможно, так как при этом необходимо учитывать много неформальных параметров. СА8Е-продукты предоставляют только удобные средства описания КС.
При разработке концептуальной схемы базы данных подсистем АС БУ проектировщик руководствуется (сознательно или нет) тремя абстракциями.
1. Агрегация. Проектировщик объединяет некоторые реквизиты предметной области в один агрегат (рис. 13).
2. Обобщение. Проектировщик объединяет однотипные агрегаты в сущность
Рис. /2. Пример описания в нотации Баркера фрагмента ЕЯ-диаграммы для подсистемы Многовалютный операционный день "
Реквизиты
Рис. 13. Пример объединения реквизитов в агрегат
Агрегаты
40702810300000000009 15.03.99 12000000 24000000 0 123000000 1
40702810300000000009 16.03.99 1000000 2000000 0 124000000 1
Сущность (схема агрегата) Обороты по счёту
Номер счёта Дата Дебет Кредит Актив Пассив Признак пересчёта баланса
Рис. 14. Пример объединения агрегатов в сущность
(интенсионал), которая имеет имя и некоторую совокупность атрибутов (рис. 14).
3. Ассоциация (связывание). Проектировщик связывает сущности между собой. При этом связи могут быть разных типов: род-вид, часть-целое и т. д. Например, связь на рис. 2.10 определяет сущность "Обороты по счету" как "часть" счета.
Теперь рассмотрим нотацию IDEF1X, используемую для разработки концептуальной схемы базы данных.
Как уже отмечалось, этот способ описания КС применяется в CASE-средстве ERwin. С помощью данного пакета можно на основе концептуальной схемы разработать логическую схему (ЛС) БД для большого числа СУБД: Oracle, Sybase, Informix и др. Последняя версия ERwin генерирует ЛС БД для 20 СУБД.
Следует отметить, что нотация (изображение) ER-диаграммы IDEF1X отличается от нотации Баркера. В табл. 4-6 перечислены отличия нотаций Баркера и IDEF1X.
Используя инструментальные средства ERwin, можно построить фрагмент концептуальной схемы базы данных подсистемы "Многовалютный операционный день" (см. рис. 12) в нотации IDEF1X (рис. 15).
Клиент банка
Код счёта
Имеет/ Связан с
Юридическое лицо
Цифровой кпд клиента (FK)
Физическое лицо
Юридический адрес Код 0КП0
Идентиф код налогоплательщика Код C0AT0
Номер и почт адрес налог икспеюуяи Наимен и почт адрес Пенс фонда Данные фонда медицин страхования Директор Главный бухгалтер
Цифровой код клиента (FK)
Документ, удостоверяющий личность
Рис. 15. Пример описания в нотации ЮЕР'IX фрагмента ЕЯ-диаграммы для подсистемы "Многовалютный операционный день'
Таблица 4
Отличия в обозначении сущностей
Нотация Баркера Нотация IDEF1X (независимая сущность)
имя имя
#ключ ключ
атрибуты атрибуты
Таблица 5
Отличия в обозначении связей
Нотация Баркера Нотация Erwin Особенности построения связи в пакете Erwin
[£ в А В | Построить идентифицирующую связь. В окне Relationship пакета Erwin должна быть установлена радиокнопка Zero, One or More (выбрать связь, щелкнуть правой клавишей мыши, выбрать пункт Relationship). Сущность В является зависимой
<
А в А в Построить идентифицирующую связь. В окне Relations!» р пакета Erwin должна быть установлена радиокнопка One or More. Сущность В является зависимой
ч .... щ р
И в А в Построить идентифицирующую связь. В окне Relationshi р пакета Erwin должна быть установлена радиокнопка Zero or One. Сущность В является зависимой
Z
и о 00.....•[*] Построить неидентифицирующую связь.В окне Relationship пакета Erwin установить радиокнопку Zero, One or More. Сущность В является независимой
А ---- Но ■ в Построить неидентифицирующую связь.В окне Relationshi р пакета Erwin установить радиокнопку One or More. Сущность В является независимой
И........н Во ' ' Z -B Построить неидентифицирующую связь.Вокне Relationship пакета Erwin установить радиокнопку Zero or One. Сущность В является независимой
Таблица 6
Отличия в обозначениях супертипов и подтипов
Нотация Баркера
Нотация Erwin
Примечания
имя1
#ключ1
атрибуты!
имя2
#ключ2
атрибуты2
имяЗ
#ключЗ
атрибуты
ИМЯ1
ключ!
атрибуты!
Сущности "имя2" и "имяЗ" являются зависимыми
имя 2
fатрибуты 2 ^ ключ 2_
имяЗ
f атрибутыЗ Ч^ ключЗ
^^ атрибуты 2 ^
атрибутыЗ
Концептуальная схема используется в дальнейшем для разработки логической схемы базы данных автоматизированной системы бухгалтерского учета.
Описание спецификаций приложений подсистем бухгалтерского учета
Спецификация процесса (СП) используется для описания функционирования процесса в случае отсутствия необходимости детализировать его с помощью диаграммы потоков данных (ЭРО). Фактически СП представляет собой алгоритм описания задачи, выполняемой процессом. Множество всех СП является полной спецификацией системы. СП содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Известно большое число разнообразных методов, позволяющих задать тело процесса. Соответствующий язык может варьироваться от структурированного естественного языка или псевдокода до визуальных языков программирования (типа РЬО\У-форм и диаграмм Насси-Шнейдермана) и формальных компьютерных языков1.
В силу сложности подсистем АС БУ для описания спецификаций их приложений (прикладных программ) следует использовать структурированный естественный язык (псевдокод). Он является разумной комбинацией строгости языка программирования и читабельности естественного языка и состоит из подмножества слов, организованных в определенные логические структуры, арифметических выражений и диаграмм.
Управляющие структуры языка имеют один вход и один выход. К ним относятся:
а) последовательная конструкция:
ВЫПОЛНИТЬ функция 1 ВЫПОЛНИТЬ функция2 ВЫПОЛНИТЬ функцияЗ
б) конструкция выбора:
ЕСЛИ <условие> ТО
ВЫПОЛНИТЬ функция 1 ИНАЧЕ
ВЫПОЛНИТЬ функция2 КОНЕЦ ЕСЛИ
в) итерация:
ДЛЯ <условие>
ВЫПОЛНИТЬ функция КОНЕЦ ДЛЯ
'Калянов Г.Н. CASE структурный системный анализ (автоматизация и применение). М.: Издательство "ЛОРИ", 19
ИЛИ
ПОКА <условие>
ВЫПОЛНИТЬ функция КОНЕЦ ПОКА
Спецификации процессов можно описать с помощью различных CASE-средств: CASE.Аналитик, BPwin, Designer/2000 и др. Рассмотрим пример.
При разработке диаграммы потоков данных (рис. 8) был включен процесс "Регистрация платежных документов". Ниже приведены спецификации этой задачи в терминах структурированного естественного языка. @СПЕЦ.ПРОЦ. ОД 1.2.1.
@ВХОД - нет @ВЫХОД - таблица платежных документов ВЫПОЛНИТЬ Отобразить окно и ввести дату
ВЫПОЛНИТЬ Отобразить меню и ввести номер корреспондентского счета
ВЫПОЛНИТЬ Отобразить список платежных документов на введенную дату и выбранный корреспондентский счет ПОКА не нажата клавиша Esc ЕСЛИ нажата клавиша Enter ТО ВЫПОЛНИТЬ Отобразить форму для редактирования реквизитов текущего платежного документа ИНАЧЕ ЕСЛИ нажата клавиша Insert ТО ВЫПОЛНИТЬ Отобразить форму для ввода реквизитов нового платежного документа ИНАЧЕ ЕСЛИ нажата клавиша F5 ТО ВЫПОЛНИТЬ Копировать текущий платежный документ на выбранную дату
ИНАЧЕ ЕСЛИ нажата клавиша F3 ТО ВЫПОЛНИТЬ Отобразить плановый остаток по счету ИНАЧЕ ЕСЛИ нажата комбинация клавишей Shift+F3 ТО ВЫПОЛНИТЬ Отобразить плановые платежи по счету ИНАЧЕ ЕСЛИ нажата клавиша F8 ТО ВЫПОЛНИТЬ Отобразить меню "Операции" и выбрать пункт меню ЕСЛИ выбран 1-й пункт ТО
ВЫПОЛНИТЬ Провести текущий документ ИНАЧЕ ЕСЛИ выбран 2-й пункт ТО
ВЫПОЛНИТЬ Удалить проводки по текущему документу
ИНАЧЕ ЕСЛИ выбран 3-й пункт ТО ВЫПОЛНИТЬ Провести все отобранные документы (см. F2) ИНАЧЕ ЕСЛИ выбран 4-й пункт ТО ВЫПОЛНИТЬ Удалить проводки по всем отобранным документам
КОНЕЦ ЕСЛИ ИНАЧЕ ЕСЛИ нажата комбинация клавишей Shift+F5 ТО
ВЫПОЛНИТЬ Перенести документ на дату ИНАЧЕ ЕСЛИ нажата клавиша Del ТО
ВЫПОЛНИТЬ Удалить платежный документ, подтвердить удаление клавишей PgDn ИНАЧЕ ЕСЛИ нажата комбинация клавишей Alt+M ТО
ВЫПОЛНИТЬ Сформировать рейс (макет) в РКЦ
ИНАЧЕ ЕСЛИ нажата клавиша F2 ТО
ВЫПОЛНИТЬ Отобрать платежные документы по признакам (пачка, номер, номер рейса, дебет/ кредит, сумма, все неисполненные, внутренний л/с, корреспондентский счет, внешний л/с, наименование получателя платежа) ИНАЧЕ ЕСЛИ нажата клавиша F9 ТО
ВЫПОЛНИТЬ Обновить экран (читать данные с сервера) ИНАЧЕ ЕСЛИ нажата комбинация клавишей Shift+F9 ТО
ВЫПОЛНИТЬ Настроить параметры бланков
ИНАЧЕ ЕСЛИ нажата комбинация клавишей Ctrl+F9 ТО
ВЫПОЛНИТЬ Настроить параметры печати
ИНАЧЕ ЕСЛИ нажата комбинация клавишей Alt+F9 ТО
ВЫПОЛНИТЬ Настроить реквизиты банка ИНАЧЕ ЕСЛИ нажата клавиша F10 ТО
ВЫПОЛНИТЬ Поиск платежного документа в таблице (по сумме, по внутреннему счету, по внешнему счету, по наименованию получателя платежа) ИНАЧЕ ЕСЛИ нажата комбинация клавишей Ctrl+F10 ТО
ВЫПОЛНИТЬ Поиск следующего документа в таблице
КОНЕЦ ЕСЛИ КОНЕЦ ПОКА
@КОНЕЦ СПЕЦ.ПРОЦ ОД 1.2.1
При разработке прикладных программ "горячие" клавиши часто заменяют экранными кнопками. Спецификации процессов используются в дальнейшем при разработке текстов прикладных программ подсистем бухгалтерского учета и документации на систему. К сожалению, в настоящее время отсутствуют развитые инструментальные средства, позволяющие автоматически генерировать код достаточно сложной программы по ее спецификациям.
Разработка логической схемы базы данны банковских информационных подсистем
Концептуальная схема (КС) базы данных не зависит от системы управления базами данных (СУБД), используемой при разработке и эксплуатации автоматизированной системы бухгалтерского учета. Логическая схема (ЛС) является отражением концептуальной схемы в СУБД-ори-ентированную среду, т. е. зависит от выбранной СУБД. При разработке ЛС решаются следующие задачи:
1) выполняется оптимизация логической схемы базы данных подсистем АС БУ,
2) уточняются параметры атрибутов таблиц базы данных (БД),
3) определяются атрибуты, для которых СУБД будет строить дополнительные индексы,
4) генерируется DDL-сценарий (Data Definition Language) с описанием логической схемы БД. С помощью современных CASE-средств могут быть решены 2, 3 и 4 задачи. Первая задача решается, как правило, вручную.
1. Оптимизация логической схемы. Вопросы оптимизации ЛС изучает теория нормализации отношений1. Рассмотрим таблицу "Код счета" на рис. 15. Эта таблица имеет следующие недостатки:
• Избыточность. Значения атрибутов "Цифровой код клиента", "Наименование клиента", "Директор /клиент/" и "Главный бухгалтер /клиент/" повторяются в каждом счете, связанном с данным клиентом.
• Потенциальная противоречивость. При изменении перечисленных выше атрибутов в таблицах "Клиент банка" и "Юридическое лицо" (рис. 15) важно не забыть обновить эти атрибуты и во всех записях таблицы "Код счета", куда они входят.
'Ульман Дж. Основы систем баз данных. - М.: Финансы и статистика, 1983.
Дейт К. Введение в системы баз данных. - К.: Диалектика, 1998.
Доказано, что таблица не обладает указанными недостатками, если она находится в третьей нормальной форме (ЗНФ). Существует простой способ построения таблицы в ЗНФ: таблица будет находиться в третьей нормальной форме, если каждый ее атрибут зависит только от ключа этой таблицы.
В рассматриваемом примере таблица "Код счета" не находится в ЗНФ, так как ее атрибуты "Наименование клиента", "Директор /клиент/" и "Главный бухгалтер /клиент/" зависят не только от ключа "Номер счета", но и от неключевого атрибута "Цифровой код клиента" этой таблицы. Таблица "Код счета" будет находиться в ЗНФ (а поэтому не будет иметь указанных выше недостатков), если атрибуты "Наименование клиента", "Директор /клиент/" и "Главный бухгалтер /клиент/" вообще исключить из таблицы.
Но преобразование таблицы к ЗНФ приводит, как правило, к увеличению времени выполнения запросов к базе данных. Действительно, после нормализации таблицы "Код счета" для включения в справку о счете наименования клиента и фамилий директора и главного бухгалтера потребуется в соответствующей программе выполнить дополнительные обращения к таблицам "Клиент банка" и "Юридическое лицо". Поэтому, если основным показателем АС БУ является время поиска в базе данных, то таблицы не нормализуют, а недостатки схемы базы данных, которые при этом появляется, пытаются устранить программным путем.
2. Уточнение параметров атрибутов таблиц. На этом этапе с помощью CASE-средств атрибутам присваиваются уникальные (в рамках одной таблицы) идентификаторы, состоящие из латинских букв и цифр, определяется возможность хранения пустых значений (NULL), а также определяются типы полей:
• целое число (INTEGER, SMALLINT, SERIAL);
• действительное число (DEZIMAL(p), DEZIMAL(p,n), DOUBLE PRECISION, FLOAT);
• битовые данные (BYTE);
• дата (DATE, DATETIME, INTERVAL);
• символьная строка (CHARACTER(n), CHAR(n), VARCHAR(n), TEXT);
• денежная величина (MONEY(p,n)).
В скобках приводятся описания типов данных, принятых в стандартах SQL/89 и SQL/921, которые поддерживаются многими СУБД (Oracle,
Informix, Sybase и др.) и CASE-средствами. На рис. 16 показана схема (рис. 15) с уточненными параметрами атрибутов.
3. Определение атрибутов, для которых СУБД будет строить дополнительные индексы.
По умолчанию CASE-средства определяют индекс для атрибутов таблицы, входящих в первичный ключ (РК — Primary Key). Данный ключ обладает тем свойством, что в таблице базы данных не могут храниться две и более записей, совпадающих по первичному ключу. На рис. 16 эти атрибуты располагаются вверху схемы таблицы, отделены от остальных полей горизонтальной линией и помечены слева значком в виде ключа. Индексирование атрибутов позволяет существенно уменьшить время поиска записей в таблице, если в условии поиска указаны эти атрибуты2. Но при этом следует помнить, что индексирование увеличивает время выполнения операторов обновления, так как СУБД будет изменять не только записи таблицы, но и индексы. Если предполагается, что какой-либо атрибут (или группа атрибутов) будет часто использоваться в условии поиска, то для такого атрибута (или группы атрибутов) целесообразно определить индекс. С этой целью для атрибута следует описать с помощью опций CASE-средства инвертированный список (IE — Inversion Entry). В отличие от первичного ключа в таблице могут храниться несколько записей, совпадающих по атрибуту из инвертированного списка.
Для схемы на рис. 16 были определены три инвертированных списка:
• для атрибута Client_Name ("Наименование клиента" на рис. 15) таблицы Client ("Клиент банка");
• для атрибута Client_Code ("Цифровой код клиента") таблицы Account ("Код счета");
• для атрибута Client_Name ("Наименование клиента") таблицы Account ("Код счета"). Ведение этих списков позволит в будущем
осуществлять быстрый поиск клиента банка не только по его цифровому коду, но и по имени, а также выполнять поиск банковских счетов не только по их номерам, но и по цифровому коду клиента и его имени.
'Кузнецов С.Д. Стандарты языка реляционных баз данных SQL: краткий обзор // Системы управления базами данных. -М„ 1996. - № 2. - С. 6-36.
2Ульман Дж. Основы систем баз данных. - М.: Финансы и статистика, 1983.
Дейт К. Введение в системы баз данных. - К.: Диалектика, 1998.
На рис. 16 используется следующее обозначение инвертированного списка: IEn.k, где п -это номер инвертированного списка в таблице, к - число атрибутов, вошедших в список.
Следует отметить, что с помощью аббревиатуры FK (Foreign Key) обозначаются внешние ключи таблицы, то есть те атрибуты, значения которых должны совпадать со значениями соответствующих атрибутов родительской таблицы. Внешние ключи используются для поддержки ссылочной целостности базы данных АС БУ1.
4. Генерация DDL-сценария с описанием логической схемы.
'Дейт К. Введение в системы баз данных. - К.: Диалектика, 1998.
Современные CASE-средства позволяют генерировать DDL-сценарий на языке описания данных конкретной СУБД. Продукт Designer/2000 создает описание JIC только для СУБД Oracle. Пакет ERwin ERX 3.5 позволяет генерировать тексты описаний для 20 различных СУБД. Ниже приведены результаты автоматической генерации логической схемы пакетом ERwin ERX 3.5 для СУБД Огас1е7 по описанию, представленному на рис. 16. Здесь приведены только операторы создания таблиц и индексов.
CREATE TABLE Client
(Client Code VARCHAR(20) NOT NULL, Client_Name VARCHAR(40) NULL, Resident_Indication CHAR(l) NULL,
Client
Account
Client_Code: VARCHARÇ20) NOT NULL
Client_Name: VARCHAR(40) NULL (IE1.1) Residentjndication: CHAR(1) NULL Relationship_Form: VARCHAR(20) NULL First_Date: DATE NULL Phone: VARCHAR(20) NULL Tele«: VARCHARpO) NULL Fas: VARCHAR(20) NULL Post_Address: VARCHAR(40) NULL Client_Category: CHAR(1) NULL SWJIFTAttibute: VARCHARP) NULL
1
Juridical Person
Client_Code: VARCHARÇ20) NOT NULL (FK)
Juridical_Address: VARCHAR(40) NULL Code_OKPO: VARCHAR(20) NULL Tanpayer_Code: VARCHAR(20) NULL Code_C0AT0: VARCHAR(20) NULL TaKjnspection: VARCHARP) NULL Pension_Fund: VARCHARP) NULL MedicalJnsurance: VARCHARP) NULL Director: VARCHAR(30) NULL Accountant_General: VARCHAR(30) NULL
Q. Account_Number: DECIMAL(20.0) NOT NULL
Client_Code: VARCHAR(20) NULL (FK) (IE1.1) Account_Type: CHAR(1) NULL AdditionalJndication: VARCHAR(20) NULL Blockjndication: CHAR(1) NULL Date_Open: DATE NULL Date_Closed: DATE NULL Follouijndication: CHAR(1) NULL Differencejndication: CHAR(1) NULL Rate_Enchange: DECIMAL(15) NULL Difference_Account: DECIMAL(20,0) NULL Client_Name: VARCHAR(40) NULL (IE2.1) Account_Name: VARCHAR(20) NULL Currency: VARCHAR(30) NULL Executor: VARCHAR(30) NULL Balance: DECIMAL(15) NULL Balance_Type: CHAR(1) NULL Last_Date: DATE NULL Director: VARCHAR(30) NULL Accountant_General: VARCHAR(30) NULL
Turnover
Account_Number: DECIMAL(20,0) NOT NULL (FK) Date: DATE NOT NULL
Debit: DECIMALS5) NULL Credit: DECIMAL(15) NULL Assets: DECIMAL(15) NULL Liabilities: DECIMAL(15) NULL Recount_lndication: CHAR(1) NULL
Physical_Person
Client_Code: VARCHAR(20) NOT NULL (FK)1
Document: VARCHAR(60) NULL
Рис. 16. Пример описания фрагмента ЕЯ-диаграммы для подсистемы "Многовалютный операционный день " с уточненными параметрами атрибутов
Relationship_Form VARCHAR(20) NULL, First_Date DATE NULL, Phone VARCHAR(20) NULL, Telex VARCHAR(20) NULL, Fax VARCHAR(20) NULL, Post_Address VARCHAR(40) NULL, Client_Category CHAR(l) NULL, SWIFT Attibute VARCHAR(60) NULL, PRIMARY KEY (Client_Code));
CREATE UNIQUE INDEX XPKClient ON Client
(Client_Code );
CREATE INDEX XIE1 Client ON Client
(Client_Name);
CREATE TABLE Account
(Account_Number DECIMAL(20,0) NOT NULL,
Client_Code VARCHAR(20) NULL, Account_Type CHAR(l) NULL, Additional_Indication VARCHAR(20) NULL, Blockjndication CHAR(l) NULL, Date Open DATE NULL, Date Closed DATE NULL, Followjndication CHAR(l) NULL, Difference_Indication CHAR(l) NULL, Rate_Exchange DECIMAL(15) NULL, Difference_Account DECIMAL(20,0) NULL, Client_Name VARCHAR(40) NULL, Account_Name VARCHAR(20) NULL, Currency VARCHAR(30) NULL, Executor VARCHAR(30) NULL, Balance DECIMAL(15) NULL, Balance_Type CHAR(l) NULL, Last_Date DATE NULL, Director VARCHAR(30) NULL, Accountant_General VARCHAR(30) NULL, PRIMARY KEY (Account_Number), FOREIGN KEY (Client_Code) REFERENCES Client);
CREATE UNIQUE INDEX XPKAccount ON
Account (Account_Number);
CREATE INDEX XIE1 Account ON Account
(Client_Code);
CREATE INDEX XIE2Account ON Account
(Client_Name);
CREATE TABLE Turnover
(Account_Number DECIMAL(20,0) NOT NULL,
Date DATE NOT NULL, Debit DECIMAL(15) NULL, Credit DECIMAL(15) NULL, Assets DECIMAL(15) NULL, Liabilities DECIMAL(15) NULL, Recount_Indication CHAR(l) NULL,
PRIMARY KEY (Account_Number, Date), FOREIGN KEY (Account_Number) REFERENCES Account);
CREATE UNIQUE INDEX XPKTurnover ON Turnover (Account_Number, Date);
CREATE TABLE Physical_Person
(Client_Code VARCHAR(20) NOT NULL, Document VARCHAR(60) NULL, PRIMARY KEY (Client_Code), FOREIGN KEY (Client_Code) REFERENCES Client);
CREATE UNIQUE INDEX XPKPhysical_Person ON Physical_Person ( Client_Code );
CREATE TABLE Juridical_Person
(Client_Code VARCHAR(20) NOT NULL, Juridical_Address VARCHAR(40) NULL, Code OKPO VARCHAR(20) NULL, Taxpayer_Code VARCHAR(20) NULL, Code COATO VARCHAR(20) NULL, Tax_Inspection VARCHAR(60) NULL, Pension_Fund VARCHAR(60) NULL, Medicaljnsurance VARCHAR(60) NULL, Director VARCHAR(30) NULL, Accountant_General VARCHAR(30) NULL, PRIMARY KEY (Client_Code), FOREIGN KEY (Client_Code) REFERENCES Client);
CREATE UNIQUE INDEX XPKJuridical_Person ON Juridical_Person ( Client_Code ).
CASE-средства позволяют генерировать триггеры и хранимые процедуры, которые затем будут вызываться ядром СУБД. Например, важно, чтобы после закрытия счета и его дальнейшего удаления из базы данных были бы удалены и все обороты по этому счету. Ниже показано, как эту задачу можно решить с помощью пакета ERwin ERX 3.5.
Если при настройке связи между таблицами Account и Turnover (рис. 16) параметру "Parent Delete" присвоить значение CASCADE, то при генерации схемы к предыдущему тесту будет добавлено следующее описание триггера:
create trigger tD_Account after DELETE on Account for each row
- ERwin Builtin Thu Feb 25 17:19:52 1999
— DELETE trigger on Account declare numrows INTEGER; begin
/* ERwin Builtin Thu Feb 25 17:19:52 1999 */ /* Account имеет Turnover ON PARENT DELETE CASCADE */ delete from Turnover where
/* % JoinFKPK(Turnover,: % Old," = "," and") */ Turnover.Account_Number = :old.Account_Number; - ERwin Builtin Thu Feb 25 17:19:52 1999 end;/
Ядро СУБД будет автоматически обращаться к этому триггеру после удаления записи Account. Триггер, в свою очередь, будет удалять записи Turnover, связанные с удаленной записью Account. Следует также отметить, что пакет ERwin ERX 3.5 генерирует и другие триггеры, поддерживающие особенности связей между таблицами (табл. 5 и 6).
CASE-средства позволяют сохранить сгенерированный DDL-сценарий с описанием логической схемы в файле (например, schema.sql). Далее, чтобы создать схему базы данных и оттранслировать триггеры и хранимые процедуры, например, в среде СУБД Oracle, достаточно запустить программу SQL*Plus и выполнить команду @schema.sql.
Разработка прикладных программ подсистем бухгалтерского учета
Многие CASE-средства (Designer/2000, ERwin и др.) позволяют генерировать простые экранные формы по описанию таблиц базы данных. В качестве примера рассмотрим процесс создания формы "Регистрация платежных документов" с использованием средства Designer/20001.
1. При построении диаграммы потоков данных (этап моделирования системы) определяются сущности базы, с которыми связан процесс "Регистрация платежных документов". Из рис. 17 видно, что в процессе регистрации платежных документов используется сущность "Платежные документы", которая связана с сущностью "Код счета" (рис. 15). Связи между сущностями базы данных обычно не показывают на диаграмме потоков данных, на рис. 17 эта связь приведена для наглядности.
2. После разработки логической схемы базы данных (этап проектирования) выполняется редактирование интерфейсных свойств столбцов таблицы "Платежные документы" (рис. 18). Здесь указывается, какие столбцы (атрибуты) выводить
Регистрация платёжных документов
Код счёта
/ \
Платёжные документы
1 Ричарде М. Oracle 7.3. Энциклопедия пользователя. - К.: Издательство "ДиаСофт", 1997.
Рис. J 7. Фрагмент диаграммы потоков данных
на экран (Dspl), значения каких атрибутов разрешается добавлять (Ins) и обновлять (Upd) в базе, по каким столбцам можно осуществлять поиск (Sel), значения каких столбцов можно не указывать при вводе (Opt), для каких атрибутов допускается поиск по контексту (Ctx) и выбор значения из списка при вводе (Lov).
Конечно, в колонке Column на рис 18 отображаются идентификаторы атрибутов, состоящие из латинских букв и цифр. Здесь названия столбцов приведены на русском языке для наглядности.
3. Перед генерацией описывается, в каком виде столбцы будут выведены на экран, число строк таблицы, отображаемых на экране, и др. Имя столбца на экране может отличаться от имени соответствующего атрибута схемы базы данных. Для формы можно подготовить также меню, которое будет отображаться во второй строке окна. На рис 19 приведен пример сгенерированной формы. Согласно выполненным настройкам (рис. 18) с помощью этой формы можно осуществлять только ввод и поиск платежных документов.
Следует подчеркнуть, что описанный выше подход к разработке приложений имеет ограниченное применение для автоматизированных систем бухгалтерского учета. Это связано с большой сложностью алгоритмов программ АС БУ. Действительно с помощью сгенерированной формы (рис. 19) нельзя
• редактировать реквизиты платежного документа в отдельном окне;
• копировать и переносить документ на дату;
• отображать плановые остатки и платежи по счету;
• проводить и удалять проводки по документам;
• формировать рейсы в РКЦ;
• настраивать параметры печати и др.
Со1итл Dspl Ins Upd Sel Opt Ctx Lov
Внутренний номер документа 1
Номер платежного документа X X X X
Дата платежного документа X X X X
Пачка X X X X
ИНН клиента банка X X X X 1 Ш§ШЛЩш x
Номер счета клиента банка X X X X X
Наименование клиента банка X \ X X X X
Сумма платежа X X X X
Признак платежа (Д, К) X X X ЩхшВЩ : X
Расходы X X X X li'/'x ¡Щи1® '
БИК банка-корреспондента 1 х X X X X
Корреспондентский счет банка-корреспондента X X X X 1" ' ЗЙЙРpäi:4| x
Наименование банка-корреспондента 1 х X X X X X
Город, где находится банк-корреспондент X X X X X
ИНН клиента-корреспондента 1 х X X X ' X
Номер счета клиента-корреспондента X X X X
Наименование клиента-корреспондента X X X X X X
Тип отправления X X X X S X
Дата получения товара X X X X X
Назначение платежа X X X X X X
Вид операции (01-п/п. 02-т/п и т.д.; 1 х X X X E X
Срок платежа X X X X
Очередность X X X X
Способ обработки (группа) X X X X X
Корреспондентский счет банка 1 х X X X X
Номер рейса X X X X
Вид платежа 1 х X X X
Состояние документа X X X
Признак получения документа 1 х X X X X X
Состояние отправки X X X
Время ввода платежного документа 1 х X X
Время изменения платежного документа X X X t;
Рис. 18. Редактирование интерфейсных свойств столбцов таблицы "Платежные документы "
В настоящее время для реализации сложных программных комплексов используются средства быстрой разработки приложений RAD (Rapid Application Development): Developer/2000, Centura
Рис. 19. Пример сгенерированной формы
Team Developer, SQLWindows, PowerBuilder, Delphi, C++Builder и др. Используемые здесь языки относятся к классу 4GL (Fourth Generation Languages). Перечисленные продукты обладают свойствами CASE-средств, так как позволяют разработчикам постепенно увеличивать степень детализации программ, а также не вникать во многие детали среды разработки и функционирования программного обеспечения. На рис. 2.20 представлена схема разработки приложений АС БУ на основе RAD-технологии.
Здесь вся форма состоит из блоков (block), а каждый блок - из пунктов (items). Блок может соответствовать заголовку окна (стрелка 1 на рис. 20), таб-
Регистрация платёжных документов
File Edit Option
—Платёжные документы -
Вид № пл. опег док.
Дата
ИНН Наимен. Сумма Призн. Расходы БИК
клиента клиента, клиента, платежа платежа
банка-к.
си cm cm □□ cm ш cm cm □ cm cm
сп пз m □ □ □ □ m □ □ □
□ □ □□□□□□□ □ □
□ □ □□□□□□□ □ □
en en □□□□□□□ m □
Count 'О
лице базы данных (стрелка 2), набору кнопок (стрелка 3), по которым выполняются те или иные действия, описанные в спецификациях задачи, и т. д. Пункты блока могут быть связаны с полями ввода исходных данных (блок "Заголовок"), столбцами таблицы (блок "Платежные документы"), кнопками (блок "Кнопки для обработки платежных документов") и др.
Для каждого пункта, описывающего кнопку на экране, определяют триггеры (triggers), где можно описать процедуру, которая будет выполняться после щелчка мышкой на кнопке (WHEN-BUTTON-PRESSED). Сначала эта процедура может иметь пустое тело. Этот вариант следует использовать на начальном этапе разработки приложения, когда вид экранной формы необходимо согласовать с сотрудником банка, который будет работать с этой прикладной программой. Здесь не требуется высокой детализации обрабатывающих процедур. После уточнения вида формы можно детализировать тексты процедур, выполняемых при нажатии кнопок. В частности, программа, обрабатывающая нажатие кнопки "Редактирование" (рис. 20), может содержать вызов окна с реквизитами текущего платежного документа и кнопками для его обработки (стрелка 4).
Object Navigator
Q-Block
Заголовок Items
Дата
Номер корр. счёта Наимен. корр. счёта
ГП-И Платёжные документы П- Items
[+] Вид опер. № пл. док.
pj—И Кнопки для обработки платёжных документов П-Items
I ГП—Н Редактирование Q-Trlggers
1_Л WHEN-BUTTO^-PRESSED / ф-р Ввод (Д, К)
[+1—Ц Редактирование J 4
П~рД Кнопки редактирования
Пустое тело или ото-Сразить окно с блоками "Редактирование" и "Кнопки редактирования"
Регистрация платёжных документов
Платёжные документы за Корр. счёт I ■ Наимен. [
Редактирование Ввод (Д. К) Копирование
Вид № пл. Пачка Л/с ИНН Наимен. Сумма Приза
опер. док. клиента клиента. клиента. платежа платежа
ПЗ из □ □ m i—i ГЗ 1—1
ПЛ CJ СП гз □
□ си i_i i i Г 1 1 1
ПЗ CZU □ Г"1 Г. 1 Г~1
— CZ] си i_i сш CJ 1_1
13
Count *0
Рис. 20. Схема разработки приложений АС БУна основе RAD-технологии
Выбор архитектуры информационной системы коммерческого банка
При разработке структуры коммерческого банка, включающего несколько филиалов и имеющего связи с различными клиринговыми центрами, возникает проблема оценки архитектурных решений банковской сети. Под архитектурой системы здесь понимается описание комплекса технических средств (КТС) (станций, локальных вычислительных сетей, телекоммуникационных каналов связи и др.), сетевой операционной системы (ОС), системы управления базой данных (СУБД). В многофилиальной автоматизированной банковской системе приложения и таблицы базы данных (БД) распределяются по различным узлам (серверам), то есть система бухгалтерского учета становится распределенной.
При создании распределенных АС БУ большое значение имеет анализ временных показателей. Особенность этих характеристик определяется тем, что даже опытному проектировщику АС БУ бывает очень трудно спрогнозировать их значения, так как временные показатели зависят, в основном, от решений, принимаемых на ранних этапах проектирования автоматизированной системы бухгалтерского учета, то есть от концептуальной схемы базы данных, спецификаций разрабатываемых программ, архитектуры будущей системы, от наполнения базы данных. Поэтому важно дать проектировщику АС БУ, выполняющему разработку в среде СУБД, подход, позволяющий прогнозировать временные показатели распределенных АС БУ и выявлять потенциальные "узкие места" таких систем на основе описаний проектных решений. Это особенно важно, если учесть,
Запросы к ЕД
Концептуальный проект
Таблицы базы данных АС БУ
Транзакции
Серверы базы данных
Технический проект (архитектура АС
БУ)
Локальные и телекоммуникационные сети
Рабочие станции (сотрудники банка)
Рис. 21. Схема организации связей между компонентами распределенной АС БУ
что основной язык (SQL) доступа к данным относится к классу непроцедурных языков. Неосторожное использование спецификаций этого языка может привести к существенному увеличению времени реакции системы бухгалтерского учета.
В настоящее время для оценки показателей производительности информационных систем используются системы массового обслуживания (СМО), которые не учитывают особенностей выполнения приложений; для них непросто получить исходные данные; трудно проверить выполнение предпосылок их использования. Тем более в этих моделях не учитывается механизм декомпозиции запросов к распределенной базе данных на подзапросы и особенности их обработки в узлах АС БУ; не учитываются объемы данных промежуточных и результирующих таблиц базы данных, передаваемых по каналам связи.
Имеется способ1 оценки показателей производительности информационных систем, позволяющий решить указанные проблемы путем использования принципиально нового класса моделей анализа, учитывающих механизмы оптимизации запросов к распределенной базе данных. Предлагаемый комплекс инструментальных средств проектирования (КИСП) предназначен для проведения вычислительных экспериментов с целью анализа временных показателей распределенных систем обработки данных (РСОД), ос-
' Информационная система поддержки принятия проектных решений разработчиком распределенных систем обработки данных: Руководство пользователя / МГТУ им. Н. Э. Баумана. - М., 1999.
нову которых составляют распределенные базы данных и приложения (в частности, РСОД может состоять из одного сервера СУБД). Этот комплекс может быть использован для анализа и выбора архитектуры распределенной автоматизированной системы бухгалтерского учета.
КИСП включает взаимосвязанные подсистемы, обеспечивающие описание:
1) концептуальной схемы базы данных АС БУ и наполнения базы данных (прогнозируемое число записей в таблицах банковской системы и мощности атрибутов),
2) запросов (SQL-oпepaтopoв) и транзакций АС БУ, которые могут обращаться к другим транзакциям распределенной системы; транзакция -это прикладная программа, выполняющая обращение к базе данных и формирующая ответ сотруднику банка, вызвавшему эту программу,
архитектуры АС БУ (топологии и характеристик узлов и сетей из реестров результатов тестов ТРС и параметров сетей), распределения таблиц (с учетом тиражирования) и транзакций по узлам АС БУ, интенсивностей обращений сотрудников банка к транзакциям.
На рис. 21 представлена схема организации связей между компонентами проектируемой распределенной АС БУ, которая может быть использована при описании анализируемой системы бухгалтерского учета в КИСП.
Здесь сплошными стрелками показаны связи типа "обращение к", а пунктирные линии изображают связи типа "входят, размещаются в". Так, запросы к БД (операторы SQL) входят в состав транзакций (2), при выполнении которых операторы SQL обращаются к таблицам базы данных АС БУ(1). Описания таблиц базы данных, запросов и транзакций образуют концептуальный проект (КП) АС БУ. При проектировании стремятся, чтобы концептуальный проект не зависел от реализации, то есть от архитектуры будущей АС БУ (комплекса технических средств, общесистемных пакетов и др.). После выбора КТС, ОС, СУБД выполняется распределение таблиц базы данных и транзакций по узлам распределенной системы (стрелки 3, 4, 5, 6). Таблицы АС БУ хранятся на серверах базы данных, а транзакции могут размещаться на рабочих станциях, серверах приложений, серверах базы данных (хранимые проце-
3)
4)
5)
дуры). Стрелки 7, 8, 9 обозначают обращения транзакций к таблицам базы данных. Следует отметить, что серверы приложений могут отсутствовать или располагаться в тех же узлах, что и серверы базы данных.
В рамках КИСП созданы реестры с описанием параметров различных типов сетей, а также с результатами тестов, проведенных по спецификациям международной организации Transactional Processing Performance Council (TPC) для разных серверов и суперсерверов (более 20 фирм: Sun, Compaq, HP, Digital, IBM и т.д.), СУБД (Oracle, Informix, Sybase, MS SQL Server и т.д.), сетевых ОС (различных версий UNIX, Windows NT 4.0 и т.д.) и серверов приложений (Tuxedo, TopEnd и т.д.).
На основе описания параметров АС БУ комплекс анализирует характеристики производительности и выявляет "узкие места" распределенной системы бухгалтерского учета. КИСП рассчитывает для каждого варианта архитектуры АС БУ следующие показатели:
1) загрузки узлов (серверов и клиентов) и сетей и их составляющие, связанные с выполнением запросов и транзакций,
2) время выполнения транзакций и его составляющие, связанные с узлами, сетями, запросами и вызываемыми транзакциями,
3) время доступа из узлов к транзакциям, учитывающее время передачи входных и выходных данных от рабочих станций,
4) число блоков, обрабатываемых при выполнении запросов SQL.
Важно подчеркнуть, что проектирование распределенных автоматизированных систем бухгалтерского учета, как правило, выполняется в условиях большой неопределенности исходных данных. Поэтому описание параметров АС БУ и расчеты характеристик могут выполняться в КИСП с использованием нечетких чисел.
Ниже приведено описание основных шагов, которые необходимо выполнить проектировщику, чтобы с помощью КИСП оценить характеристики производительности архитектуры АС БУ.
1. Описание схемы базы данных АС БУ.
На этом шаге вызывается экранная форма, с помощью которой можно
• выполнить описание основных реквизитов (терминов), используемых в банке,
• сформировать таблицы из реквизитов,
• определить свойства таблиц и их атрибутов.
2. Описание запросов и транзакций. На данном шаге требуется
• перечислить запросы, которые будут использоваться в АС БУ,
• выполнить описание запросов,
• перечислить транзакции и определить их состав (наборы запросов),
• определить свойства запросов и транзакций.
3. Описание архитектуры АС БУ. Здесь необходимо
• перечислить узлы и сети будущей системы и определить топологию АС БУ,
• для каждого узла и сети определить (назначить) характеристики из заранее подготовленных реестров,
• назначить свойства узлов и сетей.
4. Распределение транзакций и таблиц.
На этом шаге вызывается экранная форма, с помощью которой можно
• выполнить распределение ранее описанных таблиц базы данных и транзакций запросов по узлам АС БУ,
• определить свойства этого распределения.
5. Обращения к транзакциям из узлов. На данном шаге требуется
• определить, какие узлы (сотрудники банка) обращаются к каким транзакциям,
• назначить свойства этих вызовов (интенсивности и др.).
6. Обращения к транзакциям из транзакций. Здесь можно
• определить, какие транзакции вызывают какие транзакции,
• назначить свойства этих вызовов (число обращений и др.).
7. Расчет характеристик архитектуры АС БУ. На этом шаге вызывается экранная форма, с
помощью которой можно
• выполнить расчеты временных характеристик функционирования АС БУ для различных вариантов архитектурных решений.
8. Анализ загрузок узлов АС БУ и их составляющих.
На этом шаге можно
• посмотреть загрузки узлов для различных вариантов архитектуры,
• посмотреть "разложение" загрузок узлов по запросам,
• посмотреть "разложение" загрузок узлов по транзакциям.
9. Анализ загрузок сетей АС БУ и их составляющих.
Здесь можно
• посмотреть загрузки сетей (каналов) для различных вариантов архитектурных решений,
• посмотреть "разложение" загрузок сетей по запросам,
• посмотреть "разложение" загрузок сетей по транзакциям.
10. Анализ времени выполнения транзакций АС БУ (по узлам и сетям).
На этом шаге вызывается экранная форма, с помощью которой можно
• посмотреть время выполнения транзакций для различных вариантов архитектуры,
• посмотреть "разложение" этого времени по узлам, которые были задействованы при выполнении транзакции,
• посмотреть "разложение" времени по сетям, которые были задействованы при выполнении транзакции.
11. Анализ времени выполнения транзакций АС БУ (по запросам и транзакциям).
На этом шаге можно
• посмотреть время выполнения транзакций для различных вариантов архитектуры,
• посмотреть "разложение" этого времени по запросам, которые обрабатывались при выполнении транзакции (включая запросы транзакций, к которым обращалась данная транзакция),
• посмотреть "разложение" времени по транзакциям, к которым обращалась данная транзакция.
12. Анализ времени доступа из узла к транзакции.
Здесь можно
• посмотреть время доступа узла к транзакции, то есть время выполнения вызываемой транзакции (с учетом ее обращений к другим транзакциям) плюс время передачи входных и выходных данных между данным узлом и узлом, где выполнялась вызываемая транзакция.
13. Анализ числа блоков на один запрос транзакции АС БУ.
На этом шаге вызывается экранная форма, с помощью которой можно
• посмотреть число блоков, обработанных при выполнении запросов автоматизированной системы бухгалтерского учета. Предлагаемая методика проектирования автоматизированной системы бухгалтерского учета (АС БУ), может быть реализована с помощью различных СА8Е-средств.
