Редактор Процедур (Procedure Editor)
Для программирования тех частей Вашего приложения, разработка которых средствами
визуального программирования затруднена, например сложных вычислительных процедур или
процедур пакетной обработки, в Среду Разработки Приложений PROGRESS введен Редактор
Процедур, имеющий все необходимые средства для удовлетворения нужд разработчика по
написанию программ.
Редактор Процедур позволяет быстро создавать, модифицировать и тестировать сложные,
многократно используемые процедуры, которые могут использоваться всеми членами группы
разработчиков и могут вызываться из любого места программы.
Редактор Процедур поддерживает полный набор средств редактирования, включая вставку и
удаление блоков, поиск и замену фрагментов текста и многие другие, позволяющие делать
масштабные изменения в текстах нескольких программ одновременно.
Редактор интегрирован с остальными средствами Среды Разработки Приложений PROGRESS. Не
выходя из Редактора Процедур, Вы можете:
Улучшать и создавать новые компоненты приложений, генерируемые
Построителем Интерфейса Пользователя или утилитой Results для более
тщательной разработки интерфейсов и отчетов.
Вызывать Отладчик Приложений PROGRESS для эффективного решения
проблем, возникающих в логике работы Вашего приложения.
Осуществлять доступ к Словарю Данных PROGRESS для создания и
поддержки атрибутов центрально-хранимых данных, таких как представление
данных, правила проверки правильности ввода и целостности данных.
Запрашивать в режиме on-line обширный справочник, который включает в
себя полную информацию о системе и набор примеров для изучения языка
4GL.
Вызывать встроенный Компилятор Приложений PROGRESS для быстрой
компиляции всего приложения или отдельных его частей.
Подобная высокая степень интеграции Редактора Процедур с остальными средствами среды
разработки PROGRESS, гарантирует Вам получение высокой производительности при работе с
любыми компонентами приложений.
Редакторы свойств и редакторы компонент - поведение IDE
Логично, что при визуальном подходе к определению характеристик компонент (работа в design-
time), необходимы средства определения редакторов специфических свойств в Инспекторе
Объектов (Object Inspector).
Рекомендуемая литература
Тандоев А.Ю. Архитектура продуктов клиент-сервер фирмы Sybase. СУБД № 1, 1995, с. 62-69.
Горин С.В., Тандоев А.Ю. Среда разработки приложений PowerBuilder. DBMS/Russian Edition,
№ 1, 1995, с.38-41.
Горин С.В., Тандоев А.Ю. Линия продуктов Sybase для создания сложных информационных
систем. Компьютерра, № 37-38 (117-118), с.44-48; № 39 (119), с.26-30.
Монахова Е.Н. System 11 в проекции на Лондон и Москву. PC Week/Russian Edition, № 19,
1995, с.1.
[]
[]
[]
Реляционные расширители
Хорошим примером применения перечисленных новых возможностей являются реляционные
расширители DB2 (DB2 Relational Extenders). Они предоставляют широкие возможности для
работы с нетрадиционными данными, используя возможность определения пользовательских
типов данных и функций. Для хранения мультимедиа данных расширители используют
поддерживаемые DB2 большие объекты, а для поддержания целостности по ссылкам -
триггеры.
В настоящее время существует пять реляционных расширителей, позволяющих работать с
изображениями, сложными текстовыми документами, видео, аудио, и даже с отпечатками
пальцев.
Репликационный сервер Sybase Replication Server
Репликационный сервер, входящий в состав Sybase System 11, использует асинхронную модель
репликации транзакций. При разработке модели данных проектируются и правила репликации.
Затем проводится конфигурирование системы. При работе прикладной программы изменения
данных отслеживаются системными средствами и в соответствии с конфигурацией требуемые
данные передаются в удаленную СУБД (рис. 8).
Репликационный сервер представляет собой отдельную задачу, запускаемую одновременно с
СУБД. Он имеет свой входной язык и стандартный для продуктов Sybase сетевой интерфейс
Open Server. Такое разделение снижает нагрузку на СУБД и делает систему в целом более
открытой.
Репликация использует интуитивно понятный принцип "публикации" изменяемых данных и
"подписки" на изменения.
Транзакция может вносить изменения (т.е. добавлять, удалять и изменять записи) в одну или
несколько таблиц базы данных. Выбранные для репликации таблицы специальным образом
помечаются. Для каждой такой таблицы или группы ее строк, выбранной по заданному условию,
определяется один узел (СУБД), в котором данные таблицы являются первичными. Это тот узел, в
котором происходит наиболее активное обновление данных. Репликационному серверу,
обслуживающему БД с первичными данными, задается описание тиражирования (replication
definition). В этом описании, в частности, могут быть заданы интервалы значений первичного
ключа таблицы (или другое условие на первичный ключ), при выполнении которого измененные
данные будут тиражироваться из этого узла к подписчикам. Если условие не задано, то описание
тиражирования действует для всех записей таблицы.
Возможность тиражирования группы записей таблицы означает, в частности, что часть записей
таблицы может быть первичными данными в одном узле, а часть - в других.
Репозитарий - централизованная база данных проекта
Все модели и спецификации, относящиеся к проекту прикладной системы и возникающие на
различных этапах ее жизненного цикла, хранятся в централизованной базе данных - репозитарии.
Работа над проектом во многом сводится к работе с этой базой данных - вводу и коррекции
различных описаний, проверке их согласованности и полноты, преобразованию одних моделей в
другие и т.д. Вся информация в репозитарии, относящаяся к одной и той же прикладной системе,
называется приложением. В общем случае репозитарий может содержать несколько приложений.
Средства доступа к репозитарию обеспечивают удобный многооконный объектно-
ориентированный интерфейс ко всем элементам репозитария в рамках выбранного приложения.
Все данные приложения представляются в виде иерархии типов, двигаясь по которой можно
работать с различными объектами, определяя и уточняя их характеристики с помощью
универсального окна свойств (рис.5).
Репозиторий дизайна приложений (Application Design Repository)
PowerBuilder тесно интегрирован с базой данных, в которой хранится репозиторий дизайна
приложений. Разработчики могут использовать интерфейс в режиме "укажи и щелкни кнопкой мыши"
для определения центрального репозитория, содержащего широкий спектр атрибутов отображения
данных, таких как шрифты, заголовки, метки, форматы изображения, правила проверки и
графические стили редактирования, включая радиокнопки, альтернативы, открывающиеся списки,
открывающиеся Окна данных (DataWindows), одно- и многострочные стили редактирования,
а также шаблоны редактирования ввода данных.
Репозиторий дизайна приложений PowerBuilder повышает производительность разработчика,
облегчает создание стандартов приложений и заставляет следовать этим стандартам во всей
организации. Как только репозиторий определен, значительно ускоряется создание сложных Окон
данных (DataWindows) и отчетов.
Централизованное определение репозитория дизайна приложений ускоряет и упрощает поддержку и
обновление существующих приложений. Разработчики могут определить в репозитории стандарт
создания целостного интерфейса пользователя. Для полноты контроля и гибкости представления
данных в Художнике Окна данных и Художнике отчетов разработчику
предоставлена возможность переопределять для отдельных объектов расширенные атрибуты,
установленные в репозитории.
Одна из черт нашего времени
Одна из черт нашего времени - качественный скачок в автоматизации финансово-хозяйственной
и производственной деятельности предприятий. Программы нового поколения - корпоративные
системы, выполненные в технологии клиент/сервер, - предоставляют такие возможности для
учета и управления, о которых руководители еще недавно могли только мечтать. Ряд ведущих
фирм разрабатывает и предлагает такие проекты для предприятий различных отраслей и видов
деятельности. Сообщения об этом регулярно появляются в компьютерной прессе и компьютерных
рубриках экономических изданий, корпоративные системы демонстрируются на тематических
выставках, семинарах, конференциях.
Результат работы генератора - новый класс объектов
Генератор сохраняет результат работы в виде программы, описывающей новый оконный или
визуальный класс. Эти классы могут использоваться в рамках одного или нескольких
приложений.
Генератор окон сохраняет описание сгенерированного оконного класса в виде нескольких файлов
(рис. 1):
< имя >.wif - файл с описанием структуры окна в формате WIF (Window Intermediate
Format). Этот файл может быть прочитан генератором окон для последующего
редактирования.
< имя >.4gh - заголовочный файл, содержит декларацию нового оконного класса.
< имя >.4gl - программный файл, содержит функции обработки событий в окне и его
органах, заданные программистом. В этом файле содержатся также определения дополнительных
или переопределенных функций оконного класса. Файлы 4gh и 4gl обрабатываются компилятором
и генератором приложений.
Если при формировании окна был задан атрибут "главное окно", то в 4gl-файл будет добавлена
головная функция MAIN. Она будет содержать оператор подключения к БД и вызов главного
окна. Таким образом, простое приложение, не требующее сложной обработки данных, может быть
целиком создано средствами визуального программирования.
< имярис.rs > - для каждого импортированного графического файла, использованного как
элемент оформления окна, создается файл ресурсов.
специально разработана для удовлетворения
Microsoft SQL Server 6.0 - специально разработана для удовлетворения требований, предъявляемых
системами распределенной обработки данных (таких как тиражирование данных, параллельная
обработка, поддержка больших баз данных (БД) на относительно недорогих аппаратных
платформах, сохраняющая простоту управления и использования). Сервер имеет средства
удаленного администрирования и управления операциями, организованные на базе объектно-
ориентированной распределенной среды управления. Новые возможности, такие как OLE
Automation и средства программирования административных задач на языке Visual Basic for
Applications, обеспечивают интеграцию с приложениями, работающими на ПК. По-прежнему
Microsoft уделяет очень большое внимание соответствию своих продуктов существующим
промышленным стандартам, что отразилось в расширенной поддержке ANSI SQL и ODBC.
Microsoft SQL Server 6.0 входит в состав семейства Microsoft BackOffice, объединяющего пять
серверных приложений, разработанных для совместного функционирования в качестве
интегрированной системы. Она позволяет пользователям повысить производительность процесса
принятия решений средствами систем, базирующихся на архитектуре клиент-сервер. Кроме того,
Microsoft SQL Server 6.0 завершает линию средств разработки, включающих Microsoft Access,
Visual FoxPro®, Visual Basic и Visual C++™.
Для каждой из этих областей имеются СУБД, промежуточное ПО для работы в разнородной среде
и инструменты для разработки приложений. Главные требования к этому ПО показаны на
рис.2.
Sybase System 11, наряду со средствами разработки и другим программным обеспечением Sybase,
образует функционально-полный и вместе с тем открытый набор программных средств для каждой
области работы (рис.3).
Современные требования к продуктам клиент/сервер
| OLTP различные виды операций | DSS
хранилища данных | Массовое использование |
Базы данных | Управление данными и
транзакциями |
Промежуточное ПО | Удобство работы в
разнородной среде Преобразование и перемещение данных |
Инструменты | Быстрая разработка
приложений Поддержка многих методик и баз данных |
Особенно остро встает для разработчиков компонент вопрос создания и использования
редакторов свойств, когда свойства имеют сложный тип. Например, свойство может предоставлять
ссылку на достаточно сложную структуру - запись или на строго определенных наследников
одного из стандартных или пользовательских классов (возможные ситуации: 1) класс "множество
данных" TDataSet - является предком и таблиц, и запросов, и хранимых процедур; можно
сформулировать такую задачу, когда в качестве значения свойства в design-time должны выступать
только запросы и таблицы, но, ни в коем случае - хранимые процедуры; 2) шрифт описывается
рядом характеристик, представляемых вложенными записями).
Delphi предоставляет разработчику ряд базовых классов, входящих в иерархию VCL, которые
предназначены для создания редакторов свойств.
Designer/2000
Анализ деятельностиМоделированиеГенерация приложений
Репозитарий
ОтчетыГрафика
Экранные формы
Developer/2000
Цикл разработки в S-Designor
Особенность реализации цикла разработки в S-Designor заключается в том, что он позволяет
выполнять "сквозное проектирование". Это значит, что разработав концептуальная модель можно
автоматически сгенерировать физическую и после этого выполнить генерацию структуры БД. При
обратном проектировании последовательность действий прямо противоположная. Можно получить
физическую модель на основе структуры БД и после этого автоматически сгенерировать
концептуальную модель. Разумеется на каждом этапе можно вносить изменения в модели
концептуального и физического уровней.
Часто возникает вопрос: "Если генерация физической модели из концептуальной и концептуальной
модели из физической выполняется автоматически, надо ли каждый раз корректировать модель
соответствующего уровня"? Ответ - нет. S-Designor четко отслеживает соответствие между
концептуальным и физическим уровнем и "помнит" не только изменения в структуре объектов модели
(уточнения связей, выполненные при переходе на физический уровень), но и их расположение на ER-
диаграмме. При генерации этим "учетом изменений" можно управлять. Таким образом,
автоматическая генерация - процесс, выполняемый в S-Designor очень эффективно и
качественно.
Экран определения нотации модуля BPM
К специфическим особенностям системы относится возможность использования символьных
иерархических идентификаторов процессов вместо числовых, а также удобные функции автоматической
перенумерации объектов диаграмм в порядке расположения на схеме или в указанной пользователем
последовательности. Система может строить дерево процессов и дает возможность переопределять их
иерархическую вложенность перемещением процессов из одних узлов дерева в другие.
Для анализа и реинжениринга бизнес-процессов (BPR) имеется возможность определить используемые
ресурсы и задать их удельную стоимость. При построении моделей можно указывать, какие ресурсы в
каком объеме используются процессами. Система автоматически подсчитывает стоимость каждого
процесса с учетом стоимости его подпроцессов, а также общую стоимость каждого ресурса по всей
модели.
Обозначения мощности связи в нотации IE
Имя связи на логическом уровне представляет собой "глагол", связывающий сущности. Физическое
имя связи (которое может отличаться от логического) для ERwin означает имя ограничения (constraint)
или индекса.
Сокращение времени обработки за счет применения вертикального и горизонтального параллелизма.
Методы фрагментации выполнения применяется в обеих моделях серверов, с той разницей, что
Informix-ODS для выполнения подзапросов и подзадач создает потоки, выполняемые параллельно
на нескольких процессорах, а в Informix-OXPS выполнение подзапросов и подзадач распределяется
между ко-серверами. Фрагментация выполнения дает многократный выигрыш в
производительности на следующих типах задач:
обработка характерных для приложений DSS сложных запросов, которые
включают сканирование, сортировку, соединения огромных объемов данных,
распределенных по множеству дисков и/или ко-серверов, группирование,
вычисление агрегатных функций;
массовые вставки;
построение индексов;
резервирование журналов транзакций, сохранение и восстановление
данных;
загрузка, выгрузка данных, реорганизация баз данных;
Informix - единственная на сегодня СУБД, которая обладает средствами распараллеливания для
столь обширного набора операций.
3.3.1. Вертикальный параллелизм. Итераторы
Элементарные операции, из которых состоит реализация любого запроса, называются
итераторами. Итератор - это программный объект, который воспринимает потоки строк от одного
или двух источников, выполняет над ними некоторый вид обработки и выдает результирующий
поток строк. Источниками данных могут служить дисковые файлы, сетевые соединения,
результирующие потоки других итераторов. Основное свойство итераторов - единообразие их
внешнего интерфейса, благодаря которому они могут произвольным образом объединяться.
Рассмотрим пример выполнения запроса:
SELECT state, SUM(order_item)
FROM customer, order
WHERE order.customer_id = customer.id
GROUP BY state
ORDER BY SUM(order_item)
Дерево его реализации (рис. 2) включает следующие типы итераторов:
SCAN - Сканирует таблицы и индексы.
HASH JOIN - Реализует алгоритм соединения методом хеширования.
GROUP - Группирует данные (GROUP BY) и вычисляет агрегатные функции.
SORT - Сортирует данные.
Дерево итераторов на рис. 2 реализует одновременное выполнение на разных процессорах или ко-
серверах множества циклов обработки данных за счет конвейеризации промежуточных
результатов. Так, результаты сканирования таблиц могут передаваться другому ко-серверу (в
OXPS) или другому потоку (в ODS), который сможет начать соединение по мере поступления
строк исходных таблиц. Результат соединения передается еще одному ко-серверу или потоку,
который начнет выполнять суммирование, и т. д.
3.3.2. Горизонтальный параллелизм. Рефрагментация промежуточных
результатов
Для того чтобы ускорить выполнение запроса, для каждой элементарной операции создается
несколько итераторов, которые распределяются между ко-серверами (OXPS) или выполняются как
отдельные потоки (ODS). Координацией совместной деятельности множества однотипных
итераторов занимается итератор типа EXCHANGE. EXCAHGE рефрагментирует результаты,
полученные от нижележащих итераторов и передает их итераторам верхнего уровня (рис. 3).
3.3.3. Баланс между приложениями OLTP и DSS
Задачи, выполняемые на сервере СУБД, можно разделить на три категории: OLTP, DSS и пакетной
обработки.
Пример OLTP-запроса: Есть ли свободный номер в какой-либо берлинской гостинице на 8-е
декабря?
Пример DSS-запроса: Каковы будут затраты на реализацию стратегии X охраны здоровья
сотрудников по сравнению со стратегией Y с учетом демографического профиля компании?
Традиционная модель данных ADABAS
Традиционная реляционная модель данных
Эта модель соответствует ANSI/ISO стандарту SQL и реализована в виде либо надстройки над
ADABAS-C, либо как неотъемлемая часть ADABAS D.
Модель данных сущность-связь (E/R модель)
В ADABAS предусмотрено расширение до модели Entity-Relationship (или E/R модели) для
управления сложными структурами данных с высокой степенью связности. Оно поддерживает
также рекурсивные структуры данных.
Объединяя эту модель с другими моделями ADABAS можно строить мощные
интегрированные базы данных и, соответственно, прикладные системы. Предпочтительные
области для применения этих моделей - системы представления знаний, моделирование поведения
сложных технических и биологических систем, расчеты потребностей, планирование материальных
ресурсов различного вида и назначения (Bills of Materials).
Обработка и управление произвольными текстами
Этот тип данных (и соответствующие средства манипулирования ими) обеспечивает доступ к
документам, обрабатываемым ADABAS, как к произвольным текстам. Возможно сочетать разного
рода обработку текстовых данных со стандартными процедурами ADABAS для работы с
форматированными данными. Например, библиотеки, юридические конторы, службы новостей,
телекомпании, газеты и журналы, правительственные организации - все, кто имеет и будет иметь
данные в виде т.н. "свободных" или неструктурированных текстов.
Обработка и управление географическими данными
В отличие от традиционных географических (картографических) систем, которые используют
структуры хранения данных (реляционные и др.) независимо от собственно географической
информации, обеспечивая их совместное использование, как правило, только на уровне SQL-
интерфейса, подход SOFTWARE AG характеризуется глубокой интеграцией на всех уровнях
хранения и обработки.
Картографическая информация, координатные привязки объектов, форматированные данные и
текстовая информация неограниченного объема хранятся в рамках единой БД. Точно также в
рамках одной программы и даже одного оператора (среда NATURAL) интегрирована и обработка
этой комплексной информации. Важно, что при этом обеспечивается не только высокая
производительность геоинформсистем, но за счет поддержания логики транзакций гарантируется
целостность и безопасность хранения базы данных и другие ее неотъемлемые характеристики.
Взаимодействие компонент ядра JAM
Редактор Экранов
Визуальное проектирование интерфейса в JAM осуществляется с помощью Редактора Экранов.
Приложения, разработанные в JAM, имеют многооконный интерфейс. Окна (экраны), из которых
состоит интерфейс приложения, разрабатываются в Редакторе Экранов. Разработка отдельного
экрана заключается в размещении на нем интерфейсных элементов, возможной (но не
обязательной) их группировке и конкретизации различных их свойств. Объекты имеют достаточно
широкий набор свойств, включающий визуальные характеристики (позиция, размер, цвет, шрифт
и т.п.), поведенческие характеристики (разнообразные фильтры, форматы, защита от ввода и т.п.)
и ряд свойств, ориентированных на работу с БД.
В распоряжении разработчика имеются следующие интерфейсные элементы:
Статические метки (static label)- произвольный фиксированный текст
или фиксированный графический образ;
Динамические метки (dynamic label)- произвольный текст или графический
образ; может быть изменен в процессе исполнения приложения. Источником
информации может быть БД;
Однострочные текстовые поля ввода/вывода (single line text);
Многострочные текстовые поля ввода/вывода (multi-line text);
Экранные кнопки (pushbutton);
Переключаемые экранные кнопки (toggle button)- фиксируется состояние
нажата/отпущена;
Элементы единственного выбора (radio button);
Элементы множественного выбора (check box);
Прокручиваемые списки (list box);
Опциональные меню (option menu) - осуществляет выбор одного значения
из раскрывающегося меню;
Комбинированные меню (combo box) - комбинация опционального меню и
однострочного текстового поля;
Шкалы (scale) - элемент ввода/вывода числовых данных;
Табличные фреймы (grid) - объединяет элементы типов "однострочный
текст" и "динамическая метка" в табличное представление;
Графические диаграммы (graph);
Линии (line);
Рамки (box).
Данный набор элементов вполне соответствует стандарту CUA и является функционально полным
для разработки приложений информационных систем.
Некоторые однотипные объекты можно объединять в группы следующих видов:
Синхронизированные группы - обеспечивается синхронизированная
прокрутка содержимого нескольких объектов
Группы выбора - обеспечивается пометка нескольких строк содержимого
объекта;
Разнотипные объекты можно объединять в специальные группы "Образ
таблицы БД" (table view).
В графическом Редакторе JAM реализован режим перемещения элементов с помощью мыши (drag
and drop) и возможность работы в одном сеансе с несколькими проектируемыми экранами. С
помощью нескольких служебных окон Редактора возможно уточнение характеристик элементов
(размеры, цвет, позиция и др.).
JAM является событийно-ориентированной системой, т.е. для каждого типа интерфейсных
элементов приложения определен набор событий (открытие и закрытие для экранов, работа с
фокусом для управляющих элементов и элементов ввода/вывода, событие "проверка" (validation),
нажатие клавиш клавиатуры и т.д.). Определение обработчиков этих событий осуществляется в
Редакторе и задает логику работы приложения. Обработчиками событий могут быть:
Функции ядра JAM - более 300 функций самого различного назначения,
включая функции динамического (т.е. в процессе исполнения приложения)
изменения свойств объектов;
Функции, написанные на JPL (внутренний процедурный интерпретируемый
язык JAM); Из JPL-функций доступны функции ядра;
Функции, написанные на любом внешнем языке программирования 3-го
поколения (C, Pascal, Fortran и т.п.), совместимом по вызовам с C; Из этих
функций доступны функции ядра JAM и JPL-функции.
Редактор экранов JAM может работать в одном из трех режимов:
Режим редактирования (Edit Mode) - разработка экранов;
Режим тестирования (Test Mode) - тестирование разрабатываемых
экранов;
Режим приложения (Application Mode) - интерпретация всего приложения в
целом.
На рис. 2 представлена диаграмма переходов между режимами Редактора Экранов.
Режим приложения
Режим редактирования
Sybase System 11 выпущена
Sybase System 11 выпущена сейчас для основных UNIX-платформ. Версии Sybase SQL Server для
Intel-платформ ожидаются в первой половине 1996 года.
Sybase: Единая архитектура, оптимизированные продукты
| OLTP различные виды операций | DSS
хранилища данных | Массовое использование |
Базы данных | SQL Server - серверные
продукты Высокая производительность и масштабируемость для бизнес-
приложений |
Промежуточное ПО | Enterprise CONNECT -
разнородные системы Интероперабельность и репликация |
Инструменты | Семейство продуктов PowerBuilder Стандарт де-факто при разработке приложений, работающих с различными базами
данных |
Первая версия CASE-инструментария фирмы ORACLE, ORACLE*CASE 5.0 появилась в 1989 году
для сервера ORACLE/6 с ориентацией на символьный режим для конечного пользователя.
Существенные изменения потребовались в следующей версии, ORACLE*CASE 5.1 (1993г.), в связи
с реализацией нового сервера ORACLE/7 и перехода к графическому интерфейсу конечного
пользователя. В настоящее время завершена работа по выпуску в промышленную эксплуатацию
новой CASE-среды под названием DESIGNER/2000, работающей в среде MS WINDOWS. Этот
продукт вместе со средствами разработки DEVELOPER/2000 реализуют новый подход фирмы
ORACLE к общей среде создания и сопровождения прикладных систем (рис. 2).
Стандартные редакторы свойств ( более 20) являются наследниками базовых редакторов и, вместе с
последними, доступны программисту для расширения/изменения функциональности, опять-таки, с
использованием механизмов наследования и полиморфизма. Регистрация редакторов свойств и
регистрации компонент аналогична регистрации самих компонент.
Так как редакторы свойств и редакторы компонент определяют design-time, существование
таких редакторов и возможность расширения их функциональности являются вторым признаком
открытости Delphi.
Административная консоль SQL Server
Администратор может создавать новые группы, группировать серверы удобным с
административной точки зрения образом, выполнять манипуляции над объектами (базами данных,
таблицами, хранимыми процедурами, триггерами и т.д.).
К сожалению, когда принимается решение о выборе мощной СУБД масштаба предприятия, из
внимания специалистов, принимающих это решение, часто ускользает то обстоятельство, что ПО
подобного класса обязательно должно включать развитые средства администрирования. В
крупных информационных системах СУБД выполняет не только функции "мясорубки" по
перемалыванию колоссальных объемов информации, но и сложные функции
администрирования.
Microsoft SQL Server 6.0 предлагает "активную" модель администрирования системы. В отличие от
предыдущей версии продукта, администратор получил в свое распоряжение средства,
позволяющие предупреждать неблагоприятное развитие событий вместо того, чтобы, сломя
голову, кидаться исправлять последствия сбоя системы, когда пользователи уже не имеют доступа
к хранящейся в ней информации. SQL Server 6.0 позволяет определять так называемые
предупреждения (alert), которые являются реакцией системы на возникновение того или иного
события.
Как видно из рис.3 , предупреждение срабатывает при возникновении
ошибки с кодом 018 в базе данных master.
Дерево реализации запроса
Примеры заданий пакетной обработки - массовая загрузка данных, выдача сложных отчетов,
действия по реорганизации базы данных.
Архитектурные и технологические решения, о которых говорилось выше, направлены на то, чтобы
обеспечить эффективную обработку всех типов заданий. Однако не менее важная проблема -
обеспечить рациональное одновременное выполнение смеси таких задач на сервере. Если
применение методов фрагментации выполнения ничем не ограничено, то сильно распараллеленное
выполнение нескольких сложных запросов приведет к недопустимому замедлению OLTP-
приложений, выполняющихся на том же сервере.
Для решения этой проблемы предусмотрены механизмы регулирования, которые позволяют
динамически управлять степенью распараллеливания запросов и долей системных ресурсов,
выделяемых для параллельной обработки сложных запросов. В часы наиболее активной работы
приложений OLTP запросы DSS могут выполняться с невысокой степенью распараллеливания. В
остальное время, или на серверах, где приложения OLTP отсутствуют, устанавливается
максимальная степень использования параллельной обработки.
Диаграмма уровня сущности
Теперь перейдем в режим задания атрибутов (Display/Atribute Level). В редакторе "Entity/Attribute"
зададим на русском языке имена ключевых и неключевых атрибутов. Заметим, что для дочерней
сущности "дети" ключевой атрибут "номер служащего" не указывается вручную. ERwin обеспечивает
его миграцию из родительской сущности. То же происходит с другими дочерними сущностями.
Для атрибута "имя" сущности "служащий" укажем, что он является альтернативным ключом (будем
считать, что у всех служащих уникальные имена/фамилии). Для этого после имени атрибута поместим
указатель AK1 в скобках.
Результат работы отображен на диаграмме ERwin (рис. 3) в нотации IDEF1X.
Классификация архитектур клиент/сервер
SOFTWARE AG использует этот подход для поддержки прикладных проектов, предлагая
широкий набор собственных программных продуктов.
С целью интеграции в приложения функциональности программных средств других фирм
соблюдены многочисленные интерфейсы, получившие общее признание.
Переходы между режимами Редактора Экранов
Каждый экран, входящий в приложение, сохраняется в виде отдельного файла. Кроме этого,
экраны могут сохраняться в виде библиотек экранов. Библиотека экранов представляет собой
файл, содержащий хранящиеся экраны и индексную таблицу, ускоряющую поиск необходимых
экранов. Одновременно в системе может быть открыто несколько экранных библиотек.
Приложение NewEra может
Генерация отчетов. NewEra предоставляет средства для описании структуры текстовых отчетов и
их генерации. Более современные, графические, средства создания отчетов имеются в системе
Informix-ViewPoint Pro, которая входит в комплект поставки NewEra (см. ниже).
В то же время
В то же время на Intel-платфорах работает СУБД для рабочих групп Sybase SQL Anywhere 5.0 -
новая версия популярной СУБД Watcom SQL, которая теперь имеет режим совместимости с Sybase
SQL Server на уровне языка и интерфейсов.
Серверные продукты Sybase System 11
| OLTP различные виды операций | DDS
хранилища данных | Массовое использование | |
| СУБД |
Первый этап связан с моделированием и анализом процессов, описывающих деятельность
организации, технологические особенности работы. Целью является построение моделей
существующих процессов, выявление их недостатков и возможных источников
усовершенствования. Этот этап не является обязательным в случае, когда существующая
технология и организационные структуры четко определены, хорошо понятны и не требуют
дополнительного изучения и реорганизации. В состав DESIGNER/2000 входят удобные средства
поддержки этого этапа, позволяющие строить наглядные представления процессов и взаимосвязей
между ними и анализировать их с использованием средств мультимедиа.
На втором этапе разрабатываются детальные концептуальные модели предметной области,
описывающие информационные потребности организации, особенности функционирования и т.д.
Результатом являются модели двух типов - информационные, отражающие структуру и общие
закономерности предметной области, и функциональные, описывающие особенности решаемых
задач.
На следующей стадии, этапе проектирования, на основании концептуальных моделей
вырабатываются технические спецификации будущей прикладной системы - определяется
структура и состав базы данных, специфицируется набор программных модулей. Первоначальный
вариант проектных спецификаций может быть получен автоматически с помощью специальных
утилит на основании данных концептуальных моделей.
И наконец, на этапе реализации создаются программы, отвечающие всем требованиям проектных
спецификаций. Использование генераторов приложений, входящих в состав DESIGNER/2000,
позволяет полностью автоматизировать этот этап, существенно сократить сроки разработки
системы и повысить ее качество и надежность.
В соответствии с общей архитектурой инструментальные средства, входящие в состав
DESIGNER/2000, разбиваются на следующие компоненты (рис. 4):
средства доступа к репозитарию
средства управления репозитарием
средства анализа деловой деятельности
средства концептуального моделирования
средства проектирования системы
генераторы приложений
|
навигатор объектов репозитария
матричный диаграммер
средства администрирования
средства моделирования процессов
диаграммер ER-моделей
диаграммер иерархии функций
диаграммер потоков данных
диаграммер структуры приложения
навигатор параметров
навигатор процедурной логики
диаграммер баз данных
диаграммер модулей
генератор сервера
генератор форм
генератор отчетов
|
Архитектура взаимодействия с СУБД
Кроме написания SQL-запросов непосредственно разработчиком, в JAM существует возможность
автоматической генерации SQL-запросов. Эта возможность реализуется Менеджером Транзакций
JAM. Работа Менеджера Транзакций основана на том, что объекты приложения имеют ряд
свойств, характеризующих взаимосвязь объекта приложения с объектом БД и то, как эти объекты
участвуют в операциях с БД (SQL-операторы select, insert, update, delete). Экранные интерфейсные
элементы (поля ввода/вывода) отображаются в поля таблиц БД. Экранные поля, отображаемые на
одну таблицу БД, группируются в группу типа Образ Таблицы (table view). Кроме этого,
существуют специальные объекты типа связь (link), описывающие связи между таблицами БД. Эта
информация в подавляющем большинстве случаев является достаточной для автоматической
генерации SQL запроса для выполнения той или иной операции с БД. Задание этой информации
может быть осуществлено или непосредственно разработчиком, или же автоматически при
импорте структуры БД (метаданных) в Репозиторий JAM. При этом для каждой таблицы БД в
Репозитории JAM создается отдельный вход (entry), в котором создается соответствующий Образ
Таблицы (table view) и свойства объектов (т.е. членов группы table view) настраиваются
соответствующим образом. Если СУБД, структура БД которой импортируется, поддерживает
конструкции "primary / foreign keys", то будут автоматически созданы объекты типа связь (link).
Для разработки приложений с использованием Менеджера Транзакций в Редакторе Экранов
предусмотрены следующие возможности:
Окно DB Interaction - представляет в графическом виде образы всех
таблиц (Table View), присутствующих на разрабатываемом экране, и их
отношения друг с другом;
Опция Trace On / Trace Off - в режимах приложения и тестирования
трассируются все SQL команды, генерируемые Менеджером Транзакций;
Отладчик ядра JAM позволяет более детально анализировать работу
Менеджера Транзакций; возможна установка точек прерывания при
активизировании Менеджера Транзакций.
Менеджер Транзакций, получив ту или иную команду, анализирует соответствующие свойства
экранных объектов, строит необходимый SQL-запрос и исполняет его. Команды менеджера
Транзакций имеют очень простую и краткую форму и могут не зависеть от содержимого
экрана.
Таблица 1>
Основные команды Менеджера Транзакций
Команда
| Действие |
NEW
| Подготовка к вводу новых
записей, в том числе и для нескольких связанных
таблиц |
VIEW
| Выбор информации из БД с
целью просмотра |
SELECT
| Выбор информации из БД с
целью изменения, отличается от команды VIEW установкой
блокировок |
CONTINUE
| Повторить предыдущую
команду VIEW или SELECT для следующей
записи |
SAVE
| Запись сделанных измененной в
БД |
CLOSE
| Перевод Менеджера
Транзакции в начальное состояние |
В табл. 1 приведены основные команды Менеджера Транзакций и их краткое
описание.
В результате вместо написания SQL запроса, который может состоять из десятка строк, достаточно
вызвать Менеджер Транзакций с соответствующей командой. Например, err =
sm_tm_command("SELECT").
Непосредственно работа Менеджера Транзакций определяется Моделью Транзакции. Модель
Транзакции - это алгоритм реализации каждой команды Менеджера Транзакции, который
определяет все аспекты его работы, например установку блокировок при выполнении команды
SELECT (выборка для модификации), генерацию уникального первичного ключа при добавлении
новой записи (если сама СУБД не реализует этой возможности) и т.д. Для каждой поддерживаемой
СУБД в составе соответствующего JAM/DBi поставляется своя Модель Транзакции. Модель
Транзакции поставляется в исходных кодах и опытные разработчики могут таким образом
модифицировать поведение Менеджера Транзакции. Каждая Модель Транзакции имеет имя и даже
для одной СУБД в одном приложении может быть определено и использовано несколько Моделей
Транзакции.
В зависимости от контекста команды, выполняемой Менеджером Транзакций, существует
возможность управления поведением экранных объектов. Например, при выполнении команды
VIEW (транзакция "только чтение") можно запретить ввод или изменение информации в экранных
полях и сделать кнопку "Запись" неактивной. Эта возможность реализуется через механизм стилей
JAM. Стиль - это определение свойств для различных контекстов команд. Компонента JAM
Редактор Стилей, которая упоминалась выше, позволяет разработчику определять свои
стили.
JAM может работать практически со всеми распространенными РСУБД, включая Oracle, Informix,
Sybase, Ingres, Rdb, DB2, InterBase, Gupta, Netware SQL Server, ODBC-совместимые БД и др.
Диаграмма уровня атрибутов в нотации IDEF1X
Вид той же диаграммы в нотации IE (Information Engineering) показан на рис.4.
Диалог описания предупреждения
Привязка предупреждения к конкретной базе данных дает возможность назначать различную
реакцию системы на события в различных базах данных. Помимо встроенных кодов ошибок
предупреждение может реагировать на пользовательские ошибки, определяемые в коде хранимых
процедур и триггеров. При необходимости может быть вызвана на исполнение описанная
предварительно задача и послано сообщение администратору по электронной почте или на
пейджер.
Конечно, неплохо на каждый "чих" вызывать администратора, но как быть организациям с
разветвленной структурой, не имеющим возможности закрепить за каждым сервером специалиста
высокой квалификации? Что делать, если проблема возникла вечером, в выходные? К счастью,
активная модель администрирования SQL Server очень хорошо проявляет себя именно в таких
сложных ситуациях.
Мы уже упоминали, что к предупреждению можно привязать ту или иную задачу. Задача может
представлять собой:
команду операционной системы, .CMD или .EXE файл;
команду процесса тиражирования;
команду чтения журнала;
команду процесса синхронизации процесса тиражирования;
выражение языка Transact-SQL (в том числе имя хранимой процедуры).
В результате, прежде чем выдергивать администратора среди ночи из теплой постели, система в
состоянии сделать попытку самостоятельно решить возникшую проблему (конечно, если
администратор заранее подготовил ее к этому). И только в том случае, если задача после
выполнения сообщает о невозможности решения возникшей проблемы, имеет смысл прибегать к
помощи человека. Каждой задаче можно назначить вызов администратора по электронной почте
или пейджеру при успешном завершении или провале.(Рис.4)
Cерверные продукты Sybase System
Cерверные продукты Sybase System 11 обладают мощной и гибкой архитектурой, построенной на
основе продуктов и библиотек Sybase Open Client/Server . Среди основных
серверных продуктов Sybase System 11 (рис.4):
Sybase SQL Server - мощная высокопроизводительная реляционная СУБД;
Sybase MPP - расширение архитектуры Sybase SQL Server, разработанное и
оптимизированное для массовой параллельной обработки. Он обладает
открытой параллельной архитектурой, предназначенной для поддержки очень
больших баз данных (VLDB);
Sybase IQ - серверный механизм построения битовых индексов для
высокоскоростного выполнения сложных запросов к большим объемам данных;
Sybase SQL Anywhere - "легкая" полнофункциональная СУБД на Intel-
платформах для мобильных пользователей и небольших групп;
Sybase Replication Server - репликационный сервер для построения
распределенных систем на основе тиражирования данных;
Sybase OmniConnect - сервер, обеспечивающий работу приложений-
клиентов в "прозрачном" режиме с несколькими серверами так, как будто
работа идет с одним сервером; при этом в распределенную систему могут
включаться СУБД различных производителей - Sybase, Oracle, IBM и т.д.
Вспомогательные серверные продукты Sybase System 11 включают:
Sybase Backup Server - специальный сервер для высокопроизводительной
выгрузки и загрузки баз данных, не требующий остановки SQL Server и не
снижающий его производительности;
Sybase Monitor Server - в сочетании с графической клиентской частью
выполняет мониторинг различных параметров состояния SQL Server;
Sybase Replication Agent - специальные компоненты, отслеживающие
изменения в данных через журналы транзакций различных СУБД для
включения их в систему репликации. Replication Agent существуют, в частности,
для Sybase SQL Server, Oracle, DB2, Sybase SQL Anywhere.
Sybase Audit Server - записывает информацию о действиях пользователей в
специальную базу данных, доступную для анализа.
К инструментальным средствам фирмы Sybase относятся, в частности, лидирующее средство
быстрой разработки приложений PowerBuilder и CASE-система S-Designor, выпускаемые
подразделением Powersoft. Эти средства работают со всеми основными СУБД. В первой половине
1996 года выпускаются версии PowerBuilder 5.0 (с новыми средствами компиляции и
распределенными объектами) и S-Designor 5.0 (с модулями описания бизнес-процессов, моделей
данных и генерации приложений). Фирма АлконсСофт является бета-тестером данных продуктов.
PowerBuilder и S-Designor подробно описаны в публикациях .
Наличие средств построения программных модулей генерации кода и обработки внутренней IDE-
информации, называемых экспертами, являются третьим признаком открытости архитектуры
Delphi.
Диаграмма уровня атрибутов в нотации IE
Так как имена атрибутов и сущностей задавались нами на русском языке, для перехода к физическому
уровню модели следует поставить им в соответствие идентификаторы таблиц, колонок и ограничений,
удовлетворяющие правилам целевой СУБД (обычно это означает использование латинских букв,
цифр и некоторых специальных символов).
В редакторе "Database Schema" указываем для каждой сущности соответствующее имя таблицы.
Затем в редакторе "Attribute Definition" задаем имена колонок таблиц, соответствующие атрибутам
сущностей. ERwin и здесь обеспечивает миграцию имен колонок в подчиненные таблицы.
На этом этапе можно воспользоваться и редактором "Extended Attributes" для определения
расширенных атрибутов PowerBuilder (формата отображения, маски редактирования, правила
контроля, выравнивания, заголовков и комментариев).
В редакторе "Relationship Definitions" указывается физическое имя связи, которое соответствует
имени ограничения (constraint), создаваемого ERwin в базе данных.
Теперь все готово к созданию БД и нужно выбрать целевую СУБД (если этого не было сделано
раньше). Выберем, например, Sybase System 10.
В редакторе SYBASE Database Schema задаем типы данных для колонок таблиц.
Диалог, в котором происходит выбор типа данных, приведен на рис.5.
Диалог описания задачи
Теперь давайте рассмотрим сценарий, по которому могут развиваться события. Ночью произошел
сбой в электросети. Источник бесперебойного питания выработал свой ресурс, потом выполнил
ShutDown сервера, и система прекратила работу. Со временем электропитание было
восстановлено, и компьютер снова включился. Не секрет, что Windows NT способна выполнять
автоматическую, без участия человека, регистрацию в сети. В силу того, что SQL Server и SQL
Executive представляют собой сервисы операционной системы, им можно назначить атрибут
"стартовать автоматически". SQL Server стартовал, и на исполнение была запущена хранимая
процедура, которая также имеет атрибут "автостарт". Такая процедура может, например,
выполнить проверку целостности базы данных. Если проверка прошла успешно, система
продолжает работу в штатном режиме. Если проверка показала, что система неработоспособна,
можно пойти как минимум двумя путями: хранимая процедура генерирует ошибку, вызывающую
предупреждение, которое, в свою очередь, вызывает на выполнение задачу. Можно сразу поднять
тревогу и вызвать администратора.
Но электронная почта пригодна не только для того, чтобы поднимать тревогу, она может
использоваться и для штатной работы. SQL Server 6.0 умеет читать почту и отвечать на письма. В
том случае, когда задержки на прохождение электронного письма не критичны для работы,
пользователь или администратор могут использовать почту для посылки запросов серверу и
получения от него ответа. Это позволяет обращаться к серверу в режиме Off-line практически с
любого компьютера (как известно, клиентское приложение одной из наиболее популярных в
России коммуникационных сетей - Релком - прекрасно работает даже на машинах с процессором
286).
Инфраструктура среды распределенных приложений
Данный продукт предлагает коммуникационный интерфейс, с помощью которого части (или
разные) приложения могут обмениваться информацией. Функции интерфейса поддерживают
синхронное и асинхронное взаимодействие приложений, при этом, первый тип наиболее
подходит для реализации диалоговых систем, тогда как второй - для систем типа запрос/ответ
или предполагающих обмен большими объемами данных.
С точки зрения архитектуры продукт ENTIRE BROKER выполнен в виде ядра -
коммуникационного сервера, регистрирующего доступные в сети серверы приложений
(функциональные серверы) и клиентов, запрашивающих данные серверы.
Взаимодействие клиентов ENTIRE BROKER с ядром базируется на еще одном продукте
SOFTWARE AG - ENTIRE NET-WORK, с помощью которого взаимодействие частей
приложения становится полностью независимым от используемого в системе транспортного
протокола.
В качестве языков, на которых может быть разработано приложение, использующее как
возможности обращения к функциональным серверам (клиенты), так и собственно
функциональные серверы, могут быть использованы наиболее распространенные языки,
поддерживающие CALL-интерфейс.
Рекомендуемый SOFTWARE AG подход к построению распределенных приложений состоит в
разработке их частей на NATURAL, в котором имеется полный набор компонентов, необходимых
для построения распределенных приложений не зависящих от аппаратно-программных платформ.
Сочетание ENTIRE BROKER, ENTIRE NET-WORK и NATURAL обеспечивает
прозрачность для клиентов местонахождения сервера (необходимо знать только своего
брокера), создавая администраторам прикладных систем условия для их правильного
масштабирования.
Модель базы данных в модуле RDM
Структура данных, на основе которой будет строится
ER-модель
Любые комбинации столбцов таблиц и связей можно выделить для генерации индексов. SILVERRUN
сама может сгенерировать индексы для первичных и альтернативных ключей, а также операторы
контроля ссылочной целостности на основе характеристик связей.
В модели имеются конструкции для подтипов и альтернативных связей. Причем отсутствует требование
принадлежности только к одному подтипу, что позволяет моделировать встречающиеся на практике
ситуации, не попадающие под определение категоризации в таких нотациях, как, например, IDEF1.
Для поддержки различных методологий модуль RDM предоставляет возможность переопределения
нотации. На рис. 5 изображен экран выбора графических символов для представления различных
характеристик связей.
Взаимодействие JAM, CASE и СУБД
На рис. 4 приведена схема взаимодействия JAM и CASE с использованием модуля
JAM/CASEi.
Следует отметить, что модуль JAM/CASEi позволяет осуществлять импорт/экспорт не только в
раздел ERD репозитория CASE, но и в раздел DFD.
Кроме модуля JAM/CASEi фирма-производитель распространяет модуль JAM/CASEi Developer's
Kit. С помощью этого модуля можно самостоятельно разработать интерфейс (т.е.
специализированный модуль JAM/CASEi) для конкретного инструмента CASE, если готового
модуля JAM/CASEi для данной CASE-системы еще не существует.
Системный администратор может разделить
Системный администратор может разделить кэш SQL Server на несколько именованных областей и
приписать эти области различным базам данных и объектам баз данных. Имеется возможность
группировать именованные области кэша так, чтобы более эффективно проходил обмен с диском
большими блоками. Связывание именованных кэшей и объектов баз данных осуществляется при
помощи вызова системных процедур (рис.6).
Средства управления репозитарием с помощью аналогичного интерфейса реализуют
административные функции управления, включая создание и удаление приложений, управление
доступом к данным со стороны различных пользователей, предоставление прав одному
приложению использовать часть спецификаций другого, экспорт и импорт отдельного
приложения или всего репозитария и т.д.
Как унифицированный доступ ко всем спецификациям указанные средства удобны при получении
справочной информации, корректировки отдельных параметров. Однако в процессе создания
прикладной системы, т.е. при построении моделей различных уровней удобнее пользоваться
альтернативными средствами ввода информации в репозитарий, ориентированными на заданный
тип моделей и позволяющими кроме ввода символьной информации получать графические
представления в виде различных диаграмм и схем.
И действительно, ряд производителей программных продуктов, относящихся к перечисленным
категориям, заявил о поддержке ими Delphi на достаточно высоком уровне интеграции
(подразумевая, например, для CASE-систем, не только генерацию кода в соответствии с
синтаксисом Object Pascal, но и доступ к таким продуктам непосредственно из IDE). В качестве
примера можно привести компанию Popkin Software (производителя CASE-средства System
Architect), объявившую о поддержки Delphi в своих продуктах еще в августе 1995 года. Известен
ряд систем контроля версий - Intersolv PVCS и MKS Source Integrity, способных работать с Delphi
(32-разрядная версия PVCS входит в поставку Delphi Client/Server Suite 2.0, планируемого к выходу
в первом квартале 1996 г.) и , например, мониторов транзакций (существует опыт взаимодействия с
Novell Tuxedo и др.).
Описанные возможности интеграции с внешними приложениями на базе совокупности открытых
интерфейсов, определяют четвертый признак открытости архитектуры Delphi.
Диалог определения прав доступа
Уровень
| Компоненты SQL Server 6.0 DMF |
Уровень 1
Представление/Манипуляция
| Средство администрирования SQL Enterprise Manager,
программирование на Visual Basic или Visual FoxPro |
Уровень 2 Объекты управления
| OLE интерфейс для доступа ко всем средствам
администрирования и управления SQL Server |
Уровень 3
Реализация/Обработка
| Процессор данных SQL Server, сервисы SQL Executive |
Архитектура SQL-DMF изначально предназначена для работы в распределенных средах и
предоставляет необходимую гибкость и масштабируемость за счет разделения процесса
администрирования на три четко определенных уровня:
Экран выбора символов для характеристик связей
Различные группы пользователей имеют доступ к разным подмножествам базы данных и к ограниченному
набору операций над ними. Для моделирования пользовательских (внешних по терминологии ANSI
SPARC) представлений в модуле RDM используется механизм подсхем. Подсхема - это подмножество
модели данных, доступное конкретному приложению или группе пользователей. SILVERRUN позволяет
управлять "прозрачностью" границы между схемой и подсхемой, а также по требованию интерактивно
переносить изменения из схемы в подсхему и наоборот. Число уровней подсхем не ограничено: можно
создавать подсхемы подсхем.
Определение физической модели
Теперь можно перейти к созданию базы данных. Для этого выполняется команда "Sybase schema
generation". ERwin построит пакет SQL-предложений генерации базы данных. На рис.6 показан диалог выбора параметров генерации пакета для генерации БД.
На рисунке видно, что может быть задан фильтр (генерация не всех таблиц), пакет SQL-предложений
можно просмотреть (preview), распечатать, сохранить в файл (report), выполнить генерацию
(generate).
Схемы удаленного доступа к БД ADABAS посредством SQL
В случае, если прикладная система написана на NATURAL или языках 3-го поколения с
использованием языка манипулирования данными (ЯМД) СУБД ADABAS, доступ к удаленной
СУБД реализуется в соответствии с рис. 6.
Платформа СЭВМ (UNIX, IBM) | |
|
IBM, UNIX, MS Windows | MS Windows |
Платформы клиентов
Запросы на выборку данных
Запросы на выборку данных и запросы на их изменение в этом случае не блокируют друг друга, и
конкретные приложения, для которых допустим режим "грязного чтения", могут существенно
выиграть в производительности. В то же время для транзакций, требующих целостности данных,
нельзя использовать уровень изоляции 0.
Установка уровня изоляции может производиться либо для конкретного запроса SELECT, либо
для сессии пользователя в целом.
Диаграмма строится из стандартных элементов, основными из которых являются:
Базовый процесс - процесс, определяющий общий контекст для всех подпроцессов данной
диаграммы, т.е. тот главный процесс, который описывается данной диаграммой.
Шаг процесса - определенная часть деятельности в рамках базового процесса;
впоследствии любой шаг может служить основой для нового базового процесса и новой
диаграммы.
Хранилища - предназначены для представления некоторого информационного фонда или
материального склада.
Потоки - описывают передачу информации или материальных объектов между двумя
шагами процессов или между процессом и хранилищем.
Организационные единицы - представляют структуру предприятия или фирмы; допускается
иерархическая структура организационных подразделений без ограничения на уровень
вложенности.
События - могут быть входные и выходные; служат для связи различных диаграмм
процессов.
По мере уточнения модели классифицируются шаги процессов (ввод данных, принятие решений,
выдача отчета), типизируются потоки (поток данных, материальный поток, временный поток),
хранилища (хранилище данных, материальный склад) и др. элементы. Для каждого типа можно
использовать свое графическое представление, окраску (рис.7).
Вследствие такой открытости архитектуры Delphi, большое количество третьих компаний уже
выбросило на рынок (или объявило о соответствующих планах) как различные расширения
библиотеки компонент VCL (более 200 только коммерческих наборов компонент на октябрь
1995г.) так и средства интеграции своих продуктов (external-site interface).
Компоненты SQL-DMF
Ранее существовавшие подходы к системному администрированию приводили к запоздалой
реакции на сбой системы, а администратору отводилась роль "пожарного". С другой стороны,
обработчик событий SQL Executive изначально проектировался для поддержки активной модели
администрирования, позволяющей администратору определять предупреждения и проводить
корректирующие операции до возникновения проблемы. Кроме того, администратор может
заранее определить уведомления, которые будут рассылаться по электронной почте или на
пейджер.
SQL Executive работает как сервис операционной системы и при необходимости может быть
запущен автоматически для загрузки списка задач, хранящегося в таблице SQL Server.
Консолидация модели данных с моделью в словаре
Возможные режимы консолидации в S-Designor:
Consolidate
- | консолидировать модель с моделью в словаре.
|
Simulate
- | имитировать консолидацию без внесения
реальных изменений в словарь метабазы. |
Create
- | создать проект или модель в
словаре. |
Replace
- | заменить существующую модель. Данный
режим эффективно использовать в случае, если консолидируемая
модель значительно отличается от модели в словаре. |
Создавая проект администратор может указать имя пользователя, который станет
владельцем этого проекта или сделать это после создания проекта. Так назначается владелец
проекта.
Проект может включать несколько моделей данных (Рис.7).
Обеспечивается возможность одновременно разрабатывать отдельные модели отдельными
разработчиками. Консолидацию выполняет администратор проекта или пользователь, имеющий
соответствующие полномочия.
Схемы удаленного доступа к БД ADABAS посредством ЯМД ADABAS
Данный интерфейс предлагается фирмой SOFTWARE AG в качестве основного при разработке
переносимых приложений в среде ADABAS/NATURAL.
Как видно из рисунка клиентами СУБД ADABAS могут быть не только приложения, выполняемые
в среде рабочих станций, но и приложения, написанные на NATURAL или языках
программирования 3-го поколения и выполняемые как под Windows, так и в среде IBM и UNIX.
Дополнительно к основному интерфейсу языка манипулирования данными для платформы
Windows SOFTWARE AG предлагает доступ к базам данных ADABAS с помощью DDE-
протокола, оформляя доступ к СУБД в виде DDE-сервера (ADADDE). Некоторые примеры
программных продуктов, поддерживающих DDE-протокол, также приведены на рис. 6.
Наряду с удаленным доступом к базам данных ADABAS, SOFTWARE AG предлагает
использовать продукт ENTIRE ACCESS для доступа к реляционным базам данных третьих фирм
из приложений, написанных на NATURAL (рис. 7).
С любым отдельным шагом
С любым отдельным шагом процесса или с потоком можно связать специальное изображение в
виде иконки, звуковое сопровождение, повышая выразительность и наглядность всей диаграммы в
целом. Для более детального рассмотрения отдельный шаг процесса можно также связать с заранее
заготовленным видеоклипом, показывающим, как осуществляющий соответствующий
технологический этап в реальной жизни (рис.8).
Схемы удаленного доступа к реляционным СУБД с помощью ENTIRE ACCESS
ENTIRE ACCESS позволяет разработчику приложений полностью использовать преимущества
NATURAL как универсального инструментария разработки переносимых приложений в
средах неоднородных баз данных, обеспечивая доступ не только к удаленным, но и к локальным
(работающим на той же ЭВМ, что и приложение) реляционным базам данных других фирм.
Предоставляемый этим продуктом интерфейс позволяет разработчику приложений на NATURAL
применять для доступа к реляционным СУБД, наряду с ANSI SQL, синтаксис ЯМД,
реализованный в NATURAL для доступа к базам данных ADABAS.
При этом из одной программы NATURAL возможно обращение к нескольким реляционным
СУБД разных изготовителей и работающим на разных платформах.
Внутренняя исполнительная система NATURAL преобразовывает предложения ЯМД и SQL в
вызовы ENTIRE ACCESS, выполняющего необходимые преобразования форматов данных и
обмен сообщениями с соответствующей СУБД.
В качестве транспорта запроса к удаленной РСУБД применяется продукт ENTIRE NET-
WORK.
Список моделей проекта
Создав проект, администратор назначает пользователям полномочия, например, на отдельные
подмодели. Полномочия действуют в момент консолидации. Модели или подмодели, на которые
пользователи не имеют полномочий, недоступны для редактирования.
Реализуя функцию управления доступом для моделей и подмоделей данных, S-Designor
обеспечивает возможность руководителю проекта контролировать все изменения, которые влияют на
проект в целом. При этом, модель данных всегда доступна, актуальна и гарантированно целостна.
Структура объектной модели SQL Server
Системы архитектуры клиент-сервер предлагают много новых задач, требующих нового подхода.
Мощные серверы баз данных должны адаптироваться к растущим требованиям динамичной и все
более усложняющейся работы в распределенных средах. SQL Server 6.0, снабженный развитой
средой администрирования распределенных систем, удовлетворяет этим требованиям.
Выбор синхронизируемых таблиц
ERwin "знает" о таких особенностях хранения данных в отдельных СУБД, как сегменты (в Sybase) и
табличное пространство (в Oracle). Информация о физическом размещении может быть включена в
модель и использована при прямом и обратном проектировании.
В одном или нескольких
В одном или нескольких узлах (СУБД), которым нужны измененные данные, в обслуживающем его
репликационном сервере создается подписка (subscription) на соответствующее описание
тиражирования. Здесь будет поддерживаться (с небольшой задержкой) копия первичных
данных.
Современные СУБД используют системный журнал, в который делаются записи о изменениях в
базе данных и завершении транзакций. Журнал используется сервером БД для отката и доката
транзакций после сбоев и для резервного копирования. Репликация данных в Sybase также
использует журнал как источник информации о завершенных транзакциях.
В узле, содержащем первичные данные, для каждой тиражируемой базы данных запускается
специальная компонента - репликационный агент (Replication Agent - RA). Он подключается к
серверу БД и получает от него уведомления о завершении транзакций. Измененные данные
передаются репликационному серверу, обслуживающему этот узел. Репликационный сервер в
соответствии с описанием тиражирования и подписками отправляет данные в специальном
эффективном протоколе по месту назначения - соответствующим репликационным серверам в
удаленных узлах.
Именно в этом месте - между репликационными серверами - связь может быть медленной или
недостаточно надежной. Передаваемые данные в составе транзакции при недоступности узла-
получателя записываются в стабильные очереди на диске и затем передаются по мере возможности.
Данные могут передаваться в удаленный узел по маршруту, содержащему несколько
репликационных серверов. Данная возможность лежит в основе построения иерархических систем
репликации.
По умолчанию репликационный сервер сохраняет смысл операций. Это значит, что удаление
записи из первичной таблицы (выполнение оператора DELETE) приведет к выполнению такого же
оператора DELETE в узле, хранящем копию таблицы; выполнение INSERT или UPDATE над
первичной таблицей точно так же приведет соответственно к добавлению или обновлению записи
в копии таблицы в результате работы системы репликации.
Имеется гибкий механизм
конфигурирования так называемых функциональных строк (function strings), которые
переопределяют любую операцию на макроязыке с возможностью подстановки параметров.
В одной базе данных могут содержаться как первичные данные, так и данные-копии. Приложение-
клиент, работающее со своей СУБД, может вносить изменения напрямую (операторами INSERT,
DELETE, UPDATE) только в первичные данные. Для изменения копии данных предназначен
механизм асинхронного вызова процедур.
Для работы механизма асинхронного вызова процедур в нескольких базах данных создаются
процедуры с одинаковым именем и параметрами, но, возможно, с различным текстом. В одной
базе данных процедура помечается как предназначенная к репликации. Вызов этой процедуры
вместе со значениями параметров передается через журнал и механизм репликации к узлам-
подписчикам. Затем в базах данных подписчиков вызывается одноименная процедура с теми же
значениями параметров.
Таким образом, для обновления "чужих" для узла данных (копии данных) прикладная программа-
клиент вместо выполнения оператора UPDATE вызывает заранее определенную в этом узле
хранимую процедуру и передает ей параметры (например, значение первичного ключа и новые
значения для обновляемых колонок). Тело этой процедуры пустое и она не выполняет никаких
действий, однако ее вызов записывается в журнал. Механизм репликации обеспечивает вызов на
узле, содержащем первичные данные, одноименной процедуры с подстановкой параметров. В теле
этой процедуры может быть записан оператор UPDATE, обновляющий первичные данные. Тот же
механизм репликации передаст изменения в данных узлу, инициировавшему операцию.
Репликационный сервер и Replication Agent реализованы в виде отдельных модулей и могут
выполняться не на том же компьютере, что сервер базы данных. Включение в систему
репликационного сервера практически не оказывает влияние на загрузку сервера первичной базы
данных.
СУБД, хранящая вторичные данные, может быть любой СУБД, доступной через шлюз, в том числе
Oracle, Informix, Ingres, DB2, RMS, ISAM, или даже приложение Open Server.
СУБД, хранящая первичные данные, требует наличия для нее RA. Сейчас RA имеется для Sybase
SQL Server, Oracle, DB2, Sybase SQL Anywhere. Готовятся RA и для других СУБД. Интерфейс RA
открыт и возможно создание RA для нестандартных источников данных.
Некоторые применения тиражирования данных:
сервер, выполняющий активное обновление данных (OLTP), разгружается
от сложных запросов, связанных с поддержкой принятия решений (DSS);
консолидация данных от подразделений в центре;
обмен данными по медленным и/или ненадежным линиях связи;
поддержание резервной базы данных;
построение сети равноправных узлов, обменивающихся данными.
Важно, что репликационный сервер тиражирует транзакции, а не отдельные изменения в базе
данных. Метод тиражирования транзакций гарантирует целостность внутри транзакции, и, как
следствие, невозможность нарушения ссылочной целостности. Схема обновления первичных
данных и копий данных исключает возможность возникновения конфликтов (конфликты могут
быть вызваны только неправильным проектированием системы или сбоем).
Концепция репликации данных
Главный узел может находиться под управлением IBM или UNIX-ЭВМ. Узлы-реплики могут
располагаться на любой платформе серверных ЭВМ, на которой может быть установлен ADABAS,
и которая может быть доступна через ENTIRE NET-WORK.
В состав продукта входит административная компонента, использующая специальные
файлы главной СУБД, где создаются описания главных файлов и файлов-реплик, а также
связанные с ними файлы журналов изменений и файлы подтверждения.
Файл подтверждения необходим для регистрации ранее выполненных транзакций в файлах-
репликах.
Файл-реплика может быть полной или выборочной копией главного файла в зависимости от
условий репликации, задаваемых администратором распределенной базы данных.
Процесс репликации может быть инициирован вручную, с помощью специальной диалоговой
утилиты, выполняться по таймеру в пакетном режиме, либо запускаться автоматически, при
завершении транзакции в главном узле.
Для обеспечения целостности данных используются стандартные механизмы обеспечения
целостности транзакций ADABAS, что требует присутствия в одной базе данных главного файла и
соответствующего ему файла журнала изменений. Аналогичные условия налагаются и на файлы-
реплик и связанные с ними файлы подтверждения.
[]
[]
[]