Супертаблицы - органы управления для взаимодействия с БД

Связи категоризации

Связи (relationships) в ERwin

Sybase Backup Server

Sybase IQ

Sybase MPP

Табл. 1. Данные с высоким уровнем секретности

Табл. 2. Данные с низким уровнем секретности

Табл. 3. Данные, доступные пользователю с высоким уровнем секретности

Технические предложения на разрабатываемый проект содержат:

Технология быстрой разработки приложений на основе CASE-средств фирмы CADRE

Тенденции в мире систем управления базами данных

Типизация данных

Типы данных, определяемые пользователем

Тиражирование данных

Требования к аппаратным ресурсам

Триггеры

Убираются внутрифирменные барьеры

Удаленное отображение данных (эмуляция терминала)

Удобные объекты (Object Easy)

Удобство и простота работы

Укрупненная система моделей организации.

Улучшение работы OLTP приложений

Улучшение работы с Data Warehouse

Улучшение работы с очень большими БД

Uniface

Унификация атрибутов

Управление эскалацией блокировок

Управление конфигурацией

Управление объектами

Управление оптимизатором SQLBase

Управление публикациями и статьями в них

Управление транзакциями

прежнему поддерживает уровни изоляции транзакций

Microsoft еще более расширила

Установка максимального числа строк на странице

Утилита Results

Утилита Tools

Внешние функции хранимых процедур

Возможности интеграции и направления развития

Распределенные базы данных невозможно рассматривать

Введение в PowerBuilder

Высокоскоростное создание/восстановление страховочных копий

CASE представляет собой интегрированный программный

WSQL DDE-сервер

Запуск (Run)

Защита данных и поддержка работы

Для взаимодействия с БД генератор окон предоставляет две разновидности органов управления,
называемых супертаблицами (SuperTable):

Супертаблица свободного формата - окно, в полях которого
изображаются данные одной строки выборки из базы данных.
Супертаблица матричного формата - отображает в виде разлинованной
роллируемой таблицы одновременно несколько строк выборки.
Для создания и редактирования супертаблицы вызывается вспомогательный инструмент -
редактор супертаблиц. Он связывается с желаемой базой данных, показывает список всех
имеющихся в ней таблиц, представлений и суперпредставлений и позволяет указать мышью
столбцы, которые необходимо включить в текущую супертаблицу. Для каждого включенного
столбца редактор создает орган управления, называемый суперполем, который позволяет вводить
или просматривать значения. Автоматически вставляются заголовки столбцов.

Редактор предлагает также заготовки командных кнопок, часто используемых при работе с БД -
Retrieve (выполнить выборку), Insert Row (вставить строку), Delete Row (удалить строку), Apply
All - сохранить в БД изменения, сделанные пользователем в супертаблице, и др. В супертаблицу
можно обычным образом включить стандартные органы управления. Таким образом,
конструктивно супертаблица представляет собой рамку, содержащую суперполя и другие органы
управления.

Для пары супертаблиц можно графическими средствами определить отношение master-detale.

Например, таким отношением можно связать супертаблицу, отображающую сведения о клиенте, и
супертаблицу, с информацией о счетах, чтобы в ней автоматически производилась выборка счетов
текущего клиента.

После того как структура супертаблицы определена, задаются ее атрибуты - некоторая выборка из
базы данных, тип используемых блокировок и др.

Развитая встроенная функциональность супертаблиц и суперполей позволяет достаточно легко
реализовать:

Выполнение и просмотр заданной выборки. Выборка задается либо
статически, при описании супертаблицы, либо динамически, программным
способом.
Выполнение "запроса по образцу". Пользователь задает в полях
супертаблицы интересующие признаки, затем нажимает кнопку "Выбрать" - в
супертаблице появляется результат выборки.
Редактирование данных. Пользователь изменяет выбранные данные,
уничтожает и вставляет строки, затем нажатием соответствующей кнопки
фиксирует сделанные изменения в БД.
Доступ к БД в супертаблицах реализован на основе универсального объектного интерфейса,
который позволяет использовать Informix или любую СУБД, доступную посредством интерфейса
ODBC.

Некоторые сущности определяют целую категорию объектов одного типа. В ERwin в таком случае
создается сущность для определения категории и для каждого элемента категории, а затем вводится
для них связь категоризации. Родительская сущность категории называется супертипом, а дочерние -
подтипом.

Например, сущность "сотрудник" может содержать данные как о штатных работниках, так и о
временно нанятых. Первые и вторые имеют различные, частично пересекающиеся наборы атрибутов
(минимальное пересечение подтипов составляет первичный ключ). Общая часть этих атрибутов,
включая первичный ключ, помещается в сущность-супертип "сотрудник".

Различная часть (например, данные почасовой оплаты для временных работников и данные о
зарплате и отпуске для штатных работников) помещается в сущности-подтипы.

В сущности-супертипе вводится атрибут-дискриминатор, позволяющий различать конкретные
экземпляры сущности - подтипа.

В зависимости от того, все ли возможные сущности-подтипы включены в модель, категорийная связь
является полной или неполной. Продолжая пример, если супертип может содержать данные об
уволенных сотрудниках, то эта связь - неполной категоризации, так как для него не существует записи
в сущностях - подтипах.

В ERwin полная категория изображается окружностью с двумя подчеркиваниями, а неполная -
окружностью с одним подчеркиванием.

Связь - это функциональная зависимость между двумя сущностями (в частности, возможна связь
сущности с самой собой). Например, важно знать фамилию сотрудника, и не менее важно знать, в
каком отделе он работает. Таким образом, между сущностями "отдел" и "сотрудник" существует связь
"состоит из" (отдел состоит из сотрудников). Связь - это понятие логического уровня, которому
соответствует внешний ключ на физическом уровне. В ERwin связи представлены пятью основными
элементами информации:

тип связи (идентифицирующая, неидентифицирующая,
полная/неполная категория, неспецифическая связь);
родительская сущность;
дочерняя (зависимая) сущность;
мощность связи (cardinality);
допустимость пустых (null) значений.
Связь называется идентифицирующей, если экземпляр дочерней сущности идентифицируется через ее
связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской сущности,
при этом входят в первичный ключ дочерней сущности. Дочерняя сущность при идентифицирующей
связи всегда является зависимой.

Связь называется неидентифицирующей, если экземпляр дочерней сущности идентифицируется иначе,
чем через связь с родительской сущностью. Атрибуты, составляющие первичный ключ родительской
сущности, при этом входят в состав неключевых атрибутов дочерней сущности.

Для определения связей ERwin выбирается тип связи, затем мышью указывается родительская и
дочерняя сущность. Идентифицирующая связь изображается сплошной линией; неидентифицирующая
- пунктирной линией. Линии заканчиваются точкой со стороны дочерней сущности.

При определении связи происходит миграция атрибутов первичного ключа родительской сущности в
соответствующую область атрибутов дочерней сущности. Поэтому такие атрибуты не вводятся
вручную.

Атрибуты первичного ключа родительской сущности по умолчанию мигрируют со своими именами.
ERwin позволяет ввести для них роли, т.е. новые имена, под которыми мигрирующие атрибуты будут
представлены в дочерней сущности.
В случае неоднократной миграции атрибута такое
переименование необходимо. Например, сущность "посредническая сделка" имеет атрибут "код
предприятия-продавца" и "код предприятия-покупателя". В данном случае первичный ключ сущности
"предприятие" ("код предприятия") имеет две роли в дочерней сущности.

На физическом уровне имя роли - это имя колонки внешнего ключа в дочерней таблице.

Мощность связи представляет собой отношение количества экземпляров родительской сущности к
соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме
неспецифической, эта связь записывается как 1:n.

ERwin в соответствии с методологией IDEF1X предоставляет 4 варианта для n, которые
изображаются дополнительным символом у дочерней сущности: ноль, один или больше (по
умолчанию); ноль или один; ровно N, где N - конкретное число.

Допустимость пустых (NULL) значений в неидентифицирующих связей ERwin изображает пустым
ромбиком на дуге связи со стороны родительской сущности.

Обозначения мощности соответственно ноль, один или больше, один или больше, ноль или один в
нотации IE приведены на рис. 1.

Sybase Backup Server - это специальный сервер для высокопроизводительной выгрузки и загрузки
баз данных, не требующий остановки SQL Server и не снижающий его производительности.

Дамп базы данных и журнала производится без прекращения использования БД. Поэтому имеется
возможность выполнять дамп часто, что повышает надежность системы. Backup Server выполняет
весь необходимый ввод-вывод. Команды на дамп или загрузку выдаются непосредственно для SQL
Server, который обращается к Backup Server. Основные характеристики Backup Server:

можно выполнять дамп параллельно частями так, что данные из одной БД и
журнала будут одновременно записываться на несколько (до 32) устройств;
один дамп может занимать несколько лент или файлов;
имеется возможность выполнять выгрузку и загрузку в локальной сети так,
что SQL Server находится на одном компьютере, а Backup Server и лента - на
другом;
поддерживаются все платформо-специфичные опции работы с лентой,
такие, как именование томов, размеры блоков и т.д.;
несколько выгрузок и загрузок могут управляться с одного или нескольких
локальных или удаленных серверов.

При правильной конфигурации производительность выгрузки может превышать 10 Гигабайт в
час.

Выгрузка производится в два этапа - сначала выгружается состояние данных на момент начала
дампа, а затем оно дополняется изменениями, произошедшими за время дампа.

Имеется возможность получения как полного дампа базы данных, так и дампа
изменений.

Иерархическая конфигурация управления

	Уровень 1 память процедурный кэш
	Уровень 2 атрибуты объектов буферы кэшей
Уровень 3 полный доступ ко всем конфигурационным переменным (более 300)

В системах поддержки принятия решений используется два типа продуктов. Одни оптимизированы
для предварительно известных запросов, а другие - для запросов "на лету" (т.е. заранее
неизвестных). Sybase IQ не требует заранее определять "пути", то есть не требует использовать
предварительные знания о структуре запросов.

Архитектура Sybase MPP

Sybase MPP - это расширение архитектуры Sybase SQL Server, разработанное и оптимизированное
для массовой параллельной обработки. Он обладает открытой параллельной архитектурой,
предназначенной для поддержки очень больших баз данных (VLDB). Sybase MPP использует
стандартный SQL и открытые интерфейсы. С ним работают те же приложения, что и с SQL Server,
без необходимости перепрограммирования (рис.9).

Sybase MPP выполняет параллельно операции считывания (выборки), добавления, обновления и
удаления записей. Параллельно выполняются и загрузка/восстановление, и создание индексов.
Архитектура Sybase MPP не содержит узких мест, связанных с разделяемой памятью или
разделяемым дисковым пространством. При выполнении параллельной выборки Sybase MPP
использует индексы.

Дополнительные процессоры и диски могут добавляться в систему постепенно, достигая
масштабируемости в сотни раз. Имеется возможность тиражировать и перестартовать ключевые
компоненты системы так, чтобы обеспечить быстрое восстановление при сбоях.

С точки зрения приложений, пользователей и разработчиков Sybase MPP выглядит как сервер с
одной логической базой данных. Для этой базы данных работает оптимизатор запросов.
Поддерживаются хранимые процедуры и глобальный репозитарий, где хранится информация о
размещении данных.

Для управления системой имеются графические утилиты.

ИмяДиагноз

Ивлев	Рак легких
Иванов	Пневмония
Ярцев	Ожог второй степени
Суворов	Микроинфаркт

Обратим внимание на то, что сведения о пациенте по фамилии Иванов присутствуют на обоих
уровнях, но содержат разные диагнозы.

Мы хотим реализовать такую дисциплину доступа, чтобы пользователи с низким уровнем
благонадежности могли манипулировать только данными на своем уровне и не имели
возможности сделать какие-либо выводы о присутствии в секретной половине сведений о
конкретных пациентах. Пользователи с высоким уровнем благонадежности должны иметь доступ к
секретной половине таблицы, а также к информации о прочих пациентах.

Дезинформирующих строк о секретных пациентах они видеть не должны:

ИмяДиагноз

Иванов	СПИД
Ивлев	Рак легких
Иванов	Пневмония
Петров	Сифилис
Сидоров	Стреляная рана
Ярцев	Ожог второй степени
Суворов	Микроинфаркт

(Обратим внимание на то, что строка "Иванов Пневмония" здесь отсутствует.)

Размножение строк, обеспечивающее необходимую дисциплину доступа, стандартными средствами
SQL можно реализовать следующим образом:

CREATE TABLE BaseTable1 (

PatientName char (20),

Disease char (20),

Level char (10)

) WITH PRIMARY KEY (PatientName, Level)

;

CREATE TABLE BaseTable2 (

UserName char (20),

SecurityLevel char (10)

) WITH PRIMARY KEY (UserName)

;

CREATE VIEW PatientInfo (

PatientName,

Disease

) AS SELECT PatientName, Disease

FROM TABLE BaseTable1

WHERE BaseTable1.Level = (

SELECT SecurityLevel FROM BaseTable2

WHERE UserName = username ()

) OR (

BaseTable1.Level = "LOW"

AND NOT EXISTS (

SELECT * FROM BaseTable1 AS X

WHERE X.PatientName = BaseTable1.PatientName

AND X.Level = "HIGH"

)

)

;

Всем пользователям предоставляется доступ только к представлению PatientInfo.
Пользователи с низким уровнем благонадежности увидят только информацию, выдаваемую
первой конструкцией WHERE:

WHERE BaseTable1.Level = (

SELECT SecurityLevel FROM BaseTable2

WHERE UserName = username () )

поскольку для них поле SecurityLevel имеет значение "LOW". В формирование представления
для благонадежных пользователей внесут вклад обе конструкции WHERE, причем в случае
совпадения имен менее секретные записи будут заслонены более секретными (конструкция NOT
EXISTS).

Мы видим, что в отличие от систем с меточной безопасностью, стандартные SQL-серверы
предоставляют довольно тяжеловесные средства для реализации механизма размножения строк.
Тем не менее, эти средства не так плохи, как может показаться на первый взгляд. Можно надеяться,
что оптимизатор SQL-запросов, входящий в комплект любой современной СУБД, сделает время
доступа к представлению PatientInfo сравнимым с временем извлечения строк из базовых
таблиц.

Нетрудно понять, что борьба с получением информации путем логического вывода актуальна не
только для медицинских баз данных и что она (борьба) требует кропотливого труда при
проектировании модели данных и иерархии привилегий, а также при реализации видимых
пользователям представлений.

моделирование бизнес-процессов, включающее описание организационной
структуры предприятий, их технологических процессов и систем
документооборота, а также связей с внешними организациями;
разработка планов реинжиниринга предприятий;
определение Автоматизированных Рабочих Мест (АРМов) и
информационного взаимодействия между АРМами и внешними базами
данных;
определение основных задач и направлений, решаемых в системе;
постановки всех функциональных подсистем;
разработка технологии решения задач пользователей в условиях автоматизации;
проектирование концептуальной модели базы данных;
определение основных входных и выходных сообщений;
определение требований к системному программному обеспечению и
инструментальным средствам, с помощью которых будет осуществляться
прикладное программирование;
определение требований к техническим средствам, средствам связи,
обеспечивающим надежную и эффективную эксплуатацию системы.
определение конфигурации и состава разрабатываемых систем.
определение организационной структуры и оценка необходимой численности
эксплуатационного персонала разрабатываемых систем.

А.В.Закис, М.И.Макаров, Н.И.Приезжий, DataX/FLORIN, Inc.
VantageTeam Builder фирмы CADRE (известный ранее как WESTMOUNT I-CASE Yourdon) - одно из
наиболее мощных на Российском рынке средств разработки информационных систем. Основанный на
структурном подходе, он позволяет вести разработку параллельно по трем направлениям -
построение модели данных, разработка модели поведения системы (функциональной модели) и
проектирование интерфейса системы. В нашей предшествующей статье мы
описали основные возможности продукта. Также весьма обстоятельно они описаны в статье Вендрова
. Поэтому в настоящей статье мы ограничимся весьма кратким общим обзором
продукта, а основное внимание уделим более детальному анализу инструментов кодогенерации. В
частности, мы поделимся некоторыми результатами собственного использования VantageTeam Builder
для быстрой генерации приложений, в том числе, для разработки собственного генератора
GRINDERY. В силу ограниченности опыта авторов в статье рассматривается генерация приложений
только для СУБД Informix, хотя VantageTeam Builder позволяет вести разработку приложений для
различных СУБД, в том числе для Sybase, Oracle и Ingres.

Сергей Кузнецов
Системы управления базами данных (СУБД) играют исключительную роль в организации
современных промышленных, инструментальных и исследовательских информационных систем.
Тематика СУБД поистине безгранична. В предлагаемом коротком обзоре описываются наиболее
интересные направления исследований и разработок.

Реализованная в S-Designor типизация данных - средство достижения универсальности типов
данных, используемых в модели. На уровне концептуальной модели разработчик оперирует с
внутренними типами данных S-Designor. Эти типы данных представлены достаточно
широким набором и, что важно, независимы от целевой СУБД. При переходе на физический уровень
эти типы данных заменяются типами данных целевой СУБД. Правила соответствия универсальных
типов данных и целевых определяются во внешнем текстовом файле, доступном для редактирования.
В нем же определяются все правила кодирования SQL-предложений для конкретной СУБД.
Соответствие типов данных и конструкции SQL-предложений для конкретной СУБД можно
переопределять, хотя такая необходимость возникает крайне редко.

Эта версия DB2 дает пользователю возможность определять новые типы данных. Новый тип
данных должен соответствовать одному из базовых типов, предоставляемых системой, но для них
может быть определена своя семантика. При этом DB2 способна манипулировать такими данными
в соответствии с определенной для них логикой. Можно задать набор операций, допустимых для
некоторого типа данных, изменив его по сравнению с относящимся к базовому типу.

В DB2 реализован механизм строгой типизации. К данным новоопределенного типа применимы
при этом только те операции, которые определены для него самого, а не для базового класса. Для
СУБД такой подход предоставляет мощный механизм контроля целостности данных.

Так, можно определить тип "почтовый индекс" как производный от целого, но при этом запретить
операции умножения и деления для данных этого типа, как не имеющие смысла, в то время как для
базового класса эти операции справедливы.

Два пользовательских типа данных, производные от одного и того же базового, различаются
системой, что можно использовать для предотвращения некорректных операций с разнородными
данными. Например, определим наряду с упомянутым выше типом "почтовый индекс" другой
производный от целого тип "номер телефона". Попытка сравнить "номер телефона" и "почтовый
индекс" будет восприниматься системой как ошибка, даже если для каждого из этих типов
операция сравнения определена.

Одной из наиболее интересных новых возможностей SQL Server 6.0 является тиражирование
данных.

В силу того, что продукт изначально создавался для работы с распределенными данными, СУБД
снабжена надежной и открытой архитектурой, хорошо интегрированной, гибкой и
управляемой.(Рис.8)

JAM как среда разработки и приложения, построенные с его использованием, не являются
ресурсоемкими системами. Достаточно сказать, что на платформе MS-Windows достаточно иметь
8MB ОЗУ и 50 MB дискового пространства для среды разработки. На UNIX-платформах
требования к аппаратуре нивелируются природой UNIX.

Триггеры - это определяемые пользователем действия, которые выполняются, когда над таблице, к
которой прикреплен триггер, выполняются операции INSERT, UPDATE или DELETE. В SQLBase
действия триггера являются хранимыми процедурами. Иными словами, пользователь создает
хранимые процедуры, которые описывают действия, совершаемые триггерами.

В SQLBase триггеры используются для решения трех основных задач:

Усиление ссылочной целостности - Триггеры могут быть использованы для
реализации ограничений ссылочной целостности, выходящие за пределы
стандартных ограничений SQLBase. Например, пользователь может захотеть
реализовать правило. каскадного изменения данных (update cascade rule). Он
может это сделать, создав триггер, который будет обновлять дочернюю
таблицу (таблицы) при каждом изменении колонки в родительской таблице.
Проверка данных - Триггеры могут выполнять разнообразную проверку
данных. Значения колонок могут передаваться в триггерные процедуры в
качестве параметров, где над ними могут производиться самые разнообразные
операции. В текущей версии SQLBase реализован механизм, который
позволяет производить ввод данных в таблицы непосредственно из триггера,
без передачи информации извне. Например, пользователь может создать
триггер, который будет получать из приложения данные для ввода в строку
таблицы, создавать уникальный ключ для этой строки внутри своей процедуры
и передавать в базу данных полную строку с ключом. Помимо генерации
ключей, триггеры SQLBase могут выполнять и другие подобные операции.
Регистрация изменения данных - Создатель таблицы или администратор
базы данных может пожелать иметь информацию о времени каждого
изменения данных в таблице, а также о том, какой пользователь эти изменения
производил. Для этого он создает триггер, в который поступает системное
время операции UPDATE и имя пользователя. Процедура триггера затем
вводит эту информацию в специальную таблицу регистрации изменений.
Использование триггеров подобного типа позволяет организовать системы

регистрации изменений не зависящие от действий пользователя и поэтому
наиболее надежные при попытках выполнения несанкционированных
операций.

Поскольку триггер запускается автоматически при изменении содержимого таблицы, любой
пользователь, обладающий привилегиями по отношению к этой таблице, может запустить триггер.
Следует отметить, что триггер всегда запускается с привилегиями автора, а не пользователя, т.е. на
время выполнения триггера пользователь получает привилегии автора процедуры, вызываемой
триггером.

Триггер может быть определен для выполнения либо перед операцией insert/update/delete (before
триггер), либо после нее (after триггер). Типичный пример использования before триггеров -
проверка данных. After триггеры полезны в тех случаях, когда хранимая процедура триггера
содержит код, анализирующий содержимое таблицы, на которой определен триггер, и этот код
должен включать результаты последней операции insert/update/delete.

Операции insert/update/delete, которые содержат предложения WHERE или суб-запросы (sub-
selects), модифицируют более одной строки таблицы. Триггеры SQLBase могут быть
сконфигурированы таким образом, чтобы запускаться только один раз за всю операцию или
каждый раз при изменении отдельной строки.

Update триггеры могут быть определены таким образом, чтобы запускаться только при изменении
отдельных колонок таблицы (селективные update триггеры) или реагировать на любое изменение
данных в таблице.

При передаче данных в процедуры триггеров можно использовать следующие типы данных в
качестве параметров процедур:

Значения колонок таблицы - Поскольку триггер определяется на конкретной
таблице базы данных, он "знает" о ее строении: количестве, именах и типах
колонок и т.д. Поэтому значения колонок таблицы могут передаваться в
процедуру непосредственно по своим именам.
Константы
Псевдоконстанты - В процедуру можно передавать некоторые ключевые
слова SQLBase, такие как USER, SYSTIME и другие.

Если в процессе выполнения операции UPDATE содержимое колонки изменяется, имеется

возможность передать в процедуру триггера как старое, так и новое значение колонки. Для этого
служит предложение REFERENCING в определении триггера. Если предложение REFERENCING
не используется, по умолчанию значение колонки является старым для before update триггеров и
новым для after update триггеров. Поскольку для insert триггеров старых значений не существует,
значение колонки по умолчанию является новым. Аналогично, значение колонки для delete
триггера является старым.

Ограничения триггеров

При использовании триггеров существует целый ряд ограничений:
Все триггеры должны иметь уникальные имена.
Нельзя иметь два идентичных триггера. Другими словами, не может быть
двух before insert триггеров на одной таблице.
Если update триггер определен на конкретной колонке или группе колонок,
на данной таблице нельзя определить update триггер на всю таблицу.
На таблице можно определить не более двух insert, двух delete и четырех
update триггеров одновременно.
Допускается не более восьми уровней рекурсии триггеров. Рекурсия
триггеров возникает в тех случаях, когда операция insert/update/delete внутри
процедуры триггера запускает другой триггер.
Предложение REFERENCING допускается только для update триггеров.
Кроме того, это предложение возможно только для триггеров, запускающихся
для каждой изменяемой строки отдельно, поскольку в противном случае
значения колонок становятся неопределенными.
Хранимая процедура триггера должна быть статической.

Пример триггера

Ниже приведен пример триггера, который реагирует на обновление колонки в таблице.
Предположим, мы имеем таблицу T1, содержащую целочисленную колонку C1 и таблицу T2 с
колонками (OldC1 int, NewC1 int, Updater char(10)). В триггер передаются старое и новое значение
колонки C1 и имя пользователя. Триггер затем вводит эту информацию в таблицу T2. (Отметим
возможность определения хранимой процедуры триггера непосредственно в теле триггера с
помощью оператора INLINE.)

create trigger tg1 before update of c1 on t1
referencing old as o new as n
(execute inline (o.c1, n.c1, user)
procedure p1 static
parameters
number: old
number: new
string: updater
actions
call sqlimmediate( 'insert into t2 values (:old, :new, :updater)' )
for each row;

Думаем, многие руководители сейчас озабочены информационной разобщенностью своих
специалистов. Корпоративные системы сыграют немаловажную роль в том, чтобы коллектив
начал работать как единая команда, ориентированная на выполнение общей цели (увеличение
прибыли предприятия).

Для обеспечения согласованной работы произвольного числа пользователей в единой
компьютерной сети наиболее подходящей является технология клиент/сервер, в которой один или
несколько самых мощных компьютеров, называемых серверами, используются не для работы, а
выделяются для хранения данных со всех участков и, главное, для обеспечения правильного
взаимодействия между рабочими местами. Все остальные компьютеры в сети являются клиентами.
Раньше в компьютерных сетях применялась технология файл-сервер, которая практически не
обеспечивала защиты данных от сбоев и ошибок специалистов и создавала поэтому множество
аварийных ситуаций. Клиент/серверная технология гораздо надежнее и "умнее": она позволяет
избегать потерь данных (например, когда несколько людей пытаются одновременно вносить
изменения в одни и те же данные), гораздо лучше обеспечивает сохранность информации и от
случайностей, и от злого умысла, и, наконец, она дает возможность работать в сети гораздо
большему числу людей одновременно.

Средства эмуляции терминалов исторически являются одними из первых продуктов, реализующих
возможность совместного функционирования ГЭВМ, СЭВМ и ПЭВМ. Они по-прежнему остаются
одними из наиболее популярных продуктов, особенно для удаленного администрирования
ресурсами ГЭВМ и СЭВМ.

SOFTWARE AG предлагает использовать в качестве эмулятора терминалов продукт ENTIRE
CONNECTION (рис. 3).

ГЭВМ (IBM)СЭВМ (UNIX)

MS Windows

Наследование, инкапсуляция и полиморфизм
Доступ к элементам управления других фирм
PowerBuilder использует практический подход к объектной технологии, позволяющий разработчикам
информационных систем осуществить быстрый переход к объектно-ориентированной разработке без
необходимости знать и использовать специфические трудноизучаемые языки программирования. Он
полностью поддерживает наследование, инкапсуляцию и полиморфизм.

Приложение, созданное при помощи PowerBuilder, является композицией ряда объектов, таких как
окна, меню, функции, структуры и Окна данных. Объекты, выполняющие общие функции,
такие как Кнопка печати (Print button), могут многократно использоваться в разных
приложениях, реально сокращая время разработки, а также повышая продуктивность программистов
и качество программ.

PowerBuilder включает графическую среду для создания определенных пользователем объектов,
событий и функций, которая значительно упрощает повторное использование кода и делает более
удобным сопровождение. Поддержка многоуровневого наследования облегчает разработку и
сопровождение библиотек объектных классов. Доступ к элементам управления других фирм, таким
как объекты VBX и C++, осуществляется прозрачно при помощи Художника объектов
пользователя (User Objects Painter).

Понятие "интуитивно понятный интерфейс" означает, что уже после 1-2 часов экспресс-обучения
человек свободно может общаться с программой. Такие системы учитывают психологию людей,
они дружелюбны и понятны, широко используют изображения и звук вместо текста. Работать с
такой системой может даже непрофессионал, и ему не требуется изучать тома документации.
Человек видит на экране просто свой рабочий стол со стопками чистых бланков, папками с
подшивками документов, журналами и ведомостями.

Кроме того, существует ряд современных технологий, облегчающих общение человека и
компьютера. Эти технологии особенно оценят те специалисты, которым приходилось работать с
неудобными системами, где простейшая операция требует многократных нажатий кнопок
клавиатуры и сложных переходов по меню.

Основными задачами описания организации на уровне укрупненной системы моделей являются
отображение основных бизнес-процессов, которые описаны на стратегическом уровне, исходя из
основных целей и задач организации (без привязки к ее структуре), на реальную иерархически -
функциональную структуру организации, а также выделение основных функций подразделений и
уточнение состава и характеристик бизнес -процессов.

На этом этапе проводится обследование подразделений, в результате которого выявляются
выполняемые в них основные функции, их вход и выход. Эти функции распределяются по бизнес-
процессам, проходящим через каждое подразделение. В результате формируются и уточняются
общие списки бизнес-процессов и функций по подразделениям, списки входных и выходных
документов и другие характеристики, и вся эта информация наполняет каждый бизнес-процесс
конкретным содержанием. Таким образом, бизнес-процессы становятся путеводителями через
иерархически - функциональную структуру организации, определяющими функциональные и
информационные связи между различными подразделениями.

В процессе отображения бизнес-процессов по уровням организационной иерархии формируется и
уточняется общий список бизнес-процессов, и могут появиться новые бизнес-процессы.

В Oracle 7.3 модифицированы многие алгоритмы, связанные с обработкой OLTP приложений.
Увеличена скорость выполнения таких приложений, улучшено использование буферов памяти,
более компактным стал программный код, SQL-операторы и процедуры занимают меньше места в
оперативной памяти. Триггеры БД теперь хранятся в откомпилированном виде, что
ускоряет их выполнение. Улучшена работа Parallel Server Option. Обмен данными между
узлами кластера сведен к минимуму, уменьшена вероятность возникновения коллизий. SQL*Net
может при открытии нового сеанса связи с кластером учитывать загрузку узлов кластера.
Улучшены алгоритмы работы Oracle в среде мониторов транзакций.

Следует также упомянуть о появлении механизма сериализованных транзакций. Ранее Oracle
обеспечивал согласованный результат выполнения запроса без выполнения блокировки. Однако
для того, чтобы обеспечить эту согласованность в рамках транзакции приходилось объявлять эту
транзакцию read only (т.е. она не содержала операторов, модифицирующих данные). Это снижало
результаты Oracle при тестировании по тесту ТРС С, т.к. запросы и модификации приходилось
выносить в отдельные транзакции. Новый вид сериализованных транзакций позволяет смешивать
в общей транзакции и DML операторы и операторы запроса. При этом такая транзакция работает
на согласованном представлении БД, т.е. не замечает всех изменений, производимых во время ее
работы другими транзакциями. Таким образом механизм согласованности без блокировки
расширен на всю транзакцию.

В этой области все улучшения можно разбить на 2 группы:

улучшение алгоритмов оптимизации специфичных для Data Warehouse
запросов;
ускорение выполнения запросов к большим таблицам.

Задачи, связанные с использованием Data Warehouse породили группу специфических запросов,
для которых не годятся стандартные методы оптимизации. Кроме того, успешное выполнение
запросов к большим таблицам невозможно без распараллеливания работы. И оптимизатор должен
учитывать при выборе плана выполнения запроса такие факторы, как степень распараллеливания,
количество процессоров, распределение данных таблицы по дискам, распределение таблиц по
узлам распределенной БД, близость тех или иных процессоров и дисков в МРР архитектурах. Не
учитывание этих факторов может значительно замедлить выполнение SQL операций. Например, в
некоторых случаях параллельное сканирование таблицы выгоднее, чем выборка из нее по индексу.
Cost based оптимизатор Oracle 7.3 учитывает все эти факторы. Кроме того, для правильного
построения плана выполнения SQL оператора желательно учитывать распределение данных в
столбцах таблицы. Поэтому Oracle 7.3 позволяет собирать такую информацию и строит на ее
основе гистограммы распределения данных в столбце, а оптимизатор использует эти
гистограммы при принятии решения.

Для Data Warehouse часто используются звездные запросы (star query). В них извлекается
информация из одной огромной центральной таблицы и множества мелких таблиц -
справочников. Oracle 7.3 выделяет и оптимизирует такие запросы. При этом сначала соединяются
справочники, а затем эта небольшая сводная справочная таблица соединяется с центральной
таблицей. При работе с центральной таблицей используются индексы.

В задачах Data Warehouse часто используются представления (View ), полученные за счет
объединения (Union) множества мелких таблиц однотипной структуры. Например, продажи за год
- объединение продаж за месяц. Операции выборки из таких больших VIEW будут ускорены, если
быстро будут исключены из рассмотрения те мелкие таблицы, которые не удовлетворяют

условиям запроса. Например, если нас интересуют продажи за первые 10 месяцев, то не следует
учитывать продажи за ноябрь и декабрь. Оптимизатор Oracle 7.3 учитывает это при работе.
Ускоряется и выполнение запросов с условием NOT IN (анти JOIN ). Оптимизатор также
учитывает новые алгоритмы Oracle, ускоряющие выполнение SQL операторов. Среди них следует
отметить следующие:

Новый алгоритм соединения таблиц с использованием хэширования (hash join). Этот
алгоритм исключает необходимость сортировки и слияния участвующих в соединении таблиц. Он
дает ускорение в 10 - 100 раз. Он очень удобен и для параллельной обработки. Основная идея
заключается в том, что меньшая из таблиц (или меньшая часть двух соединяемых фрагментов
таблиц) хэшируются в оперативной памяти. А вторая таблица (фрагмент) сканируется и для
каждой ее строки по хэш функции находится в оперативной памяти соответствующая запись
первой таблицы. Разделение таблиц на фрагменты также выполняется с учетом хэш функций.

Битовые индексы. Для индексирования столбцов с низкой кардинальностью ( т. е.
содержащих небольшое число значений, например: пол - М или Ж, цвет - красный, желтый, синий)
удобно использовать битовые (bit map) индексы. Для каждого значения столбца строится битовая
линейка, в которой число битов равно числу значений в столбце и биты, соответствующие
позиции данного значения в столбце, установлены в 1. Например, для столбца "пол" будет
построено 2 битовых линейки. Операции поиска по этому столбцу сведутся для Oracle к
выполнению логического И/ИЛИ над этими линейками. Кроме того, битовые линейки хранятся в
упакованном виде. Oracle умеет одновременно работать как с битовыми (т.е. более компактными,
чем обычные индексы) так и с обычными индексами. Тип индекса прозрачен для приложения, но
скорость выборок из больших таблиц с битовыми индексами возрастает значительно. Ранее
битовые индексы использовались в SQL*Textretrieval для работы с текстовыми БД.

Усиление распараллеливания выполнения операций.

В Oracle 7.3 распараллеливаются такие
подэтапы выполнения SQL запроса, как SCAN, JOIN, AGREGATE, DUBLICATE
ELIMINATION, UNION, UNION ALL, HASH JOIN. Поэтому выборки, построения и
перестройки индекса, копирования таблиц реализуются быстрее.

Асинхронное оптимистичное чтение. При сканировании таблиц Oracle может не
ограничиваться считыванием с диска необходимой в данный момент информации, а совместить
обработку этой информации со считыванием последующих блоков. Считывание выполняется в
параллельном режиме и время выполнения запроса снижается за счет уменьшения влияния
ввода/вывода.

Выделенные временные табличные пространства. В предыдущих версиях Oracle оператор
SQL, выполняющий сортировку, создавал, использовал, а затем удалял временные области в БД.
Это требовало времени на управление выделением пространства. Кроме того, в том же Tablespace
могли находиться и другие объекты БД. Создание выделенных tablespace только для сортировки
позволит избежать этих накладных расходов.

Перестройка индекса на базе существующего индекса. Использование при перестройки
индекса информации о старом индексе ускоряет выполнение этой операции. В больших БД
перестройка индекса позволяет освободить неиспользуемое индексом пространство БД.

В этой области все улучшения можно разбить на три группы: ускоренная подготовка БД к работе;
улучшение управления пространством в БД, повышение производительности при работе с
большой БД.

До сих пор для повышения надежности работы прикладной системы на базе Oracle использовались
два варианта: кластерная архитектура (Oracle Parallel Server) и репликация. В версии Oracle 7.3
добавляется новая возможность - STAND BY (резервная) база. Это очень удобно,
например, на случай возможности взрыва центрального офиса с основной БД. Stand by база
создается на другом компьютере (возможно в другом районе) и является копией основной базы.
Она находится в режиме постоянного восстановления и не доступна для работы. Восстановление
резервной базы ведется автоматически на основе передаваемых ей от основной базы журнальных
файлов. В случае уничтожения основной базы, резервная очень быстро переводится в рабочий
режим и становится основной. В последующее время на месте старой основной БД можно
организовать новую резервную БД. Основная и резервная БД должны работать на одинаковых
компьютерах, одинаковых версиях операционной системы и Oracle.

До сих пор в случае сбоя БД Oracle выполнял ее восстановление в два этапа: rollout - откат вперед
с восстановлением всех потерянных при сбое изменений и rollback - откат назад транзакций, не
законченных к моменту сбоя. До окончания этих двух последовательных этапов БД была
недоступна для работы. Процесс открытия большой БД после сбоя мог затянуться надолго.
Поэтому в Oracle 7.3 Вы можете выполнить быстрое восстановление и получить доступ к
БД после первого этапа, а rollback будет выполняться позднее в фоновом режиме. Это снизит
время простоя БД.

Новая утилита DB_VERIFY позволит Вам выполнить контроль целостности БД, ее блоков,
backup копий БД. В версии Oracle 7.3 значительно улучшено управление пространством в БД.
Объекты БД ( таблицы, индексы, сегменты отката и т.д. ) могут состоять из частей (экстентов),
разбросанных по tablespace.
Их число было ограничено. Сейчас это ограничение снято и очень
большие объекты БД могут занимать неограниченное число экстентов. Кроме того, если в
результате модификации данных область, занимаемая таблицей, индексом и т.д. заполнена лишь
частично, то можно освободить неиспользованное пространство, передав его в общий пул
свободного пространства tablespace (команда ALTER TABLE ... DEALLOCATE UNUSED).
Это позволит разместить в БД больше объектов. Если в БД образуется несколько смежных
участков свободного пространства, то процесс SMON умеет склеивать их в единый кусок. Однако
теперь это может сделать и администратор БД с помощью команды ALTER TABLESPACE ...
COALESCE.

Ну и наконец для больших БД логический экспорт БД и ее больших объектов всегда занимал
много времени. Утилита экспорта EXP работала с БД как обычное приложение, использующее
команды языка SQL и стандартный вариант их обработки. Новый (прямой) режим
экспорта работает в несколько раз быстрее, поскольку он "обходит" многие фазы стандартной
обработки SQL и выбирает данные из БД в обход Oracle Server.

(Compuware)

Uniface 6.1 представляет собой среду разработки крупномасштабных приложений "клиент-сервер"
и имеет следующую компонентную архитектуру:

Application Objects Repository (репозиторий объектов приложений) содержит метаданные, автоматически используемые всеми остальными компонентами на протяжении жизненного цикла ИС.
Application Model Manager поддерживает прикладные модели, каждая
из которых представляет собой подмножество общей схемы БД с точки зрения
данного приложения.
Rapid Application Builder - средство быстрого создания экранных форм
и отчетов на базе объектов прикладной модели. Оно включает графический редактор форм, средства прототипирования, отладки, тестирования и документирования. Реализован интерфейс с разнообразными типами оконных элементов
управления (Open Widget Interface) для существующих графических систем -
MS Windows (включая VBX), Motif, OS/2.
Developer Services (службы разработчика) - используются для
поддержки крупных проектов и реализуют контроль версий, права доступа,
глобальные модификации и т.д. Это обеспечивает разработчиков средствами
параллельного проекти-рования, входного и выходного контроля, поиска,
просмотра, поддержки и выдачи отчетов по данным системы контроля версий.
Deployment Manager (управление распространением приложений) -
средства, позволяющие подготовить созданное приложение для
распространения, установить и сопровождать его (при этом платформа
пользователя может отличаться от платформы разработчика). В их состав
входят сетевые драйверы и драйверы СУБД, сервер приложений (полисервер),
средства распространения приложений и управления базами данных. Uniface
поддерживает интерфейс практически со всеми известными программно-
аппаратными платформами, СУБД, CASE-средствами, сетевыми протоколами
и менеджерами транзакций.
Personal Series (персональные средства) - используются для
создания сложных запросов и отчетов в графической форме, а также для
переноса данных в такие системы, как WinWord и Excel.

В качестве примера можно привести результаты предварительного анализа перечисленных выше
СП, которые сведены в краткую таблицу характеристик, приведенную ниже.

Таблица характеристик СП

Поддержка полного жизненного цикла ИСОбеспечение целостности проекта Независимость от платформыОдновременная групповая разработка БД и приложений

СП	West-mount I-CASE + Uniface	Designer/2000+Developer/2000	SILVER-RUN + JAM	ERwin/ERX + PowerBuilder
+	+	+	+
+	+	-	-
+ (ORACLE, Informix, Sybase, Ingres и др., dbf-файлы)	- (целевая СУБД - только ORACLE)	+ (ORACLE, Informix, Sybase, Ingres и др.)	+ (ORACLE, Informix, Sybase, поддержка ODBC)
+	- *)	- *)	- *)

*) разработчики приложений могут начинать работу с базой данных только после
завершения ее проектирования.

Анализ данных, приведенных в таблице, показывает, что из перечисленных СП только комплекс
Westmount I-CASE+Uniface наиболее полно удовлетворяет всем критериям, принятым в качестве
основных. Так, например, в комплексе Westmount I-CASE+Uniface целостность базы проектных
данных и единая технология сквозного проектирования ИС обеспечивается за счет использования
интерфейса Westmount-Uniface Bridge. Следует отметить, что каждый из двух продуктов сам по
себе является одним из наиболее мощных в своем классе.

Таким образом, наиболее развитыми средствами разработки крупномасштабных ИС на
сегодняшний день является, по мнению автора, комплекс Westmount I-CASE+Uniface. С другой
стороны, его применение не исключает использования в том же самом проекте таких средств, как
PowerBuilder, для разработки сравнительно небольших прикладных систем в среде MS
Windows.

[]
[]
[]

Зависимая сущность может наследовать один и тот же внешний ключ от более чем одной родительской
сущности, или от одной и той же родительской сущности через несколько связей. Если не введены
различные роли для такого множественного наследования, ERwin считает, что в зависимой сущности
атрибуты внешнего ключа появляются только один раз.

Унификация - это объединение двух или более групп атрибутов внешних ключей в один внешний
ключ (группу атрибутов), в предположении, что значения одноименных атрибутов в дочерней
сущности всегда одинаковы.

Рассмотрим пример: сущность "сотрудник" имеет первичный ключ "код сотрудника" и связан
идентифицирующей связью с сущностями "супруга" и "дети". При этом происходит миграция
первичного ключа в зависимые сущности. В свою очередь, сущность "супруга" связана
неидентифицирующей связью с сущностью "дети". Имеются два пути миграции ключа, однако в
сущности "дети" атрибут "код сотрудника" появляется один раз в качестве элемента первичного
ключа.

Существуют случаи, когда унификация атрибутов дает неверный с точки зрения предметной области
результат. Для отмены унификации для атрибутов вводятся имена ролей.

Эскалация блокировок в SQL Server - это предельное количество блокировок страниц данных для
таблицы, при достижении которого транзакция будет блокировать таблицу целиком. Имеется
возможность управлять этой границей, которая по умолчанию составляет 200 страниц.

Для управления сервером имеется как набор хранимых процедур и set-команд, так и графическое
средство.

При работе с параметрами конфигурации в командном режиме введено три уровня представления -
базовый уровень, служащий для управления основными параметрами, промежуточный уровень и
детальный уровень, на котором доступны все параметры тонкой настройки (рис.10). Параметры
организованы иерархически в соответствии с группами функций SQL Server, которыми они
управляют. Имеется возможность создать несколько поименованных конфигураций и легко
переключаться между ними.

Объекты, созданные в процессе разработки приложения, хранятся в библиотеках PowerBuilder.
Разработчики могут использовать в приложении объекты из одной или нескольких библиотек.
Обычно каждый член коллектива разработчиков имеет свою собственную тестовую библиотеку, а
также использует разделяемые библиотеки общих объектов, хранящиеся на сетевых файловых
серверах.

Оптимизатор SQLBase выбирает план выполнения запроса на основе информации, которая
хранится в самой базе данных. При этом он, естественно, не обращается к данным непосредственно
(например, не производит анализ распределения данных по колонкам заданной таблицы),
поскольку в этом случае выбор плана выполнения занимал бы гораздо больше времени, чем
собственно выполнение запроса. Вместо этого оптимизатор использует статистику, хранящуюся в
таблицах базы данных. Эта статистика создается сервером SQLBase сразу после создания объектов
базы данных или в результате выполнения команды UPDATE STATISTICS.

В новой версии SQLBase 6 пользователю предоставлена возможность изменять эту статистику и,
таким образом, воздействовать на оптимизатор и реальное выполнение SQL запросов.

Изменение статистики возможно с помощью новой команды UPDATE STATISTICS. Полное
описание синтаксиса этой команды приведено в документации по SQLBase. Вкратце же синтаксис
команды UPDATE STATISTICS выглядит следующим образом:

Для модификации табличной статистики

UPDATE STATISTICS ON TABLE имя-таблицы

SET колонка-статистики = ...., ;

Например,

UPDATE STATISTICS ON TABLE ORDER

SET ROWCOUNT = 10000, PAGECOUNT=100;

(количество строк в таблице равно 10000, а количество страниц - 100)

Для модификации индексной статистики

UPDATE STATISTICS ON INDEX имя-индекса

SET колонка-статистики = ...., ;

Например,

UPDATE STATISTICS ON INDEX ORDER_IX1

SET HEIGHT = 2, CLUSTERCOUNT = 10000, LEAFCOUNT = 10000/150,
DISTINCTCOUNT(order_num) = 5000 ;

Управление статистикой базы данных

Управление статистикой базы данных в SQLBase служит следующим целям:

Предоставить средства изучения поведения приложений в процессе разработки, когда вы не
имеете доступа к реальной (продажной) базе данных.

Помочь разработчику и администратору смоделировать реальную базу данных используя малое
количество фактических данных.

Следует отметить, что существующий метод воздействия на выполнение SQL запросов с помощью
команды UPDATE STATISTICS является очень сложным и весьма нелинейным. В новой версии
SQLBase планируется появление специального модуля "Управление планом выполнения", которая
даст возможность специалистам и пользователям воздействовать на способы выполнения запросов
к базе данных непосредственным образом.

После того как база данных открывается для публикации (это видно по соответствующей
пиктограмме в диалоговом окне среды администрирования), администратор определяет, какие
таблицы или/и части таблиц подлежат тиражированию. Организация
тиражирования данных SQL Server обеспечивает высокую гибкость и позволяет точно
указать, какие элементы базы данных получает тот или иной подписчик.(Рис.9,10)

Архитектура Sybase System 11 поддерживает как синхронную, так и асинхронную модель
управления транзакциями. Модель выбирается в соответствии с требованиями предметной
области.

Централизованное хранение данных и доступ к центральной БД в условиях географически
распределенной системы приводят к необходимости установления соединений между центральным
сервером, хранящим данные, и компьютерами-клиентами. Большинство компьютеров-клиентов
отделены от центрального сервера медленными и недостаточно надежными линиями связи,
поэтому работа в режиме удаленного клиента становится почти невозможной. Этим можно
объяснить часто существующую ситуацию, когда в узлах распределенной системы функционируют
группы автоматизированных рабочих мест (АРМ) и эти группы АРМ не связаны друг с
другом.

Содержательная сторона задачи обычно требует обмена данными между группами АРМ, так как
изменения в данные могут вноситься в одной группе АРМ, а использоваться - в другой. Обмен
данными на практике часто реализуется регламентной передачей файлов, либо через модемное
соединение, либо "с курьером".

То, что данные доставляются к месту назначения не системными средствами, а путем
экспорта/импорта файлов, приводит к необходимости участия человека в процессе обмена, что
влечет за собой неоперативность поступления данных и необходимость реализации внешних
механизмов контроля целостности и непротиворечивости. Результатом является высокая
вероятность ошибок. Кроме того, реализация всех алгоритмов обмена данными и контроля в этом
случае возлагается на прикладных программистов, проектирующих АРМ. Объем работ по
программированию и отладке подпрограмм обмена соответствует числу различных АРМ. Это
также приводит к повышению вероятности ошибок в системе.

В современной технологии АРМ объединены в локальную сеть. АРМ-клиент выдает запросы на
выборку и обновление данных, а СУБД исполняет их. Запросы клиента в соответствии с
требованиями задачи сгруппированы в логические единицы работы (транзакции).
Если все
операции с базой данных, содержащиеся внутри транзакции, выполнены успешно, транзакция в
целом выполняется успешно (фиксируется). Если хотя бы одна из операций с БД внутри
транзакции не выполнилась успешно, то все изменения в БД, произведенные к этому моменту из
транзакции, отменяются (происходит откат транзакции). Такое функционирование обеспечивает
логическую целостность данных в базе данных.

При распределенной обработке изменения, проводимые приложением-клиентом, могут
затрагивать более чем один сервер СУБД. В этом случае для поддержания целостности необходимо
применение транзакционного механизма, реализуемого системными средствами, а не прикладной
программой.

Производители современных промышленных СУБД обеспечивают поддержку распределенной
обработки транзакций. Распределенная обработка данных основывается на синхронных или
асинхронных механизмах обработки распределенных транзакций. Эти механизмы могут
использоваться совместно. Выбор того или иного механизма зависит от требований конкретной
подзадачи, так как каждый механизм обладает сильными и слабыми сторонами.

Sybase System 11 по- прежнему поддерживает уровни изоляции транзакций 1-3. К ним добавился
уровень 0, который для данных, уже модифицированных некоторой транзакцией, предотвращает
их изменение другими транзакциями. Другие транзакции, модифицирующие такие данные,
блокируются до завершения первой транзакции. Однако другим транзакциям позволяется
считывать измененные, но незафиксированные данные. Уровень изоляции 0 также известен под
названием "грязное чтение".

Производительность: Именованные кэши


Таблицы и индексы ставятся в соответствие именованным кэшам Уменьшается уровень конкуренции за ресурсы менеджера буферов Можно управлять использованием памяти для баз данных, индексов и таблиц Возможно назначение кэша для объекта во время исполнения Оптимизатор учитывает особенности работы с множественными кэшами

У SQL Server 6. 0 Microsoft еще более расширила возможности параллельной обработки
симметричной архитектуры сервера. За счет параллельного выполнения широкого диапазона
внутренних функций СУБД с использованием множественных потоков операционной системы при
работе на многопроцесорных системах резко возрастает производительность и масштабируемость
многих операций (таких как определенные типы запросов, сканирование таблиц, создание
индексов, создание/восстановление страховочных копий, проверка целостности базы данных и
т.д.).

При создании таблицы или индекса можно указать максимальное число строк, хранимых на
странице данных или странице индекса. Эта возможность позволяет оптимизировать блокировки
для часто обновляемых таблиц. SQL Server использует установленное значение при добавлении и
удалении строк.

Утилита Результаты - это средство доступа к данным и формирования отчетов для конечного
пользователя, которое позволяет непрограммистам удовлетворять собственные потребности по
обработке данных и создании отчетов. Утилита Результаты работает в режиме образца-подсказки
при создании запросов и отчетов. Пользователь начинает работу с построения запроса к базе
данных. Затем при помощи меню-управляемого интерфейса он создает запрос для выбора
информации из базы, которую он хотел бы видеть в отчете.

После того, как запрос определен, у пользователя имеется возможность просмотреть полученную
информацию в различных форматах, включая:

Формы - выбранные данные отображаются по одной записи для
детального изучения информации
Таблицы - данные отображаются в виде строк и столбцов, в формате
сходном с форматом представления данных в электронных таблицах.
Пользователь может просматривать данные, перемещаясь вперед или назад
по этой таблице.
Отчеты - данные отображаются в виде отчета, с заголовками,
сносками, итогами и т.д., определенными пользователем. Пользователи могут
воспользоваться шаблонами отчетов, созданных разработчиками приложения,
утилитой Результаты или Построителем Отчетов.
Наклейки - данные отображаются в одном из стандартных форматов
для наклеек: конверты, складские наклейки и др.
Экспортирование - позволяет пользователю записать данные во
внешний файл в различных форматах хранения данных.
Так как сама утилита Результаты написана на языке 4GL PROGRESS, она является легко
изменяемой и расширяемой, а также может быть легко включена в любое PROGRESS
приложение

Когда Ваше приложение должно устанавливаться в различных местах, то сразу возникает ряд
вопросов.

Будет ли разрешено пользователям модифицировать имеющиеся процедуры и, возможно,
добавлять новые?

Будет ли разрешено пользователям изменять определения Словаря Данных?

Есть ли необходимость поставлять обновленные версии приложения без повторной поставки всей
системы?

Утилита Tools содержит набор программ, предназначенных для упаковки и распространения
приложений PROGRESS, включая программы для:

Блокирования схемы базы данных таким образом, чтобы конечный
пользователь не был способен модифицировать определений данных
Поставки следующих версий пользователям, включая новые определения
данных и новые или модифицированные модули приложения
Подготовки загрузочной информации, программ пакетной обработки и пр.
для пользователей.
Утилита Tools позволяет Вам решать многочисленные вопросы, связанные с распространением,
инсталляцией и обновлением версий Ваших приложений.

Хранимые процедуры позволяют объединить большое количество операций над базой данных
непосредственно с базой данных. Это обеспечивает возможности расширения функциональности
наряду с большой гибкостью. Дополнительно, хранимые процедуры имеют следующие
преимущества:

Перенос процедурной логики в базу данных для распределенной
использования многими приложениями.
Улучшение производительности путем объединения большого количества
запросов к базе данных в один вызов сервера.

Хранимые процедуры также предоставляют мощный процедурный язык с конструкциями, хорошо
знакомыми разработчикам.

В случае SQLBase процедурным языком является SAL. Однако, как указывалось выше, язык
хранимых процедур SQLBase все еще является подмножеством полного языка SAL, имеющегося в
SQLWindows. Кроме того, многие пользователи SQLBase хотели бы иметь возможность создавать
собственные процедуры, не будучи привязанными к какому-либо конкретному языку.

Естественно, одним из способов расширения функциональности хранимых процедур SQLBase
является расширение используемого подмножества языка SAL. Такой путь, однако, не дает
возможности пользователям гибко добавлять компоненты и собственные функции для реализации
дополнительной функциональности существующих систем. Поэтому процесс придания хранимым
процедурам SQLBase большей "открытости" проводится по двум направлениям:

Создание мощного и расширяемого механизма, позволяющего
пользователям самим расширять функциональность хранимых процедур на
основе концепции plag & play с применением стандартных компонентов или
пользовательских программ.
Возможность выбора пользователем любого языка программирования для
реализации процедурной логики.

Первым шагом на этом пути является поддержка в SQLBase нового типа объектов базы данных,
называемого внешней функцией (External Function).

Внешняя функция - это любая пользовательская функция, которая располагается в отдельной
библиотеке (Dynamic Link Library или DLL для платформы Windows) и может быть динамически

вызвана для выполнения из другой задачи. Функция может быть написана на любом языке,
допускающем создание DLL. Единственным ограничением является требование использования в
качестве параметров типов переменных, поддерживаемых SQLBase, и следование требованиям
программного интерфейса.

После того, как внешняя функция и интерфейс к ней описываются в базе данных, эта функция
может быть вызвана из хранимой процедуры точно так же, как вызывается любая другая функция
SAL. Вызов внешней функции можно представить в виде следующей диаграммы.

Пользователи могут создавать или приобретать библиотеки полезных функций, которые
выполняют специфические задачи, например, производят трансформации данных, чтобы
отмасштабировать на другие единицы измерения. Определяемые пользователям функции могут
быть как очень простыми, так и очень сложными и выполняться в различных режимах в
зависимости от типа задачи, которую они решают.

Применение внешних функций дает пользователям SQLBase следующие преимущества:

Этот механизм помогает пользователям управлять расширением
функциональности SQLBase. Вместо использования встроенных функций,
которые не всегда могут удовлетворять существующим требованиям,
пользователи могут создавать свои собственные наборы функций.
Появляется возможность динамического подключения пользовательского
кода к SQLBase не дожидаясь, например, новой версии продукта. Кроме этого,
для использования и смены внешних функций не нужно перекомпоновывать
приложение или останавливать и перезапускать сервер базы данных.
Реализуется простая и понятная для использования парадигма.
Возможность вызывать внешние функции из процедурного языка является
естественным механизмом создания модульных процедур.
Наконец, внешние функции не увеличивают ресурсопотребление SQLBase
и не сказываются на его производительности для других клиентов, позволяя
при этом иметь доступ к практически неограниченному множеству функций.

Внешняя функция является новым объектом схемы базы данных SQLBase.

Она создается с
помощью команды CREATE EXTERNAL FUNCTION. Имя функции, ее физическое положение и
интерфейс (параметры и их типы данных, возвращаемые данные и пр.) передаются в этой команде.
Данная информация хранится в системном каталоге в специальных таблицах. Ниже приведен
пример описания внешней функции.

CREATE EXTERNAL FUNCTION MyFunc
PARAMETERS (Number: INT)
RETURNS (BOOLEAN: WORD)
DESCRIPTION 'Sample External Function Declaration'
LIBRARY MYLIB.DLL
EXPORT ORDINAL 2
EXECUTE IN SAME THREAD
Типы данных для параметров функции и возвращаемого значения состоят из двух частей. Сначала
описывается "внутренний формат", соответствующий стандартным типам данных SAL. Могут
быть использованы все типы данных SAL, которые поддерживаются хранимыми процедурами (см.
выше). "Внешний формат", который следует за внутренним, описывает один из стандартных
форматов C, который служит для передачи данных во внешнюю функцию.

Предложение EXECUTE IN описывает как SQLBase будет загружать динамическую библиотеку и
в каком контексте с точки зрения сервера базы данных будет выполняться внешняя функция. Это, в
свою очередь, определяет тип операций, которые могут осуществляться внутри внешнего
кода.

Можно предложить много различных путей использования механизма внешних функций. Ниже
приведен ряд примерных сценариев.

Набор пользовательских функций трансформации и трансляции данных,
которые могут быть использованы при извлечении строк из результата запроса,
а также при вставке и изменении строк. Функция такого типа может принимать
значение одной (или нескольких) колонки и возвращать трансформированные
данные на основе действующих в организации правил (business rules) для
отображения в приложении.
Следующая категория функций может быть названа "Предупреждения и
уведомления". Их суть состоит в том, что при наступлении определенного
состояния базы данных могут запускаться триггеры. Эти триггеры выполняют
хранимые процедуры. Может оказаться полезным уведомлять некоторых

пользователей или приложения о наступлении определенного состояния базы
данных. Одним из примеров такого типа функций может быть функция,
направляющая по электронной почте сообщение определенным
пользователям о том, что данные в созданных ими таблицах были изменены
другими пользователями. С помощью этих же функций можно в принципе
реализовать механизм "теплой связи", когда пользователь будет получать
уведомления от сервера всякий раз, когда будут изменены данные его result
set.
Еще одной иллюстрацией возможностей технологии внешних функций
может являться пример удаленного доступа для запуска хранимых процедур.
Например, приложение может вызвать хранимую процедуру на локальном
сервере SQLBase, чтобы получить доступ к некоторым данным. Однако,
хранимая процедура может содержать логику, распознающую ситуацию когда
требуемые данные на сервере отсутствуют или являются устарелыми. В таком
случае использование внешней функции поможет установить контакт к
удаленной базе данных и извлечь нужные данные. Эти данные затем могут
быть занесены в локальную базу данных и возвращены приложению.
Другим классом внешних функций могут быть генераторы отчетов в режиме
off-line. При этом вместо запуска приложения отчетов с клиентской машины
весь модуль (или набор функций) может быть создан в виде динамической
библиотеки, которая вызывается из хранимой процедуры как внешняя функция.
Код этой функции может осуществлять контакт с базой данных и извлекать
нужные для генерации отчета данные. Основным преимуществом такого
подхода является повышение производительности, поскольку весь код будет
выполняться на сервере без передачи данных и команд по сети.

Многие ведущие производители СУБД включают поддержку вызова внешних функций из серверов
баз данных. Некоторые из них поддерживают только вызовы внешних функций с помощью
расширений процедурных языков ( в качестве примеров можно привести Microsoft SQLServer для
NT и Sybase). Другие допускают вызов функций также из SQL запросов.К таким система
относятся Oracle 7 и Rdb. В последующих версиях SQLBase. фирма Gupta планирует реализовать
несколько механизмов вызова внешних функций, включая их использование в выражениях SQL
запросов (сейчас в этих целях используются встроенные функции SQLBase).

На широкое распространение PowerBuilder как инструмента разработок приложений в среде
клиент/сервер существенно повлияла его открытость для интеграции самых разнообразных продуктов
третьих фирм, а также динамичное развитие самого продукта.

Распределенные базы данных невозможно рассматривать вне контекста более общей и более
значимой темы распределенных информационных систем. Процессы децентрализации и
информационной интеграции, происходящие во всем мире, неизбежно должны рано или поздно
затронуть нашу страну. Россия, в силу своего географического положения и размеров "обречена"
на преимущественное использование распределенных систем. На мой взгляд, это направление
может успешно развиваться лишь при выполнении двух главных условий - адекватном развитии
глобальной сетевой инфраструктуры и применении реальных технологий создания распределенных
информационных систем.

Второе условие, рассматриваемое как ключевой фактор развития информационных технологий в
нашей стране, составляет предмет предлагаемого в данной статье обсуждения.

Важность этой темы осознают все. Действительно, страна прошла начальный этап локальной
компьютеризации. Многие задачи "автоматизации в малом" или "автоматизации в среднем" уже
решаются адекватными средствами на достаточно высоком технологическом уровне. Но вот
задачи совершенно иного качества - задачи создания корпоративных информационных систем -
нуждаются в осмыслении и анализе. Сложность нынешнего этапа во многом предопределена
традиционализмом и инерционностью мышления, выражающейся в попытке переноса средств и
решений локальной автоматизации в мир распределенных систем. Этот мир живет по своим
законам, которые требуют иных технологий.

Существует ли сейчас понимание того, какими должны быть эти технологии? Боюсь, что нет. В
большинстве же случаев преобладает стремление использовать знакомые, понятные,
испробованные и поэтому родные средства для решения новых задач, принципиально
отличающихся от того, чем приходилось заниматься раньше.

Поведение и мотивация разработчиков вполне понятны и оправданы. Ставится задача - построить
информационную систему "клиент-сервер" на базе локальной сети с централизованной базой
данных.

В последнее время технология клиент- сервер стала темой номер один в компьютерном мире.
Многие склонны считать это скорее модой, чем объективной тенденцией развития
информационных технологий. Однако, нельзя отрицать тот факт, что на сегодняшний день именно
в технологии клиент-сервер нашли и находят свое отражение наиболее передовые идеи и решения,
которые будут доминировать на рынке в 90-е годы нашего столетия, да и в начале следующего
тысячелетия.

Наиболее яркими представителями технологии клиент-сервер являются многопользовательские
реляционные СУБД. Они получили широчайшее распространение и завоевали всеобщее признание
прежде всего благодаря своей надежности и производительности. В последнее время практически
все фирмы-производители СУБД клиент-сервер проделали огромную работу по повышению
потребительских свойств своих продуктов - повышению их быстродействия, улучшению
пользовательского интерфейса и упрощению процедур поддержки и администрирования.

СУБД клиент-сервер работают в самых различных системах на самых разных компьютерах. Так,
СУБД на mainframe управляют базами данных до нескольких терабайт, предоставляя
необходимую информацию тысячам пользователей одновременно. В то же время локальные СУБД
на компьютерах класса notebook обслуживают отсоединенных пользователей, предоставляя им
возможность работать с репликами их корпоративных баз данных практически в любом
месте.

Данная статья посвящена одному из ярких представителей сегодняшней технологии клиент-сервер
- реляционной СУБД SQLBase фирмы Gupta Corporation. Эта СУБД завоевала широкое признание
во всем мире и у нас в России, где за полтора года было продано почти полторы тысячи серверов
SQLBase для различных платформ.

SQLBase становится платформой разработки приложений и систем во многих областях, включая
банковские и бухгалтерские системы, документооборот, системы поддержки принятия решений,
геоинформационные системы и многие другие. При этом растет интерес специалистов в области
СУБД, разработчиков конечных приложений, системных администраторов и простых
пользователей к техническим возможностям и особенностям SQLBase. Пользуясь предоставленной
возможностью автор, Технический директор компании Интерфейс, попробует в данной статье
удовлетворить этот интерес.

BM Database 2 представляет собой реляционную систему управления базами данных. Она
позволяет пользователям работать с реляционными данными, используя язык структурных
запросов SQL. Первая реализация этой СУБД появилась в 1983 году для операционной системы
MVS , и впоследствии была перенесена на многие другие платформы. Еще
более широкую популярность приобрел введенный в DB2 язык SQL, являющийся в настоящий
момент общепринятым для работы с реляционными базами данных в архитектуре
клиент/сервер.

Изначально разработанная для работы с коммерческими данными, DB2 завоевала сильные
позиции на рынке реляционных СУБД как весьма стабильная система, пригодная для
автоматизации организаций любого масштаба.

Стремительный прогресс информационных технологий оказывает весьма существенное влияние на
решаемые СУБД задачи, и DB2 существенно изменилась за время своего существования.

Одним из уже сложившихся направлений деятельности фирмы ORACLE стала разработка
методологических основ и производство инструментальных средств для автоматизации процессов
разработки сложных прикладных систем, ориентированных на интенсивное использование баз
данных.

Основу CASE-технологии и инструментальной среды фирмы ORACLE
составляют:

методология структурного нисходящего проектирования, при которой
разработка прикладной системы представляется в виде последовательности
четко определенных этапов (рис.1);
поддержка всех этапов жизненного цикла прикладной системы, начиная с
самых общих описаний предметной области до получения и сопровождения
готового программного продукта;
ориентация на реализацию приложений в архитектуре "клиент-сервер" с
использованием всех особенностей современных серверов баз данных,
включая декларативные ограничения целостности, хранимые процедуры,
триггеры баз данных, и с поддержкой в клиентской части всех современных
стандартов и требований к графическому интерфейсу конечного пользователя;.
наличие централизованной базы данных, репозитария, для хранения
спецификаций проекта прикладной системы на всех этапах ее разработки.
Такой репозитарий представляет собой базу данных специальной структуры,
работающую под управлением СУБД ORACLE;
возможность одновременной работы с репозитарием многих
пользователей. Такой многопользовательский режим почти автоматически
обеспечивается стандартными средствами СУБД ORACLE. Централизованное
хранение проекта системы и управление одновременным доступом к нему всех
участников разработки поддерживают согласованность действий
разработчиков и не допускают ситуацию, когда каждый проектировщик или
программист работает со своей версией проекта и модифицирует ее
независимо от других;
автоматизация последовательного перехода от одного этапа разработки к
следующему. Для этого предусмотрены специальные утилиты, с помощью
которых можно по спецификациям концептуального уровня (модели
предметной области) автоматически получать первоначальный вариант
спецификации уровня проектирования (описание структуры базы данных и
состава программных модулей), а по последним после всех необходимых
уточнений и дополнений автоматически генерировать готовые к выполнению
программы;
автоматизация различных стандартных действий по проектированию и
реализации приложения: предусматривается генерация многочисленных
отчетов по содержимому репозитария, обеспечивающих полное
документирование текущей версии системы на всех этапах ее разработки; с
помощью специальных процедур предоставляется возможность проверки
спецификаций на полноту и непротиворечивость и т.д.

Стратегия
Анализ
Проектирование
РеализацияДокументирование
Внедрение
Поддержка

Продукт S- Designor фирмы Powersoft адресован разработчикам информационных
систем. Это графический инструмент для проектирования структуры реляционных баз данных. S-
Designor реализует популярную методологию информационного моделирования, основанную на
представлении информационных объектов и взаимосвязей между ними в виде ER-диаграммы
("сущность-связь"). Используемая в S-Designor нотация - IE (Information Engineering).

В S-Designer эффективно реализована связь как со множеством современных СУБД, так и со
средствами разработки приложений. По завершении разработки модели данных S-Designor
генерирует пакеты SQL-предложений для широкого набора СУБД, включая Oracle, Ingres,
Informix, Sybase, RDB, SQL Server, DB2, AS/400, SQLBase, Access и Paradox. Имеется
встроенный ISQL. Для поддерживаемых СУБД автоматически генерируются триггеры,
обеспечивающие ссылочную целостность. Предусмотрена возможность редактировать хранимые
процедуры непосредственно при подготовке физической модели. Для обеспечения сопровождения
существующих систем S-Designor позволяет проводить восстановление модели по структуре
базы данных (БД). В течение всего цикла разработки модели данных ( Рис. 1) с помощью S-
Designor могут быть получены разнообразные отчеты по модели.

На этапе проектирования модели данных S-Designor дает возможность определить элементы
пользовательского интерфейса будущих приложений, работающих с проектируемой базой данных.
Это достигается редактированием репозиториев систем 4GL. В качестве средств разработки
поддерживается PowerBuilder , TeamWindows,
Progress, Uniface и другие.

S-Designor работает в среде Microsoft Windows и Windows NT. Для
его использования достаточно компьютера с процессором 386SX и объемом памяти от 4
мегабайт. В S-Designor присутствуют элементы, характерные для программ редактирования -
линейка инструментов, интерфейс " drag-and-drop", импорт/экспорт графических файлов,
инструменты для создания стандартных графических элементов, управление цветом и шрифтовым
выделением.

При работе с S-Designor сразу заметны очень высокая скорость отрисовки диаграммы и
эффективная реализация интерфейса к СУБД.

Развитые средства быстрого редактирования объектов модели и достаточно полный набор средств
управления расположением объектов на диаграмме - характерные черты, делающие S-
Designor особенно привлекательным.

PowerBuilder включает набор инструментов, обеспечивающих всестороннюю поддержку разработки
приложений: Интеллектуальный SQL (SQL Smart), Удобные объекты (Object Easy),
Коллективную разработку (Enterprise Enabled) и Интегрированную среду проектирования
(Developer Designed).

Создание/восстановление страховочных
копий теперь может выполняться почти на порядок быстрее за счет использования одновременно
до 32 устройств (диски или стриммеры), на которых создается страховочная копия базы данных.
Специалистами Microsoft была достигнута производительность копирования более 20 Гб/час. Это
означает, что при работе с большими и очень большими БД страховочная копия может быть
создана в нерабочие часы. Теперь же использование новых возможностей SQL Server позволяет
работать с базами данных 100 Гб и выше на соответствующим образом конфигурированных
компьютерных системах. Это отвечает требованиям организаций, устанавливающих большие базы
данных на относительно дешевых компьютерных системах.

(CADRE Technologies Inc.)

Westmount I- CASE представляет собой интегрированный программный продукт, обеспечивающий
выполнение следующих функций:

графическое проектирование архитектуры системы (проектирование
состава и связи вычислительных средств, распределения задач системы
между вычислительными средствами, моделирование отношений типа "клиент-
сервер", анализ использования мониторов транзакций и особенностей
функционирования систем в реальном времени);
проектирование диаграмм потоков данных, "сущность-связь", структур
данных, структурных схем программ и последовательностей экранных форм;
генерация кода программ на 4GL целевой СУБД с полным обеспечением
программной среды и генерация SQL-кода для создания таблиц БД, индексов,
ограничений целостности и хранимых процедур;
программирование на языке C со встроенным SQL;
управление версиями и конфигурацией проекта;
генерация проектной документации по стандартным и индивидуальным
шаблонам;
экспорт и импорт данных проекта в формате CDIF.

Westmount I-CASE можно использовать в конфигурации "клиент-сервер", при этом база
проектных данных может располагаться на сервере, а рабочие места разработчиков могут быть
клиентами.

Westmount I-CASE функционирует на всех основных UNIX-платформах и VMS. В качестве
целевой СУБД могут использоваться ORACLE, Informix, Sybase и Ingres.

В качестве отдельного продукта поставляется интерфейс Westmount-Uniface Bridge,
обеспечивающий совместное использование двух систем в рамках единой технологической среды
проектирования (при этом схемы БД, структурные схемы программ и последовательности
экранных форм непосредственно в режиме on-line, без создания каких-либо файлов экспорта-
импорта, переносятся в репозиторий Uniface, и, наоборот, прикладные модели, сформированные
средствами Uniface, могут быть перенесены в репозиторий Westmount I-CASE. Возможные
рассогласования между репозиториями двух систем устраняются с помощью специальной
утилиты).

В рамках версии Westmount I-CASE 4.0 предполагается обеспечить возможность
функционирования клиентской части в среде Windows 95, а серверной - в среде Windows NT.

Dynamic Data Exchange (DDE) - это метод взаимодействия приложений. DDE использует
архитектуру клиент-сервер. Так, приложение-клиент (например, Excel или Word) может
запрашивать данные у приложения-сервера.

WSQL DDE-сервер - это Windows-приложение, которое позволяет выбирать и изменять данные в
БД SQL Anywhere. Получаемые данные могут передаваться приложению-клиенту через буфер в
памяти или через системный буфер (Clipboard).

Щелчок левой кнопкой мыши на пиктограмме Run (запуск) приведет к запуску текущего приложения
в среде разработки PowerBuilder для проверки его функциональности.

Sybase MPP

Приложения

Sybase SQL Server

Базы данных

Возможность аудирования, новое свойство SQLBase 6, позволяет регистрировать информацию о
том, что происходит на сервере баз данных. Это дает возможность администраторам и
пользователям SQLBase осуществлять следующие дополнительные функции:

Мониторинг активности сервера баз данных - Регистрация разнообразной
информации на регулярной основе.
Дополнительные возможности защиты данных - Предыдущие версии
SQLBase осуществляли защиту данных на уровне имени и пароля
пользователя, однако не регистрировали попытки нарушить систему защиты.
Аудирование позволяет регистрировать такие случаи как попытки доступа к
базе данных с неправильным именем или паролем. Кроме того, есть
возможность регистрировать попытки нарушения пользователем его
привилегий по отношению к объектам базы данных, например, попытки считать
информацию из закрытых для него таблиц.
Отладка приложений - Можно использовать аудирование для отладки
конечных приложений путем просмотра того, какие действия приложение
осуществляет по отношению к базе данных и серверу.
Повышение производительности базы данных - Аудирование базы данных
позволяет получить информацию обо всех SQL запросах и транзакциях. Это
свойство можно использовать непосредственно на рабочем месте
пользователя для решения проблем типа "Я нажимаю вот эту кнопку и потом
жду 20 минут выполнения запроса". Поскольку аудирование предоставляет
временную информацию о выполнении запросов, его можно использовать для
анализа причин снижения производительности конечных приложений.

Существует два класса аудирования: глобальный аудит и аудирование производительности. В
свою очередь, каждый из классов состоит из нескольких категорий описание этих категорий
приведено на рис. 6.

Класс
Категория
ОписаниеGlobal
Performance

Rejected logons	Регистрирует неудавщиеся попытки контакта с базой данных. Используется для идентификации пользователей, которые пытаются получить доступ к закрытым базам данных.
Security violations	Регистрирует пользователей, пытающихся получить доступ к данным не имея соответствующих привилегий.
Valid logons/logoffs	Регистрирует все удавшиеся события соединения и отсоединения. Используется для регистрации сеансов работы пользователей с системой.
Valid connects/disconnects	Регистрирует все команды CONNECT и DISCONNECT.
Database create, drop, install and deinstalls	Регистрирует выполнение операций CREATE DATABASE, DROP DATABASE, INSTALL DATABASE и DEINSTALL DATABASE.
Recovery operations	Регистрирует все операции ROLLBACK.
Backup and restore operations	Регистрирует все операции BACKUP и RESTORE.
Database deadlocks and timeouts	Записывает информацию о всех событиях deadlock и timeout. Очень важная категория, которая может быть использована для разрешения проблем блокировок.
Table access information	Регистрирует информацию о том, кто реализует доступ к таблицам базы данных.
Table update information	Регистрирует информацию о том, кто выполняет операции insert/update/delete по отношению к таблицам базы данных.
Connects and disconnects	Регистрирует время выполнения каждой операции connect/disconnect.
SQL command compilation, execution, storage and retrieval	Эта категория регистрирует информацию о времени компиляции и выполнения запроса, записи и извлечения хранимой команды или процедуры.
End of transaction	Регистрирует длительность каждой транзакции. Может использоваться для выявления долго идущих транзакций, которые могут являться источниками deadlock и timeout.

<
Информация аудирования записывается в файл аудита. Файл аудита является плоским текстовым
файлом. Его содержимое можно просматривать из программы SQLConsole или в любом текстовом
редакторе.

Хотя SQLBase позволяет иметь до 32 активных файлов аудита одновременно, следует помнить, что
аудирование оказывает влияние на производительность сервера.

Информация, записываемая в файл аудита, зависит от класса аудирования и выбранных
категорий. Пользователи также могут определять собственные сообщения для записи в файл
аудита.

Процесс аудирования базы данных инициируется на уровне сервера. Это значит, что для запуска
процесса аудирования необходимо иметь соединение с сервером. Аудирование можно начать
несколькими различными способами. Наиболее удобным является использование программы
SQLConsole. Окно Audit Manager этой программы позволяет просто и удобно сконфигурировать
аудирование, запустить и остановить его, а также просмотреть любой активный файл аудита из
имеющихся на сервере.

Можно также запустить процесс аудирования новой командой на языке SQL START AUDIT. Так
как эта команда, подобно всем другим SQL запросам, может быть скомпилирована и выполнена,
START AUDIT можно выполнить из приложений SQLWindows с помощью функций SqlPrepare,
SqlExecute или SqlPrepareAndExecute.

После запуска процесса аудирования он остается активным до получения специальной команды
STOP AUDIT. SQLBase записывает строку в конфигурационный файл сервера, и эта строка
остается там все время, в течение которого аудирование является активным. Таким образом, если
сервер SQLBase сбрасывается и запускается снова, все активные файлы аудита остаются
активными.

[]
[]
[]