История и перспективы развития СУБД Progress

История и перспективы развития СУБД Progress............................................................................ 1
Особенности СУБД Progress.............................................................................................................. 2
Структура ПС Progress ....................................................................................................................... 4
Состав средств разработки прикладных программ ......................................................................... 5
Функционирование Progress в локальной сети. ............................................................................ 14
Файлы баз данных СУБД Progress и ............................................................................................... 16
их размещение на магнитных носителях. ....................................................................................... 16
Защита от ошибок и восстановление БД. ....................................................................................... 19
История и перспективы развития СУБД Progress.
Фирма Progress Software Corporation(PSC) была основана в
декабре 1981 года. Первоначальной целью разработки было
создание быстрых средств разработки и удобного сопровождения
для микро-ЭВМ, использующих ОС UNIX, учитывалась
необходимость легкой масштабируемости прикладных программ и
баз данных, а также повышенной надежности за счет специальных
методов обработки транзакций. Progress изначально разрабатывался,
как многопользовательская СУБД.
Первыми годом выпуска завершенных программных средств
является 1985. Наличие таких средств как развитый язык 4GL,
специально ориентированный на разработку баз данных, словарь
данных для описания БД и реляционная СУБД, реализованные по
единой методике и с единых позиций обеспечили уже первым
версиям Progress исключительную производительность, гибкость в
разработке приложений и удобство сопровождения.
В 1987 году PSC одной из первых в мире выпустила версию
продукта, функционирующую в режиме клиент/сервер.
Примерно в это же время Progress переходит на много
платформенную
структуру,
обеспечивая
функционирование
прикладных программ и серверов баз данных на различных типах
ЭВМ и под различными операционными системами.
В 1993 году появляется версия 7 Progress, полностью
ориентированная на графический интерфейс и объектноориентированные методы программирования. Далее в 1995 году (в
сентябре) выходит версия 8, расширяющая как средство разработки,
так и их объектно-ориентированную ориентацию.
Дальнейшая политика PSC обращена главным образом на
создание возможностей по включению в прикладные программы
компонент, написанных не к Progress, позволяя разработчикам
объединять в своих прикладных программах лучшее из того, что
есть на рынке программных средств. Еще большее развитие
предполагается для графических
средств разработки и
функционирования прикладных программ.
Особенности СУБД Progress
Progress представляет из себя совокупность программных продуктов,
которые предназначены для разработки и сопровождения ……….., больших
баз данных повышенной надежности. Он позволяет проводить разработку и
сопровождение на различных аппаратных платформах, количество которых
весьма велико, например, на широко распространенных IBM совместимых
персональных ЭВМ, VAX, HP 9000, AS/400 и многих других. Операционные
системы, с которыми работают программные продукты Progress, также
весьма разнообразны, в качестве примеров можно привести: MS DOS, OS/2,
UNIX, VAX/VMS, Novell Net Ware, OS/400 и рад других.
Отличительной чертой программных продуктов (ПП) Progress является
то, что они могут использоваться как на одной мощной ЭВМ, работающей в
режиме разделения времени со многими терминалами, так и в режиме
клиент/сервер с использованием сетей.
ПП Progress поддерживают как графический, так и символьный
интерфейс при работе с пользователем.
Исключительная мощь и удобство средств разработки позволяют
разработчику сосредотачиваться в значительной степени лишь на решении
задач проблемной области.
Полнота средств разработки
Progress можно охарактеризовать следующими особенностями:
1. Профессиональная мощь для создания ответственных прикладных
информационных систем (ИС)
Средства разработки прикладных программ (СРПП) на Progress базируется
на основе мощного и проверенного языка четвертого поколения Progress
4GL, и представляют из себя мощный и широкий спектр инструментов
разработчика. Для разработки прикладных программ Вам практически
никогда не придется использовать средства, не входящие в СРПП Progress,
например, языка С. Используя исключительно СРПП Progress, Вы можете
быть абсолютно уверены, что разработанные прикладные ИС будут
переносимыми, масштабируемыми и перенастраиваемыми программами.
2. Набор СРПП Progress обеспечивает все этапы цикла разработки.
СРПП Progress обеспечивают поддержку всех этапов жизненного цикла
программ, начиная от проектирования и разработки и кончая тестированием,
внедрением и сопровождением. Особенно стоит отметить, что СРПП
Progress обеспечивают поддержку весьма важных, но часто не оцениваемых
разработчиками, таких как документирование и обеспечение многоязыковой
поддержки.
3. Поддержка вычислительных структур как клиент/сервер, так и
центральных машин с терминалами.
Не смотря на то, что сетевые ВС с архитектурой клиент/сервер находят все
более широкое распространение, использование центральных машин,
работающих в режиме разделения времени со многими терминалами, также
остается распространенным во многих организациях. При этом СРПП
Progress позволяет проводить разработку прикладных ИС как для одной, так
и для другой структуры ВС, причем, более того, одна и та же прикладная ИС
может использоваться в обеих структурах.
4. Поддержка как графического, так и символьного интерфейсов.
Использование двух типов интерфейсов является стандартным для многих
систем разработки, однако СРПП Progress позволяет без переработки
программ переходить от одного типа интерфейса к другому.
5. Большое количество функционирующих прикладных ИС.
Очень часто одним из скорейших способов получения конкретной
прикладной ИС является принятие за основу и переработка другой
существующей прикладной ИС, особенно в том случае, если существующая
прикладная ИС обладает богатым набором функций и легко адаптируется
под конкретные требования.
Гибкие средства эксплуатации
(Flexible deployment options)
Совершенно очевидно, что, как в настоящее время, так и в будущем,
вычислительные системы будут достаточно быстро изменяться и развиваться.
СРПП Progress позволяет использовать предыдущие разработки, защищая тем
самым средства, используемые ранее, обеспечивая широкую переносимость
прикладных ИС, на различные аппаратные платформы, операционные среды и
сетевые конфигурации. При этом средства Progress обеспечивают следующие
важные возможности при эксплуатации:
1. Независимость от аппаратных платформ и операционных систем, что
позволяет эксплуатировать прикладные ИС более чем на 100 аппаратных
платформах и операционных системах.
2. Использование прикладных ИС в системах, построенных по принципу
клиент/сервер и по принципу главной ЭВМ, работающей с терминалами
в режиме разделения времени.
При этом все программные средства переносятся с одной системы на
другую без изменения. Более того, возможно функционирование
прикладных ИС на одной ЭВМ параллельно в двух режимах – клиент/сервер
и с разделением времени.
3. Независимость от конкретной базы данных.
Архитектура сервера данных (Data Server) Progress позволяет создавать и
эксплуатировать прикладные ИС в гетерогенных распределенных базах
данных. При этом прикладные ИС на Progress имеют прозрачный доступ
практически к большинству основных реляционных баз данных.
4. Масштабируемость (расширяемость).
К примеру, Вы увеличиваете производительность ВС или, напротив,
увеличиваете количество пользователей, при этом автоматически
учитываются все изменения, опять же без какого-либо изменения исходных
текстов прикладных ИС, написанных с использованием СРПП Progress,
обеспечивая тем самым оптимальную производительность практически на
любых аппаратных платформах и операционных средах.
5. Поддержка общепринятых промышленных стандартов.
Progress поддерживает стандарты ANSI SQL (Structured Query Language) и
ODBC (Open Data Base Connectivity), помимо этого поддерживает
стандартные средства DDE и DLL.
6. Независимость от сетевых протоколов.
Прикладные программы, РСУБД и серверы баз данных Progress имеют
возможность работать на любом сетевом оборудовании и поддерживают все
наиболее широко распространенные сетевые протоколы
прикладных клиентских программ с серверами баз данных.
для
связи
Структура ПС Progress
…
Прикладные
программы
Соединитель с
серверами баз данных
Весь спектр ПП Progress можно представить в виде трех больших
компонент:
 Средства разработки приложений (СРП) Progress (Progress Application
Development
Environment
(ADE),
позволяющих
проводить
проектирование, разработку, тестирование и эксплуатацию
прикладных программ (систем) с использованием, как графического,
так и символьного интерфейсов);
 Реляционная система управления базами данных (РСУБД) Progress
(Progress Relational Database Management System (RDBMS)),
позволяющая эффективно управлять данными, расположенными, как
на одном томе, так и в многотомной конфигурации, в частности и на
нескольких серверах;
 Серверы баз данных, отличных от Progress RDBMS, (Data Server), при
этом прикладные программы, написанные на языке Progress 4GL,
имеют возможность с поддерживаемыми базами данных, отличных
от Progress RDBMS, работать без изменений. К таким базам данных
следует отнести Oracle, Sybase, DB2/400 (для ЭВМ AS/400) и ряд
других, причем достаточно «старых» баз данных, построенных,
например, на базе ISAM (Index Sequential Access Method). Последнее
крайне важно, так как позволяет сохранить и активно использовать
старые базы, наполненные за длительный период на других
платформах. Помимо доступа к конкретным базам данных Progress
позволяет иметь доступ к любым базам, использующим стандарт
ODBS (Open Data Base Connectivity) – открытые средства связи с
базами данных. Стоит отметить, что стандарта ODBC в настоящее
время придерживаются практически все производители СУБД и, в
частности, Fox Pro, подробно изучаемый на нашей кафедре.
Структура связей с различными базами данных выглядит следующим
образом:
Progress
Oracle
Sybase
…
Db2/400
к другим
рабочие места на ПЭВМ
или терминалах
ODBC
серверам
БД
Использование ODBC позволяет Progress иметь для ряда серверов СУБД
иметь как бы двойной доступ к базам данных: через собственный сервер и через
ODBC, также возможно, например, для Oracle.
Мы уделили во введении сравнительно большее внимание компоненте
серверов данных Progress по причине того, что в дальнейшем наше внимание
будет обращено главным образом на другие компоненты.
Говоря об основных отличиях Progress от других СУБД необходимо отметить
главное: Progress позволяет проводить разработку и сопровождение
разработанных прикладных программ и баз данных исключительно средствами
самого Progress без привлечения других программных средств, более того, все
средства необходимые и достаточные для разработки включены в состав
Progress ADE, т.е. разработчик, приобретая компонент для разработки,
приобретает полностью абсолютно все необходимые средства. Другим важным
отличием Progress является наличие многих серверов баз данных, позволяющих
программам на Progress связываться с другими базами даже без использования
ODBC.
Состав средств разработки прикладных программ
Состав средств разработки прикладных программ СРПП (Application
Development Enviroment) представляют из себя набор следующих
инструментов:
 словарь данных (СД) Data Dictionary;
 конструктор графического интерфейса (КГИ), User Interface
Builder;
 язык Progress 4GL (4 Generation Language);
 конструктор отчетов (КО), Report Builder;
 редактор текстов процедур (РП), Procedure Editor;
 коммуникатор прикладных программ (КПП), Application
Compiler;
 отладчик, Application Debuger;
 библиотекарь, Librarian;
 утилита разработки помощи (УРП), Help Development Utilities;
 программа управления разноязыковыми сообщениями (УРС),
Translation Manager;
 программа анализа производительности (ПАП), Performance
Profiles;
 программа генерации отчетов пользователей (ГОП), Results;
 средства
администрирования
данных
(САД),
Data
Administrator;
 средства поддержки (СП), Developers Toolkit.
Рассмотрим назначение этих инструментальных средств подробнее.
Отметим при этом, что все средства разработки образуют единый
интегрированный пакет, позволяющий легко переключаться от
одной составляющей к другой в процессе разработки.
Словарь данных.
СД является одним из основных, базовых средств разработки,
он позволяет создавать и модифицировать прикладные базы данных.
СД хранит описания всех элементов данных и их атрибутов
централизованно в одном месте, что уменьшает объемы прикладных
программ, упрощает эти программы и обеспечивает стандартизацию
доступа к данным, хранящимся в БД, из любых прикладных
программ.
СД состоит из трех основных составляющих: схемы базы
данных, описаний данных принимаемых по умолчанию в
прикладных программах, правил обработки данных в БД и триггеров
БД. (Database Schema, Application Default, Biasness Rules and
Database Trigger).
Схема базы данных.
Схема базы данных представляет из себя набор описаний
структуры БД и характеристик элементов данных. Поля баз данных
могут иметь следующие типы: символьные, целые, десятичные,
логические, даты и указатели. Возможно также определение полей
как массивов допустимых типов данных.
Описание данных, принимаемых
прикладных программах.
по
умолчанию
в
Эти описания дают определения, как переменные, являющиеся
значениями полей базы данных используется в прикладных
программах на Progress. Например:
Формат - принимаемый по умолчанию формат, в котором данные
представляются на экране дисплея и в формируемых документах.
Метка - значение, которое по умолчанию выдается вместе со
значением поля записи в отчетах.
Помощь - принимаемое по умолчанию сообщение, которое выдается
при вводе пользователем данных в БД при заполнении форм
входных данных.
Представление (View-AS) - значение, по которому по умолчанию
связывается элемент интерфейса со значением поля базы данных.
Например, представляется: поле для записи, радиокнопка,
строка прокрутки, набор кнопок и т.д.
Правила обработки данных и триггеры БД.
Словарь данных позволяет определять действия, связанные с
элементами базы данных. Под этим понимается следующее:
 проверка допустимости данных, вводимых в базу данных;
 возможности удаления определенных записей и полей.
Кроме того имеется возможность определить сообщение
пользователю, когда он нарушает соглашения о формате вводимых
данных.
Триггеры базы данных представляют из себя программы
(процедуры) на языке Progress 4GL, связанные с событиями по
обработке значений данных в БД. Например, целесообразно создать
триггер, связанный с созданием записи в БД. Использование
триггеров дает мощное средство контроля данных, безопасности и
целостности для любых прикладных программ.
CASE мосты.
С вопросами построения баз данных на Progress тесно связаны
вопросы использования "массивов" или связей с CASE (Computer
Aided Software Engineering) (САПР ПО).
Суть CASE средств состоит в проектирование баз данных и
способов их обработки на уровне диаграмм и далее после обработки
этих диаграмм программными CASE средствами получение текстов
прикладных программ на языке 4GL и структур баз данных,
например, в терминах словаря данных (Data Dictionary). Основной
трудностью при использовании CASE средств с конкретными СУБД
является связь построенных диаграмм данных и действия над ними с
генераций кода функциональных программ на конкретном языке
СУБВ 4GL. Мосты, или связи предназначены для связи
универсальных CASE средств с генерацией кода 4GL для
конкретной СУБД. Версия 7.2 Progress обеспечивает мосты с CASE
системами Intersalv Exeleratar и Knowledgware Application
Development Workstation.
Конструктор пользовательского интерфейса.
(User Interface Builder).
КПИ является основным инструментальным средством для
проектирования и реализации прикладных программ. КПИ
позволяет создавать интерфейсы прикладных программ, определяя
на экране расположение информации, соответствующей значением
полей базы данных, а также вспомогательных управляющих
элементов, такие как кнопки, меню, поле прокрутки и т.п.
Существуют также возможности выбора цветов, размеров окон и
других атрибутов интерфейса.
Окна, записи в рамках о значениях полей баз данных, а также
управляющие кнопки, поля прокрутки имеют название графические элементы (Widget). КПИ и язык 4GL поддерживают
исчерпывающий набор средств, обеспечивающих представления
любых данных из базы и средств для операций с этим данными.
Графический и символьный интерфейс.
КПИ позволяет создавать как графический, так и символьные
варианты интерфейсов, хотя сам КПИ, как инструментальное
средство, функционирует только в графическом режиме. Это
свойство обеспечивается тем, что Progress поддерживает
исчерпывающий набор графических элементов, как для
графического, так и для символьного интерфейса.
Событийное программирование.
КПИ позволяет проводить логические проверки вводимых
данных и другие операции, аналогично тому, как это делалось в
словаре данных (Data Dictionary), создавать триггеры для
пользовательского интерфейса. Создаваемые КГУ прикладные
программы являются так называемыми программами управляемые
событиями (event-driven).
Управляемые событиями программы отличаются следующими
специфическими характеристиками. Они запускаются, выводят на
экран какой-либо вариант разработанного пользовательского
интерфейса и переходит в режим ожидания действий пользователя,
которые в нашем случае имеют специальные название: события
пользовательского интерфейса. Эти события по сути дела
определяют характер обработки в прикладных программах.
Примерами событий пользовательского интерфейса являются:
 выбор элемента меню,
 ввод данных в поле ввода,
 "нажатие" управляющей кнопки, например, с помощью мыши
или функциональной клавиши и т.д.
В ответ на конкретное событие пользовательского интерфейса
может запускаться процедура (программа) на языке 4GL, связанная с
этими событиями, и называемая триггерами пользовательского
интерфейса (user-interface trigger).
Интерфейсные триггеры.
Таким образом, триггеры пользовательского интерфейса могут
производить определенные действия в ответ на действия
пользователя в процессе ввода им информации.
В КГИ имеется редактор (Section Editor), обеспечивающий
установку процедуры и написания текста триггеров.
Генерация кодов процедур на языке 4GL.
После окончания разработки пользовательского интерфейса
КГИ автоматически создает соответствующий код на языке 4GL,
представляющий описание интерфейса, т.е. по сути дела дает
программы. При этом создается единая процедура (модуль), которое
содержит
как
код,
соответствующий
конкретному
пользовательскому интерфейсу, так и код триггера, обеспечивая
полную переносимость сгенерированного кода.
Естественно, что пользовательский интерфейс можно создать
непосредственно кодируя на языке 4GL, не пользуясь графическими
возможностями КГИ, что во многих случаях является более
предпочтительными, особенно при наличии у программиста
достаточного опыта.
Интересен,
однако,
следующий
метод
разработки,
предлагаемый, в частности в документации PSC.
1. C использованием графических средств КГИ создается
некоторый "универсальный" вариант пользовательского
интерфейса, который в дальнейшем будет использоваться как
некоторый шаблон для нескольких конкретных интерфейсов.
2. Генерируется код на языке 4GL, соответствующий этому
шаблону.
3. Код шаблона модифицируется программистами для получения
конкретного вида пользовательского интерфейса.
Язык Progress 4GL.
Основная цель создания языка Progress 4GL – обеспечить максимальные
функциональные возможности при минимальном объеме кода. Еще раз стоит
отметить, что P4GL позволяет создавать прикладные программы
исключительно и только с использованием своих средств, не привлекая
никаких других инструментальных программных продуктов.
P4GL, включая в себя все возможности языков 3GL, дает помимо этого
ряд специфических возможностей.
1. Продуманные правила умолчания. В первую очередь необходимо еще
раз отметить использование по умолчанию данных, описанных в
словаре данных (Data Dictionary). Помимо этого, используется и
встроенные в P4GL функции обработки по умолчанию, такие как
компоновка экранов, обработка ошибок, блокирование записей и
транзакций, что существенно упрощает разработку, особенно на
стадии макетирования информационных систем (ИС).
2. Гибкие средства управления интерфейсами. Качество интерфейса
приобретает особую значимость в больших, ориентированных на
работу с людьми, информационных системах. P4GL дает
исключительно большие возможности в разработке интерфейса. Он
имеет исчерпывающий набор операторов формирование графических
элементов (Widgets), который мы обсуждали ранее, полные средства
управления шрифтами, цветом, возможности “перетаскивания” (drayand-drop) объектов на экране, что является стандартом при
пользовании графическим интерфейсом.
3. Доступ к БД и управления транзакциями. P4GL включает полный
набор операторов доступа к значениям данных, хранящихся в БД.
Такие же исчерпывающие средства имеются для блокировки данных и
обработки транзакций, если разработчика по каким-либо причинам не
устраивают действия, выполняемые по умолчанию.
4. Использование стандарта ANSI SQL. (Structured Query Language)
ANSI/ISO – 89 SQL. P4GL обеспечивает доступ к данным в БД и с
использованием SQL, наряду с наличием собственных операторов
доступа.
5. Использование входных и выходных потоков. P4GL обеспечивает
возможности перенаправления потоков данных на любые внешние
устройства и с любых внешних устройств, в файлы из файлов
операционной системы. Любая программа имеет возможность
перенаправлять практически неограниченное количество потоков
(стандарт UNIX, в MS DOS только в ОС).
6. Доступ к операционной системе. Имеется возможность временного
выхода из прикладных программ в ОС для выполнения каких-либо
единичных действий и для запуска пакетных файлов.
Кроме этого, как и любой развитой язык программирования, P4GL
позволяет вызывать функции (подпрограммы), определять типы данных,
массивы и т.д.
На языке 4GL могут быть реализованы практически все действия,
выполняемые другими составляющими СРПП (ADE), например, кроме
операций КГИ, возможно выполнение всех операций словаря данных и т.д.
Более того, практически все инструментальные средства, входящие в СРПП
сами разработаны на 4GL.
Язык позволяет поддерживать как общепринятый способ разработки ИС
(сверху-вниз), так и поддержку событийного программирования, когда
процедуры (модули) выполняются в ответ на некоторое событие, возникшее
в ИС.
Конструктор отчетов (Report Builder).
КО представляет собой графическое средство, позволяющее определять
компоновку и содержание отчетов. Допускается построение как табличных, так
и других форматов. Аналогично этому, как это предлагается делать для КГИ, и
здесь возможно графическое создание достаточно универсальных шаблонов
отчетов и дальнейшая настройка на конкретные требования.
Редактор процедур (РП Procedure Editor).
РП является достаточно развитым текстовым редактором в отличие от
использующегося в КГИ редактора разделов (Section Editor), он обеспечивает
стандартные средства редактирования, такие как поиск и замена, вырезка и
вставка, использование “горячих” клавишей, печать, работу с несколькими
файлами одновременно и т.д. РП тесно взаимодействует с другими
составляющими СРПП.
Помимо стандартных средств редактирования РП позволяет:
- вызывать отладчик для анализа логических ошибок в редактируемой
процедуре (модуле),
- обеспечить доступ к словарю данных для просмотра и возможных
изменений схемы базы данных и значений, принимаемых по
умолчанию в прикладных программах,
- вызывать компилятор, как для обработки отдельных модулей, так и
всей прикладной программы в целом,
- извлекать требуемый код на языке 4GL из библиотек,
- обращаться к системе помощи, как для получения справочной
информации, так и для возможного включения в редактируемый
текст примеров из системы помощи.
Компилятор (Compiler).
Компонента СРПП, преобразующая исходный код процедур на языке 4GL в
исполнительный. В процессе работы компилятор выдает сообщения о
выполняемых им действиях, а также сообщения об ошибках и возможных
способах их устранения. Напомним, что синтаксический анализ исходных
текстов проводится также и редактором процедур.
Отладчик.
Отладчик позволяет обнаруживать и исправлять логические ошибки в
процедурах, а также ошибки при манипулировании данными. Он может быть
вызван из КГИ или редактора процедур, а также запущен самостоятельно.
Основные свойства отладчика следующие:
-
-
пошаговые выполнения процедур и расстановка точек останова
программы,
анализ текущего состояния переменных, параметров, буферов,
стеков, транзакций и триггеров, что позволяет точно локализировать
конкретные места возникновения ошибок,
отслеживать возникновения событий и осуществлять трассировку
выполнения триггеров, связанных с событиями.
Библиотекарь (Librarian).
Б. Имеет две основные функции, связанные одна с другой.
1. Он содержит и обеспечивает интерактивный доступ к библиотечному
набору готовых процедур на языке P4GL. Представленный набор
процедур схватывает весь спектр возможностей языка P4GL, причем
представленные процедуры могут являться шаблонами для
дальнейших разработок. В составе библиотеки содержится
прикладные программы, генераторы графических символов, типовые
шаблоны, значки (icons) для отображения в Windows.
2. Помимо этого Б. позволяет разработчику создавать свои собственные
библиотеки процедур на языке P4GL.
Утилита разработки системы помощи (Help
Development Utilities).
СРПП Progress включает в себя средства разработки гипертекстовой системы
помощи для прикладных программ.
При работе клиентской части в MS Windows Progress использует драйвер
программы просмотра помощи Windows (Windows Help Viewer).
Непосредственно программа просмотра помощи Progress повторяет все
функциональные
возможности ПП Windows на других графических и
символьных интерфейсах.
При использовании мощного текстового процессора RTF TD 2-11 возможно
создание файлов помощи с гипертекстом и графическими элементами. СРПП
Progress содержит также компилятор помощи (Help Compiler), преобразующего
исходные файлы в двоичные файлы для программы просмотра.
Учитывая широкую переносимость Progress на разные платформы исходные
файлы помощи могут быть использованы на различных типах машин.
Средства
оптимизации
(Performance Profiler).
производительности
Эти средства состоят из двух утилит, позволяющих оптимизировать работу
программы на Progress.
1. Утилита оптимизации прикладных программ собирает статистические
данные об используемых ресурсах и временных характеристиках
выполняемых прикладных программ,
2. Утилита оптимизации баз данных собирает статистические данные о
запросах отдельных программ к базе данных, состоянии БД и
характеристиках обработки.
Обе эти утилиты позволяют проводить тонкую настройку программ и баз
данных для достижения максимальной производительности.
Средства многоязыковой поддержки (Translation
Manager).
Это средство позволяет использовать многоязыковую поддержку
прикладных программ на нескольких языках. При этом возможно создание
многоязыковых интерфейсов, подсказок, сообщений об ошибках и т.п. Помимо
многоязыковой поддержки вполне естественной является возможность смены
терминологии, если это, конечно, требуется для различных групп
пользователей.
Суть многоязыковой поддержки состоит в том, что в прикладные программы
включаются не символьные строки, а ссылки на эти строки. Сами же
символьные строки или сообщения хранятся в специальных файлах, различных
для разных языков, со своими ссылками, одинаковых для разных языков. При
запуске программы непосредственно указывается какой язык, а следовательно и
какой файл использовать в программе.
Пользовательские отчеты (Results).
Это средство пользователя не программиста, позволяющего на основе
специального интерфейса формировать запросы к базе данных и на этой основе
формировать отчеты.
Средство не нашло широкого применения, т.к., предъявляя повышенные
требования к квалификации пользователя, не давало существенного выигрыша в
разработке. Реально проще обратиться к программисту для получения нового
отчета.
Средства администратора БД.
(Data Administration).
Средства администрирования БД позволяют разработчику или администратору
БД решать следующие задачи:
- выгружать и загружать данные и схему базы данных;
- обмениваться информацией о структуре БД с серверами баз данных,
отличных от Progress РСУБД;
- определять права доступа к данным;
- импортировать и экспортировать данные баз данных из различных СУБД.
Использование средств администрирования происходит в течение всего
жизненного цикла программы, начиная с разработки и заканчивая
эксплуатацией и сопровождением.
Инструментарий разработчика.
(Developers Toolkit)
Средство, позволяющее управлять распространением прикладных
программам, осуществлять установку (installation), включает дополнительные
средства (upgrade).
Это набор утилит для упаковки, распространения и эксплуатации прикладных
программ.
Функционирование Progress в локальной сети.
Progress в локальной сети функционирует в режиме клиент-сервер. В
простейшем случае это означает, что прикладная программа выполняется на
рабочей станции, а обработка запросов к базе данных – на серверной машине.
Такая архитектура в значительной степени уменьшает траффик в сети и более
рационально использует вычислительные возможности рабочих станций по
сравнению с использованием централизованной машины.
Отдельную машину, работающую в локальной сети, будем называть узлом.
В локальных сетях, предназначенных для функционирования Progress,
различают три вида узлов:
1. Рабочая станция, выполняющая прикладные программы;
2. Машина сервера баз данных ;
3. Сетевой файл – сервер.
Конкретный узел (машина) локальной сети может выполнять
одновременно несколько видов функций узлов, перечисленных выше.
Далее рассмотрим функции сетевых узлов и некоторые возможные
конфигурации локальной сети при использовании Progress.
Рабочая станция, выполняющая прикладные
программы (Application Workstation ).
С позиций Progress рабочая станция является узлом сети, на котором
выполняется одна или более, в зависимости от операционной системы,
прикладных функциональных программ, представляющих из себя клиентские
части.
Важно отметить, что в зависимости от операционной системы и
конфигурации ЛВС на рабочей станции могут одновременно выполняться как
локальные клиентские части, так и локальные серверы.
Машина сервера базы данных.
МСБД представляет из себя узел сети, на котором выполняются один
или более серверов (серверных процессов) для локальных или удалённых
клиентов.
Существует два типа серверов баз данных: однопроцессный и
многопроцессный.
Однопроцессный сервер базы данных обслуживает лишь по одному
процессу на каждую базу данных. В этом случае сервер организует очереди
запросов для всех клиентов (пользователей). Такой режим используется для
серверов баз данных, работающих под управлением MS Windows и Net Ware.
Многопроцессный сервер баз данных обслуживает выполняет
одновременно несколько процессов для каждой базы данных. Каждому из
серверов организует очереди запросов и их обработку для одного или
нескольких клиентов. При этом существует некий выделенный процесс
посредник (broker) для каждого дополнительного клиентского запроса к базе
данных. Такой режим используется для серверов баз данных, работающих под
управлением UNIX и VAX/VMS.
Как правило база данных храниться на локальных дисках, присоединенных
к машине сервера баз данных, что обеспечивает целостность баз данных и
максимальную производительность сервера. Однако , в зависимости от
структуры прикладных программ и конкретной структуры сети база данных в
принципе может храниться и на другом узле, не совпадающем с узлом сервера
баз данных.
Сетевой файл – сервер.
СФС является узлом сети, на котором хранятся разделяемые файлы, а также,
возможно, выполняются функции сервера печати. К разделяемым файлам могут
быть отнесены разделяемые файлы и программы РСУБД Progress, а также
другие разделяемые файлы. Эти программы и файлы могут использоваться,
естественно, как клиентскими частями рабочих станций, так и серверами баз
данных.
Примеры и анализ сетевых конфигураций.
Мы рассмотрим лишь некоторые возможные примеры сетевых
конфигураций для Progress, на практике, естественно, конфигурации ЛВС могут
отличаться от приводимых в примерах.
Файлы баз данных СУБД Progress и
их размещение на магнитных носителях.
Однотомные и многотомные базы данных.
Файлы базы данных и другие файлы Progress могут размещаться как на одном,
так и на нескольких физических или логических томах.
Однотомная база данных создаётся Progress по умолчанию. Это наиболее часто
используемая структура из экономических соображений. При этом однотомные
базы данных накладывают ограничения на объём баз данных.
Рассматривая этот вопрос важно отметить что БД Progress состоящая возможно
из многих таблиц представляет из себя единый файл с точки зрения операционной
системы.
Progress имеет свои собственные ограничения объёма базы данных в 2 Гбайта.
Однако, на этот объём накладываются ограничения операционных систем.
Следующая таблица показывает ограничения объёмов БД для различных
операционных систем.
Тип ОС
Максимальный размер файла БД
UNIX
1.65 Гб
DOS/MS Windows
8 Мб
OS/2
2 Гб
MVS
2 Гб
Из рассмотрения этой таблицы становится очевидным, что однотомные базы
данных не всегда удовлетворяют требованиям на их реальные объёмы.
Многотомные базы данных Progress могут размещаться на количестве
дисковых томов вплоть до 100. Для их создания и поддержки используются
специальные утилиты.
При выборе варианта построения БД – однотомная или многотомная
учитываются следующие соображения:
1) ограничения на объём файла базы данных при выборе однотомного
варианта.
2) повышение производительности прикладных программ при использовании
многотомной БД.
3) возможность резервного копирования дифференциального файла без
необходимости закрытия БД.
Таким образом, если имеется возможность, использование многотомных баз
данных является более предпочтительным.
Файлы баз данных Progress.
СУБД Progress поддерживает следующие файлы:
1.Файлы баз данных.
Файлы баз данных содержат схему базы данных, данные в формате таблиц БД
и, возможно, индексы, если они используются.
Для однотомных БД эти файлы имеют расширение *.db , например, clients.db –
база данных клиентов.
Для многотомных баз данных создаются:
- файл схемы баз данных, имеющий расширение *.db ;
- файлы, содержащие данные и, возможно, индексы, имеющие расширение
*.dn , где n-целое число.
2. Файл регистрации(журнал) (log file).
Этот файл представляет из себя текстовый файл в формате ASCII, в который
записывается информация о важных событиях, происходящих с базой данных,
таких как инициализация базы данных, её закрытие(shutdown), а также ошибки,
возникающие при работе с БД. Файл имеет расширение *.lg.
3.файл отката транзакций(before image file).
Этот файл содержит информацию, необходимую для восстановления базы
данных при возникновении ошибок во время выполнения транзакций, главным
образом при изменении значений полей БД. Этот файл может располагаться как на
одном томе с файлом базы данных, так и на разных с ним томах. Файл обеспечивает
восстановление БД способом, называемом «откат назад»(roll-back recovery). Он
имеет расширение *.bi и является, вообще говоря, обязательным для
функционирования БД. Файл создаётся и поддерживается автоматически. Для
многотомных баз данных создаётся количество файлов отката, равное количеству
файлов базы данных, в этом случае файлы отката имеют расширение *.bn, где nцелое число, равное числу в расширении связанного с ним файла базы данных *.dn.
4. Дифференциальный файл (after-image file).
Этот файл создаётся, если используется способ восстановления БД,
называемый откат вперёд(roll-forward recovery). Он содержит информацию,
необходимую для восстановления БД после её разрушения, если предварительно
была создана копия БД на некоторый момент времени. Информация в
дифференциальном файле содержит абсолютно все изменения, проведенные в БД
со времени её последнего копирования. Таким образом копия БД и
дифференциальный файл дают возможность восстановить актуальное состояние БД
в случае её разрушения. Для БД, расположенной на одном томе дифференциальный
файл имеет расширение *.ai, а для многотомной БД - *.an, где n-целое число,
соответствующее числу в расширении файла БД *.dn.
Для восстановления БД с использованием дифференциального файла
используются специальные программы-утилиты.
5.Файл журнала транзакций(transaction log file).
При использовании двухфазной фиксации при осуществлении транзакций
одновременно с несколькими базами данных создаётся специальный файл, который
содержит информацию, необходимую для обеспечения целостности баз данных.
Файл имеет расширение *.tl.
6.файл блокировок(lock file).
При запуске прикладных программ для работы с БД создаётся файл
блокировок, имеющий расширение *.lk, размещаемый в одном каталоге с файлом
БД. Файл существует только в процессе работы ПП с БД. При успешном
завершении ПП Progress удаляет этот файл. Файл содержит информацию о
блокировках записей и/или полей БД и, естественно, может динамически меняться
в процессе функционирования ПП. Если в процессе функционирования произойдёт
ошибка и ПП будет перезапущена, возможно появление сообщения о том, что файл
блокировок уже существует. Файл следует удалить, но только в том случае, если
работа с БД успешно завершена или ещё не начиналась, иначе при удалении файла
блокировок БД будет разрушена и потребуется её восстановление на основе
последней копии и дифференциального файла.
Рекомендации по расположению файлов СУБД PROGRESS.
На следующем рисунке показано типовое расположение файлов на магнитных
носителях. Принципиально возможно и другое расположение файлов.
Файл БД
Дифференциальный
файл
Файл
регистрации
Vol.1
Vol.2
Файл журнала
транзакций
Файл
отката
ЭВМ
Файл
блокировок
При выборе конкретного места хранения файлов необходимо учитывать
следующие основные соображения:
- дифференциальный файл должен хранится на диске, отличном от диска, на
котором хранятся файлы баз данных (*.db) и файлы отката транзакций(*.bi)
, что позволит восстановить БД при выходе из строя любого из дисков;
- для повышения производительности системы файлы БД и файлы отката
целесообразно хранить на разных дисках, т.к. при работе с БД к этим
файлам идёт одновременное обращение.
- Также для повышения производительности желательно использовать
многотомную структуру БД.
Помимо рассмотренных файлов Progress создаёт и использует при работе с ПП
ещё ряд временных файлов, которые уничтожаются при завершении работы ПП.
Защита от ошибок и восстановление БД.
Откат транзакций.
Откат транзакций выполняется автоматически при работе с ПП, хотя
существуют возможности блокировки отката.
Рассмотрим простой пример. Пусть имеется БД некоторых продаж – sales.db,
в которой хранится таблица покупателей, для каждого покупателя существует
своя запись customer.
Пусть для всех записей осуществляется изменение одного и того же
определенного поля. Совокупность этих изменений представляет из себя
транзакцию. К примеру для двух записей такое изменение прошло успешно, а
при обработке третьей записи произошла ошибка. При повторном запуске
Progress последуют сообщения примерно следующего содержания:
** The last session was abnormally terminated.
** Any incomplete transactions are being backed out.
** Data recovery is complete. You must rerun all active transactions.
Press spacebar to continue.
При повторном запуске конкретной процедуры, содержащей неудавшуюся
транзакцию, первые две успешные записи остаются в исходном, уже
измененном состоянии, а запись 3 восстанавливается с использованием
содержимого BI файла в состояние, которое она имела до начала транзакции.
(Рисунок 9-1 SAG).
Осуществляется это следующим образом. До начала проведения изменений в
базе данных в рамках конкретной транзакции. Progress копирует информацию,
подлежащую изменению в BI файл. Это копирование инициируется любым
оператором, изменяющим запись. Далее, при возникновении ошибки в процессе
выполнения транзакции, информация из BI файла используется для приведения
БД в состояние, в котором та была до начала транзакции.
Таким образом, наличие BI файла с информацией о состоянии БД до начала
транзакции полностью защищает систему от ошибок, возникающих в процессе
работы, но только в том случае, если носитель, на котором расположена база
данных, физически не разрушен.
Откат вперед.
Откат вперед позволяет вводить защиту от последствий разрушения
носителя, на котором размещается БД. Суть этого состоит в следующем.
Периодически все БД копируются на некоторый носитель (съемный HD,
стриммер и т.п.), который сохраняется отдельно от работающей системы. После
проведения копирования все изменения, проводимые в БД записываются в так
называемый after-image файл (AI), который является по сути
дифференциальным файлом, хранящим все изменения в БД после её последнего
копирования. Важно, что естественно, чтобы AI файл сохранялся на носителе,
отличном от того, на котором хранится сама БД, обеспечивая тем самым крайне
малую вероятность их одновременного физического разрушения. При
разрушении одного из носителей возможны следующие варианты:
1.Разрушается диск с AI файлом.
Необходимо немедленно сканировать базу данных на независимый носитель
и сохранить его. Заменить разрушенный носитель с AI файлом и вновь
запустить систему, указав, что AI файл новый.
2.Разрушается диск с базой данных.
Необходимо заметить разрушенный носитель. Восстановить утраченную БД
с помощью имеющейся утилиты, используя последнюю сохраненную копию
базы и информацию из AI файла. Это реально возможно, т.к. в AI файле
содержится вся информация об изменениях БД после последнего резервного
копирования. Конкретно, резервная копия БД копируется на новый носитель и
далее утилита, используя информацию из AI файла, изменяет резервную копию
БД, приводя её к состоянию перед разрушением носителя.
Важно, отметить следующее, даже, если разрушение носителя произошло во
время обработки информации, целостность БД не будет нарушена, т.к. запись в
AI файл. Таким образом, после восстановления БД она будет находиться в
состоянии, полностью совпадающем с состоянием перед выполнением
неудачной транзакции. Следующий рисунок показывает взаимосвязь этапов
выполнения транзакции с BI и AI файлами
транзакция
начало
действие 1
действие 2
…
…
действие n
конец
AI
файл
BI
файл
Здесь важно сделать ряд замечаний по объемам BI и AI файлов.
BI файл содержит информацию о состоянии изменяемых полей записей
перед началом транзакции. После успешного завершения транзакции
содержимое BI файла обновляется и в любом случае его объем сравнительно
невелик и не превышает объем изменяемой информации в БД в пределах одной
транзакции.
Напротив, объем АI файла может достигает значительной величины. В АI
файл записываются все изменения БД со временем ее последнего резервного
копирования и, если период времени между двумя копированиями достаточно
велик, то и объем АI файла также может быть весьма значительным.
Двухфазная фиксация.
Two-Phase Commit
Двухфазная фиксация транзакций позволяет сохранить целостность БД при
проведении одной транзакции с несколькими базами. При работе с одной базой
системная ошибка, не связанная с разрушением носителя не приведет к потере
целостности, т.к. произойдет откат назад неудачной транзакции с
использованием информации из BI файла. При работе с несколькими базами в
рамках одной транзакции ситуация существенно усложняется.
DB1
Обработка
DB2
BI1
BI2
Пусть есть две БД DB1 и DB2 и два BI файла BI1 и BI2. Например, средства
снимаются со счетов в DB1, проводится их обработка и результаты зачисляются
на счета в DB2. (Простейшая обработка – снятие комиссионных).
Все это выполняется в рамках одной транзакции
Пусть средства сняты со счетов в DB1, транзакция относительно DB1 прошла
успешно и BI1 файл изменен, но ошибки не обнаружено. В процессе занесения
результатов обработки в DB2 произошла ошибка, транзакция для DB2 считается
ошибочной и произошел откат на основе информации из файла BI2. Все как
будто бы в порядке, но целостность баз потеряна.
Для того чтобы избежать этого должен существовать некоторый механизм,
согласующий правильность обработки двух БД. Этот механизм и носит
название двухфазной фиксации транзакций.
Его действие разбивается на две фазы:
1) проведения действий над базами и фиксация результатов;
2) анализ успешности проведения действий и выдача сигналов о проведении
окончательной фиксации.
Для реализации этого алгоритма необходим некоторый координатор, общий
для всех обрабатываемых баз данных. Координатор представляет собой
некоторый процесс, связанный с обработкой всех задействованных баз.