CASE-система SILVERRUN
CASE-система SILVERRUN американской фирмы Сomputer Systems Advisers, Inc. (CSA) используется для
инструментального обеспечения анализа и проектирования информационных систем бизнес-класса. Она
применима для поддержки любой методологии, основанной на раздельном построении функциональной и
информационной моделей (диаграмм потоков данных и диаграмм "сущность-связь").
Настройка на конкретную методологию обеспечивается выбором требуемого графического изображения
символов моделей и набора правил проверки проектных спецификаций. В системе имеются готовые
настройки для наиболее распространенных методологий: Gane/Sarson, Yourdon/DeMarco, Merise,
Ward/Mellor, Information Engineering. Для каждого проектного понятия имеется возможность добавления
собственных описателей.
Централизованное управление распределенными серверами
Центральная административная консоль SQL Server 6.0 заменила собой набор утилит, которые
существовали в предыдущей версии сервера. Из этой консоли, называемой Microsoft SQL
Enterprise Manager, администратор способен выполнять любые действия по администрированию
системы, как бы велика она ни была. На рис. 2 хорошо видны
несколько групп серверов.
Что можно ожидать от следующей версии SQL Server
В настоящее время проходит бета-тестирование SQL Server 6.5 - следующая версия сервера баз
данных Microsoft. Несмотря на то что обсуждение бета-версий дело неблагодарное, давайте
посмотрим на некоторые основные нововведения, которые планируется включить в продукт,
запланированный к выходу во втором квартале текущего года.
Следуя линии поддержки работы с большими объемами данных в SQL Server 6.5 планируется
включить поддержку "хранилищ данных".
Будут добавлены следующие возможности: аналитическая обработка данных в реальном времени
(online analytical processing - OLAP) при запросах, тиражирование в базы данных, производимые
другими компаниями, и поддержка программируемых устойчивых представлений и операций по
группировке данных на нескольких серверах.
Цикл разработки в S-Designor
При проектировании в S-Designor используется двухуровневый подход . Первый уровень - концептуальная модель данных (ER-диаграмма). Второй уровень -
физическая модель данных. При переходе на второй уровень S-Designor автоматически
генерирует соответствующую физическую модель данных для заданной СУБД, учитывая специфику
последней.
Концепция S-Designor - реализация классической теории информационного моделирования,
включающей четкое разделение между концептуальной моделью данных (представление объектов
реального мира и их взаимосвязи) и физической (отображение этих объектов в терминах, близких к
физическому представлению). Например, связи многие ко многим. Согласно теории информационного
моделирования и проектирования баз данных, такая связь при реализации должна быть
детализирована добавлением третьей уточняющей таблицы. S-Designor позволяет
представлять такие связи на концептуальном уровне модели. При генерации физической модели
S-Designor автоматически добавляет промежуточную таблицу, таким образом детализируя эту связь.
Cобственная репликация данных SQL Remote
SQL Remote - это система репликации (тиражирования данных) между базами данных SQL
Anywhere, основанная на передаче сообщений. Эта система администрируется из единого центра и
наиболее подходит для обмена данными с laptop-компьютерами и другими пользователями, связь с
которыми есть от случая к случаю. Система SQL Remote может использовать для репликации
средства электронной почты (MAPI, VIM, SMTP), файловый обмен и готовящийся к выходу
механизм Sybase Messaging Services.
SQL Remote реплицирует данные между "консолидированной" БД и одной или несколькими
"удаленными" БД. В качестве удаленных могут выступать как сетевые серверы SQL Anywhere, так
и локальные однопользовательские БД. SQL Anywhere поддерживает иерархическую модель
репликации (рис.12).
Консолидированная БД содержит все данные. Удаленные БД могут содержать часть данных или
все данные (удаленные БД, разумеется, могут содержать любые другие таблицы, не участвующие в
репликации).
Изменения, проведенные в консолидированной БД, тиражируются в удаленные БД. Изменения,
проведенные в одной из удаленных БД, попадают в консолидированную БД и затем в другие
удаленные БД.
Для обмена данными SQL Remote использует сообщения. Поэтому необязательно иметь прямое
сетевое соединение с удаленными БД. Достаточно организовать обмен сообщениями, например, по
электронной почте.
Приложения в архитектуре клиент-сервер, работающие в режиме сессии, используют тот или иной
сетевой транспорт (TCP/IP, IPX/SPX и др.) Точно так же приложения, работающие с сообщениями,
используют службы сообщений, такие как Microsoft Messaging API (MAPI), Lotus Vendor
Independent Messaging (VIM), Internet Simple Mail Transfer Protocol (SMTP) или даже простой
обмен файлами.
Детальная система моделей организации.
Главными целями создания детальной системы моделей является построение концептуальной
модели данных и функциональной модели организации. Для достижения этих целей проводится
детализация описания деятельности организации от уровня описания реализации общих бизнес-
процессов в организации и списковых моделей в подразделениях до уровня детальных моделей
подразделений, позволяющих выделить все функции подразделений, обрабатываемые
документы, основные данные, описать регламент работы персонала и создать в итоге
функциональную модель организации и концептуальную модель данных.
Выявленные в процессе обследования подразделения функции распределяются по бизнес-
процессам этого подразделения, наполняя их конкретными работами данного подразделения.
При этом описания бизнес-процессов могут дополняться и уточняться. В моделях описываются и
детализируются бизнес-процессы, функции, информационные потоки, входные и выходные
документы, взаимодействие внутри организации и с внешними объектами, данные, бизнес-
правила, роли персонала и регламент, их взаимосвязи, временные и прочие характеристики.
Описание деятельности организации с помощью бизнес-процессов и бизнес-правил позволяет
определить где, когда и кем выполняется каждая функция, какие данные, информационные и
функциональные взаимосвязи для этого нужны, и откуда эти данные поступают.
Построенная системы моделей организации может использоваться для трех целей. Во-первых,
построенные модели могут быть использованы для формирования требований к ИС. Во-вторых,
система моделей может быть использована для анализа деятельности организации с целью ее
улучшения, путем проведения инжиниринга или реинжиниринга организации в зависимости от
результатов анализа. И, наконец, на основании анализа построенных систем моделей, а также
существующих в организации ИС, формируется стратегический план создания, развертывания,
сопровождения и развития информационной системы.
Документация
В состав JAM входит полный комплект документации в электронном виде. При этом используется
гипертекстовая система Dyna Text фирмы Electronic Book Technologies. Dyna Text доступна на
многих платформах, поддерживаемых пакетом JAM. Печатный вариант документации
поставляется за дополнительную плату. Если на какой-либо платформе Dyna Text система
недоступна, то печатная документация поставляется бесплатно. Вся документация представлена на
английском языке.
Домены
Часто используемые комбинации свойств можно поименовать. Такая комбинация свойств,
называемая доменом, может наследоваться. Например, можно определить домен "Дата" для
отображения всех колонок с датами в приложении в одном стиле, домен "Дата рождения ребенка"
наследует все атрибуты от домена "Дата" и вносит дополнительный атрибут - цвет отображения.
Пример определения домена показан на рис.11.
Достоинства реляционного и объектного подхода к построению информационных систем
При разработке базы данных объекты предметной области должны быть описаны в терминах
предоставляемой СУБД модели данных. Чем лучше природа данных соответствует
предоставляемой модели, тем проще и эффективнее будет схема данных. В случае же
несоответствия схема не будет отражать семантики предметной области, что делает ее сложной и
неэффективной.
Классическая реляционная модель данных идеально подходила для создания баз данных
сравнительно простой структуры и содержащих данные простых типов. Схема типичной
экономической или административной базы данных времен разработки DB2 удобно описывается
при помощи реляционной модели, так как необходимые данные естественно представляются в виде
отношений. При возрастании возможностей аппаратуры реляционные СУБД позволяют увеличить
объем хранимых данных и скорость их обработки, но мало применимы для работы с данными
новых типов и сложной структуры, так как такие данные сложно моделировать при помощи
имеющихся в реляционной модели абстракций.
Для решения таких задач эффективны объектно-ориентированные информационные системы
(ООИС), в которых сущности реального мира представляются как объекты данных href="#lit">[2]. Состояние объектов описывается как значения их атрибутов, а их поведение
(применимые к ним операции) определяется реализацией их методов. Это позволяет представлять
объекты предметной области в естественном для них и семантически значимом виде, что
существенно упрощает разработку и модификацию схемы данных. Реляционная модель данных
может рассматриваться как подмножество объектно-ориентированной, что накладывает серьезные
ограничения на использование реляционных СУБД при построении ООИС. Однако это именно то
подмножество, которое на протяжении последних лет используется в большинстве работающих
реляционных систем, что привело к детальной разработке этой модели. В результате современные
РСУБД отличает совершенство реализаций, обеспечивающее высокую надежность и
производительность, в отличие от объектно-ориентированных баз данных, находящихся сегодня
на ранней стадии своего развития. Более того, существуют задачи , для
которых объектный подход не дает преимуществ.
Доступ к распределенной базе данных (интеграция/репликация данных)
Среда распределенных баз данных в рамках проектов корпоративных систем предполагает
возможность синхронизации изменений, производимых в отдельных фрагментах таких баз данных,
путем автоматического распространения транзакций изменений по узлам сети ( репликация
данных).
SOFTWARE AG включила XA-интерфейс (спецификация X/Open XO/CAE/91/300) в продукт
ADABAS версии 2.2 для ряда платформ UNIX и операционных систем IBM mainframe.
Продукт ENTIRE TRANSACTION PROPAGATOR поддерживает репликацию данных,
предоставляя возможность распространения транзакций изменений в среде баз данных
ADABAS.
В отличие от схем с двухфазовой фиксацией транзакции, требующей постоянной доступности всех
вовлеченных в транзакцию ядер СУБД (узлов), репликаторы данных требуют доступности только
одного ядра, называемого главным (рис. 8). Изменение файлов,
на главном узле выполняется синхронно с обработкой.
Доступ к удаленной базе данных (серверы баз данных)
Доступ к удаленным базам данных (серверу базы данных) предполагает, что приложение,
взаимодействующее с базой данных не должно меняться в зависимости от того, в каком узле сети
находится сервер базы данных.
При этом, существенную роль начинает играть язык, на котором приложение взаимодействует с
СУБД. За последние годы развитие получил язык SQL, ставший фактически промышленным
стандартом в мире открытых систем.
Реализация принципа независимости приложений от источников (серверов) данных, нашло
решение в виде уже упоминавшегося выше продукта ENTIRE NET-WORK, обеспечивающего
универсальный транспорт запросов от приложения до серверов баз данных.
Установка этого продукта на каждом из узлов сети как на платформах серверных ЭВМ, так и
рабочих станций клиентов, обеспечивает доставку запросов и данных между серверами баз данных
ADABAS и их клиентами.
На следующих схемах изображены варианты доступа к базам данных ADABAS, расположенных на
различных серверных платформах из приложений-клиентов на рабочих станциях.
Изображенные на рис. 5 конфигурации являются стандартными для
доступа к серверам баз данных ADABAS со стороны клиентов на рабочих станциях под
Windows.
Embedded SQL
Sybase Embedded SQL прекомпилятор позволяет программисту использовать ANSI-операторы
SQL в тексте программы на Си и Коболе. Для оптимизации статических запросов SQL
прекомпилятор может генерировать хранимые процедуры. Прекомпилятор интегрирован с XA-
интерфейсом для работы с мониторами транзакций.
Фирма-производитель
Американская фирма Computer Systems Advisers, Inc. (CSA) является поставщиком средств
проектирования и создания информационных систем архитектуры "клиент-сервер", а также занимается
консалтингом в области информационных технологий. Продукты фирмы используются в более 5000 мест
по всему миру. Среди пользователей - известнейшие представители компьютерного бизнеса (Apple, Cray,
Data General, IBM, Intel, Lotus Development, Texas Instruments), финансовой сферы (American Express,
Citibank, Morgan Guarantee Trust, World Bank), производители массовых товаров и услуг (General
Electric, Pepsicola, Pizza Hut, Polaroid), университеты (Harvard, Stanford, Yale), кинокомпании (MCI,
Walt Disney).
Фрагментация приложений
Поставляемая с Informix-NewEra библиотека классов прикладного сервера (Application Server Class
Library) предназначена для создания распределенных многозвенных приложений. В таком
приложении на машине-клиенте обслуживается только интерфейс с пользователем, а прикладная
бизнес-логика реализуется при помощи одной или нескольких серверных компонентов.
Предполагается, что поддержка серверных компонентов приложений NewEra будет обеспечена для
всех платформ, на которых могут работать серверы СУБД Informix.
В последующих версиях NewEra планируется реализация расширенного инструментария
распределенного программирования. В него войдут средства для автоматического создания
коммуникационного кода, обеспечивающего взаимодействие удаленных компонентов, а также
распределенный отладчик. При необходимости, фрагментация приложения может быть
переопределена без перепрограммирования содержательного кода, что чрезвычайно важно в
условиях постоянно изменяющихся потребностей.
Функции, определяемые пользователем
Функции, определяемые пользователем, позволяют скрывать внутреннее представление данных от
приложения, обеспечивая некоторую инкапсуляцию данных. Они также позволяют определять
новые операции как для базовых типов данных, так и для типов, определяемых пользователем.
Функции, определяемые пользователем, позволяют достичь многократного использования кода за
счет того, что операции, общие для различных приложений, хранятся на сервере, а не включаются
в каждое отдельное приложение.
Для реализации этих функций используются языки программирования, а для их регистрации в
СУБД - введенный в язык определения данных оператор CREATE FUNCTION. Фактически этот
оператор связывает пользовательскую функцию с конкретной программой, выполняемой при
вызове этой функции. Использование пользовательских функций вместо непосредственного
доступа к данным может обеспечить некоторую инкапсуляцию данных, что можно использовать
для того, чтобы скрыть от пользователя их внутреннюю структуру.
Кроме того, DB2 поддерживает механизм перегрузки имен пользовательских функций,
аналогичный применяемому в ООБД, однако не позволяет связывать функции с конкретными
элементами данных, как связаны методы и объекты при объектном подходе.
Дополнительную гибкость функциям, определяемым пользователем, придает способность
одновременно работать как с данными DB2, так и другими данными, как, например, файлами,
электронной почтой и др.
Возможны два варианта взаимодействия функций, определяемых пользователем, с сервером DB2.
Первый заключается в том, что функция имеет прямой доступ к БД, что позволяет достичь
максимальной производительности, но представляет собой потенциальную угрозу
работоспособности сервера и целостности данных.
Во втором варианте функция выполняется как отдельный от сервера БД процесс, что обеспечивает
защиту данных и СУБД, но снижает производительность.
Пользователь может выбирать оптимальный для своей задачи подход в зависимости от ее
специфики.
Генерация кода - эксперты
В процессе развития и, в том числе, визуализации средств разработки приложений, на фоне
стандартизации пользовательского интерфейса в различных областях применения конечных
систем, неотъемлемой частью таких инструментов стали генераторы кода и форм представления и
ввода информации - эксперты.
Кроме того, что Delphi включает ряд уже готовых к использованию экспертов (например, DataBase
Form Expert, генерирующий формы и соответствующий код для простых приложений обработки
баз данных с использованием запросов), эта среда программирования предоставляет
разработчикам интерфейс для создания собственных экспертов, встраиваемых в IDE.
Необходимо отметить, что функциональность таких экспертов может не ограничиваться на
генерации кода, в силу того, что интерфейс экспертов дает возможность получения информации о
внутренних объектах IDE, таких как палитра компонент. Вследствие этого, под общим названием
"эксперты" могут фигурировать программные модули, позволяющие управлять повелением IDE,
окна дизайнера и ее редактора исходных текстов, а также генерировать отчетную информацию о
создаваемом проекте. (На приведенном выше рисунке вы можете увидеть эксперт, разработанный
в Delphi и встроенный в IDE; функциональность этого эксперта заключается в предоставлении
разработчику информации об иерархии наследования зарегистрированных компонент без
компиляции; в данном случае доступ осуществляется через меню "Help", хотя возможна
регистрация и в "галерее" шаблонов Delphi).
Генерация отчетов
По завершении работы над информационной моделью, как правило, распечатываются логический и
физический уровни диаграммы, а также отчет по соответствиям сущность-таблица, атрибут-имя
колонки, сущность-атрибуты. Диаграмма физической модели является необходимым, почти
достаточным и очень удобным материалом для разработчиков программ. Дополнительная
информация для группы разработчиков прикладных программ содержится в отчете "имена таблиц и
колонок", который может быть легко построен с помощью ERwin. Выбор режима построения отчета
показан на рис.12.
Генерация приложений
Современная версия S-Designor позволяет автоматически генерировать приложения.
Приложения генерируются в интерфейсе MDI (многодокументный интерфейс). Обеспечивается
возможностью генерации связанных окон данных (master-detail). Приложения генерируются на основе
template, который поставляется с S-Designor. Окна данных в приложении генерируются
согласно выбранным таблицам модели данных. Для генерации приложения достаточно указать только
ряд необходимых параметров, таких как имя библиотеки в которой будет сохранено приложение,
источник данных в терминах ODBC, с которым будет работать приложение, имя библиотеки,
содержащей template, а также некоторые другие параметры.
Имеется возможность автоматически генерировать запросы (Query) как объекты в терминах целевых
средств разработки на основе представлений (View).
Генерация приложений и схем баз данных
Спецификации схемы (или подсхемы) можно перенести через соответствующий мост в среду разработки
приложений или сгенерировать схему базы данных для СУБД.
SILVERRUN не подменяет среду разработки и не содержит средств моделирования видов экранов или
форматов отчетов. Эти функции специфичны для каждого языка разработки. SILVERRUN передает
данные о форматах ввода, правилах редактирования, формах представления прямо в репозиторий среды
разработки. Программисту остается расставить поля на экранах, подправить, если нужно, генерируемые
большинством языков четвертого поколения автоматически SQL-запросы для этих экранов, определить
систему меню - и основа работающего приложения создана.
Генерация схемы базы данных происходит путем создания файла с SQL-операторами, в которые
переводятся конструкции модели данных. Этот файл используется для физического создания базы данных
на сервере. На рис. 6 приведен фрагмент схемы для СУБД Informix OnLine, полученной из модели,
изображенной на рис. 4.
--
================================================
===
-- table: Order
--
================================================
===
create table Order
(
OrderNum INTEGER not null,
OrderDate DATE default TODAY not null,
OrderCost MONEY not null,
CustomerName CHAR not null,
primary key (OrderNum)
)
;
--
================================================
===
-- referential integrity triggers section
--
================================================
===
-- =======================================
-- Procedure raise_exception for errors messages
-- =======================================
create procedure
messages_errors(errno INTEGER, isam INTEGER, errmsg char(255))
raise exception errno, isam, errmsg;
end procedure;
--
================================================
===
-- Controls the INSERT action on table Order.
-- Rule : CHILD INSERT RESTRICT
-- Parent : Customer
-- Child : Order
-- Direction : Order_Customer
--
================================================
===
create trigger tr_ins_Order insert on Order
referencing NEW as inserted
for each row
when
(
(select count(*) from Customer
where
inserted.CustomerName = Customer.CustomerName
) = 0
)
(
execute procedure messages_errors
(
-746,
0,
'Insert of "Order" denied: corresponding "Customer" does not
exist.'
)
)
;
--
================================================
===
-- Controls the DELETE action on table Customer.
-- Rule : PARENT DELETE RESTRICT
-- Parent : Customer
-- Child : Order
-- Direction : Customer_Order
--
================================================
===
create trigger tr_del_Customer delete on Customer
referencing OLD as deleted
for each row
when
(
exists
(
select * from Order
where
Order.CustomerName = deleted.CustomerName
)
)
(
execute procedure messages_errors
(
-746,
0,
'Delete of "Customer" denied: referencing "Order" exists.'
)
)
;
Рис. 6. Фрагмент схемы базы данных для СУБД Informix
OnLine
Генератор окон - Window Painter
Генератор окон NewEra - инструмент, который позволяет в графическом режиме создавать новые
классы окон и визуальных объектов. Под визуальным объектом понимается группа
взаимосвязанных органов управления окна, например, группа радиокнопок или супертаблица
(орган управления для взаимодействия с таблицами БД) в комплекте с управляющими
кнопками.
Генератор отчетов - JAM/RW
Одним из дополнительных модулей JAM является Генератор Отчетов. Компоновка отчета
осуществляется в Редакторе Экранов JAM. Описание работы отчета осуществляется с помощью
специального языка.
Генератор отчетов позволяет определить:
Данные, выводимые в отчет. Источниками информации для отчетов
могут быть результаты исполнения SQL-запросов (в том числе и
сгенерированные Менеджером Транзакций), внешние источники, информация,
введенная конечным пользователем и т.д;
Группировку выводимой информации. Уровни вложенности подотчетов и
детализации не ограничены;
Динамическое управление исполнением отчета;
Форматирование вывода, включая интеллектуальное разбиение на
страницы;
Заголовки и подвалы страниц и групп; использование в них внешних
данных;
Дополнительную обработку с помощью JPL-процедур или внешних
функций, написанных на языках 3-го поколения;
Динамическое управление исполнением отчета;
Устройство вывода.
Генератор Отчетов (Report Builder)
Это графическое средство, которое позволяет пользователю определять внешний вид и содержание
генерируемых отчетов. С его помощью можно создавать множество разнообразных отчетов, в том
числе:
отчеты в табличном виде
рулонные отчеты
отчеты, состоящие из нескольких разделов
только итоговые (суммарные) отчеты
Генератор Отчетов позволяет просмотреть на экране дисплея вид будущего отчета и при
необходимости внести требуемые коррективы. Текст отчета может содержать такие атрибуты
текста, как курсив, подчеркивание, плотность печати, а также выравнивание текста, цвет и тип
шрифта.
Кроме построения самостоятельных отчетов, Генератор может быть использован для генерации
отчетов для конечного пользователя следующим образом. Вы создаете основную логику отчета по
отбору данных и разметку страниц. Затем вы передаете конечному пользователю этот отчет вместе
с Генератором Отчетов Report Builder или утилитой Results, при помощи которых он может в
соответствии с собственными нуждами изменить формат отчета и отбираемые данные. Подобные
возможности по созданию шаблонов в значительной степени увеличивают возможности
пользователей, а также освобождают разработчиков от необходимости затрачивать чрезмерные
усилия на создание новых отчетов.
Генератор приложений
Генератор приложений (Application Builder) - графический инструмент для построения
приложений, состоящих из нескольких файлов. Разработчик описывает структуру приложений в
терминах проектов, программ, файлов. Проект может состоять из одной или нескольких
программ, каждая программа собирается из одного или нескольких исходных файлов (рис. 3).
Описания проектов сохраняются в системной базе данных.
Генератор позволяет собирать как интерпретируемый, так и выполняемый вариант приложения.
Выполняемое приложение создается в виде EXE-файла и, возможно, нескольких динамически
загружаемых библиотек (DLL).
Генераторы приложений
Входящие в состав DESIGNER/2000 генераторы разбиваются на две группы:
генератор сервера
генераторы клиентской части
Генератор серверной части автоматически строит по спецификациям базы данных тексты
программ на языке SQL, используя все средства определения баз данных, включая триггеры,
хранимые процедуры и т.д.
Генераторы клиентской части обеспечивают автоматическое формирование текстов программных
модулей по их спецификациям, записанным в репозитарии. Все модули приложения
классифицируются по типам, основными из которых являются экранные формы, отчеты,
процедуры. Для каждого типа имеется свой генератор, результатом работы которого является
программа, написанная на языке, соответствующем этому типу: генератор форм создает
приложения для ORACLE/Forms, генератор отчетов позволяет получать процедуры на PL/SQL
либо приложения для ORACLE/Report.
Исходной информацией для работы любого генератора служат спецификации таблиц базы данных
и спецификации модулей. В спецификации модуля указываются такие его параметры, как
наименование, тип, некоторые характеристики внешнего представления (заголовки, параметры).
Кроме того, перечисляются используемые таблицы базы данных и для каждой из них
специфицируется, какие операции к ней могут применяться (выборка, ввод записей,
корректировка, удаление), какие ее столбцы и каким образом участвуют в работе модуля.
Каждый используемый столбец может описываться разнообразными описателями, включая
форматы вывода, способы упорядочения, основные типы операций над данными, возможность
автоматической генерации значений при вводе новых записей и др. В простейших же случаях
можно использовать их стандартные значения, задаваемые по умолчанию, что существенно
сокращает время на получение первоначальной версии работающей программы.
Кроме этой информации об особенностях модуля генератор использует спецификации таблиц базы
данных и взаимосвязей между ними. Это позволяет при описании в репозитарии собственно
модуля не заботится об указании, каким образом связаны используемые таблицы, из каких
таблиц берутся данные для заполнения того или иного столбца, какие дополнительные действия
необходимо выполнить при изменении содержимого данной таблицы, чтобы не нарушить
целостность всей базы данных (так, при удалении записи из таблицы может потребоваться
проверка, не ссылаются ли на нее записи из других таблиц) и т.п.
Например, если мы хотим создать экранную форму для таблицы СОТРУДНИКИ, то нет
необходимости включать в число используемых таблиц ОТДЕЛЫ в качестве источника для
заполнения столбца ОТДЕЛ в таблице СОТРУДНИКИ. Генератор, анализируя структуру базы
данных, автоматически создаст правильный список возможных значений и включит в текст
программы все необходимые проверки на правильность вводимых данных. Такой принцип
работы генераторов особенно существенен для поддержки прикладной системы: при
необходимости изменения схемы базы данных (добавилась новая таблица, логически связанная с
уже существующими, или изменился тип некоторой взаимосвязи между базовыми таблицами и
т.п.) можно не вносить никаких изменений в старые спецификации модулей, а лишь
перегенерировать их и все необходимые изменения в тексты программ будут внесены
автоматически.
Несмотря на то, что спецификации модуля в репозитарии описывают его лишь в самом общем
виде без уточнения различных деталей внешнего представления форм и отчетов, особенностей
функционирования, существует возможность дополнительной "настройки" с помощью
многообразных параметров, управляющих работой генераторов. Более четырехсот таких
параметров, тщательно классифицированных, позволяют получать по одной и той же
спецификации работающие программы, различающиеся внешними представлениями,
особенностями функционирования, стилем оформления исходного текста и т.д.
При необходимости сгенерированный текст программы можно дополнительно доработать и
дополнить, пользуясь непосредственно соответствующими инструментальными средствами
разработки "нижнего уровня", входящими в состав DEVELOPER/2000.
В этом случае появляется
некоторая опасность несоответствия конечной версии программы спецификациям проекта, что
особенно неудобно при возможных изменениях проекта, например схемы базы данных. Такое
изменение требует перегенерации модулей с учетом новых таблиц и взаимосвязей, а с другой
стороны выполнение повторной генерации "уничтожит" старую версию программы со всеми
введенными "вручную" дополнительными фрагментами. Для такой ситуации в DESIGNER/2000
предусмотрен специальный режим работы генераторов - регенерация. При регенерации
происходит не замена старого программного текста на новый, а его "редактирование", когда по
возможности вносятся лишь необходимые изменения и не корректируются отдельные
фрагменты. При этом можно управлять уровнем изменений и запретить модифицировать
определенные фрагменты программы (например, все, относящееся к описанию расположения
полей или триггеры заданного типа и т.п.).
Из дополнительных средств, входящих в состав генераторов, особый интерес представляют
утилиты, позволяющие использовать DESIGNER/2000 не только для новых разработок,
начинающихся с этапа постановки задачи, но и для готовых прикладных систем, которые были
спроектированы и реализованы без использования CASE-средств. Для такой ситуации
предусмотрена возможность реинженигинга системы - автоматического создания по работающей
версии приложения его описания в репозитарии, т.е. спецификаций структуры базы данных,
программных модулей типа экранных форм и отчетов, ER-модели. Полученные описания могут
быть использованы для анализа возможностей и выявления недостатков существующей версии
приложения, а впоследствии модифицированы в соответствии с новыми требованиями и
условиями функционирования системы. На основе отредактированных спецификаций
производится генерация новой версии системы.
Графические средства конфигурирования и администрирования
Конфигурирование и управление процессом тиражирования данных на уровне предприятия
обычно представляет собой сложную и требующую больших затрат времени задачу. В SQL Server
6.0 эта задача выполняется с помощью развитых графических инструментов административного
управления и, таким образом, резко упрощается. Администраторы могут определить все аспекты
процесса создания тиражируемых данных, диспетчирования процессов, установки подписки и
полностью контролировать защищенность тиражируемых данных. Для каждой публикации можно
определить записи или столбцы, входящие в публикацию, и то, какие подписчики имеют право
обращения к каким публикациям. В каждой публикации администратор имеет полный контроль
над доступом к ее данным.
Графическое редактирование модели
Все объекты модели ERwin могут редактироваться средствами, принятыми в Windows - группировка,
копирование, удаление, перемещение, использование системного буфера. Установка цветов и
шрифтов осуществляется в удобных диалогах.
Компоненты модели, представленные текстом (имена сущностей, атрибутов, текстовые элементы)
могут редактироваться непосредственно на экране.
Характеристика языка программирования NewEra
В отличие от языков скриптов, предлагаемых многими инструментальными системами, NewEra
представляет собой полномасштабный высокоуровневый объектно-ориентированный язык,
содержащий ряд встроенных средств для программирования доступа к базам данных и
графического пользовательского интерфейса. NewEra является развитием языка Informix-4gl,
поддерживая все его возможности за исключением операторов и встроенных функций для работы с
экранными формами и меню.
Характеристики проекта
при традиционном подходе:
Сложность проекта ~ 1850 ф.т.
Типичная норма выработки - 18 ф.т. на человеко-месяц
Проект потребует - 103 человеко-месяца
5 человек - более 20 месяцев
при спиральной модели жизненного цикла:
Сложность проекта ~ 1850 ф.т.
Проект потребовал - 38 человеко-месяцев
Норма выработки - 48,5 ф.т. на человеко-месяц
Высокая производительность проекта достигалась за счет использования средств автоматизации анализа и проектирования (CASE SilverRun), языка четвертого поколения (JAM), за счет автоматизации всей технологической цепочки (мост SR-(JAM), использования средств конфигурационного управления (PVCS), средства автоматизации тестирования QualityWorks.
[]
[]
[]
Хранение информации в модели ERwin
Обычно модели ERwin сохраняются на диск в виде файла. Имеется возможность хранить модель в
целевой СУБД. Для этого с помощью самого ERwin в целевой СУБД создается метабаза ERwin. В
этой базе данных сохраняется информация модели. В частном случае базой данных могут быть и
dBase-файлы, с которыми ERwin работает через ODBC.
Хранимые процедуры
Хранимые процедуры (stored procedures) представляют собой приложения, которые хранятся в базе
данных. Обычно, в среде клиент-сервер конечные приложения располагаются на клиентской
машине и там же выполняются. Любой доступ к базе данных из конечного приложения использует
контакт с сервером по компьютерной сети. Когда же приложение располагается внутри базы
данных, оно называется хранимой процедурой. Хранимые процедуры выполняются
непосредственно на компьютере сервера базы данных.
SQLBase использует хранимые процедуры, написанные на языке инструмента разработки
конечных приложений SQLWindows Application Language (SAL).
Использование хранимых процедур преследует следующие цели:
Повышение производительности - Так как прикладная программа
перенесена на сервер, она не требует затрат на передачу информации по сети
при обращении к базе данных. Кроме того, сервер обычно бывает более
мощным компьютером, чем клиентские машины. Следовательно, те же
операции выполняются на сервере быстрее.
Простота использования - Обычно, технология клиент-сервер
подразумевает большое количество клиентов, подключенным к одному
серверу. Использование хранимых процедур позволяет хранить приложение на
одном компьютере, а не на каждом клиенте в отдельности. Если приложение в
базе данных модифицируется, оно становится сразу доступно всем клиентам в
наиболее обновленном виде.
Усиление защиты данных - Пользователь может получить возможность
доступа к данным только через использование заранее запрограммированных
процедур и не иметь прямой возможности изменять данные. Следовательно,
набор операций, которые могут быть осуществлены пользователем, легко
контролируются с помощью управления доступом к небольшому числу
хранимых процедур.
Ускорение процесса освоения - Хранимые процедуры SQLBase пишутся на
языке SAL. Этот язык хорошо знаком разработчикам приложений на продуктах
Gupta. Кроме того, разработчики могут создавать и отлаживать прототипы
хранимых процедур в среде SQLWindows и затем переносить их в базу данных
с помощью программы SQLConsole.
В SQLBase имеется возможность хранения двух типов процедур.
Хранимые команды - это SQL запрос, который хранится на сервере в
скомпилированном виде (то есть вместе со своим планом выполнения).
Выполнение хранимых команд производиться гораздо быстрее, чем обычных
SQL запросов, поскольку целый ряд шагов, необходимых для выполнения
запроса, производится в момент записи хранимой команды в базу данных. В то
же время хранимые команды имеют ограниченную функциональность в рамках
синтаксиса языка SQL.
Хранимые процедуры - это приложения, объединяющие SQL запросы и
процедурную логику (операторы присваивания, логического ветвления и т.д.).
Хранимые процедуры позволяют хранить на сервере сложные приложения,
выполняющие большой объем работы без передачи данных по сети и
взаимодействия с клиентом.
Создание хранимых процедур
Хранимые процедуры и хранимые команды SQLBase создаются с помощью команды STORE языка SQL или при помощи функции sqlsto() SQL/API.
Тело хранимой процедуры состоит из следующих элементов или разделов:
Имя процедуры. Является идентификатором процедуры и
используется при извлечении (retrieve) процедуры из базы данных перед ее
выполнением.
Переменные. SQLBase поддерживает 5 типов данных в качестве
переменных хранимых процедур. Все они идентичны типам данных
SQLWindows с теми же именами.
а Number - Числовой тип данных
а Boolean - Логический тип данных с допустимыми значениями
TRUE/FALSE
а String - Строковый тип данных
а Date/Time - Этот тип может быть использован для данных типа
Дата, Время или Дата/Время
а Sql Handle - используется в качестве курсоров для доступа к
базе данных
Секция описания переменных хранимой процедуры состоит из двух блоков: блока параметров
(Parameters) и блока локальных переменных (Local Variables).
Блок параметров содержит переменные, которые передают информацию в хранимую процедуру
или возвращают информацию из нее в вызывающее процедуру приложение. Блок параметров
эквивалентен списку bind-переменных в SQL запросе.
Хранимые процедуры SQLBase могут
содержать параметры двух типов: для ввода и для вывода. Параметры вывода обозначаются
ключевым словом RECEIVE перед описанием типа переменной. Эти параметры эквивалентны
списку into-переменных в запросах SELECT.
Блок локальных переменных содержит описания переменных, которые используются только
внутри данной хранимой процедуры и не могут быть определены извне.
Процедурная логика. Этот раздел начинается с ключевого слова
ACTIONS. Он содержит всю логику и выполняемые инструкции процедуры.
Весь код этого раздела пишется на языке SAL. Хранимые процедуры SQLBase
поддерживают некоторое подмножество полного языка SAL. Например, в
текущей версии SQLBase реализована поддержка только тех функций SAL,
которые начинаются с префикса Sql ( SqlPrepare()). Поддержка
остальных функций (начинающихся с префикса Sal) будет реализована в
последующих версиях продукта.
Раздел процедурной логики может также состоять из следующих необязательных секций:
ON PROCEDURE STARTUP - Эта секция используется для процедур инициализации,
таких как установление контакта с базой данных, компиляция запросов и т.д. Она выполняется
только во время первого выполнения хранимой процедуры.
ON PROCEDURE EXECUTE - Данная секция выполняется всякий раз, когда хранимая
процедура выполняется командой EXECUTE. Во время первого выполнения эта секция
выполняется после секции ON PROCEDURE STARTUP. Во время всех последующих команд
EXECUTE выполняется только эта секция.
ON PROCEDURE FETCH - Эта секция выполняется всякий раз, когда процедуре
передается команда FETCH в случае использования процедуры в качестве result set (не забудьте,
что хранимые процедуры ведут себя подобно запросам SELECT). При этом строки из множества
результатов возвращаются из процедуры посредством переменных типа RECEIVE.
ON PROCEDURE CLOSE - Данная секция выполняется в тот момент, когда для курсора,
связанного с хранимой процедурой, происходит компиляция нового запроса или этот курсор
отсоединяется от базы данных.
Она используется для выполнения операций завершения, таких как
выпуск транзакции COMMIT, отсоединение от базы данных и т.д.
Если процедура не содержит описанных выше секций, по умолчанию предполагается, что она
состоит из одной секции ON PROCEDURE EXECUTE.
Хранимая процедура может быть определена как статическая или динамическая с помощью
ключевых слов STATIC/DYNAMIC после имени процедуры. По умолчанию, хранимые процедуры
SQLBase являются динамическими. Если процедура определяется как статическая, все SQL запросы
в ней должны быть предварительно скомпилированы и записаны в базу данных в виде хранимых
команд. Поэтому в статических процедурах все SQL запросы должны быть представлены в виде
строковых констант и не могут содержать переменных. Кроме того, в статических процедурах не
допускается использование команд типа CREATE, ALTER, DROP. Статические процедуры
обладают гораздо более высокой производительностью по сравнению с динамическими, поскольку
не требуют компиляции своих запросов во время выполнения.
Доступ пользователей к хранимым процедурам
Для того, чтобы выполнить хранимую процедуру, пользователь должен обладать определенными
привилегиями. Он может иметь право выполнить процедуру либо с привилегиями автора (execute
with creator privilege), либо со своими привилегиями (execute with grantee privilege). Если
пользователь выполняет процедуру с правами автора, он получает все его права по отношению к
объектам базы данных на время выполнения процедуры. При втором способе выполнения
изменения прав пользователя не происходит. Использование возможности расширения (изменения)
прав пользователя на время выполнения хранимой процедуры позволяет повысить защищенность
данных и канализировать доступ к ним через отработанные и проверенные процедуры.
Получение кодов ошибок из хранимых процедур
Процедура указывает на нормальное завершение возвращая нулевое значение в вызвавшее ее
приложение.
Если процедура возвращает ненулевое значение, оно рассматривается как ошибка.
Такое
возвращаемое значение ищется в файле ERROR.SQL, для того, чтобы выдать пользователю
соответствующее сообщение. Пользователь может поместить в ERROR.SQL свои собственные
коды и описания ошибок и использовать их для возвращения информации из хранимых
процедур.
Пример хранимой процедуры
Ниже приведен пример хранимой процедуры SQLBase, иллюстрирующей некоторые моменты,
описанные в данной статье. Эта процедура обновляет баланс по счету AccountNum в соответствии
с выплаченной суммой nAmount и возвращает новое значение баланса в переменной nNewBalance.
Если при этой операции происходит овердрафт, процедура устанавливает флаг bOverDrawn.
(Примечание: при написании хранимых процедур, также как и в коде на языке SQL, индентация
различных блоков кода имеет критическое значение. В программу SQLConsole входит редактор
хранимых процедур, который поддерживает нужные уровни индентации.)
Procedure Withdraw
Parameters
Number: nAccount
Number: nAmount
Receive Number: nNewBalance
Receive Boolean: nOverDrawn
Local Variables
Sql Handle: hSelect
Sql Handle: hUpdate
String: sSelect
String: sUpdate
Number: nStatus
Actions
On Procedure Startup
Set sSelect = 'Select Balance from Checking where
AccountNum=:nAccount' \
'into :nNewBalance'
Set sUpdate = 'Update Checking Set Balance = Balance -
:nAmount' \
'where AccountNum = :nAccount'
Call SqlConnect( hSelect )
Call SqlPrepare( hSelect, sSelect )
Call SqlConnect( hUpdate )
Call SqlPrepare( hUpdate, sUpdate )
On Procedure Execute
Call SqlExecute( hSelect )
Call SqlFetchNext (hSelect, nStatus )
Set nNewBalance = nNewBalance - nAmount
If ( nNewBalance < 0 )
Set bOverDrawn = TRUE
Else
Set bOverDrawn = FALSE
Call SqlExecute( hSelect )
On Procedure Close
Call SqlDisconnect( hSelect )
Call SqlDisconnect( hUpdate )
Художник баз данных (DataBase Painter)
Художник баз данных предоставляет интерактивные средства для создания и поддержки баз
данных SQL. Разработчики могут создавать таблицы и представления, определять первичные и
внешние ключи, запускать командные файлы баз данных, обеспечивать безопасность и
редактировать данные из базы данных.
Центральный репозиторий дизайна приложений (Central Application Design Repository) предоставляет
развитые возможности управления хранением расширенных атрибутов столбцов, таких как
заголовки, метки, форматы изображения, правила проверки и графические стили
редактирования.
Художник библиотек (Library Painter)
Художник библиотек позволяет разработчикам совместно использовать все объекты
приложений, такие как окна, Окна данных, меню, структуры и Объекты пользователей
(User Objects). Эти объекты хранятся в одной или нескольких библиотеках, локализованных в одном
месте или распределенных в сети. Возможность проверки при выдаче и возврате объектов (check-
in/check-out) позволяет предотвратить одновременное обновление одного объекта несколькими
разработчиками. Предоставляются также возможности поиска в библиотеках, анализа взаимосвязи и
создания подробных отчетов для разработчиков по библиотекам и их компонентам.
Художник библиотек предлагает также прозрачный доступ ко множеству систем контроля
версий и систем управления конфигурацией, разработанных третьими фирмами. Разработчики,
создающие крупные приложения, могут поддерживать несколько версий объектов и отслеживать, кто
и когда внес данное изменение.
Художник функций (Function Painter)
Художник функций позволяет разработчику создавать и поддерживать функции, которые
чаще всего представляют собой общие процедуры, неоднократно используемые в одном или
нескольких приложениях, сокращая при этом объем повторяющегося кода.
Художник меню (Menu Painter)
Художник меню создает меню и линейки инструментов, которые можно связать с любым
окном как в процессе определения окна, так и динамически из программы, в ходе ее выполнения.
Художник настроек (Preferences Painter)
Художник настроек позволяет настраивать конфигурацию PowerBuilder в соответствии с
привычками и вкусом разработчика.
Художник Объектов пользователей (User Object Painter)
Художник Объектов пользователей создает объекты, определенные пользователями, из
стандартных элементов управления Windows, предварительно определенных объектов пользователей
и элементов управления VBX. Художник Объектов пользователей может также создавать
невидимые объекты пользователя, обеспечивая полное использование объектно-ориентированной
техники разработки. Используя построитель классов C++ (C++ Class Builder), основанный на
технологии Watcom, объекты пользователя можно реализовывать на языке C++.
Художник Окна данных (DataWindow Painter)
Художник Окна данных создает интеллектуальный объект данных для просмотра,
манипулирования и обновления реляционных баз данных без необходимости программирования на
SQL. Художник Окна данных содержит множество параметров, предоставляемых в режиме
"укажи и щелкни кнопкой мыши", которые позволяют изменять оформление внешнего вида Окна
данных. Не прибегая к программированию, разработчики могут создавать деловую графику,
вычисляемые столбцы, автоматические сводки, а также осуществлять межтабличный анализ. Окна
данных могут быть динамическими и поддерживать изменения во время выполнения приложения
в виде незапланированных запросов и отчетов, чтобы удовлетворить самым специфическим
требованиям конечных пользователей.
Художник окон (Window Painter)
Художник окон создает окна (являющиеся основным элементом интерфейса приложений) и
элементы управления, которые могут быть частью окна. Элементами управления являются командные
кнопки, линейки прокрутки, списки выбора, открывающиеся списки выбора, радиокнопки,
альтернативы, элементы управления Окна данных (DataWindow) и многое другое.
Художник переноса данных (Data Pipeline Painter)
Художник переноса данных обеспечивает разработчикам доступ к данным и перенос данных без
программирования, даже если они находятся в различных базах данных. Определения DataPipeline
могут быть сохранены в виде объектов и затем использованы в приложениях.
Художник приложений (Application Painter)
Художник приложений определяет среду приложения, включая имя приложения и его
пиктограмму, установленные по умолчанию цвета и шрифты, программы обработки событий
приложений, список библиотеки, а также позволяет разработчику графически просматривать всю
иерархию объектов приложения. Как только все объекты приложения будут созданы,
откомпилированы и протестированы, Художник приложений создаст исполняемый файл
(.EXE).
Художник проектов (Project Painter)
Художник проектов позволяет указывать порядок и параметры сборки различных
приложений из общего набора объектов в библиотеках PowerBuilder. Определения проектов
сохраняются в библиотеках и позволяют автоматизировать большинство действий по подготовке
готового приложения.
Художник структур (Structure Painter)
Художник структур создает сложные структуры данных для использования их в
конструкциях языка PowerScript и для связи с внешними функциями. Структуры помогают
разработчику организовать переменные в программах и облегчают взаимодействие с внешними
функциями.
Художник запросов (Query Painter)
Художник запросов предоставляет графические средства для создания запросов к базам
данных и сохранения этих запросов в виде объектов. Объекты запросов можно использовать в
качестве источника информации для Окна данных и отчетов, обеспечивая еще более тесную
интеграцию с базами данных. Художник запросов полностью поддерживает графическое
рисование SQL как для таблиц, так и для представлений. Для дополнительной гибкости пользователи
при желании могут иметь полный доступ к оператору SQL Select.
Идентификация модели заголовком (Title)
Данный заголовок поддерживается в S-Designor специальным образом и служит не только
для того, чтобы как-то приукрасить модель. Заголовок содержит идентифицирующую информацию,
которая также хранится в центральном словаре данных и используется как при организации
групповой разработки модели данных, так и в других целях.
Идентификация сущностей. Сущности в ERwin
На диаграмме сущность изображается прямоугольником. В зависимости от режима представления
диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие
сведения.
Горизонтальная линия прямоугольника разделяет атрибуты сущности на два набора - атрибуты,
составляющие первичный ключ в верхней части и прочие (не входящие в первичных ключ) в нижней
части.
Сущность представляет собой множество реальных или абстрактных объектов, например, люди,
места, события, факты, которые имеют общие характеристики. Сущность - это логическое понятие.
Сущности соответствует таблица в реальной СУБД. В ERwin сущность визуально представляет три
основных вида информации:
атрибуты, составляющие первичный ключ;
неключевые атрибуты;
тип сущности (независимая/зависимая).
Первичный ключ - это атрибут или набор атрибутов, уникально идентифицирующий экземпляр
сущности. Если несколько наборов атрибутов могут уникально идентифицировать сущность, то
выбор одного из них осуществляется разработчиком на основании анализа предметной области.
Для каждого первичного ключа ERwin создает при генерации структуры БД уникальный индекс.
Экземпляры независимой сущности могут быть уникально идентифицированы без определения ее
связей с другими сущностями; зависимая сущность, наоборот, не может быть уникально
идентифицирована без определения ее связей с другими сущностями. Зависимая сущность
отображается в ERwin прямоугольником с закругленными углами.
Информационная безопасность систем управления базами данных
Надежда Вьюкова, Владимир Галатенко
АО "Инфосистемы Джет"
Informix-ViewPoint Pro
Продукт Informix-ViewPoint Pro используется в двух качествах:
как вспомогательный инструмент администрирования баз данных
Informix и репозиториев приложений;
как самостоятельный инструмент для разработки простейших приложений.
Инструмент администрирования SQL Central
SQL Central - графическое средство администрирования БД, работающее под Windows 95 и
Windows NT 3.51. SQL Central соответствует интерфейсу Windows 95, поэтому его легко освоить и
использовать.
Главное окно SQL Central похоже по дизайну на Windows 95 Explorer. Оно разделено на две
панели. В левой панели в виде дерева представлены серверы, базы данных и схемы баз данных с
глубиной, доходящей до каждого "контейнера" - объекта базы данных. В правой панели показано
содержимое выбранного контейнера.
Из SQL Central осуществляются все административные действия от создания баз данных,
загрузки/выгрузки до создания таблиц, процедур и назначения полномочий. SQL Central также
управляет системой репликации SQL Remote, описанной выше.
Для удобства предусмотрен drag-and-drop интерфейс, контекстная подсказка и контекстное меню
по правой кнопке мыши.
Инструментальная среда PowerBuilder
Инструментальная среда разработки PowerBuilder состоит из ряда интегрированных графических
инструментов - художников, позволяющих коллективу разработчиков проектировать, создавать,
интерактивно тестировать и применять приложения клиент/сервер в режиме "укажи и щелкни
кнопкой мыши". Cреда разработки PowerBuilder может быть расширена для организации
непосредственного доступа к набору инструментальных средств разработки других фирм. Интерфейс
пользователя PowerBuilder MDI позволяет разработчикам открывать окна нескольких художников
одновременно, что дает возможность мгновенно получить доступ к нужному режиму работы.
Поддержка средой разработки правой кнопки мыши упрощает и ускоряет процесс создания сложных
приложений.
Инструменты для создания модели в ERwin
Основные инструменты создания модели доступны как из меню, так и через окно инструментов. С их
помощью создаются независимые и зависимые сущности, идентифицирующие и неидентифицирующие
связи, полные и неполные категории, неспецифические связи и текстовые элементы.
Нажатием мыши над сущностью производится вход в один из многочисленных редакторов
ERwin:
редакторы, связанные с сущностью в целом (определение сущности,
дополнительная информация, триггеры, индексы, характеристики таблицы,
хранимые процедуры, связанные с таблицей);
редакторы атрибутов (определение атрибутов, колонки таблицы в
физическом представлении модели, репозитарий средства 4GL, например,
расширенные атрибуты в PowerBuilder ).