Гринберг А.С., Иванюкович В.А., Новыш Б.В., Шешолко В.К. Ситуационный анализ и моделирование на основе информационных технологий баз данных
Подождите немного. Документ загружается.
редактировать данные любого типа, кроме изображений. Если
пользователь должен выбрать значения из списка, то могут быть
использованы объекты список ListBox или раскрывающийся список
ComboBox. Данные, которые могут принимать одно из двух значений,
отображаются с помощью объекта поле проверки CheckBox. Для
создания таблиц предназначен объект Grid.
2. Объекты для управления работой приложений. В первую очередь это
средства создания различного типа кнопок – объект кнопка управления
CommandButton, таймерTimer и др.
3. Объекты для оформления интерфейса пользователя. Объект Image
создает элемент управления в виде изображения формата BMP, который
реагирует на действие пользователя. Объект Label создает метку для
вывода поясняющего текста, есть объекты для создания элементов
управления в виде линии, прямоугольника, окружности и т.п.
4. Объекты-контейнеры. Предназначены для объединения группы объектов.
Например, объект-контейнер Form объединяет все элементы управления,
размещаемые в одном окне.
5. Объекты OLE. Такие объекты поддерживаются технологией OLE 2.0 и
позволяют использовать объекты из других приложений, работающих в
операционной системе Windows, в том числе и настраиваемые элементы
управления ActiveX (их использование позволяет обеспечить
пользовательскому приложению практически любую функциональность,
реализовать которую встроенными средствами невозможно или
затруднительно).
8.2. Логические системы управления базами данных
Одним из наиболее перспективных направлений исследований в области
работы с данными являются системы управления базами данных, основанных
на логике. В научной литературе по этой тематике довольно часто встречаются
такие термины, как логическая база данных, экспертная СУБД, дедуктивная
СУБД, система баз данных, основанная на правилах, база знаний, система
управления базой знаний, логика как модель данных, выполнение рекурсивных
111
запросов и т.д. Однако смысл этих терминов не всегда прозрачен, т.е. их
использование в том или ином контексте не всегда легко связать с привычной
терминологией, что усложняет понимание традиционного подхода к
исследованию баз данных. Вот почему необходимо разъяснить эти
представления на основе обычных идей и принципов построения баз данных.
8.2.1. Экстенсиональная и интенсиональная части базы данных
В реальных базах данных можно выделить три различные вида информации.
Во-первых, это информация, характеризующая структуры пользовательских
данных (описание структурной части схемы базы данных). Такая информация в
случае реляционной базы данных сохраняется в системных отношениях-
каталогах и содержит главным образом имена базовых отношений и имена и
типы данных их атрибутов. Во-вторых, это собственно наборы кортежей
пользовательских данных, сохраняемых в определенных пользователями
отношениях. В-третьих, это правила, определяющие ограничения целостности
базы данных, триггеры базы данных и виртуальные отношения
(представления).
Информация первого и второго вида в совокупности явно описывает
объекты (сущности) реального мира, моделируемые в базе данных. Это явные
факты, предоставленные пользователями для хранения в БД. Эту часть базы
данных принято называть экстенсиональной.
Информация третьего вида предназначена для управления данными при
выполнении различного рода операций, задаваемых пользователями –
ограничения целостности могут блокировать выполнение операций обновления
базы данных, триггеры вызывают автоматическое выполнение
специфицированных действий при возникновении специфицированных
условий, определения представлений вызывают явную или косвенную
материализацию представляемых таблиц при их использовании. Эту часть базы
данных принято называть интенсиональной; она содержит не
непосредственные факты, а информацию, характеризующую семантику
предметной области.
В реляционных базах данных наиболее важное значение имеет
экстенсиональная часть, а интенсиональная часть играет в основном
112
вспомогательную роль. В логических системах баз данных, основанных на
правилах, эти две части как минимум равноправны.
8.2.2. Активные базы данных
По определению база данных называется активной, если СУБД по
отношению к ней выполняет не только те действия, которые явно указывает
пользователь, но и дополнительные действия в соответствии с правилами,
заложенными в саму базу данных. Реализация такого аппарата в СУБД очень
сложна, накладна и не полностью понятна.
Среди вопросов, ответы на которые до сих пор не получены, следующие.
Как эффективно определить набор вспомогательных действий, вызываемых
прямым действием пользователя? Каким образом распознавать циклы в
цепочке "действие-условие-действие-..." и что делать при возникновении таких
циклов? В рамках какой транзакции выполнять дополнительные условные
действия?
Масса проблем не решена даже для сравнительно простого случая
реализации триггеров SQL, а задача ставится уже гораздо шире. По существу,
предлагается иметь в составе СУБД продукционную систему общего вида,
условия и действия которой не ограничиваются содержимым базы данных или
прямыми действиями над ней со стороны пользователя. Практически все
современные работы по активным базам данных связаны с проблемой
эффективной реализации такой продукционной системы.
В проекте стандарта SQL3 предусматривается существование языковых
средств определения условных воздействий. Их реализация и будет первым
практическим шагом к логическим активным базам данных.
8.2.3. Дедуктивные базы данных
По определению, дедуктивная база данных состоит из двух частей:
экстенциональной, содержащей факты, и интенциональной, содержащей
правила для логического вывода новых фактов на основе экстенциональной
части и запроса пользователя.
113
Логические выводы делаются на основании дедуктивной аксиомы, которая
также называется правилом вывода (или правилом заключения). В общем,
дедуктивная аксиома – это правило, по которому на основе некоторых фактов
можно вывести новые факты. Например, на основе фактов «Анна – мать
Татьяны» и «Татьяна – мать Ольги» согласно очевидной дедуктивной аксиоме
можно вывести, что Анна – бабушка Ольги.
Легко видеть, что при таком общем определении SQL-ориентированную
реляционную СУБД можно отнести к дедуктивным системам. Действительно,
определенные в схеме реляционной БД представления – это интенциональная
часть БД. В конце концов не так уж важно, какой конкретный механизм
используется для вывода новых фактов на основе существующих. В случае
SQL основным элементом определения представления является оператор
выборки языка SQL, что вполне естественно, поскольку результатом оператора
выборки является таблица. Обеспечивается и необходимая расширяемость,
поскольку представления могут определяться не только над базовыми
таблицами, но и над представлениями.
Основным отличием реальной дедуктивной СУБД от реляционной является
то, что и правила интенциональной части БД, и запросы пользователей могут
содержать рекурсию. Возможность определения рекурсивных правил и
запросов дает возможность простого решения в дедуктивных базах данных
проблем, которые вызывают большие проблемы в реляционных системах
(например, проблемы разборки сложной детали на примитивные
составляющие). С другой стороны, именно возможность рекурсии делает
реализацию дедуктивной СУБД очень сложной и во многих случаях
неразрешимой эффективно проблемой.
Мы не будем здесь более подробно рассматривать конкретные проблемы,
применяемые ограничения и используемые методы в дедуктивных системах.
Отметим лишь, что обычно языки запросов и определения интенциональной
части базы данных являются логическими (поэтому дедуктивные базы данных
часто называют логическими). Имеется прямая связь дедуктивных баз данных с
базами знаний (интенциональную часть баз данных можно рассматривать как
114
базу знаний). Более того, трудно провести грань между этими двумя
сущностями, по крайней мере, общего мнения по этому поводу не существует.
Какова же связь дедуктивных баз данных с реляционными СУБД, кроме
того, что реляционная база данных является вырожденным частным случаем
дедуктивной? Основным является то, что для реализации дедуктивной СУБД
обычно применяется реляционная система. Такая система выступает в роли
хранителя фактов и исполнителя запросов, поступающих с уровня дедуктивной
СУБД. Такое использование реляционных СУБД резко актуализирует задачу
глобальной оптимизации запросов.
При обычном применении реляционной СУБД запросы обычно поступают
на обработку по одному, поэтому нет повода для их глобальной
(межзапросной) оптимизации. Дедуктивная же СУБД при выполнении одного
запроса пользователя в общем случае генерирует пакет запросов к реляционной
СУБД, которые могут оптимизироваться совместно.
Конечно, в случае, когда набор правил дедуктивной базы данных становится
велик, и их невозможно разместить в оперативной памяти, возникает проблема
управления их хранением и доступом к ним во внешней памяти. Здесь опять же
может быть применена реляционная система, но уже не слишком эффективно.
Требуются более сложные структуры данных и другие условия выборки.
8.3. Оптимизация базы данных
В реляционных системах цель оптимизации состоит в том, чтобы
перевести реляционное выражение на более эффективный семантический
уровень. В реляционных системах, как правило, организована автоматическая
оптимизация – пользователь может не задумываться над способом выражения
своих запросов, т.е. над тем, как сформулировать запрос, чтобы система
выполнила его с максимально возможной производительностью. Более того,
существует реальная возможность, что оптимизатор сформулирует запрос
лучше, чем пользователь. Во-первых, автоматический оптимизатор обладает
достаточным количеством информации, которой пользователь может не иметь.
Точнее, оптимизатор должен обладать некоторыми статистическими данными,
такими как кардинальное число каждого домена и каждого базового
115
отношения, количество различающихся значений для каждого атрибута в
отношении, количество вхождений каждого значения в атрибутах и т.п. (такая
информация хранится в системном каталоге). Благодаря наличию этих данных,
оптимизатор способен более точно оценивать эффективность любой стратегии
реализации конкретного запроса. Во-вторых, если с течением времени
статистика базы данных значительно изменится (например, база данных будет
физически реорганизована), то для реализации запроса может потребоваться
совсем иная стратегия, чем до реорганизации; другими словами, может
понадобиться повторная оптимизация, или реоптимизация. В реляционных
системах процесс реоптимизации – это просто повторная обработка исходного
запроса системным оптимизатором. В-третьих, оптимизатор – это программа,
поэтому он более "настойчив" по сравнению с человеком. Оптимизатор вполне
способен рассматривать буквально сотни различных стратегий реализации
данного запроса, в то время как программист вряд ли изучает более трех-
четырех стратегий. Наконец, в оптимизаторе могут быть использованы
накопленные знания и опыт программистов, в противном случае пользователям
будет предоставлен набор неэффективных возможностей.
Можно сказать, что оптимизация запросов является сильной стороной
реляционных систем и ее назначение состоит в выборе эффективной стратегии
для вычисления данного реляционного выражения.
Приведем пример, показывающий эффективность оптимизации
реляционных вычислений. Рассмотрим запрос "Получить имена поставщиков,
которые поставляют деталь Д2". Алгебраическая запись этого запроса:
((ПОСТАВКИ JOIN ПОСТАВЩИКИ) WHERE Д№=’Д2’) [ИМЯ_П]
Предположим, что база данных содержит информацию о 100 поставщиках
и 10j000 партий товаров, только 50 из которых являются партиями с деталями
Д2. Если система будет вычислять выражение прямо (т.е. без оптимизации), то
последовательность выполняемых действий будет выглядеть так:
1. Соединение отношений ПОСТАВКИ и ПОСТАВЩИКИ (по атрибуту П№). На
этом этапе считывается информация о 10j000 партий товаров и 10j000 раз
считывается информация о 100 поставщиках (один раз для каждой партии
товаров). После этого создается промежуточный результат, состоящий из
116
10j000 соединенных кортежей. Этот результат записывается на диск (ради
примера предположим, что для промежуточного результата в основной
(оперативной) памяти не хватает места).
2. Выборка кортежей с данными только о детали Д2 из результата,
полученного на этапе 1. На этом этапе выполняется чтение 10j000 записей
обратно в оперативную память и создается новое отношение, которое состоит
из 50 кортежей и, по нашему предположению, может поместиться в
оперативной памяти.
3. Проекция результата, полученного на этапе 2, по атрибуту ИМЯ_П. На
этом этапе создается требуемый результат (состоящий максимум из 50
кортежей, которые могут поместиться в оперативной памяти).
Такой же результат может быть получен следующим способом:
1. Выборка кортежей с данными только о детали Д2 из отношения
ПОСТАВКИ. На этом этапе выполняется чтение 10j000 кортежей и создается
результат, состоящий только из 50 кортежей, который, как мы предполагали,
может поместиться в оперативной памяти.
2. Соединение результата, полученного на этапе 1, с отношением
ПОСТАВЩИКИ (по атрибуту П№). На этом этапе выполняется считывание данных
о 100 поставщиках (только один раз, а не один раз на одну партию деталей, так
как данные обо всех партиях деталей Д2 уже находятся в памяти). Результат
содержит 50 кортежей (которые все еще помещаются в память).
3. Проецирование результата, полученного на этапе 2, по атрибуту ИМЯ_П.
Требуемый результат (не более 50 кортежей) помешается в оперативной
памяти.
Первая из показанных процедур выполняет, в общем, более 1j010j000
операций ввода-вывода кортежа, в то время как вторая процедура выполняет
около 10j100 операций ввода-вывода. Следовательно, вполне понятно, что если
принять "количество операций ввода-вывода кортежа" в качестве меры
производительности, то вторая процедура в 100 раз эффективнее первой. (На
практике мерой производительности служит количество операций ввода-
117
вывода страницы, а не одного кортежа, но для данного примера эту поправку
можно игнорировать.)
Таким образом, мы видим, что незначительные изменения в алгоритме
вычисления (выполнение выборки, а затем соединения, вместо соединения, а
затем выборки) приводят к значительному увеличению производительности.
Производительность повысится еще больше, если отношение ПОСТАВКИ
индексировано или хешировано по атрибуту Д№. В этом случае количество
кортежей, считываемых на этапе 1 второй процедуры, уменьшится с 10j000
всего до 50, и полученная процедура будет в 7j000 раз эффективнее
оригинальной. Аналогично индекс или хеш-таблица для атрибута П№
отношения ПОСТАВЩИКИ позволит на этапе 2 уменьшить количество операций
ввода-вывода кортежей со 100 до 50, и процедура вычисления запроса станет
более чем в 10j000 раз эффективнее своего оригинального аналога. Это
означает, что если оригинальная процедура вычисления запроса выполняется 3
часа, то оптимизированная версия этой процедуры выполнится за одну секунду.
В современных системах управления реляционными базами данных
автоматическая оптимизация выполняется при запуске первого реляционного
вычисления – запроса, создания таблицы, формы и т.п. Тем не менее, полезно
знать о возможностях, которые предоставляет используемая СУБД (такая
информация есть в справочной системе).
8.4. Безопасность баз данных
При обсуждении баз данных необходимо отличать термины безопасность
и целостность (о целостности данных речь шла в предыдущих главах). Термин
безопасность относится к защите данных от несанкционированного доступа,
изменения или разрушения данных, а целостность – к точности или истинности
данных. По-другому их можно описать следующим образом:
Под безопасностью подразумевается, что пользователям разрешается
выполнять некоторые действия. Под целостностью подразумевается, что
эти действия выполняются корректно.
Между ними есть и некоторое сходство – как при обеспечении
безопасности, так и при обеспечении целостности система вынуждена
118
проверить, не нарушают ли выполняемые пользователем действия некоторых
правил.
Среди многочисленных аспектов проблемы безопасности необходимо
отметить следующие:
Правовые, общественные и этические аспекты (имеет ли право некоторое
лицо получить запрашиваемую информацию, например о кредите клиента).
Физические условия (например, закрыт ли данный компьютер или
терминальная комната или защищен каким-либо другим образом).
Организационные вопросы (например, как в рамках предприятия,
обладающего некой системой, организован доступ к данным).
Вопросы реализации управления (например, если используется метод
доступа по паролю, то как организована реализация управления и как часто
меняются пароли).
Аппаратное обеспечение (обеспечиваются ли меры безопасности на
аппаратном уровне, например с помощью защитных ключей или
привилегированного режима управления).
Безопасность операционной системы (например, затирает ли базовая
операционная система содержание структуры хранения и файлов с данными
при прекращении работы с ними).
Некоторые вопросы, касающиеся непосредственно самой системы
управления базами данных (например, существует ли для базы данных
некоторая концепция предоставления прав владения данными).
В данной главе будут затронуты только вопросы, касающиеся последнего
пункта этого перечня.
В современных СУБД поддерживается избирательный или обязательный
подход к вопросу обеспечения безопасности данных.
При избирательном управлении некий пользователь обладает различными
правами (привилегиями или полномочиями) при работе с разными объектами.
Более того, разные пользователи обычно обладают и разными правами доступа
119
к одному и тому же объекту. Поэтому избирательные схемы характеризуются
значительной гибкостью.
При обязательном управлении каждому объекту данных присваивается
некоторый классификационный уровень, а каждый пользователь обладает
некоторым уровнем допуска. При таком подходе доступом к определенному
объекту данных обладают только пользователи с соответствующим уровнем
допуска. Поэтому обязательные схемы достаточно жестки и статичны.
На практике в большинстве систем предусматривается избирательный
доступ и только в некоторых – обязательный.
Независимо от того, какие схемы управления допуском используются, все
решения относительно допуска пользователей к выполнению тех или иных
операций принимаются на стратегическом уровне и СУБД только приводит в
действие уже принятые ранее решения.
Для того чтобы разобраться, какие правила безопасности к каким запросам
доступа применяются, в системе должны быть предусмотрены способы
опознания запрашивающего пользователя. Поэтому в момент входа в систему
от пользователя обычно требуется ввести не только его идентификатор
(например, имя или должность), но также и пароль (чтобы подтвердить свои
права на заявленные ранее идентификационные данные).
В общем случае, при избирательном управлении доступом правила
безопасности обладают пятью компонентами.
1. Имя (правило будет зарегистрировано в системном каталоге под этим
именем; это имя появится в любом системном сообщении или сообщении о
состоянии системы в ответ на нарушение этого правила).
2. Одна или несколько привилегий (например, RETRIVE или DELETE).
3. Диапазон, к которому это правило применяется (например, в качестве
диапазона могут рассматриваться все кортежи поставщиков из Минска).
4. Один или несколько пользователей (точнее, идентификаторов
пользователей), которые обладают специально заданными привилегиями в
заданном диапазоне.
120