Корпоративные базы данных - статьи
Переносимость приложений, разработанных с помощью JAM
JAM, как среда разработки, доступен на нескольких десятках программно-аппаратных платформ,
включая Windows, Windows 95, Windows NT, OS/2, Mac, VMS и практически все распространенные
UNIX платформы. На этих же платформах, соответственно, доступны и приложения, построенные
с использованием JAM. Переносимость JAM-приложений между платформами практически
абсолютная.
Реализация переносимости между типами интерфейсов - алфавитно-цифpовой и графический
интерфейсы. JAM-приложения могут исполняться как в алфавитно-цифровом, так и в GUI-режиме
практически на всех поддерживаемых платформах, где реализованы оба режима. Из GUI
поддерживаются MS-Windows, Presentation Manager, X-Windows, Macintosh. Переносимость между
типами интерфейса также практически абсолютная за исключением недоступности векторных
шрифтов и графических образов в алфавитно-цифровых режимах.
Переносимость локализованных приложений между различными программно-аппаратными
платформами с различными кодировками национального алфавита (например, перенос
русскоязычных приложений между Windows и UNIX) может иметь минимально возможную
трудоемкость. При максимально активном использовании Репозитория JAM достаточно изменить
написание только базовых объектов. В ряде случаев JAM дает возможность избежать и этой
работы. Это достигается соответствующим переопределением устройств ввода/вывода (клавиатура
и терминал).
Платформы
SQLBase разрабатывалась специально для применения на персональных компьютерах с
процессорами фирмы Intel. В настоящее время эта СУБД выпускается для следующих сетевых
операционных систем: Novell NetWare 3.x и 4.x, Windows 95 и NT, OS/2 2.x. Существует также
локальная версия для платформы Windows 3.x. При работе в Windows 95, Windows NT и OS/2
SQLBase поддерживает как традиционную технологию клиент-сервер, так и новую технологию
клиент-клиент, позволяющую создавать сложные системы серверов баз данных с распределением
данных и задач между компьютерами даже в одноранговой сети. В ОС NetWare SQLBase является
классическим сервером баз данных, таким же как Oracle или Sybase.
Поддержка локализации
JAM поддерживает 8-битные кодировки символов алфавита. Форматы ввода/вывода
даты/времени, валюты, чисел являются настраиваемыми. Системные сообщения вынесены в
отдельные файлы и доступны для перевода.
Поддержка многопользовательского режима
"Оптимистическая" и "Пессимистическая" модели блокировок
Блокировки
Уровни изоляции
Особенности сервера
Поддержка очень больших баз данных и съемных носителей
Для версии 4.21а очень большой считалась база данных размером 10-15 Гб (хотя некоторые
организации, например, Sprint, работали с базами данных размером 60 Гб и более).
Высокоскоростная параллельная обработка делает возможной поддержку работы с базами данных
размером 100 Гб и более на соответствующим образом конфигурированных системах. Не только
процесс создания страховочных копий выполняется быстрее, но и такие операции, как проверка
целостности базы данных (выполняется командой DBCC), сильно выигрывают от использования
параллельного сканирования и увеличенных блоков ввода/вывода. Возможность сохранения в
страховочной копии (восстановления из копии) индивидуальных таблиц позволяет сократить
время, необходимое на сохранение (восстановление) отдельных таблиц базы данных. Поддержка
распространения баз данных на съемных носителях (таких как CD-ROM) позволяет выпускать
различного рода справочники или информационные материалы. Интересно отметить, что
гибкость SQL Server проявляется и при работе с очень маленькими объемами информации. Так,
для того чтобы базу данных можно было сохранить на дискете, ее минимальный размер снижен до
1 Мб.
SQL Anywhere поддерживает ODBC API
SQL Anywhere поддерживает ODBC API не только на платформах Windows и Windows NT, но и в
DOS, OS/2 и QNX. SQL Anywhere 5.0 поддерживает спецификацию ODBC 2.1 уровня 2.
Поддержка средств 4GL
ERwin выпускается в нескольких различных редакциях, ориентированных на наиболее
распространенные средства разработки 4GL. В числе поддерживаемых средств - PowerBuidler фирмы
Powersoft, SQL Windows фирмы Gupta, Visual Basic фирмы Microsoft, Oracle*CASE фирмы
Oracle.
Средства двунаправленного взаимодействия ERwin с базой данных обеспечивают управление
информацией, ориентированной как на серверную, так и на клиентскую часть. Например, для
PowerBuilder можно просматривать/редактировать расширенные атрибуты в редакторах ERwin.
Ориентация ERwin на средства 4GL позволяет задать для будущих приложений большинство
параметров, непосредственно связанных с базой данных, уже на стадии проектирования
информационной модели.
Покажем принципы организации такого взаимодействия на примере PowerBuilder.
PowerBuilder создает в базе данных несколько внутренних таблиц для хранения своего репозитария
(расширенных атрибутов для datawindow). Использование расширенных атрибутов гарантирует
сохранение стиля отображения одних и тех же колонок базы данных для всех приложений,
создаваемых рабочей группой. В расширенных атрибутах задаются такие параметры, как формат
отображения, стиль редактирования, выражение проверки на корректность, начальное значение,
выравнивание, ширина и высота элемента отображения, метка для формы редактирования, заголовок
для табличного отображения.
Для расширенных атрибутов допустимы те же операции синхронизации, что и для всей модели, то есть
описания могут быть загружены в базу данных и, наоборот, созданные из среды PowerBuilder
описания расширенных атрибутов могут быть загружены из базы данных в ERwin для
модификации.
Пример определения расширенных атрибутов показан на рис.9.
Поддержка Transact-SQL
SQL Anywhere 5.0 включает набор расширений языка Watcom SQL в сторону диалекта Transact-
SQL Sybase, используемого в Sybase SQL Server на различных платформах.
Диалект Transact-SQL сам по себе не является лучше или хуже диалекта Watcom SQL. Достигнутая
совместимость означает, что на нижних уровнях распределенной информационной системы можно
использовать "легкую" по ресурсам, мощную по функциональности и дешевую СУБД SQL
Anywhere, а на уровне выше - промышленную высокопроизводительную СУБД Sybase. При этом
приложения, работающие с этими СУБД, окажутся инвариантны к тому, с какой СУБД они
работают.
Подход к представлению проектной информации
Проектные данные могут быть представлены множеством способов. Это спецификации функций, файлов
баз данных, экранов ввода информации, бланков документов и картотек. Что же общего между этими
столь разными представлениями? Это содержащиеся в них данные. В конечном счете, информационная
система - это система хранения и обработки информации. Поэтому в SILVERRUN основой всех
представлений являются данные. Они являются общей частью всех формализмов (типов описаний) и
универсально обрабатываются всеми модулями.
Один и тот же элемент данных может в разных представлениях иметь разные названия и форматы. В
SILVERRUN обеспечена возможность связывать элементы данных различных представлений с общим
элементом (common item), выражающим смысл представленной этими элементами данных информации.
Этот общий элемент может стать столбцом таблицы базы данных в новой системе или просто
использоваться как универсальный термин для связи разных представлений.
Последовательность проектирования модели данных в S- Designor
Процесс построения информационной модели данных состоит из следующих шагов:
определение сущностей;
определение зависимостей между сущностями;
задание первичных и альтернативных ключей;
определение атрибутов сущностей;
переход к физическому описанию модели (выполняется автоматически);
редактирование имен таблиц и их атрибутов на физическом уровне (если в
модели имеются, например, связи "многие ко многим" или иерархические
рекурсивные связи и их надо уточнить);
проектирование триггеров, процедур и ограничений;
генерация базы данных.
Четкое разделение между концептуальной и физической моделями в S-Designor выражается в
том, что на каждом уровне действуют соответствующие четко выраженные правила. На
концептуальном уровне не выполняется миграция атрибутов
первичного ключа в дочернюю сущность, так как это было бы уже не отображение реального мира (в
данном случае перечня атрибутов конкретного объекта).
Миграция выполняется на физическом
уровне
Необходимость построения физической модели как отдельного шага проектирования объясняется
требованием приведения описания сущностей и связей, определенных на стадии построения
концептуальной модели, к физической структуре с учетом специфики целевой СУБД. При генерации
физической модели из концептуальной сущности становятся таблицами, атрибуты - колонками, для
альтернативных ключей генерируются уникальные индексы, а идентификаторы становятся
первичными ключами.
При генерации физической модели S-Designor, если это необходимо, детализирует связи.
Связь "многие ко многим" порождает новую таблицу. Таким образом обеспечивается автоматическая
нормализация модели. Идентификаторы сущностей, участвующих в связи, мигрируют в новую
таблицу. Первичный ключ в зависимой таблице составляет теперь сумму атрибутов первичных
ключей родительских таблиц. При уточнении иерархической рекурсивной связи S-Designor
автоматически добавляет новую колонку, являющуюся внешним ключом, которую при
необходимости можно переименовать.
Для управления уникальностью строк и ускорения доступа к данным могут назначаться индексы. Для
первичных и внешних ключей индексы формируются автоматически.
На показан результат автоматического преобразования
концептуальной модели данных в физическую. Заметим, что на данном уровне уже нет различий
между идентифицирующими и неидентифицирующими связями, так как в физической структуре
данных такие типы связей действительно неразличимы, поскольку, реализуются одними и теми же
общими механизмами СУБД.
Построение архитектуры информационной системы
Принимается решение, из каких приложений (подсистем) будет состоять система. Анализируются
существующие системы. Архитектура системы документируется в виде DFD, где функции представляют
компоненты приложений с указанием используемой информации (путем ссылки на сущности и связи ER-
модели). ER-модель также делится на группы сущностей, обрабатываемых приложениями. Результат:
Архитектура информационной системы.
Построение бизнес-модели предметной области
Строится функциональная (DFD) и информационная (ER) модели предметной области. При построениии
функциональной модели выявляются первичные структуры данных, которые преобразуются в сущности
ER-модели. Результат: Модель бизнес-процессов, содержащая Первичные структуры данных, и
Концептуальная модель данных.
Построение корпоративных информационных систем: технологии и решения
Старыгин, МетаТехнология
Тел.: 253-38-22, ф. 255-12-90,
()
Под корпоративной информационной системой будем понимать информационную систему масштаба предприятия. Главной задачей такой системы является информационная поддержка производственных, административных и управленческих процессов (далее - бизнес-процессов), формирующих продукцию или услуги предприятия.
За последние десятилетия радикально изменились принципы, методы построения и архитектура такой системы. Так, если в 60-х годах считалось, что никакой процесс не должен автоматизироваться до тех пор, пока он функционирует эффективно, то сегодня господствующим является прямо противоположный подход. Считается, что любой процесс должен автоматизироваться только после того, как он эффективно организован.
Эти изменения явились результатом обобщения опыта построения множества информационных систем в которых автоматизация отдельных операций или сложившихся "ручных" процедур приносила локальные временные улучшения, не затрагивающие общую эффективность работы.
Главными особенностями современного подхода к построению корпоративной информационной системы предприятия являются:
всесторонний анализ бизнес-процессов, на основе которого производится разработка проекта информационной системы и обоснование заложенных в нем решений;
использование широкой палитры современных методологий и инструментальных средств моделирования и проектирования систем;
детальная проработка и согласование с заказчиком всех этапов разработки проекта, контрольных точек, требуемых ресурсов.
Такой подход обеспечивает разработку интегрированных решений, построенных на объективных данных о работе предприятия, своевременное согласование всех принципиальных вопросов между Заказчиком, Генеральным Подрядчиком и другими участниками работ и направлен на сохранение сделанных в систему инвестиций.
Теоретическую основу соответствующих работ, выполняемых фирмой МетаТехнология, составляет множество понятий, концепций и методологий, используемых для описания, анализа и оценки различных аспектов работы предприятия.
Основными компонентами этого множества являются (список упорядочен по алфавиту):
| Activity Based Budgeting - планирование бюджета на основе выполняемых функций или операционное планирование бюджета - планирование бюджета компании или инвестиционного проекта с использованием принципов, средств и методов ABC. Фактически представляет собой обратное проектирование ABC-системы |
| Activity Based Costing - функционально-стоимостной анализ - метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах |
| Activity Based Management - управление на основе ABC-информации или операционное управление - методология, описывающая средства и способы управления организацией для совершенствования бизнес-процессов и повышения прибыльности на основе информации, предоставляемой в результате ABC-анализа |
| Activity Resource Planning - функциональное планирование ресурсов - метод планирования ресурсов компании на основе анализа функций, задействованных в бизнес-процессах и данных ABC-анализа |
| Business Process Reengenering- реорганизация бизнес-процессов - направление деятельности, включающее "фундаментальное переосмысление и радикальное перепланирование критических бизнес-процессов с целью улучшения их эффективности в отношении затрат, качества выполнения и скорости" |
| Continuous Process Improvement - непрерывное совершенствование процессов - один из подходов к совершенствованию качества бизнес-процессов в рамках TQM |
| Color Petri Nets - раскрашенные сети Петри - методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов, для входящих потоков различной структуры |
| Data Flow Diagrams - диаграммы потоков данных - методология структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных к которым осуществляется доступ |
| Entity-Relationship Diagrams - диаграммы "сущность-связь" - способ определения данных и отношений между ними, обеспечивающий детализацию хранилищ данных проектируемой системы включая идентификацию объектов (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей) |
| Методология функционального моделирования, являющаяся составной частью SADT и позволяющая описать бизнес-процесс в виде иерархической системы взаимосвязанных функций |
| Методология информационного моделирования, являющаяся составной частью SADT и основанная на концепции "сущность-связь" (entity-relationship) |
| Structured Analysis and Disign Tecchnique технология структурного анализа и проектирования |
| State Transition Diagrams - диаграммы переходов состояний - методология моделирования последующего функционирования системы на основе ее предыдущего и текущего функционирования |
| Total Quality Management - глобальное управление качеством - направление деятельности, изучающее бизнес-процесс с целью такой их организации, которая гарантирует идеальное качество продукции |
На рассмотренные понятия и методологии сгруппированы по основным направлениям использования в работах по моделированию и анализу бизнес-процессов.
В качестве инструментальных средств выполнения работ используются:
Пакет Design/IDEF компании Meta Software - для функционального и информационного моделирования, анализа и проектирования бизнес-процессов;
Основными особенностями Design/IDEF являются:
полная поддержка методологий IDEF0 и IDEF1X;
интеграцию функционального и информационного представления системы в рамках единой модели;
контроль непротиворечивости модели на протяжении всего цикла ее создания;
встроенный словарь данных, позволяющий создавать неограниченное количество параметров описания любого объекта,
генератор отчетов, позволяющий создавать отчеты о функциях и потоках данных модели;
интерфейсы к внешним программам, экспорт и импорт данных;
поддержка коллективной работы группы разработчиков.
корпоративных информационных систем поддержки бизнеса">
Рис. 1. Области использования различных методологий
в работах по моделированию, анализу бизнес-процессов и построению
корпоративных информационных систем поддержки бизнеса
Пакет EasyABC Plus компании ABC Technologies - для функционально-стоимостного анализа бизнес-процессов;
Основными особенностями EasyABC Plus являются:
поддержка ABC-метода анализа бизнес-процессов, выявление затратных центров, подготовка данных для планирования и управления предприятием;
возможность определить любое количество уровней назначения стоимости между ресурсами, функциями, стоимостными объектами;
поддержку работы с реальными и бюджетными данными, что дает возможность оценить реальную производительность по сравнению с запланированными показателями;
возможность моделирования результатов принимаемых решений в режиме "что-если";
возможность анализа групп функций или стоимостных объектов, помеченных одинаковыми метками (атрибутами);
генерация разнообразных отчетов;
экспорт и импорт данных.
Пакет ServiceModel компании PROMODEL - для имитационного моделирования выполнения бизнес-процессов, анализа зависящих от времени характеристик, распределения ресурсов.
Основными особенностями ServiceModel являются:
возможность использования функциональных моделей бизнес-процессов, подготовленных в Design/IDEF;
учет множества дополнительных элементов, описывающих поведение модели: продолжительность выполнения функций, время передачи выходных данных, объем данных, схема приоритетов исходных данных, весовые коэффициенты выходных данных, параллельные процессы, категории ресурсов, комплексные ограничения и др.
контроль корректности разработанной модели, выявление ошибок и неоднозначностей;
изменение характеристик входящих потоков и распределения ресурсов по принципу "что-если";
возможность использования в модели пользовательских программ;
сбор статистических данных и генерация разнообразных отчетов;
использование анимационных эффектов для демонстрации работы модели.
Пакет S-Designor компании Powersoft - для создания концептуальных и физических моделей структуры базы данных.
Основными особенностями S-Designor являются:
поддержка широкого класса объектов моделирования: сущности, элементы данных, связи, наследования, атрибуты, домены, таблицы, ссылки, столбцы, индексы, представления, триггеры, хранимые процедуры;
возможность использования правил обработки данных, построенных на основе анализа бизнес-процессов;
автоматическая генерация физической модели данных;
разделение больших моделей на подмодели с сохранением уникальности определений объекта;
средства порождения моделей (обратное проектирование): физической модели из существующей базы данных, концептуальной модели из физической;
поддержка свыше 30 баз данных: Sybase, Oracle, Informix, Ingres, SQL Server, SQL Base, Progress, Access, Paradox, FoxPro и др.;
генерация стандартных и заказных отчетов;
экспорт и импорт данных.
Все перечисленные пакеты широко использовались для создания проектов крупных информационных и бизнес-систем, связанных с анализом, реорганизацией и автоматизацией деятельности предприятий в различных странах, секторах рынка, с многообразием направлений деятельности, видов продукции, способов организации бизнеса и т.д.
Необходимо отметить, что в результате описанного выше подхода к построению корпоративной информационной системы сформировалась качественно иная чем прежде трехслойная архитектура информационной системы, основными компонентами которой являются:
слой правил бизнеса, определяющий внутренние правила выполнения бизнес-процессов и организации работ;
слой корпоративных электронных архивов и баз данных;
слой прикладных систем, обеспечивающих ввод, обработку и анализ данных в соответствии с правилами организации бизнеса предприятия.
Такая архитектура позволяет:
сохранить базу данных независимой от изменений политики бизнеса и поддержать согласованность и осмысленность данных в течение длительных периодов времени;
обеспечить возможность использовать различные интерфейсы пользователя (формы, документы) для одних и тех же правил бизнеса и, наоборот, изменять и расширять правила бизнеса, не затрагивая интерфейсы пользователя;
предоставить пользователю возможность использовать различные приложения и способы организации индивидуальной работы, не заботясь о том, как они могут повлиять на правила компании, политику и процедуры;
сформулировать описание функций каждого слоя не перегружая его описанием деталей, касающихся организации других слоев;
обеспечить формальную спецификацию интерфейсов между слоями, поддерживающих независимое развитие информационных технологий и реализующих их программных средств;
упростить разработку приложений, освободив разработчика от необходимости учитывать конкретные детали реализации других слоев;
повысить защищенность и безопасность работ за счет ограничения допуска разработчиков к информации о деталях организации других слоев.
[]
[]
[]
Построитель Интерфейса Пользователя (User Interface Builder)
Построитель Интерфейса Пользователя (User Interface Builder) является объектно-
ориентированной средой визуального программирования, которая позволяет Вам быстро строить
самые сложные приложения, просто задавая связи между поставляемыми фирмой или созданными
Вами многократно-используемыми (reusable) объектами. В дополнение к технологии визуальной
разработки экрана и использованию уже созданных объектов, Построитель Интерфейса имеет
логику доступа к данным и средства автоматической генерация кодов пользовательского
интерфейса, что позволяет значительно увеличить производительность труда разработчиков и
качество самого приложения. При этом использование Построителя Интерфейса PROGRESS
уменьшает стоимость разработки приложения за счет уменьшения количества непосредственного
кодирования, которое приходится выполнять разработчикам.
Визуальное программирование.
При помощи Построителя Интерфейса можно быстро создавать сложные приложения,
использующие базы данных. Для этого Вы, используя технику визуального программирования,
просто определяете и размещаете в нужных местах экрана объекты баз данных и
пользовательского интерфейса,. Пользовательские интерфейсы содержат набор различных
графических объектов, обеспечивающих пользователю взаимодействие с приложением. Элементы
интерфейса включают в себя командные кнопки, раскрывающиеся меню, радио-клавиши и
т.д..
Объектами баз данных являются таблицы и поля. Для добавления объекта на экран, например
командной кнопки, Вы просто выбираете ее из предлагаемого Вам набора и перемещаете в
желаемое место на экране. Аналогичная процедура проделывается и для полей базы данных:
Построитель Интерфейса предлагает список полей базы данных, из которых Вы выбираете
нужные Вам поля и, затем, позиционируете их в нужное место на экране. Объекты базы данных
отображаются в соответствии с логикой атрибутов и умолчаний, наследуемых ими от Словаря
Данных. Все установки по умолчанию при этом могут быть изменены для отображения данных в
соответствии с конкретными требованиями приложения.
Построитель Интерфейса позволяет отображать на экране или в окне одиночную запись или сразу
же список записей базы данных. Список записей автоматически обрабатывается интеллектуальным
интерфейсом, включающим в себя всю необходимую логику, необходимую для просмотра и
перемещения по полученному результирующему набору записей в режиме скроллинга вперед или
назад, вне зависимости даже от того, поддерживает ли его Ваша конкретная СУБД или нет. Как
одиночные записи, так и списки записей могут содержать и отображать информацию из
многочисленных баз данных различных форматов. Связанная с записью информация может быть
представлена в том же самом окне, в раскрывающихся окнах или таблицах.
Использование ранее созданных объектов (reusable objects)
Построитель Интерфейса делает процедуру создания, поиска, управления и использования ранее
созданных объектов весьма простым делом. Определение пользователем объектов Построителя
Интерфейса увеличивает Вашу производительность, позволяя воспользоваться результатами той
работы, которая уже была проделана Вами или членами Вашей группы разработчиков. Повторно
используемые объекты могут быть созданы либо при помощи Построителя Интерфейса либо
Редактора Процедур, и могут содержать в себе программный код, определение объектов
Интерфейса, или то и другое вместе взятое. Если Вы собираетесь переходить к объектно
ориентированному принципу разработки приложений, то использование определяемых
пользователем объектов интерфейса будет вашим первым шагом в этом направлении.
Поддержка интерфейсов для символьных и графических терминалов
Построитель Интерфейса работает только на графических станциях, но его возможности по
эмуляции пользовательского интерфейса для символьных терминалов, позволяют создавать и
тестировать интерфейсы, предназначенные для символьных терминалов точно также, как и
интерфейсы для графических (GUI) приложений. В результате Вы получаете повышение общей
производительности, так как от Вас требуется знание только одного типа Построителя
Интерфейса Пользователя.
Различные платформы, под которые разрабатывается Интерфейс Пользователя, такие как
Windows, Motif и символьные терминалы, рассматривают процедуру позиционирования и
определения размеров объектов пользовательского интерфейса с совершенно различных точек
зрения. Возможность Альтернативной Планировки экрана (Alternate Layout) в Построителе
Интерфейса использует свойство наследования для того, чтобы позволить Вам быстро создавать и
модифицировать различные версии одного и того же окна для самых различных терминалов.
Альтернативная Планировка позволяет сохранять и компилировать различные варианты
графических окон в одном исходном файле, что упрощает распространение приложений,
предназначенных для работы на терминалах в различных графических средах. Подобные
возможности позволят Вам быстро и эффективно проектировать по-настоящему переносимые
приложения.
Генерация 4GL кода
Построитель Интерфейса включает в себя мощные средства для генерации кода, нацеленные на
снижение стоимости разработки сложных форм, меню и экранов, предназначенных для управления
списками файлов. В отличие от аналогичных средств, Построитель Интерфейса PROGRESS
"заранее" знает о типе используемых данных и автоматически генерирует необходимую логику для
взаимодействия с конкретными данными. Это означает, что Вам не нужно знать язык SQL для
использования Построителя Интерфейса. В подавляющем большинстве случаев вся логика
взаимодействия с данными Вашего окна генерируется автоматически - Вам не требуется даже
визуально определять ее. Эти возможности по генерации кода позволяют создавать и встраивать в
Построитель Интерфейса повторно используемые формы и шаблоны, содержащие логику
приложения, тем самым увеличивая производительность разработки, надежность самого
приложения и уменьшая стоимость его последующей поддержки.
Построитель Интерфейса является открытым средством разработки, поддерживающим стандарт
Программного Интерфейса Приложений (API), что позволяет включать в процесс разработки
приложений на PROGRESS программные средства, разработанные третьими фирмами, такие,
например, как системы контроля за версиями исходного кода. Так как все окна и формы,
генерируемые Построителем Интерфейса хранятся в виде отдельных самостоятельных текстовых
файлов, содержащих процедуры, написанные на языке PROGRESS 4GL, то Вы можете свободно
использовать их в нескольких приложениях или модифицировать и улучшить эти процедуры,
используя любые подходящие для этой цели средства, включая текстовые редакторы и системы
контроля за версиями исходного кода. Даже, если сгенерированная процедура на языке 4GL была
модифицирована, то она все равно может быть загружена обратно в Построитель Интерфейса для
ее дальнейшего редактирования уже в графическом виде.
Событийно-управляемое (Event-Driven) Программирование и Триггеры (Triggers) Интерфейса
Пользователя. Возлагая на приложения заботу о пользователе, событийно-управляемые
приложения, написанные на PROGRESS, делают труд пользователей более продуктивным и
приятным. Наряду с управлением визуальными атрибутами интерфейса пользователя,
Построитель Интерфейса позволяет Вам определять, - каким образом приложения должны
реагировать на происходящие внешние события. Конечные Пользователи взаимодействуют с
событийно-управляемыми приложениями посредством набора операций, называемых событиями
интерфейса пользователя. В качестве примера одного из таких событий можно привести выбор
опции меню, ввод данных в поле, изменение размера окна, нажатие клавиши на экране.
Построитель Интерфейса позволяет создавать процедуры на языке 4GL, связанные с этими
событиями. Эти процедуры называются Триггерами Интерфейса Пользователя. Редактор
Триггеров, встроенный в Построитель Интерфейса позволяет быстро понять и отредактировать
логические взаимосвязи между тем, как будет выглядеть и, как будет реагировать на внешние
события Ваше приложение.
Определение Триггеров Интерфейса Пользователя для любого элемента или события, дает Вам
возможность более гибкого контроля за поведением приложения.
Организация исходного кода и логики приложений.
В дополнение к определению объектов интерфейса пользователя и триггерам, оконные объекты
PROGRESS также инкапсулируют определения переменных и внутренних процедур или "методов".
Наличие этих элементов поможет Вам легко создавать и поддерживать сложные многооконные и
многомодульные приложения, характерные для современного мира. Редактор Разделов (Section
Editor) в Построителе Интерфейса позволяет создавать и размещать разделы этих определений для
эффективной координации взаимодействия модулей в приложениях со сложной логикой работы.
Редактор Разделов обеспечивает быстрый доступ и возможность редактирования следующих
разделов для оконных объектов:
Раздел Определений. Здесь Вы определяете переменные,
константы и параметры, которые управляются или используются оконными
объектами PROGRESS. Может возникнуть ситуация, когда на экране
одновременно должно появиться несколько одних и тех же оконных объектов,
одновременно активных, и каждый такой объект будет управлять или
"инкапсулировать" свои собственные данные, что позволяет легко создавать
сложные многооконные приложения.
Раздел Процедур инициализации и закрытия окон. Вы управляете
логикой приложения, инициализирующей инкапсулированные данные окна и
активируете оконные объекты интерфейса пользователя. После
инициализации окно остается в состоянии готовности и ожидания отклика на
события и команды Пользователя "или сообщения", полученные от других
оконных объектов или объектов приложения. Здесь также указывается, какие
должны быть выполнены действия при закрытии окон, чтобы обеспечить
правильное состояние объектов
Раздел Внутренних процедур. Внутренние процедуры или "методы"
- это функции, которые могут быть вызваны или повторно использованы в
одном или нескольких триггерах оконного объекта. Использование внутренних
процедур уменьшает количество времени и усилий, необходимых для описания
поведения оконного объекта.
Так как другим компонентам приложения тоже
может потребоваться взаимодействие с Вашими оконными объектами, то
внутренние процедуры описывают также способ, каким образом будут
обслуживаться запросы от других объектов приложения. Использование
внутренних процедур для определения надежных, основанных на сообщениях
интерфейсов между оконными объектами упрощает интеграцию и поддержку
модульных многооконных приложений.
Завершенность и гибкость
Построитель Интерфейса сочетает в себе мощь, завершенность и переносимость языка 4-го
поколения PROGRESS (4GL). Экраны и окна, спроектированные на одной машине под одним
пользовательским интерфейсом (MS Windows, Motif или символьный) легко могут быть
перенесены и запущены на другой машине с другим пользовательским интерфейсом. Такая,
присущая языку переносимость, максимизирует продуктивность разработки и позволяет Вам
использовать однажды разработанное приложение на огромном множестве платформ, не прибегая
к дополнительному перепрограммированию.
Повышение производительности и мониторинг производительности
Использование журнала транзакций в SQL Anywhere уменьшает время фиксации каждой
транзакции. Сервер SQL Anywhere является 32-разрядным (кроме платформы Windows 3.X).
СУБД использует оптимизатор, который выбирает лучшую стратегию для выполнения каждого
запроса. Для этого оптимизатор определяет стоимость каждой стратегии, оценивая требуемое
количество считываний и записей на диск. Выбранная стратегия задает, в каком порядке
происходит доступ к таблицам в запросе и следует ли использовать индекс для каждой
таблицы.
Окно статистики в интерактивном средстве для формирования запросов (ISQL) позволяет
просмотреть выбранный план выполнения любого оператора SQL.
В SQL Anywhere предусмотрен набор статистической информации, предназначенной для оценки
производительности. Эта информация доступна из инструмента администратора SQL Central и
приложений-клиентов. В дополнение, подобная информация предоставляется из SQL Anywhere в
монитор производительности Windows NT.
PowerBuilder - среда разработки приложений масштаба предприятия
А.Чибисов, фирма Метатехнология
PowerBuilder™ - это объектно-ориентированный инструмент для профессиональной разработки
приложений в среде клиент/сервер, позволяющий коллективам разработчиков легко и быстро создавать
графические приложения, которые имеют доступ к базам данных и другой корпоративной информации,
хранящейся локально или на сетевых серверах.
Правила и начальные значения
В ERwin поддерживаются два типа правил (проверок допустимости значений) и начальных (по
умолчанию) значений. Правило и умолчание может быть указано для проверки со стороны клиента
(например, в PowerBuilder) и со стороны сервера.
При задании правила или умолчания для клиентской части эти атрибуты переносятся в репозитарий
средства 4GL.
На рис.10 показан диалог для задания значений по умолчанию,
устанавливаемых в PowerBuilder. Заметьте, что в одном и том же диалоге задаются умолчания,
подставляемые как на стороне клиента, так и на стороне сервера (в данном случае - Sybase).
Преимущества и недостатки архитектуры клиент- сервер
Под лозунгом "Upsizing application" компания Borland выпустила серию инструментов
разработчика, которые с успехом применялись и применяются при разработке клиент-серверных
проектов. Это прежде всего 16-разрядный Delphi 1.0, доступный на рынке уже в течение года,
вышедший с 1 марта 1996 года Delphi 2.0 для Win 95/NT, Paradox 5.0, выходящий с декабря 1995 года
Paradox 7, Visual dBase 5.5, C++ 4.5 c BDE 2.5 и выходящий с конца марта C++ 5.0 с BDE 3.0 для
Windows 95/NT. При помощи этих инструментов можно разрабатывать локальные приложения для
баз данных, а затем легко мигрировать в архитектуру клиент-сервер.
Если в локальных приложениях эти инструменты напрямую работают с данными, то в архитектуре
клиент-сервер данные с сервера доступны посредством запросов к серверу, а SQL-сервер
занимается поиском и поддержанием целостности данных. По сравнению с файл-серверной
архитектурой мы имеем реальные преимущества - более низкий сетевой трафик и большая
надежность хранения данных. Кроме того, при разработке информационной системы в
архитектуре клиент-сервер немаловажное значение имеет доступность CASE-средств, облегчающих
проектирование сложной системы.
Однако, как только мы задумываемся о создании клиент-серверной системы на более чем 100-200
клиентских мест, сразу возникают дополнительные сложности. Во-первых, стоимость коннекта -
стоимость клиентской лицензии для SQL-сервера в среднем достаточно высока и при умножении
ее на соответствующее количество возникает пугающая цифра. Во-вторых, даже если отбросить в
сторону финансовые соображения, существуют и дополнительные сложности. На каждый
клиентский коннект сервер должен выделять значительное количество памяти на аппаратуре
серверной машины, в зависимости от типа SQL-сервера это количество разное, однако общая
тенденция очевидна. Вероятность того, что в действующей системе потребуется доступ к данным с
клиентских станций разных типов и моделей, достаточно высока - в большой корпоративной или
мешкорпоративной системе мы имеем зоопарк различной техники - от терминалов и 286 моделей
до серьезных UNIX-станций. В большой информационной системе, как правило, наблюдается и
разнобой физической реализации коммуникаций - от модемных соединений 2400 бод до
оптоволокна c FDDI. Как быть, и реально ли в таких условиях говорить о приемлемом клиент-
серверном решении задачи построения информационной системы?
Симметричная архитектура Microsoft SQL Server
Симметричная архитектура Microsoft SQL Server предоставляет следующие преимущества:
снижает сложность системы
SQL Server не дублирует службы операционной системы (такие как диспетчирование,
распределение памяти, управление очередями), что делает архитектуру системы более эффективной
и стабильной;
повышает производительность
SQL Server способен обеспечить высокую скорость выполнения транзакций и обладает высокой
пропускной способностью на микропроцессорных системах, даже при одновременной работе сотен
пользователей;
адаптируется к росту нагрузки
Нагрузка на SQL Server динамически распределяется по нескольким ЦП, что повышает
масштабируемость на симметричных многопроцессорных системах.
повышает надежность
Задачи пользователя исполняются в самостоятельных потоках, и при необходимости одна задача
принудительно завершается, не оказывая влияния на выполнение остальных. Например, SQL
Server способен прервать "спящий" процесс без того, чтобы это оказало влияние на работу всей
системы. Ни одна задача не может "выйти из-под контроля".
Преимущества SQL-DMF
упрощает процесс управления распределенными серверами за счет
предоставления современного пользовательского интерфейса
административной консоли для всех задач управления и интеграции
компонентов управления и инструментов администратора, а также сервисов
внутри основного продукта;
предоставляет масштабируемую среду управления, которая может быть
адаптирована к конкретным потребностям малых и крупных заказчиков.
Разработчики могут расширить набор стандартных инструментов за счет
встроенных OLE объектов управления и поддержки средств визуальной
разработки;
делает удаленные серверы более самостоятельными с точки зрения
управления средствами сервисов, взаимодействующих с процессором данных
сервера (диспетчирование, события/предупреждения, тиражирование). Они
могут быть запрограммированы для выполнения административных задач без
участия человека;
предоставляет администраторам баз данных инструментарий,
позволяющий перейти от защитной к активной модели администрирования с
использованием развитой модели обработки событий/предупреждений для
назначения корректирующих действий при возникновении определенного рода
проблем или условий (например, переполнение журнала), вызываемых через
триггеры или предупреждения.
Преодоление ограничений реляционного подхода
Среди наиболее существенных ограничений реляционного подхода можно отметить:
невозможность использования одинакового объектно-ориентированного
подхода при разработке баз данных и приложений, их использующих;
невозможность определения новых типов данных с использованием
предоставляемых системой или ранее определенных типов;
отсутствие механизмов наследования и инкапсуляции;
невозможность связывать с данными операции их обработки.
Первое из перечисленных выше ограничений является препятствием для использования объектного
подхода к разработке приложений РСУБД.
Представление данных в виде объектов, аналогичных реальным объектам предметной области,
при построении ООИС с использованием реляционной СУБД приводит к тому, что возникает
несоответствие модели данных приложения и СУБД. Преобразование объектов в кортежи
связанных таблиц и наоборот может потребовать от разработчика таких усилий, которые сведут
на нет преимущества использования объектной декомпозиции.
Для решения этой проблемы IBM предлагает специальные библиотеки классов для доступа к DB2 с
использованием средств разработки приложений семейства VisualAge. Эта библиотека позволяет
использовать для работы с отношениями DB2 объекты специальных классов С++ или
Smalltalk.
Таким образом упрощается работа с реляционной СУБД с использованием объектно-
ориентированного языка программирования, однако данные в базе данных по-прежнему хранятся
в виде кортежей, что вызывает серьезные накладные расходы на выполнение операций соединения
при сложной структуре объектов .
В настоящий момент IBM предлагает средства, частично снимающие и остальные ограничения
продукте DB2 Common Server.
Пример разработки модели в ERwin
Рассмотрим цикл разработки на примере, приведенном в статье Кодда .
Коротко напомним содержательную сторону задачи. Ведется учет служащих. Для каждого служащего
хранится информация о детях и о списке занимавшихся этим служащим должностей. Для должностей
хранится информация по установленным должностным окладам.
Сначала создадим логический уровень модели. Для этого зададим режим отображения сущностей
(Display/Entity Level). Создадим при помощи линейки инструментов сущности "служащий", "дети",
"история работы", "история зарплаты". Будем именовать сущности на русском языке.
Выбрав каждую сущность, зададим для нее подробное описание на русском языке в редакторе "Entity
Definition". Это описание появится в отчетах ERwin и может быть отображено на диаграмме.
Укажем связи между сущностями. Например, "служащий" связан идентифицирующей связью "является
родителем" с сущностью "дети". Описание связи вводится в редакторе "Editor/Relationship".
Результат работы отображен на диаграмме ERwin (рис. 2).
Прочие возможности
До сих пор объекты типа VIEW (представление) могли быть модифицированы только в том
случае, если они строились на основе одной таблицы и не содержали вычисляемых столбцов. В
версии 7.3 можно модифицировать VIEW, полученные в результате соединения нескольких
таблиц.
Некоторые улучшения внесены в механизм сложной репликации (advanced replication option).
Теперь она позволяет выполнять не только асинхронную (через определенные интервалы времени),
но и синхронную репликацию данных. Возможно объединение таблиц БД в группы (подсхемы) и
задание репликации для всей подсхемы.
Проектирование баз данных: новые требования, новые подходы
Е.З.Зиндер, Корпорация ЛВС
"Попытка навязывать некоторую технологию
или
инструмент для удовлетворения специфической потребности,
для которой другой
инструмент более действенен
и эффективен, подобна попытке "ввернуть" шуруп
в
стену молотком, когда отвертка - под рукой:
шуруп может, в конечном счете,
войти в стену,
но во что это встанет?"
E.F.Codd, S.B.Codd, and C.T.Salley.
Providing OLAP to User-Analyst: An IT Mandate.
E.F.Codd & Associates, 1993.
Цель данного доклада - оценить сегодняшние проблемы и тенденции развития технологий
проектирования БД, а также, хотя бы отчасти - требования завтрашнего дня. Доклад может
сыграть еще одну роль: задать набор актуальных требований, которые будут служить
координатами для позиционирования конкретных частных методов и инструментов
проектирования БД (отчасти также - средств их использования и управления ими), которые
представляются в двух специальных секциях данной конференции.
Проектирование прикладной системы
На этапе проектирования формируются все спецификации, описывающие структуру и основные
компоненты будущей системы. Как и на предыдущем уровне эти спецификации разделяются на
информационные и функциональные - на описание базы данных и описание состава программных
модулей системы.
При описании базы данных указывается, какие таблицы в нее входят, специфицируются основные
характеристики этих таблиц, состав столбцов каждой из них, уточняются параметры столбцов (тип
значений, ограничения на допустимые значения, значения, принятые по умолчанию,
статистические характеристики использования и многие другие), задаются ограничения
целостности - логические условия, которые должны выполняться при любом содержании таблиц.
Кроме того, описываются дополнительные объекты базы данных ORACLE, такие как индексы,
кластеры, последовательности, основное назначение которых связано с повышением
эффективности работы с базой данных, ускорением доступа к часто используемой
информации.
Функциональные возможности системы определяются спецификацией модулей различных типов,
основными из которых являются экранные формы, обеспечивающие доступ пользователей к
информации базы данных, отчеты, используемые для вывода данных в специализированном виде,
удобном для дальнейшего анализа, меню, описывающие логику работы системы, процедурные
модули. Предполагается, что эти типы модулей позволяют описать функционирование системы
практически в полном объеме, как можно меньше прибегая к использованию дополнительных
средств таких, как, например, процедуры, написанные на внешних языках программирования. Это
поддерживается, в частности, достаточно развитыми возможностями выполнения вычислений
непосредственно в формах и отчетах: например, наличие в формах аппарата триггеров позволяет
включать в модуль типа формы алгоритмы обработки практически любой степени
сложности.
Все спецификации проекта системы разрабатываются на основе моделей концептуального уровня
и должны обеспечивать выполнение всех содержащихся в них требований и ограничений.
Первоначальный вариант спецификаций можно сформировать автоматически с помощью
специальных утилит, к которым относятся:
утилита автоматической генерации спецификаций базы данных по ER-
модели;
процедура генерации спецификаций модулей по иерархии функций и
потокам данных.
С помощью утилиты автоматической генерации проекта базы данных по ER-диаграмме будут
построены спецификации будущей базы данных - ее состав таблиц, перечень столбцов каждой из
них, уточнение характеристик столбцов, описание ограничений целостности и т.д.
При генерации схемы базы данных по ER-модели каждой сущности ставится в соответствие
таблица, атрибутам - столбцы таблиц, а для каждой связи создаются дополнительные столбцы и
определяются ограничения целостности типа внешних ключей (foreign key constraint). Подтипы
сущностей в ER-модели реализуются в схеме базы данных в виде одной общей таблицы или в виде
совокупности нескольких - по одной на каждый подтип.
По иерархии функций и диаграммам потоков данных могут быть автоматически сгенерированы
спецификации программных модулей прикладной системы, описывающие общие характеристики
модулей, с какими таблицами работает каждый из них, возможные действия с этими таблицами и
т.д. При этом анализируется диаграмма иерархии функций и для каждой элементарной функции
(нижней в иерархии) создается спецификация модуля. Тип модуля устанавливается по
определенным правилам в соответствии с указанным для функции способом работы с сущностями.
Например, если известно, что функция использует сущности только для чтения информации, то
считается, что ей должен соответствовать модуль типа отчет. Предусмотрена также возможность
"объединять" некоторые однотипные функции, т.е. создавать один модуль сразу для нескольких
различных элементарных функций. Основой для такого "объединения" служит также характер
использования функциями сущностей - если две функции работают с одними и теми же сущностями
и одинаково их используют, то это может считаться основанием для создания для них одного
Проектирование приложений (подсистем)
На основе концептуальной ER модели строится реляционная модель данных. Части ER-модели,
соответствующие различным приложениям, оформляются как подсхемы базы данных. Для каждого
приложения создается (возможно, разными группами разработчиков) детальный проект. Строится модель
системных процессов (программных функций) и подсхемы базы данных для каждой функции
(спецификация интерфейса). Поскольку все приложения работают с подсхемами одной базы данных,
обеспечивается их совместная работа. Результат: Реляционная модель данных. Для каждого приложения -
Модель данных приложения, Модель системных процессов. Для каждого интерфейса в приложении -
Спецификация интерфейса.
Программирование событий окна и органов управления
Как само окно, так и его органы управления являются объектами, образованными от стандартных
оконных и визуальных классов NewEra. Для них предопределены множества стандартных событий
(табл. 1).
Таблица 1
Примеры событий в объектах визуальных классов
| окно | start | при открытии окна |
| многие органы | activate | при активации, например, управления окна щелчком мыши |
| супертаблица | beforeRetrieve | перед началом выполнения выборки |
| супертаблица | rowRetrieve | после выборки очередной строки |
Генератор окон позволяет задавать процедуры обработки событий (точнее, тела этих процедур -
заголовки генерируются автоматически). Для ввода процедур обработки событий вызывается
программное окно, предоставляющее простейшие средства редактирования. В программном окне
можно ввести также определения дополнительных методов и событий, которые войдут в
определение нового оконного или визуального класса.
Программирование триггеров и процедур
ERwin реализует собственный макроязык для подготовки прототипов триггеров и процедур. Схема
использования прототипов заключается в подготовке шаблона для различных типов триггеров
(например, триггер, реализующий логику каскадного удаления - ON DELETE CASCADE). Базовые
шаблоны встроены в ERwin, но пользователь может определить свои собственные шаблоны и
использовать их вместо стандартных.
Макроязык шаблонов реализует большое количество макросимволов, ссылающихся на различные
объекты базы данных, например:
%Action - расширяется в UPDATE/INSERT/DELETE;
%ForEachAtt(<таблица>,<разделитель>) { <код макрокоманды> } -
циклическое выполнение группы операторов над каждым атрибутом таблицы;
%ForEachEntity() { } - циклическое выполнение функций над всеми таблицами;
%If, %else - операторы условного управления.
Например, шаблон триггера для реализации поддержки on delete cascade:
%Action /* ERwin Builtin %Datetime */
/* %Parent %VerbPhrase %Child ON PARENT DELETE CASCADE */
delete %Child
from %Child,deleted
where
/* %%JoinFKPK(%Child,deleted," = "," and") */
%JoinFKPK(%Child,deleted," = "," and")
В модели, приведенной выше для связи positions - salary_track будет сгенерирован следующий
прототип триггера:
DELETE /* ERwin Builtin Fri Jun 02 17:12:09 1995 */
/* positions приносила доход salary_track ON PARENT DELETE CASCADE */
delete salary_track
from salary_track, deleted
where
/* %%JoinFKPK(%Child,deleted," = "," and") */
salary_track.empl_id = deleted.empl_id
Все макрофункции, которые могут использоваться в триггерах, могут использоваться также и в
процедурах. Существенно, что процедуры, как и триггеры, связываются с таблицей.
Такой подход позволяет полностью исключить хаотичное внесение изменений в базу данных, так как
модель в ERwin описывает все аспекты базы, в том числе обеспечиваемые триггерами.
Программирование взаимодействия с серверами СУБД
NewEra поддерживает два способа программирования доступа к базам данных:
операторы встроенного SQL;
интерфейс библиотеки классов CCL (Connectivity Class Library).
Преимущества первого способа - простота и наглядность, совместимость с языком Informix-4gl;
однако, приложение, включающее операторы встроенного SQL, не может работать с СУБД,
отличными от Informix.
Интерфейс CCL - объектный интерфейс к базам данных, который обеспечивает открытость
приложений по отношению к используемым СУБД. Модули приложения, основанного на
интерфейсе CCL, обращаются при выполнении к одной из двух динамических библиотек,
поставляемых с Informix-NewEra (рис. 2):
CCL/Informix - реализует взаимодействие с базами данных Informix;
CCL/ODBC - реализует взаимодействие с произвольной СУБД через интерфейс ODBC.
Программный интерфейс
Основным программным интерфейсом SQLBase является SQL API - библиотека функций на языке
C, реализующая все возможности управления СУБД. Помимо базового интерфейса SQL API
существует большое количество программ и библиотек, реализующих собственные интерфейсы к
SQLBase. Среди них нужно прежде всего отметить SQLBase++ (библиотеку классов в стандарте
MFC), Borland Delphi и целый ряд языков и систем 4 поколения, включающих SQLWindows
(Gupta), PowerBuilder (Powersoft), Crystal Reports и Crystal Info.
Progress V.8: распределенные приложения на основе компонентного 4GL
Ю.Гусев, CSBI EE
Представляем инструментальные средства профессионального класса - PROGRESS (Copyright -
Progress Software Co., USA). Основные характеристики PR сравнимы (что-то чуть лучше, что-то
чуть хуже) с конкурентами (Oracle, Informix, Ingres, etc.), но по такому показателю как
удовлетворенность пользователя, по оценкам организации DATAPRO (USA), PR на первом месте
в течение 4 последних лет.
PROGRESS - полностью интегрированная среда разработки и применения приложений со своими
полностью реляционной СУБД, языком 4GL и встроенным SQL, средствами ускоренной
разработки, шлюзами (DataServers) к базам других популярных СУБД (Oracle, Rdb, RMS, DBF, Q-
ISAM, etc.), библиотеками для C, Pascal, COBOL. PROGRESS работает на огромном числе
программно-аппаратных платформ - от PC до mainframe с операционными системами MS-DOS,
OS/2, Novell, UNIX (SCO, Interactive, SunOS, A/UX, AIX, HP-UX, ULTRIX, etc.), VMS, C,
OS/BTOS, OS/400. PROGRESS поддерживает сетевые протоколы SPX/IPX, DECnet, TCP/IP,
NetBIOS, интерфейсы MS-Windows, X-Window (MOTIF, OpenLook), архитектуру клиент-сервер и
распределенные базы данных в сложных гетерогенных сетях.
PROGRESS version 8 - интернационализация и поддержка национальных алфавитов
Б.Меленевский, CSBI EE
Одним из основных требований к СУБД с точки зрения Открытых Систем является требование
адаптации к национальной информационной среде. При рассмотрении вопросов
интернационализации обычно выделяют три основные момента
Количество бит, используемых для представления символов 7 или 8.
Все ли ресурсы системы, связанные с поддержкой национальных
алфавитов (кодовые таблицы, системные сообщения) вынесены из ядра СУБД,
а их выбор достигается установкой соответствующих переменных окружения.
Поддержка всеми средствами разработки соответствующих настроек.
Кроме этого PROGRESS предоставляет уникальную возможность одновременной поддержки
нескольких языков в одном приложении, что позволяет использовать, разрабатываемые
приложения в странах с несколькими языками.
Производительность и масштабируемость
Microsoft SQL Server 6.0 имеет параллельную архитектуру, интенсивно использующую
многопоточность операционной системы для обеспечения высокой производительности и
масштабируемости на многопроцессорных системах. Все управление задачами SQL Server
организовано вытесняющим для повышения надежности и изолирования возможных сбоев. За счет
динамического распределения нагрузки на процессоры SQL Server достигает автоматической
балансировки загрузки всех ЦП компьютера. Microsoft называет это "симметричной архитектурой
сервера".
Производительность СУБД : измерение и оптимизация
(тезисы доклада)
А. Волков, журнал "СУБД"
Проблема измерения и увеличения производительности сложных программных систем, к числу
которых, конечно же, относятся и СУБД, всегда была сложной.
Доклад посвящен, большей частью, описанию методик измерения производительности СУБД,
систем оперативной обработки транзакций, систем поддержки принятия решений.
Первая часть доклада содержит краткое описание проблем, возникающих при измерении
производительности и описание подходов к построению квалифицированных методик
измерения.
Далее подробно рассматриваются тесты TPC (Transaction processing Performance Council - Совет по
производительности систем обработки транзакций), а также некоторые другие распространенные
методики измерения производительности.
При рассмотрении тестов TPC особое внимание уделено как наиболее распространенному в
настоящее время тесту TPC-C, предназначенному для измерения производительности систем
оперативной обработки транзакций, так и новым разработкам TPC - тестам TPC-D, TPC-E и TPC-
S, предназначенных для систем поддержки принятия решений и серверных компонентов системы.
В докладе не рассматриваются два наиболее широко известные теста, TPC-A и TPC-B, так как эти
методики считаются устаревшими и не поддерживаются TPC в настоящий момент.
Наиболее известные среди других рассматриваемых тестов, не относящихся к семейству TPC, -
тесты Wisconsin Benchmark и AS3AP.
Заключительная часть доклада посвящена краткому обзору основных подходов к улучшению
производительности СУБД, применимых к широкому спектру систем, и не зависимых от
конкретных продуктов.
Доклад не содержит данных по производительности конкретных систем по двум причинам. Первая
- эти цифры быстро изменяются и доступны широкому кругу заинтересованных специалистов.
Вторая, и, наверное, наиболее важная - необходимо отчетливо представлять, что означают эти
цифры и как их использовать при разработке конкретных систем.
[]
[]
[]
Протокольные службы
Библиотеки Sybase обеспечивают работу серверных и клиентских компонент со множеством
сетевых протоколов от разных производителей, в том числе TCP/IP, SPX/IPX, Named Pipes,
DECNet и другие.
Архитектура Sybase позволяет как приложению-клиенту, так и серверу одновременно работать с
несколькими интерфейсами. Например, SQL Server для Novell NetWare или Windows NT может
одновременно допускать соединения через SPX и TCP/IP.
Сводные особенности SQL Server 11 приведены на рис. 7.
| Быстрый ввод/вывод Разделение областей данных Параллельная загрузка (BCP) Опережающее считывание Много буферов кэша Обновления на месте Удобство пользования Новый интерфейс конфигурирования Простой Upgrade от 1.0 Атрибуты объектов Анализатор кэшей | Баланс загрузки Локализация кэшей Симметричная работа с сетью Симметричное управление блокировками Улучшенный менеджер транзакций Оптимизатор запросов Эффективное ведение журнала Раздельные кэши для журналов Задача - House Keeper Большое адресное пространство Более 2 Гигабайт адресуемой памяти (на DEC UNIX и др.) |
Протоколы
SQLBase осуществляет поддержку практически всех распространенных сетевых протоколов,
включая IPX/SPX для NetWare, NetBIOS, NetBEUI, Named Pipes и TCP/IP (Windows Sockets) для
Windows NT и OS/2. Для Windows 95 и Windows NT фирма Gupta разработала новый 32-
разрядный протокол обмена данными Anonimous Pipes для эффективной работы с локальным
сервером SQLBase в этих средах. Кроме этого, SQLBase поддерживает технологию SNMP, что
позволяет эффективно управлять сервером баз данных в сложных распределенных сетях под
управлением Novell NetWare. Новая версия SQLBase, которая находится сейчас в стадии Бета-
тестирования и будет выпущена в продажу в конце января, будет включать поддержку протокола
TCP/IP для NetWare.
SQLBase поддерживает стандартный интерфейс связи с базами данных в среде Windows ODBC.
Драйвер ODBC входит в комплект каждого сервера SQLBase.
Проверка правильности спроектированной модели
Данная возможность связана с тем, что проектирование в S-Designor можно выполнять в
свободном порядке. Например, проектировать сначала сущности и связи, потом атрибуты сущностей.
Такой подход в ряде случаев удобен и возможен потому, что S-Designor ведет общий словарь
данных, используемых в модели. При проверке правильности структуры объектов (в основном
сущностей и взаимосвязей между ними), S-Designor формирует протокол об ошибках, в
котором содержится полная идентификация ошибок в модели данных.
Проверка взаимных блокировок
SQL Server использует алгоритм выявления взаимных блокировок транзакций. Имеется
возможность сконфигурировать то время, через которое выполняется такая проверка. Время
задается в миллисекундах, от 500 мс. Цель конфигурирования этого параметра - повышение
производительности. Проверка взаимоблокировок - это достаточно длительная операция для
сервера. Так как проверка запускается не сразу, выше вероятность освобождения ресурса к
моменту запуска проверки. С другой стороны, излишнее увеличение времени задержки может
привести к увеличенному времени реакции для приложения, выдавшего взаимоблокирующий
запрос.
Работа c источником данных в виде пакета SQL- предложений (DDL)
Данная возможность позволяет проектировать структуру данных и выполнять генерацию SQL-
предложений не подключаясь к SQL-серверу. Генерация пакета SQL-предложений выполняется в
обычный текстовый файл. На основании содержимого файла можно выполнить обратное
проектирование - создать модель данных. Практическая польза - своеобразная "отладка" модели
данных. Это дает возможность лишний раз убедиться в правильности действий, предполагаемых
выполнить с реальной структурой БД. Поскольку, в данном случае нет необходимости подключаться
к серверу БД - проектирование можно выполнять автономно. Например, в домашних условиях, если у
Вас дома нет SQL-сервера.
Работа SQL Server с кэшами в памяти
Запись в журнал из кэша теперь происходит пакетами. Это снижает уровень конкуренции за доступ
к ресурсу журнала и, соответственно, повышает производительность (рис.5).
 | BEGIN UPDATE UPDATE UPDATE INSE RT COMMIT |  |
|
Записи передаются в журнал пакетами Уменьшается уровень конкуренции за доступ к ресурсу журнала |
Расчет необходимой внешней памяти под БД
Вычисление размера БД выполняется на основе указанного предполагаемого количества строк в
таблицах. Данная возможность является достаточно важной, так как позволяет уже на этапе
проектирования оценить необходимый объем внешней памяти на сервере. Соответственно, легко
вычислить, какой объем внешней памяти потребуется через определенное время, скажем через год.
Для этого, зная предполагаемые темпы роста объема данных, можно спрогнозировать примерное
количество записей в таблицах БД к этому времени и выполнить автоматический расчет.
Распределенная обработка и доступ к данным средствами Sybase OmniConnect
В различных узлах предприятия используются базы данных от разных производителей. Например,
в системе принятия решений это может быть Sybase, а в геоинформационной системе - Oracle.
OmniConnect осуществляет унифицированный доступ приложений к разнородным источникам
данных. Специальные шлюзовые компоненты организуют работу в системе с любой
промышленной СУБД, включая Oracle, Informix, Ingres, DB/2, RMS, ISAM. Приложения-клиенты
при этом работают только с сервером OmniConnect на диалекте SQL фирмы Sybase (TransactSQL),
а необходимая трансляция языка SQL и преобразование типов данных автоматически
осуществляется шлюзовыми модулями.
Для работы с хранилищами данных на "больших" ЭВМ (mainframe) Sybase поставляет также
продукцию фирмы Micro Decisionware - лидера на рынке промежуточного ПО (Sybase купила
фирму MDI в начале 1994 года). MDI предоставляет шлюзы в DB/2, SQL/DS, SQL/400, в том числе
через IBM DRDA-интерфейс.
OmniConnect хранит информацию о размещении таблиц на том или ином сервере БД.
Централизованно хранятся и исполняются глобальные хранимые процедуры. Приложение-клиент
может осуществлять транзакции, в которых участвуют таблицы из различных БД, а также
выполнять процедуры, которые OmniConnect при работе с СУБД, отличными от Sybase,
прозрачно преобразует к соответствующему диалекту SQL.
Распределенное приложение (серверы приложений)
Характерной чертой таких приложений является логическое разделение приложения на две или
более частей, каждая из которых может выполняться на разных компьютерах. Выделенные части
приложения взаимодействуют друг с другом, обмениваясь сообщениями в заранее
согласованном формате. Следует подчеркнуть, что в данном случае клиентом может быть не
только Windows-приложение, но и приложение (или его часть), выполняемое на одной из платформ
СЭВМ.
Для создания среды выполнения распределенных приложений SOFTWARE AG предлагает
использовать продукт ENTIRE BROKER, который может быть установлен на платформе любой
СЭВМ (IBM, UNIX и т.д.) изолированно (рис. 4) или на одной или
нескольких СЭВМ совместно с серверами приложений.
 | |||
| Windows PC | UNIX | IBM | OS/2, NT |
Расширение возможностей языка и программного доступа
Существующая версия SQL Server снабжена мощным языком программирования -Transact-SQL,
позволяющим создавать сложную логику триггеров и хранимых процедур. В новой версии язык
значительно расширен, теперь он соответствует стандарту ANSI-92, и программисты получили
новые возможности (такие как новые, соответствующие ANSI-стандарту, типы данных и
соответствующая стандарту ANSI поддержка декларативной целостности данных). Помимо
перечисленных возможностей, программист может воспользоваться генератором, автоматически
создающим уникальные значения для ключевых полей таблицы, возможностью передавать
идентификаторы и данные типа TEXT и IMAGE как параметры хранимым процедурам и многое
другое. Использование хранимых процедур, которые запускаются автоматически при каждом
старте SQL Server, позволяет создавать системы, способные выполнять различного рода задания
без участия администратора. Наиболее же интересным нововведением являются скроллируемые,
двунаправленные курсоры. Курсоры SQL Server поддерживают все режимы, определенные
расширенными требованиями ANSI, а также и ODBC семантику; они совместимы с
существующими курсорами, поддерживаемыми API в DB-Library.
Расширение возможностей языка сервера
В языке PL/SQL появились объекты типа таблица (группа однотипных полей или структур
(таблица записей)). Программист может использовать функции FIRST, LAST, NEXT, PRIOR,
COUNT, EXISTS, DELETE при работе с таблицей PL/SQL. Новый пакет ULT_FILE
расширяет язык PL/SQL функциями для работы с файлами операционной системы сервера. Файлы
можно создавать, читать, писать. Появилась возможность работать с частями полей типа LONG.
Теперь можно формировать это поле по частям с помощью нескольких операторов SQL.
Например, ограничения операционной системы на размер буфера не более 64К не будет теперь
ограничивать размер информации в LONG поле. Возможно и чтение этого поля по частям.
В версии 7.3 появилась еще одна модель деактуализации зависимых удаленных процедур (RPC).
В старой модели (она тоже поддерживается) любое изменение хода хранимой процедуры
или функции вызывало деактуализацию и дальнейшую перекомпиляцию всех зависимых от нее
хранимых процедур. Это вело к большому числу ненужных компиляций и снижало
производительность. Дополнительная модель позволяет деактуализировать зависимые процедуры
только в том случае, если у изменяемой процедуры изменилось имя или число и тип параметров.
Расширенные возможности масштабирования и высокая производительность
Особое внимание, которое было уделено повышению производительности СУБД, позволило
повысить скорость выполнения некоторых операций почти на 400% на многопроцессорных
компьютерах. Это достигается активным использованием многопроцеcсорной архитектуры
компьютера и многопоточной архитектуры операционной системы. Среди операций,
выполняющихся параллельно, можно назвать сканирование таблиц, загрузку,
создание/восстановление страховочной копии. Все это позволяет обеспечить
высокопроизводительную работу с большими и очень большими базами данных.
Разработка и внедрение системы автоматизации большого авиагрузового терминала
В. Ляшков, ФОРС
Немного о заказчике
AО "Шереметьево-Карго" - одно из крупнейших авиатранспортных предприятий в Российской Федерации, предоставляющее услуги по организации перевозки, обработке и экспедированию грузов по транспортным маршрутам России и за ее пределами.
Предприятие является официальным грузовым агентом IATA, имеет лицензию Общероссийского таможенного перевозчика, является членом Ассоциации Международных автоперевозчиков (АСМАП), декларантом на договорной основе (таможенным брокером).
АО "Шереметьево-Карго" имеет собственную сеть агентств во Франции, Германии, Италии, взаимодействует со многими аналогичными иностранными фирмами. Оно развивает и эксплуатирует крупнейший в России грузовой таможенный терминал с пропускной способностью 550 тысяч тонн груза в год, грузовой автопарк, обеспечивает продажу грузовых авиаперевозок ведущих авиакомпаний мира, организует смешанные перевозки по РФ.
Шереметьево-Карго является крупным предприятием, на котором работает более 1500 человек, обрабатывающих до 3000 накладных и грузов по ним в сутки. Режим работы предприятия - круглосуточный.
В настоящее время АО функционирует в условиях бурного развития транспортного бизнеса, происходящего на фоне изменения законодательства в стране и быстрого развития транспортных технологий. Являясь лидером среди организаций подобного рода, АО непрерывно развивает и совершенствует свои технологии.
Область применения автоматизированных систем на терминале
Первоочередной задачей системы автоматизации терминала является обслуживание основного технологического цикла обработки грузов. Цикл состоит из следующих технологических процессов: ИМПОРТ, ЭКСПОРТ и ТРАНЗИТ.
ИМПОРТ включает в себя выгрузку груза из самолета, доставку его на склад, раскомплектацию груза , проведение таможенных операций и размещение груза на складе. Далее следует извещение получателя о прибывшем грузе, опять таможенные операции и наконец выдача груза со склада клиенту. Попутно возможно оказание получателю разнообразных услуг, за которые следует выставлять счета и контролировать их оплату.
ЭКСПОРТ начинается с продажи перевозки отправителю груза, бронирования перевозки, выпуска договора перевозки - авианакладной, получения оплаты, приема груза на склад при участии таможни. Далее, за некоторое время до вылета рейса начинается селекция и комплектация груза на рейс, доставку его со склада к борту самолета и его загрузка.
ТРАНЗИТ является совокупностью первых двух процессов, зачастую с добавлением ряда промежуточных операций.
Основные технологические процессы сопровождаются рядом поддерживающих процессов:
Ведением расписания и отслеживанием графика выполнения техпроцессов;
Отслеживанием состояния и подготовкой авиационной тары;
Оказанием разнообразных услуг клиентам, начислением оплаты и отслеживанием платежей;
Поддержкой функционирования разветвленного складского хозяйства (это называется модным термином складская логистика);
Выяснением неисправностей при перевозках, в том числе розыск груза и идентификация груза без маркировки.
Все процессы обработки груза и взаимодействия со всеми заинтересованными сторонами сопровождаются интенсивным потоком документов. Основные взаимодействующие с грузовым терминалом стороны таковы:
Отправители и получатели груза;
Авиакомпании - перевозчики;
Таможня.
Очевидно, что столь многофункциональная деятельность невозможна без применения современных информационных технологий и автоматизированных систем. Применение таких систем позволяет уменьшить сроки и повысить качество обработки грузов. Это достигается благодаря более полному контролю исполнения технологического цикла и уменьшению потерь и нарушений при обработке груза.
Что предшествовало началу разработки
Опыт применения информационных систем в Шереметьево-Карго довольно давний. С 1985 г в АО работает информационная система SIGMA, французского производства на ЭВМ MITRA с сетевой СУБД типа CODASYL и программным обеспечением, написанным на COBOL.
Эта система эксплуатируется до последнего времени и обслуживает 100 одновременных on-line пользователей, 20 типов рабочих мест.
С 1985 года прошло уже более 10 лет и к настоящему моменту система SIGMA по ряду параметров перестала удовлетворять АО.
Во-первых, такое оборудование, как и запасные части для него уже давно не выпускают, что приводит к регулярным сбоям и аварийным остановам системы, приносящим большие убытки.
Во-вторых, программное обеспечение не удовлетворяет требованиям по сохранению данных в результате сбоев оборудования, и кроме того обладает рядом ограничений на объемы используемых данных.
В-третьих, развитие транспортных технологий потребовало расширения функциональности программного обеспечения, а используемая технология не позволяет гибко и быстро модифицировать устаревшие программные единицы или добавлять новые.
В-четвертых, система SIGMA морально устарела.
Было принято решение о необходимости перехода на новую систему.
В процессе анализа ситуации варианты закупки зарубежной системы или разработки собственными силами были отвергнуты как нереальные, и был сделан вывод о необходимости разработки новой системы силами российских разработчиков.
Основные требования к процессу разработки новой информационной системы и ее свойствам формулировались следующим образом:
Для построения информационно-функциональной модели предприятия обязательно использовать CASE-инструментарий. Эту модель предполагалось использовать далее при реорганизации предприятия и разработке требований к другим информационным системам, а также использовать ее для поддержки жизненного цикла и дальнейшего развития разрабатываемой системы.
Применять CASE-методологию при разработке системы на всех этапах.
Использовать мощную современную СУБД, обеспечивающую управление большими объемами данных и современный уровень защиты данных от сбоев.
В связи с тем, что предполагаемый срок жизни системы составляет 10-15 лет, применяемое системное программное обеспечение должно иметь высокий уровень мобильности и масштабируемости и быть от лидирующего поставщика.
Число одновременно работающих пользователей в системе - 150.
В начале 1994 года АО "Шереметьево-Карго" провело тендер, который совместно выиграли фирмы Интегпрог и ФОРС. Предполагалось, что вопросами поставки аппаратных средств и системной интеграцией занимается Интегпрог, а программное обеспечение разрабатывает ФОРС.
В качестве аппаратного решения был предложен сервер AViiON фирмы Data General с архитектурой SMP и операционной системой DG-UX. Сетевая среда - Ethernet.
Основными оконечными устройствами пользователя являются символьные терминалы, подключенные к терминальным серверам.
В качестве СУБД предложен ORACLE7, как полностью отвечавший требованиям заказчика.
Средством проектирования избран Oracle CASE 5.0 в силу его высокой интегрированности со средствами разработки, поддержкой многопользовательской работы и всего цикла разработки системы.
Основными средствами разработки были предложены SQL*Forms 3.0 и SQL*Menu 5.0, хорошо зарекомендовавшие себя при работе в символьном режиме.
Длительность проекта по разработке прикладного программного обеспечения была установлена в 22 месяца, из которых 6 месяцев выделялось на анализ требований и проектирование, следующие 10 месяцев - генерацию и кодирование, и еще 6 месяцев - тестирование и внедрение.
Как проходила разработка
Работы начались и проводились в полном соответствии с идеологией CASE*METHOD.
Для анализа требований и проектирования в ФОРСе была образована группа под руководством опытного аналитика, ранее работавшего с Oracle CASE. После завершения анализа, на этапе проектирования, планировалось передать дела группе разработчиков.
Заказчиком, АО "Шереметьево-Карго" и системным интегратором были организованы группы по надзору за исполнением проекта.
Большим плюсом было то, что заказчик располагает как квалифицированными бизнес-аналитиками, хорошо представляющими себе используемые технологии обработки грузов, так и опытными компьютерными специалистами, обслуживающими старую систему SIGMA.
Анализ требований проводился в тесном сотрудничестве с бизнес-аналитиками и системными программистами заказчика.
Были сданы и подписаны результаты стадий стратегии и анализа.
Началась стадия проектирования, которая неожиданно затянулась, поскольку результаты работ не утверждались заказчиком. Нормальные рабочие отношения между сотрудничавшими ранее группами заказчика и исполнителя стали напряженными. Отставание работ от плана становилось значительным, уже должен был давно начаться этап программирования.
В это время, на десятом месяце проекта, как и планировалось, к работам по данному проекту была подключена наша группа разработчиков.
Ситуация требовала быстрого анализа и принятия решений по поводу дальнейшей разработки, так как конечные сроки завершения проекта не могли быть изменены.
Изучение ситуации показало, что обследование и анализ предметной области были проведены с достаточной полнотой, собрано и структурировано много материала. В репозитарии Oracle CASE существовала достаточно подробная ER-модель, пригодная для разработки базы данных. Имелось пригодное для кодирования описание автоматизируемых функций, которое однако содержалось в файлах MS Word!
При этом между группами исполнителя и заказчика существовали расхождения по числу и объему функций, подлежащих автоматизации. Представители заказчика выражали тревогу по поводу отсутствия работающих программ.
Часть проблем возникла из-за отличия западной и российской культур разработки информационных систем. Развивавшаяся десятки лет советская школа разработки информационных систем выработала отличные от западной подходы, терминологию, этапность, документацию. Это все регламентируется государственными стандартами.
В CASE*Method названия этапов и их продолжительность, а также состав работ не совпадают с требованиями российских стандартов
По российским стандартам существенно короче этап анализа требований, а проектирование и кодирование как правило резко не разделяются.
Естественно, не получив после этапов Strategy и Analysis ни одного знакомого документа, заказчики заволновались.
К тому же CASE 5.0 не был русифицирован.
Можно представить себе состояние руководителя, ожидающего получить проектные документы, а ему в третий раз приносят документ, относящийся к анализу требований, имеющий непонятное название и на 90% содержащий английский текст!
Вот откуда и появились описания функций в MS Word... Соответственно, информационная модель оказалась отрезанной от описания функций и ни о какой генерации системы речи идти не могло.
Другая часть проблем возникла из-за нечетко очерченных в начале анализа требований границ системы. Одной из главных причин этого являлось отсутствие одинаково трактуемого всеми документа, фиксирующего эти границы.
Остальные проблемы возникли из-за совмещения должностей начальника проекта и главного аналитика в группе исполнителя. Такое совмещение в данном проекте не позволило уделять достаточно времени контактам с руководством заказчика и разъяснению применяемых подхода и методов.
Положение следовало исправлять.
В приступившей к работе группе разработки руководитель сосредоточился на доработке бизнес-модели, подготовке документов, общении с заказчиками и оперативном управлении. Был также назначен главный программист, ответственный за групповую разработку базы данных и приложений.
В то же время началась активная работа в области обучения заказчика технологиям Oracle, которая продолжается по сей день.
Поскольку огромное количество подготовленного материала не воспринималось заказчиком как нечто документальное, то сразу началась подготовка Технического Задания - привычного заказчику документа, фиксирующего границы системы.
Одновременно началась разработка базы данных на основе существующей информационной модели. В этой связи был осуществлен переход на Designer 2000, обладающий мощными возможностями моделирования данных. Такой переход полностью себя оправдал. Богатая функциональность Data Diagrammer'а и поддержка групповой работы позволили быстро получить приемлемую схему базы данных, а его хорошие презентационные возможности - успешно представить ее заказчику.
По прошествии четырех недель было подписано Техническое Задание и заказчик был ознакомлен со схемой базы данных. Напряжение заметно спало, стало налаживаться конструктивное сотрудничество.
Следующим шагом было начато программирование по уже имеющимся согласованным спецификациям. Для этого была применена технология вертикального слоения программного продукта, которая подразумевает выделение и реализацию некоторого ядра - набора программных компонент, обеспечивающих всю необходимую обработку входных данных, но не всех, а некоторой выделенной их части. Далее по известной технологии вносятся рассредоточенные изменения в реализованные программные компоненты, добавляющие новый вертикальный слой. Это позволяет расширить набор входных данных. И так далее.
По имеющимся спецификациям было выделено ядро системы, реализующее идеальный технологический цикл авиационного грузового комплекса. В ядре были выделены непересекающиеся технологии на соответствующих наборах данных. Был составлен план-график внесения дополнений в программное обеспечение. Для этого была пересмотрена этапность работ с сохранением срока окончания проекта.
Одновременно началась подготовка Технического Проекта, составной частью которого должна была стать функциональная модель, разработанная средствами Designer 2000. Улучшенные презентационные возможности и поддержка русского языка позволили успешно сотрудничать в создании функциональной модели предприятия.
Принятые решения привели к желаемым результатам. Программное ядро системы было досрочно установлено у заказчика и позволило начать комплексные испытания по всему технологическому циклу на ограниченных наборах входных данных, хотя объем закодированных функций составлял не более 35-40% от конечного.
Официальные комплексные испытания ядра программного обеспечения были проведены через шесть месяцев после подписания Технического задания. После этого последние сомнения у заказчика отпали.
Официальные комплексные испытания всего программного обеспечения начались еще через два месяца и проходили в три этапа в течение трех месяцев.
Испытания проводились на опытном стенде заказчика силами специально подготовленных пользователей.
Испытания были закончены в тот срок, который намечался для завершения проекта. Предстояла опытная эксплуатация.
Как проходит внедрение
На этом этапе предстояло решить ряд достаточно сложных задач:
Установить промышленный сервер и сконфигурировать его;
Развернуть сеть рабочих мест по всему предприятию;
Провести полное обучение и аттестацию всех пользователей системы;
Наладить функционирование новой системы в режиме параллельной работы со старой;
Провести приемку программного обеспечения, исходных текстов и документации.
Для этого были разработаны два документа под названием "Программа опытной эксплуатации" и "Концепция плавного перехода", определяющие этапы развертывания новой системы и постепенного перехода со старой системы на новую.
Программой опытной эксплуатации предусматривались три последовательных режима работы относительно старой системы:
Асинхронный режим, когда работа по конкретным документам в новой системе происходила независимо от старой системы;
Синхронный режим с неполными данными, когда данные вводятся в старую и новую систему одновременно, но в новую систему вводятся не все данные по документу;
Полный синхронный режим с параллельным вводом данных.
Обмен данных между системами не предусматривался.
Предполагалось, что при синхронных режимах объем данных, вводимых параллельно в обе системы составит 10-15% общего объема данных, вводимых в старую систему.
Указанные выше режимы работы новой системы вводились последовательно для каждого типа рабочих мест, согласно плана-графика развертывания рабочих мест. Первыми вводились рабочие места, обслуживающие процесс ЭКСПОРТ, затем - ИМПОРТ.
На первом этапе опытной эксплуатации рабочие места процесса ЭКСПОРТ подключались к опытному стенду и находились в асинхронном режиме работы.
Через два месяца был установлен промышленный сервер, к нему были подключены уже развернутые рабочие места процесса ЭКСПОРТ и началось развертывание и подключение рабочих мест процесса ИМПОРТ.
Для процесса ЭКСПОРТ был введен неполный синхронный режим, а для процесса ИМПОРТ - асинхронный.
В настоящее время, после семи месяцев опытной эксплуатации:
Установлены и подключены к промышленному серверу все рабочие места системы;
Рабочие места процесса ЭКСПОРТ функционируют в полном синхронном режиме, причем объем вводимых в новую систему данных составляет 50% всех данных по процессу ЭКСПОРТ;
Рабочие места процесса ИМПОРТ находятся в неполном синхронном режиме и функционируют с запланированной нагрузкой;
Идет аттестация пользователей системы;
Идет приемка программного обеспечения и документации системы.
Далее обсуждается ряд вопросов, которые представляют на наш взгляд определенный интерес:
Применение зарубежных методологий разработки в российских условиях;
Влияние существующей автоматизированной системы на процесс разработки и внедрения;
Обеспечение безболезненного перехода со старой системы на новую;
Реальный уровень затрат заказчика при разработке большой системы.
О применении зарубежных методологий разработки программных
систем в российских условиях
В данном разделе мы ограничимся обсуждением методологии CASE*METHOD (Classic и Fast Track) и инструментария Designer/2000.
Как известно, классические CASE-методологии разрабатывались с целью уменьшения риска в процессе выполнения проекта. Считалось, что если готовое программное обеспечение не удовлетворяет пользователя, то это результат упущений при постановке задачи. Следствием этого подхода стало увеличение времени, отведенного на стадии анализа и чистого проектирования, а программирование стало считаться чисто техническим этапом работ. На протяжении всего проекта генерируется мощный поток документов о ходе работ, в основном Progress Reports, призванных убедить заказчика, что работы идут нормально. Работы ведутся линейно, итеративность не приветствуется. Пользователь привлекается к работам в основном на этапах анализа и внедрения. Примером реализации такой методологии является ORACLE CASE*METHOD Classic.
Однако жизнь показала, что линейная неитеративная схема с большими сроками постановки задач в некоторых ситуациях неработоспособна. Это следующие ситуации:
За время выполнения проекта изменяются требования заказчика к функционированию системы;
Невозможно получить постановку задачи от пользователя, предварительно не показав ему, как программа может работать;
Заказчик не может понять, почему столько времени и денег уходит на написание бумаг, которые не приносят ему непосредственной пользы (чисто русская ситуация).
Поэтому в последнее время получили распространение методы Rapid Application Development (RAD), предполагающие:
Относительное уменьшение времени на чистую (бумажную) постановку;
Принципиальное допущение итеративности разработки, с коррекцией требований;
Непосредственное интенсивное взаимодействие разработчиков с пользователями на протяжении всего проекта;
Жесткое соблюдение временных рамок работ при регулярно проводимой приоритезации требований, позволяющей добавлять более приоритетные новые требования в обмен на менее приоритетные старые.
Примером такой идеологии является ORACLE CASE*METHOD Fast Track.
Если рассмотреть требования российских ГОСТов в сравнении с классическим CASE*METHOD, то получится следующее:
| Strategy | Техническое задание |
| Analysis | Технический проект |
| Design | |
| Build | Рабочая документация |
| Transition,Documentation | |
| Production | Ввод в действие |
Как видно, по российским стандартам существенно короче этап анализа требований, а проектирование и кодирование как правило резко не разделяются. Этим российская традиция близка к RAD-методам.
Однако наши ГОСТы также не приветствуют итеративность и к тому же требуют в Техническом проекте описания всех форм и отчетов системы, а также подробного описания алгоритмов, что близко к классическому CASE.
ORACLE Designer/2000 поддерживает как Classic, так и Fast Track, однако при его применении необходимо учитывать следующее:
Генерируемая с его помощью документация как правило не русифицирована;
Состав и структура этой документации крайне непривычны русскому заказчику, в частности, не содержат пространных описаний;
Генерация исполняемых модулей до сих пор является в основном декларируемой возможностью и по большей части бесполезна, а это значит, что диаграммеры верхнего уровня пригодны только для задач презентации результатов, но никак не для построения программной системы;
Средства разработки серверной части полностью поддерживают групповую работу и полезны на любом уровне общности.
Реально работающая методология является разумным компромиссом между этими подходами и при использовании Designer/2000 может выглядеть примерно так:
На этапе постановки задачи составляются "Описание технологического процесса", снабженное всеми видами диаграмм от Designer/2000 (используются диаграммеры верхнего уровня) и Техническое задание, задающее, в том числе, границы системы. Эта работа выполняется аналитиками. В ней обязательно участвует главный программист проекта.
Далее идет этап интерактивной разработки, выполняемой программистами-разработчиками. На этом этапе происходит уточнение требований и, при необходимости, их изменение. Работа ведется в непосредственном контакте с пользователями. На этом этапе используются диаграммеры нижнего уровня Designer/2000 и выбранные средства разработки. Технический проект не разрабатывается, однако принципиальные вопросы регулируются отдельными документами (например требования к интерфейсу пользователя, взаимодействие с внешними системами и т.д.). Этот этап заканчивается испытаниями системы и подготовленной к испытаниям предварительной документацией.
Далее идет этап опытной эксплуатации, на котором также готовится эксплуатационная документация и описание системы.
Крайне желательно суметь разделить систему на части, запускаемые в опытную эксплуатацию в разное время, поскольку работающая часть системы весьма стимулирует активность и решимость заказчика, направленные на введение в действие всей системы. Если не удается выделить сравнительно независимые части системы, то следует воспользоваться методом вертикального слоения, выделив некоторое ядро.
Влияние существующей системы на разработку и внедрение новой
Это влияние имеет как положительные, так и отрицательные стороны.
Положительным является то, что у заказчика есть работающий коллектив по поддержке системы, а пользователи обучены воспринимать работу с компьютерным оборудованием как необходимую часть техпроцесса. Немаловажно также, что руководители заказчика представляют себе выгоды, связанные с наличием работающей системы.
Отрицательное влияние старой системы особенно ярко проявляется в следующих моментах (особенно, если система является важной частью технологического процесса):
При определении границ системы заказчик будет настаивать на том, чтобы новая система как минимум исполняла ВСЕ функции старой, даже если в новой системе нет в них необходимости;
Пользователи, привыкшие к старому (даже неудобному) интерфейсу, воспримут новый интерфейс, как правило, в штыки. Например, в начале автономного тестирования модулей ядра обнаружилось сильное неприятие пользователями интерфейса, обеспечиваемого SQL*Forms 3.0. Тому виной были большое количество используемых функциональных клавиш, сложность навигации по экрану и некоторые другие особенности.
В связи с этим был разработан документ, регламентирующий вид пользовательского интерфейса для разрабатываемой системы. Согласование данного документа с заказчиком длилось более трех месяцев! В результате разработчикам в ряде случаев пришлось систематически применять нестандартные для SQL*Forms приемы программирования.
Выводы можно сделать такие:
Еще на этапе разработки Технического задания, до его подписания, необходимо тщательно изучить старую систему на предмет ее функциональности и интерфейса;
В это же время необходимо начать разъяснительную работу среди руководителей и обучение персонала новым технологиям. Упущенное здесь время все равно потом добавится (причем в гораздо большем количестве) к общей длительности проекта.
При составлении Технического задания необходимо представить сравнение функций старой и разрабатываемой систем, с тем, чтобы не возвращаться к этому позже (скажем, на этапе приемки).
Обеспечение безболезненного перехода со старой системы на новую
В данном разделе представлены основные положения документа под названием "Концепция плавного перехода", регулирующего вопросы безболезненного перехода со старой системы на новую. Данный документ является совместным трудом заказчика и обоих разработчиков системы. Он разрабатывался и согласовывался в течение шести месяцев.
Основные положения:
Процесс замены оборудования должен быть разнесен по времени с переходом на новую прикладную информационную систему;
Переход на новую систему должен быть поэтапным и однонаправленным, возврат к старой системе недопустим;
Автоматизированного обмена данными между системами не предусматривается;
В целях минимизации риска и уменьшения накладных организационных расходов необходимо обеспечить:
- минимальное пересечение по данным в старой и новой системах;
- минимальное число работников, переходящих на новую систему на каждом конкретном этапе;
- минимальное число участков и подразделений, переходящих одновременно на новую систему;
- минимальное число одновременно вводимых новых функций.
Такой подход оказывается возможным потому, что среднее время жизни 80% актуальных данных в системе (за исключением справочников) составляет две недели, поэтому время одновременной промышленной работы двух систем сравнительно невелико. Следовательно нет необходимости в автоматизированном обмене данными между системами.
План-график плавного перехода предусматривает сначала переход всего процесса ЭКСПОРТ на новую систему в течение недели.
Процесс ИМПОРТ переводится на новую систему поэтапно, по подразделениям, обслуживающим рейсы на те или иные направления
Реальный уровень затрат заказчика при разработке большой системы
Общеизвестно, что затраты заказчика при разработке большой автоматизированной системы не ограничиваются оплатой работы исполнителя. Ниже приведен список работ, проводимых руководством и специалистами заказчика:
Постановка задачи, выяснение, реинжиниринг и согласование технологии;
- Сбор и предоставление всей необходимой информации для разработки;
- Подготовка целевого вычислительного комплекса (опытного участка) для проведения работ на своей территории;
- Выбор технических средств промышленного вычислительного комплекса;
- Разработка программ испытаний, проведение автономных и комплексных испытаний;
- Разработка программы опытной эксплуатации, слежение за процессом опытной эксплуатации, отслеживание сбойных ситуаций, информирование разработчика, установка обновленных версий программного обеспечения;
- Обучение персонала, как силами учебных центров, силами исполнителя, так и силами подготовленных специалистов заказчика, подготовка программ обучения и аттестация пользователей;
- Разработка основных положений концепции перехода предприятия на новую систему автоматизации, включая планы-графики развертывания технических и программных средств;
- Осуществление собственно перехода на новую систему
Нагрузка на руководство и персонал заказчика резко увеличивается с момента подготовки к испытаниям и начинает уменьшаться только после ввода системы в промышленную эксплуатацию, причем этот процесс захватывает большинство персонала. Поэтому, чем длительный процесс внедрения, тем больше скрытых затрат несет заказчик, следовательно необходимо добиваться минимальной длительности этапов опытной эксплуатации и перехода на новую систему. Это известный факт, но его нелишне напомнить.
[]
[]
[]
Развитие системы
SILVERRUN постоянно развивается. Регулярно выпускаются новые версии системы и постоянно
обновляются мосты, что позволяет работать с самыми последними версиями поддерживаемых продуктов.
Динамичность развития системы показывает, что SILVERRUN находится на передовом рубеже среди
высокотехнологичных систем.
Дистрибутором методологии DATARUN и CASE-системы SILVERRUN в СНГ является фирма
АРГУССОФТ. Она обеспечивает техническую поддержку и обучение пользователей.
[]
[]
[]
Реализация ссылочной целостности с помощью ERwin
Ссылочная целостность - это обеспечение требования, чтобы значения внешнего ключа экземпляра
дочерней сущности соответствовали значениям первичного ключа в родительской сущности.
Ссылочная целостность может контролироваться при всех операциях, изменяющих данные
(INSERT/UPDATE/DELETE). Средства контроля ссылочной целостности в ERwin включают
автоматическую генерацию триггеров и использование механизмов декларативной ссылочной
целостности (для тех СУБД, которые поддерживают данные механизмы).
Для каждой связи на логическом уровне могут быть заданы требования по обработке операций
INSERT/UPDATE/DELETE для родительской и дочерней сущности. ERwin представляет следующие
варианты обработки этих событий:
отсутствие проверки;
проверка допустимости;
запрет операции;
каскадное выполнение операции (DELETE/UPDATE);
установка пустого (NULL-значения) или заданного значения по
умолчанию.
В соответствии с выбранным вариантом ERwin автоматически создает необходимые триггеры на
диалекте SQL целевой СУБД. При этом ERwin пользуется библиотекой шаблонов триггеров, которые
можно модифицировать.
При генерации структуры базы данных триггеры, обеспечивающие ссылочную целостность могут
быть переопределены на трех уровнях:
Могут быть переопределены триггеры, обеспечивающие правила для всей модели.
Могут быть переопределены триггеры, указанные для конкретной связи.
Могут быть переопределены триггеры, указанные для конкретной таблицы.
Тип переопределения указывается разработчиком при генерации схемы базы данных
