Часть I. Основы построения баз данных

Оглавление
Часть I. Основы построения баз данных .....................................................................................6
Тема 1. Введение в теорию баз данных ...........................................................................6
1.1 Два направления использования ЭВМ. Эволюция электронных носителей
информации....................................................................................................................6
1.2 Появление файловых систем и их основные свойства ........................................8
1.3 Потребность в новых технологиях хранения данных ........................................9
1.4 Основные понятия теории БД. Уровни представления данных .......................11
1.5 Свойства БД ...........................................................................................................14
Тема 2. Модели данных ..................................................................................................17
2.1 Понятие модели данных. ......................................................................................17
2.2 Классификация связей между объектами и их атрибутами ..............................20
2.3 Иерархическая модель ..........................................................................................23
2.4 Сетевая модель.......................................................................................................25
2.5 Инвертированные списки .....................................................................................26
Тема 3. Семантическое моделирование БД ..................................................................28
3.1 Семантические модели данных ............................................................................28
3.2 Модель сущность-связь (ER-модель) ..................................................................29
3.3 Ловушки разветвления и разрыва в ER-модели .................................................31
3.4 Возможности объектно-ориентированного языка UML для проектирования
БД ..................................................................................................................................32
3.5 Критерии выбора модели данных ........................................................................36
Часть II. организация реляционных бд ......................................................................................37
Тема 4. Реляционная модель данных .............................................................................37
4.1 Основные понятия реляционной модели данных ..............................................37
4.2 Организация связей между отношениями ..........................................................40
4.3 Средства манипулирования отношениями .........................................................42
4.4 Реляционная алгебра .............................................................................................43
4.5 Реляционное исчисление ......................................................................................46
Тема 5. Критерии РМД....................................................................................................47
5.1 Ограничения организации данных в РМД ..........................................................47
5.2 Нормальные формы РМД .....................................................................................48
5.3 Пример нормализации отношений ......................................................................51
5.4 Преимущества и недостатки РМД .......................................................................53
Часть III. современные технологии обеспечения доступа к данным .....................................54
Тема 6. Современные модели данных ...........................................................................55
6.1 Постреляционная модель данных ........................................................................55
6.2 Многомерная модель данных ...............................................................................56
6.3 Колоночные БД ......................................................................................................59
6.4 Объектно-ориентированные БД ...........................................................................60
6.5 XML БД ..................................................................................................................62
Тема 7. Архитектура клиент-сервер в БД .....................................................................65
7.1 Архитектура распределенной информационной системы ................................65
7.2 Двухзвенные модели архитектуры клиент-сервер .............................................66
7.3 Трехзвенная модель архитектуры клиент-сервер...............................................70
7.4 Сложные схемы взаимодействия .........................................................................71
7.5 Модель монитора транзакций ..............................................................................72
Тема 8. Информационные системы в сетях ..................................................................74
8.1 Информационные системы в локальных сетях ..................................................74
8.2 БД в сети Internet ...................................................................................................77
3
8.3 Организация распределенных БД ........................................................................82
8.4 Облачные БД ..........................................................................................................83
Тема 9. Режим транзакций в БД .....................................................................................85
9.1 Понятие транзакции в БД .....................................................................................85
9.2 Организация совместного доступа к общим данным ........................................86
9.3 Уровни изолированности транзакций .................................................................88
9.4 Методы сериализации транзакций.......................................................................89
9.5 Протоколы фиксации транзакций ........................................................................95
Тема 10. Индексирование в БД ......................................................................................98
10.1 Понятие индекса в БД .........................................................................................98
10.2 Схемы организации индексации БД ..................................................................99
10.3 T-деревья ............................................................................................................101
10.4 B-деревья ............................................................................................................102
10.5 Хеширование......................................................................................................103
Часть IV. Реализация БД на стандартных ...............................................................................106
платформах.................................................................................................................................106
Тема 11. Системы управления БД................................................................................107
11.1 Классификация и функции СУБД ....................................................................107
11.2 Архитектура СУБД ............................................................................................110
11.3 Задачи администрирования СУБД ...................................................................111
11.4 Критерии выбора СУБД ....................................................................................113
11.5 Перспективы развития СУБД ...........................................................................116
Тема 12. Проектирование и сопровождение БД .........................................................118
12.1 Этапы проектирования БД................................................................................118
12.2 CASE-системы ...................................................................................................120
12.3 Классификация CASE-средств .........................................................................122
12.4 Модели жизненного цикла информационных систем ...................................123
Тема 13. Защита информации в информационных системах ....................................124
13.1 Основные определения .....................................................................................124
13.2 Методы и средства защиты ..............................................................................127
13.3 Программно-аппаратные методы защиты.......................................................128
13.4 Средства защиты БД .........................................................................................132
Тема 14. Языки запросов к РБД (SQL и QBE) ............................................................135
14.1 Структура языка SQL ........................................................................................135
14.2 Запросы определения данных (DDL) ..............................................................137
14.3 Запросы выборки данных (DRL) ......................................................................141
14.4 Запросы манипулирования данными (DML) ..................................................146
14.5 Запросы администрирования доступа (DCL) .................................................147
14.6 Язык QBE ...........................................................................................................149
14.7 Связь между SQL-запросом и операциями реляционной алгебры ...............149
Тема 15. Реализация РБД с помощью MS SQL Server, MySQL, MS Access ............151
15.1 Microsoft SQL Server .........................................................................................151
15.2 Открытая платформа MySQL ...........................................................................155
15.3 Microsoft Access .................................................................................................158
Часть V. Организация экспертных систем ..............................................................................160
Тема 16. Структура экспертных систем ......................................................................160
16.1 Понятие экспертных систем .............................................................................160
16.2 Базовые функции экспертных систем .............................................................163
16.3 Режимы функционирования экспертных систем ...........................................165
16.4 Типовая структура экспертных систем ...........................................................166
16.5 Классификация экспертных систем .................................................................166
Тема 17. Проектирование АСНИ на базе экспертных систем ..................................167
4
17.1 АСНИ как информационная система ..............................................................167
17.2 Понятие и функции АСНИ ...............................................................................169
17.3 Структура АСНИ ...............................................................................................170
17.4 Основные принципы построения АСНИ ........................................................171
Рекомендуемая литература .......................................................................................176
5
ЧАСТЬ I. ОСНОВЫ ПОСТРОЕНИЯ БАЗ ДАННЫХ
Этот раздел посвящен обсуждению исторического пути возникновения
БД как технологии хранения данных. Достаточно подробно описаны ранние
модели представления данных: иерархическая, сетевая, а также модель инвертированных списков. Отдельное внимание уделяется рассмотрению семантических моделей данных.
Тема 1. Введение в теорию баз данных
1.1 Два направления использования ЭВМ. Эволюция электронных носителей
информации
Исторически начало бурного развития программно-аппаратных вычислительных средств относят к сороковым-пятидесятым годам двадцатого века.
Повышенный интерес к мощным вычислительным ресурсам был обусловлен
реализацией оборонных программ по разработке ядерного, а затем и термоядерного вооружения в двух основных научных центрах мира – СССР и
США. Проблематика математического моделирования сложных физических
процессов стимулировала интенсивное развитие аппаратной базы вычислительных машин: электронные лампы заменялись только что изобретенными
полупроводниковыми элементами, это приводило к миниатюризации и увеличению производительности вычислительных комплексов, а также к более
широкому их распространению. Вместе с этим совершенствовалось программное обеспечение, стремившееся оптимизировать использование машинных ресурсов.
Таким образом, можно определить первое направление использования
ЭВМ – применение вычислительной техники для выполнения численных
расчетов, которые слишком долго или вообще невозможно производить
вручную. Становление этого направления способствовало интенсификации
методов численного решения сложных математических задач, развитию
класса языков программирования, ориентированных на удобную запись численных алгоритмов, становлению обратной связи с разработчиками новых
архитектур ЭВМ.
Второе направление, которое непосредственно касается темы нашего
курса, это использование средств вычислительной техники в автоматических
или автоматизированных информационных системах. Начало этого процесса
относят к семидесятым-восьмидесятым годам XX века и связывают с распространением ЭВМ для коммерческих приложений, а также появлением персональных компьютеров.
В самом широком смысле информационная система представляет собой
программный комплекс, функции которого состоят в поддержке надежного
хранения информации в памяти компьютера, выполнении специфических для
данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обыч6
но объемы информации, с которыми приходится иметь дело таким системам,
достаточно велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются электронные каталоги, банковские системы, системы резервирования билетов, мест в
гостиницах и т.д.
Факт, что второе направление возникло несколько позже первого, обусловлен ограниченными возможностями компьютеров в части памяти на заре
вычислительной техники. В данном случае мы говорим о надежном и долговременном хранении информации, что возможно только при наличии запоминающих устройств, сохраняющих информацию после выключения электрического питания, т.н. энергонезависимые носители информации. Оперативная память, выполняющая задачу хранения промежуточных данных, этим
свойством обычно не обладает.
Первоначально использовались два вида устройств внешней памяти:
магнитные ленты и барабаны. При этом емкость магнитных лент была достаточно велика, но по своей физической природе они обеспечивали последовательный доступ к данным (что обеспечивалось механической перемоткой к
необходимой физической области носителя). Магнитные барабаны допускали возможность произвольного доступа к необходимому физическому массиву данных, однако при этом имели очень ограниченный объем и высокую
стоимость.
Необходимо отметить, что указанные ограничения не очень существенны для, собственно, численных расчетов. Даже если решение проблемы
предусматривает обработку или генерацию значительного объема информации, при его программной реализации можно продумать расположение необходимого объема данных во внешней памяти таким образом, чтобы алгоритм
функционировал быстро и эффективно. С другой стороны, для задач хранения и обработки информации (основных назначений информационных систем, в которых потребность в текущих данных определяется самим пользователем в режиме реального времени) использование только магнитных лент
и барабанов неудовлетворительно. Можно представить себе пользователя
коммерческой информационной системы (например, системы банковских
карточек), ожидающего выполнения каждой транзакции по несколько минут.
Одним из естественных требований к таким системам является высокая скорость выполнения запросов.
При этом именно требования к вычислительной технике со стороны нечисленных приложений вызвали появление сменных магнитных дисков, что
стало настоящим прорывом в истории вычислительной техники. Эти устройства внешней памяти обладали существенно большей емкостью, чем магнитные барабаны, обеспечивали удовлетворительную скорость доступа к данным в режиме произвольной выборки, а возможность смены дискового пакета на устройстве позволяла иметь практически неограниченный архив данных.
7
С появлением магнитных дисков началась история систем управления
данными во внешней памяти. До этого каждая прикладная программа, которой требовалось хранить данные на постоянных запоминающих устройствах,
сама определяла расположение каждой порции данных на магнитной ленте
или барабане и выполняла обмены между оперативной и внешней памятью с
помощью программно-аппаратных средств низкого уровня (машинных команд или вызовов соответствующих программ операционной системы). Такой режим работы значительно затрудняет поддержание на одном внешнем
носителе нескольких архивов долговременно хранимой информации. Кроме
того, каждой прикладной программе приходилось самостоятельно решать
проблемы именования частей данных и их структурирования во внешней памяти.
1.2 Появление файловых систем и их основные свойства
Историческим шагом в области унификации структурирования информации на физических носителях стал переход к использованию централизованных систем управления файлами (файловых систем). С точки зрения выполняющейся прикладной программы файл – это именованная область
внешней памяти, в которую можно записывать и из которой можно считывать данные. Правила именования файлов, способ доступа к данным, хранящимся в файле, и структура этих данных определяются конкретной системой
управления файлами и типом хранимой информации. Система управления
файлами берет на себя функции распределения физической памяти, соотнесение имен файлов с адресами соответствующих им массивов в физической
памяти и обеспечение эффективного доступа к данным. Первая развитая
файловая система была разработана фирмой IBM для серии 360.
Согласно своему основному назначению, информационные системы
ориентированы на хранение, выбор и модификацию постоянно существующей информации. Структура хранимых данных в каждой отдельной информационной системе может быть достаточно сложной, однако между различными такими структурами часто бывает много общего. На начальном этапе
использования вычислительной техники для управления информацией проблемы структуризации данных решались индивидуально в каждой информационной системе. Производились необходимые надстройки над файловыми
системами (библиотеки программ), подобно тому, как это делается в компиляторах, редакторах и т.д. Однако, поскольку информационные системы требуют использования нетривиальных организационных структур данных, эти
дополнительные индивидуальные средства управления данными являлись
существенной частью информационных систем и во многом повторялись от
одной системы к другой. Стремление выделить и обобщить общую часть организации данных в информационных системах, ответственную за управление сложно структурированной информацией, явилось первой побудительной причиной появления БД как технологии упорядочивания и хранения
больших массивов данных. Очень скоро стало понятно, что невозможно
8
обойтись одной лишь общей библиотекой программ, реализующей над стандартной базовой файловой системой более сложные методы хранения данных.
1.3 Потребность в новых технологиях хранения данных
Для примера предположим, что мы хотели бы реализовать простую информационную систему для организации учета студентов некоторого высшего учебного заведения. Система должна выполнять следующие действия: выдавать списки студентов по группам, поддерживать возможность перевода
студента из одной группы в другую, зачисления новых студентов и исключения учащихся. Для каждой студенческой группы должны присутствовать опции запроса имени старосты, общей численности группы, общей суммы выплаченной в последний раз стипендии и т.д. Для каждого студента должны
поддерживаться возможности получения номера зачетной книжки по полному имени студента и наоборот, формирования информации о текущем среднем балле и о размере его стипендии.
Предположим, что мы решили основывать эту информационную систему на основе обычной файловой системы и использовать для хранения информации один файл, расширив базовые возможности применяемой файловой системы за счет создания специальной библиотеки функций. Поскольку
минимальной информационной единицей в нашем случае является студент,
естественно потребовать, чтобы в этом файле содержалось по одной записи
для каждого учащегося. Какие поля может содержать такая запись? Полное
имя сотрудника (СТУД_ИМЯ), номер его зачетной книжки (СТУД_НОМЕР),
средний балл (СТУД_СРБАЛЛ), размер стипендии (СТУД_СТИП), номер
группы (СТУД_ГР_НОМЕР). Поскольку мы планируем ограничиться одним
файлом, та же запись должна содержать имя старосты группы
(СТУД_ГР_СТАР).
Назначение разрабатываемой информационной системы требует обеспечение возможности многоключевого доступа (возможен поиск данных по
значениям нескольких полей) к хранимым данным по уникальным ключам
(т.е. по значениям определенных полей, в которых содержатся уникальные и
неповторимые для каждого студента данные) СТУД_ИМЯ и СТУД_НОМЕР.
Кроме того, должна присутствовать возможность выбора всех записей с общем значением СТУД_ГР_НОМЕР – доступ по неуникальному ключу. Для того, чтобы получить численность группы или общий размер стипендии, информационная система каждый раз должна будет выбрать все записи о студентах определенной группы и посчитать соответствующие общие значения.
Таким образом, можно заметить, что реализация на базе файловой системы даже для такой простой информационной системы, во-первых, требует создания достаточно сложной библиотеки функций для многоключевого
доступа к файлам, во-вторых, приводит к образованию избыточности хранения (для каждого студента группы повторяется имя старосты), и, в-третьих,
выполнение агрегатных (суммарных) вычислений для учебных групп каждый
9
раз требует пересмотра всего файла. Кроме того, если в ходе эксплуатации
системы нам захочется, например, выдавать списки сотрудников, получающих заданную зарплату, то опять же придется либо полностью просматривать файл, либо изменять его структуру, объявляя ключевым поле
СТУД_СТИП.
Логичный выход из создавшегося положения – использование для организации информационной системы два многоключевых файла: СТУДЕНТЫ и
ГРУППЫ. Первый файл будет содержать следующие поля: СТУД_ИМЯ,
СТУД_НОМЕР, СТУД_СРБАЛЛ, СТУД_СТИП, СТУД_ГР_НОМЕР, а второй
- ГР_НОМЕР, ГР_СТАР, ГР_СТИП (размер суммарной стипендии студентов
группы) и ГР_РАЗМЕР (общее число учащихся в группе). Большинство недостатков, упомянутых в предыдущем абзаце, будут нейтрализованы. Каждый из файлов будет содержать только недублируемую информацию, необходимости в громоздких динамических вычислениях агрегатной информации
не возникает. Однако, следует заметить, что при таком подходе разрабатываемая информационная система будет обладать некоторыми новыми особенностями, сближающими ее с технологиями БД.
Прежде всего, информационная система должна иметь представление,
что работает с двумя информационно связанными файлами (движение в сторону схемы организации базы данных), осознавать назначение и смысл каждого поля (например то, что СТУД_ГР_НОМЕР в файле СТУДЕНТЫ и
ГР_НОМЕР в файле ГРУППЫ означают одно и то же), а также понимать, что
изменение информации в одном файле должно автоматически вызывать модификацию второго, сохраняя согласованность общего содержимого.
Например, если в группу зачисляется новый студент, то необходимо добавить запись в файл СТУДЕНТЫ, а также соответствующим образом обновить
поля ГР_СТИП и ГР_РАЗМЕР в записи файла ГРУППЫ, описывающей
группу, в составе которой произошли изменения.
Понятие согласованности данных является ключевым понятием БД.
Фактически, если информационная система (даже такая простая, как в
нашем примере) поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает БД. Если же
некоторая вспомогательная система управления данными позволяет работать
с несколькими файлами, обеспечивая их согласованность, ее можно назвать
простейшей СУБД. Требование поддержания согласованности данных в нескольких файлах не позволяет обойтись одной только библиотекой функций:
такая информационная система должна иметь некоторые собственные данные (метаданные) о структуре хранимой информации, а также знания, определяющие целостность данных.
Далее представим ситуацию, что в нашей первоначальной реализации
информационной системы, основанной на использовании библиотек расширенных методов доступа к файлам, обрабатывается операция регистрации
нового учащегося. Следуя требованиям согласованного изменения файлов,
информационная система добавила новую запись в файл СТУДЕНТЫ и соби10
ралась модифицировать запись файла ГРУППЫ, но именно в этот момент
произошло аварийное выключение питания. Очевидно, что после перезапуска системы ее данные будут находиться в рассогласованном состоянии. Для
исправления такой ошибки сначала потребуется обнаружить сам факт хранения рассогласованных данных (для этого нужно проверить полноту соответствия информации в файлах СТУДЕНТЫ и ГРУППЫ), а потом уже привести
информацию в согласованное состояние. Как правило, стандартные СУБД
берут эту работу на себя. В круг обязанностей вспомогательной прикладной
системы, в отличие от СУБД, обеспечение корректности хранимых данных
может не входить.
Теперь представим, что мы хотели бы организовать параллельную
(например, многотерминальную) работу с базой данных студентов. Если
опираться только на использование файлов, то для обеспечения корректности
на все время изменения любого из двух файлов доступ других пользователей
к этому файлу будет блокирован (вспомним возможности файловых систем
для синхронизации параллельного доступа). Таким образом, зачисление студента Петра Ивановича Сидорова существенно затормозит получение информации об учащемся Иване Сидоровиче Петрове, даже если они будут
обучаться в разных группах.
1.4 Основные понятия теории БД. Уровни представления данных
Следовательно БД как технология хранения данных позволяет решить
множество задач, которые затруднительно или вообще невозможно решить в
рамках применения стандартных файловых систем. К основным характерным
чертам БД можно отнести:
1). Упорядоченный (структурированный) подход к хранению массивов
данных. Наличие данных о способе организации (метаданные).
БД хранит данные в четко структурированном и специально организованном виде, исключающем совместное хранение разнородной информации.
В БД структура данных строго фиксирована и определяется стандартом используемой модели данных. Описание структуры данных (метаданные) хранятся отдельно от самих данных в так называемом, словаре (системном каталоге) данных. Таким образом, любая СУБД может работать с разными
наборами данных, поскольку структура их хранения доступна при чтении
данных. Для сравнения, в файловой системе способ хранения данных – дело
каждой программы, осуществляющей хранение и обработку данных. Структура данных встроена в программу доступа и не может быть прочитана другими программами.
2). Исключение дублирования данных и автоматизированный контроль
их целостности.
К примеру, в текстовых файлах на порядок размещения данных не
накладывается сколько-нибудь серьезных ограничений, и данные могут быть
расположены произвольно. Некоторые данные могут неоднократно повторяться. В электронных таблицах данные по строкам и столбцам располагают11
ся уже упорядочение, но все еще достаточно произвольно. В БД структура
данных строго фиксирована, что позволяет эффективно отслеживать выполнение требований по уникальности и целостности отдельных значений.
3). Возможность организации расширенных средств поиска информации. Наличие языков программирования высокого уровня для организации
сложных запросов к БД.
В современных СУБД присутствует развитый графический интерфейс,
позволяющий сделать работу пользователя с БД интуитивно понятной и эффективной, причем сама графическая оболочка не зависит ни от структуры,
ни от содержания БД, что делает стандартные платформы БД удобным и
мощным инструментом разработки универсальных БД. Для реляционных БД
разработан язык высокого уровня для реализации самых сложных запросов
(SQL).
4). Независимость программ, данных и операций.
Так как любая упорядоченность накладывает серьезные ограничения на
способ хранения и использования данных, то были предприняты действия,
направленные на повышение гибкости доступа к данным. Результатом этих
действий стала предложенная в 1978 г. трехуровневая архитектура построения баз данных. Данная схема была разработана как стандарт представления
данных (ANSI/SPARC) и в настоящий момент ее поддерживает большинство
коммерческих СУБД.
Цель трехуровневой архитектуры заключается в отделении пользовательского представления БД от ее физического представления, т.е, обеспечении независимости от данных (см. рис. 1).
Рисунок 1. Уровни архитектуры построения баз данных
Первый уровень - внутренний (internal). Определяется физической моделью данных, которая определяет размещение данных на физических носите12
лях и способы доступа к ним, структуру файлов, индексов и отдельных информационных единиц.
Второй уровень - концептуальный (conceptual). Определяется концептуальной моделью данных, которая описывает логическую структуру данных
без указания подробностей их физического хранения.
Третий уровень внешний, или уровень представлений (интерфейса). Выводит необходимые данные в требуемом формате, скрывая остальную часть
БД. Внешнее представление - это содержимое БД, каким его видит конкретный пользователь. Одному пользователю нужны сведения о товарах и их
размещении на складе, и он может не иметь понятия, что в БД хранится еще
информация о клиентах, поставщиках и т. д. Пользователь может трансформировать свое представление, не оказывая влияния на другие. Внешний уровень предоставляет также свободу выбора процедуры общения с БД. Рядовой
пользователь может применять инструменты, предлагаемые интерфейсом,
т.е. списки готовых команд и другие запрограммированные последовательности действий. Опытный пользователь может воспользоваться более сложным языком запросов, при условии, что используемая платформа поддерживает его применение.
Все уровни представления данных связаны между собой средствами
отображения одного уровня в другой путем трансляции запросов в обоих
направлениях. Запрос определенного пользователя на выборку конкретных
данных, как правило, интерпретируется на концептуальном уровне в виде
последовательности высокоуровневых процедур и затем преобразуется в последовательность низкоуровневых команд на поиск и извлечение требуемых
данных с физического носителя. Далее происходит обратная трансляция результатов запроса от физического уровня на уровень интерфейса.
Применение трехуровневой архитектуры также позволяет обеспечить
следующие уровни изолированности:
- Независимость программ и данных (program-data independent).
- Независимость программ и операций (program-operation independent).
Другими словами, каждый из уровней представления данных может
быть изменен без ущерба для других, что позволяет значительно повысить
универсальность и гибкость разрабатываемых БД.
5). Защищенность от сбоев.
Перманентное ведение электронного журнала изменений и развитые
технологии промежуточного копирования тела БД, позволяют подобрать оптимальный режим безопасного функционирования БД.
6). Возможность организации параллельного доступа множества пользователей.
Использование изолированных атомарных последовательностей действий (транзакций) позволяет организовать одновременную работу нескольких пользователей с одним и тем же объектом БД, при условии, что действия
соседних пользователей не нарушают базовые принципы БД.
13
1.5 Свойства БД
Независимость данных.
В БД независимость данных обеспечивается на логическом и физическом
уровнях. Логическая независимость предполагает независимость интерфейса
(внешнего представления) от изменения логической структуры данных на
концептуальном уровне. Независимость данных на логическом уровне обеспечивается изолированностью внешнего представления от нижних уровней
архитектуры БД, т. е. однажды разработанный интерфейс не придется переписывать заново для каждой модификации структуры данных.
Физическая независимость данных предполагает независимость организации работы с данными от закономерностей размещения на физических носителях, их типа, организации и способа доступа. Этот тип независимости
данных обеспечивается развязкой внутреннего уровня (физической модели
данных) и вышестоящих концептуального и интерфейса. Таким образом,
изменения в физической структуре хранимых данных не повлекут пересмотр
применяемой модели данных и внешнего представления.
Контролируемая избыточность данных.
Избыточность данных, в первую очередь, определяется присутствием
повторяющейся информации. Наличие неуникальной информации приводит,
во-первых, к необоснованному увеличению объема БД, а во-вторых, к возможности появления рассогласованности хранимых данных. Для примера
рассмотрим БД студентов, приведенную в предыдущей теме. До того как мы
разделили основной файл БД на два, каждая запись, характеризующая отдельного студента, содержала повторяющуюся информацию об имени старосты группы, к которой принадлежал учащийся. Подобное дублирование информации в сложных БД с развитой структурой приводит к следующим серьезным проблемам:
- нужно выполнять «лишнюю» работу, связанную с вводом неуникальных данных;
- при вводе повторяющихся данных возрастает вероятность ошибки
набора, что в дальнейшем приведет к некорректному выполнению поиска по
соответствующим неключевым полям;
- при изменении информации о некоторых объектах может возникнуть
необходимость коррекции всех записей, содержащие эти сведения, т.е. при
смене фамилии старосты придется модифицировать соответствующее поле у
всех студентов данной группы;
- согласованность данных нарушается при обновлении не всех повторяющихся данных (аномалия модификации), при ошибочном обновлении полей, не связанных непосредственно с удаляемыми данными (аномалия удаления), при добавлении некорректных данных (аномалия добавления);
- неоправданное увеличение объема БД ведет к снижению скорости выполнения запросов в целом.
14
Основное требование контролируемой избыточности данных заключается в том, что данные должны быть избыточными ровно настолько,
насколько это требуется для нормальной работы системы. Т.к. некоторая избыточность требуется для повышения эффективности работы, ускорения поиска и восстановления информации после сбоев. Условие поддержания согласованности хранимых данных лежит в основе следующего свойства БД.
Целостность и корректность хранимых данных.
Поддержание целостности БД является необходимым условием ее эффективного функционирования. Целостность – свойство БД, означающее,
что в ней содержится полная, непротиворечивая, согласованная и адекватно
отражающая предметную область информация. Сопровождение БД целью
обеспечения ее целостности включает проверку и восстановление в случае
обнаружения противоречий в хранимых данных. Целостное состояние БД
поддерживается с помощью введения ограничителей целостности (constraints) в виде условий, которым должны удовлетворять хранимые в базе
данные, выделяют три типа ограничителей целостности:
- ограничители значений, к ним относятся задание типа и формата, позволяющего ввод только соответствующих шаблону данных, например,
наиболее часто используют определение диапазона значений или списка значений;
- ссылочная целостность, которая достигается контролированием отношений между связанными данными при их модификации, для этого,
например, существуют опции каскадного удаления и обновления связанных
записей;
- целостность записи, которая обеспечивается проверкой уникальности
соответствующих значений ключей и объявлением данных, обязательных для
ввода при формировании записи.
Другим важным средством поддержания целостности является применение при работе с БД режима транзакций. Транзакцией называется некоторая неделимая последовательность операций над элементами БД, которая
начинается при согласованном состоянии БД и сохраняет его при своем завершении. При этом СУБД отслеживает процесс выполнения транзакции от
начала и до конца, и, если по каким-либо причинам (вследствие сбоев или
внешних или внутренних ошибок) транзакция остается незавершенной, то
производится отмена всех операций, входящих в ее состав (так называемый
откат транзакции). Для транзакции как логической единицы действия над
БД характерны следующие свойства:
• атомарность (выполняются либо все входящие в транзакцию операции, либо – ни одна);
• согласованность (любая транзакция должна переводить БД из одного
согласованного состояния в другое);
• изолированность (работа одной транзакции не влияет на корректность
выполнения другой);
15
• безопасность (даже аварийные сбои в работы БД не приводят к потере
согласованности данных).
Реализация режима транзакций особенно важна в многопользовательских приложениях, где для достижения приемлемых скоростей обслуживания запросов требуется параллельная обработка множества транзакций. Т.к.,
вследствие ограниченности своих ресурсов, сервер не может обрабатывать
все запросы одновременно, параллельно выполняемые процессы, как правило, разбивают на сравнительно небольшие части, составляя сценарий их поочередного выполнения. Если отдельные транзакции производят поиск или
модификацию информации в разных секторах БД, то это не приводит к возникновению каких-либо сложностей. Другое дело, когда несколько транзакций работают с одним массивом данных, и хотя бы одна из них требует его
модификации. В этом случае порядок выполнения частей транзакций играет
важную роль, поскольку корректность выполнения запросов может нарушиться.
С одной стороны, выполнение транзакций последовательно снимает эту
проблему, однако приводит к увеличению длительности выполнения запросов и повышенной нагрузке на сеть. С другой – распараллеливание транзакций (в этом случае говорят о их сериализации) является сложной задачей, т.к.
эта процедура подразумевает составление такого плана их выполнения (сериального плана), при котором суммарный эффект реализации транзакций эквивалентен эффекту их последовательного выполнения, однако, затрачивает,
при этом, меньше времени. Основной проблемой параллельного выполнения
транзакций является возможность возникновения конфликтов между одновременно выполняемыми транзакциями при взаимоисключающем обращении к одному объекту БД. Минимизация вероятности возникновения конфликтов наряду со скоростью выполнения является критерием эффективности процедуры сериализации. Составление оптимального сериального плана
выполнения транзакций по настоящее время является сложной проблемой,
для которой не существует универсального решения (детальное рассмотрения режима транзакций приведено в теме 9).
Безопасность и конфиденциальность.
Зачастую БД представляет собой значимый информационный ресурс,
безопасность которого должна быть должным образом обеспечена. Потенциальными источниками опасности для БД являются несанкционированный доступ к ее элементам и аварийные ситуации, приводящие к сбоям оборудования, обеспечивающего работу БД.
Доступ нежелательных лиц к структурам БД может повлечь следующие
последствия:
- хищение данных;
- непредумышленная и умышленная фальсификация данных;
- нарушение режима доступа к БД;
- повреждение структуры БД данных, и, как следствие, потеря ее функциональности.
16
Для обеспечения этого аспекта безопасности в современных СУБД
предусмотрена развитая система администрирования доступа, включающая в
себя защиту паролем, авторизацию и аутентификацию пользователей, поддержкой различных уровней доступа к БД и отдельным ее элементам (таблицам, формам, отчетам и т, д.).
Обеспечение бессбойной работы БД достигается постоянным ведением
электронного журнала изменений, а также развитыми средствами репликации последовательных версий БД. Это позволяет в короткие сроки восстановить согласованное состояние БД на момент начала выполнения последней
транзакции.
Необходимо сознавать, что организация безопасной работы БД – это целый комплекс мер, не исчерпывающийся только программными средствами.
Не меньшую эффективность имеют организационно-регламентирующие меры для работающего с БД персонала, а также технические методы ограничения и выявления несанкционированного физического доступа к оборудованию, обеспечивающему функционирование БД (более подробно эти вопросы
рассматриваются в теме 13).
Тема 2. Модели данных
2.1 Понятие модели данных.
Модель данных – это формализованная абстракция, воспроизводящая
информационную структуру данных. В самом простом виде модель данных
можно представить тривиальным списком параметров информации, предназначенной для хранения в БД. Однако, вследствие внутренней структурированности и взаимосвязи информационных элементов, модель данных должна
дополнительно обеспечивать возможности описания системы организации
данных. Иначе говоря, модель данных представляет собой совокупность логических концептов, описывающих информационные элементы, и общих логических закономерностей, которые используются для представления связанной структуры данных. Одна и та же предметная область может быть
представлена с помощью нескольких различных моделей, и, вообще говоря,
качество подобных представлений будет разным. Критерием выбора определенной модели может служить максимизация эффективности хранения данности, т.е. способность извлекать максимум полезной информации из минимума хранимых данных. Как выполнение этого критерия обеспечивалось в
начале истории возникновения БД, и какие подходы используются в современных технологиях хранения данных, мы увидим чуть позже. Сейчас же
введем несколько основных понятий теории баз данных.
Объектом называется элемент окружающего нас мира, сведения о котором мы хотели бы хранить. Объекты могут быть реальными или абстрактными, также могут представлять некоторую концепцию или событие.
Например, студент какой-либо группы, кафедра университета, запись о поступлении студента и т. д. Объект представляется в виде совокупности своих
17
свойств и может находиться в каких-либо отношениях с другими объектами.
Классом (типом) объектов называют логическую общность объектов, обладающих одинаковым набором свойств (СТУДЕНТ, ПРЕПОДАВАТЕЛЬ).
Выделенное по заданным признакам структурированное объединение
классов объектов, относящееся к какой-либо определенной области реального мира или необходимое для достижения какой-то заданной цели, называют
предметной областью. Например, БГУ, включающий в себя связанные
классы объектов СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, КАФЕДРА, ФАКУЛЬТЕТ;
но не следует путать предметную область БГУ с классом объектов УНИВЕРСИТЕТ.
Знания об объектах имеют три области своего представления (см. рис.
2). Первая область – это окружающий нас реальный мир. Классы объектов
являются совокупностями элементов реального мира и могут быть описаны с
помощью набора реальных объективных и субъективных свойств (факты
наличия имени собственного, окрашенности, протяженности, стоимости,
рентабельности и пр.). Вторая – область информации (иначе говоря, область
абстракций, общепринятых для описания определенной предметной области), рассматривает атрибуты классов объектов. Атрибут - это формализованное унифицированное отражение свойств класса объектов. Здесь следует
отметить, что, вообще говоря, атрибуты можно определить и для отдельного объекта, однако в рамках теории БД такой подход не практикуется, поскольку он затрудняет обобщение профильной информации и снижает эффективность ее хранения. Поэтому в дальнейшем под понятием объект мы
будем понимать класс объектов, а под понятием экземпляр объекта – экземпляр класса объектов.
Рисунок 2. Три области представления данных
Каждый объект характеризуется своей совокупностью атрибутов
(например, для объекта СТУДЕНТ: паспортный вариант ФИО на кириллице;
возраст в годах; средний балл в десятичных дробях; номер группы в целых
числах). Соответственно, каждый экземпляр объекта будет характеризоваться свойственным ему набором значений атрибутов, т.е. конкретный студент
будет характеризоваться следующей записью: Иванов Петр Сергеевич; 20;
8,5; 25. Другими словами, если в первой области представления знаний о
18
конкретных экземплярах объектов мы можем оперировать безразмерными
неопределенными категориями (меньше-больше, выше-ниже, темнее-светлее,
лучше-хуже), то во второй – необходимо прийти к некоторому унифицированному общепринятому либо частному базису.
Третья область – это физическая область сохраненных данных. Она может представлять собой бумажный носитель, электронно-магнитное или оптическое запоминающее устройство, где информация представлена в виде
символьных строк или последовательности битов, кодирующей данные.
Поскольку, как правило, в рамках одного объекта рассматривается
множество его экземпляров, каждую область представления данных в свою
очередь можно разделить на две подобласти. Первая подобласть дает общую
характеристику объекта в виде свойств, атрибутов и заголовков физических структур, в областях реального мира, области представления и физической области соответственно. Эту информацию принято называть метаданными, основным назначением которых является отображение структуры хранящихся данных. Например, мы указываем, что объект СТУДЕНТ будет характеризоваться уже описанной совокупностью атрибутов: паспортный вариант ФИО на кириллице, возраст в годах, средний балл в десятичных дробях, номер группы в целых числах.
Вторая подобласть состоит из совокупности значений свойств, значений
атрибутов и физических записей для всех рассматриваемых экземпляров
объекта в каждой из областей представления данных. Например, в виде
следующей последовательности значений атрибутов: Иванов Петр Сергеевич; 20; 8,5; 25/Васильев Александр Ильич; 18; 4,5; 13/Петров Николай Иванович; 22; 7,0; 53 и т. д. Этот массив данных принято называть телом БД, и
его назначение – содержать весь объем информации об описываемой предметной области в соответствии со структурой, определенной метаданными.
Исходя из этого, под понятием экземпляр объекта, можно рассматривать
единичный набор значений принимаемых элементами данных.
Элементы данных (значения атрибутов) могут быть простыми и составными, однозначными и многозначными, сохраняемыми и вычисляемыми
или иметь пустое значение. Составные элементы данных могут быть разделены на нескольких простых, но обычно используются как единое целое,
например, номер и серия паспорта. Если возможны ссылки на часть элемента
данных, то их лучше разложить на простые (например, дата рождения). Многозначными называют элементы данных, которые могут принимать несколько значений (например, номер телефона студента). К вычисляемыми (производным) относят элементы данных, которые могут быть определены на основе уже существующих (например, приблизительный возраст легко можно
вычислить отняв из текущего года год рождения).
Специальное пустое значение (Null) вводится для элементов данных, которые не имеют значений или могут быть опущены при вводе. Различают
следующие три случая применения значения Null:
19
- в настоящий момент не известно, какое значение имеет элемент данных, например, значение атрибута Примечание;
- элемент данных не может иметь значения в данном конкретном случае
(например, ученую степень имеет смысл заполнять только для научных работников и преподавателей);
- известно, что элемент данных имеет определенное значения, но оно не
важно или было пропущено при вводе.
Каждый атрибут связан с набором значений, называемым доменом. Домен определяет все потенциальные значения, которые могут быть присвоены
атрибуту. Например, домен «Имена» содержит все возможные имена людей,
а домен «Номера зачетки» – все возможные комбинации цифр, определенной
длины, использующихся для идентификации зачетных книжек. Для доменов
могут быть приняты ограничения на содержание и структуру (формат, шаблон), например, формат ФИО.
Некоторые элементы данных обладают важным для построения концептуальной модели свойством. Если определен факт уникальности значения,
которое принимает некий элемент данных некоторого экземпляра объекта, то
далее можно однозначно идентифицировать значения, принимаемые другими
элементами данных того же экземпляра (поскольку они принадлежат однозначно установленному экземпляру объекта). Например, по номеру и серии
паспорта компетентные органы могут установить остальные данные о человеке. Элемент данных, но которому можно однозначно идентифицировать
экземпляр объекта, называется ключевым элементом данных (ключевым атрибутом, ключом). Он может быть простым и состоять из одного элемента
данных (номер зачетки студента) или составным (сцепленным) – серия и номер паспорта. В общем случае, у одного объекта может быть несколько ключевых атрибутов. Тогда наиболее простой из них выбирают в качестве первичного ключа, а остальные – будут назваться потенциальными или альтернативными ключами.
Элемент данных (значение атрибута) является минимальным фрагментом БД. Взятый отдельно, он информации не несет и приобретает смысл
только привязке к метаданным и конкретному экземпляру объекта. Совокупность элементов данных, относящихся к одному экземпляру объекта и
построенная согласно метаданным, называется записью данных.
2.2 Классификация связей между объектами и их атрибутами
В предыдущем подразделе было дано определение модели данных, согласно которому она состоит из двух частей: собственно, логических концептов (объектов) и логических закономерностей, определяющих структуру информации (связей). И, если основные характеристики объектов нами уже
рассмотрены, анализ возможных взаимосвязей, возникающих между ними,
мы приведем далее.
Начать классификацию связей между объектами можно по критерию
количества объектов, участвующих в связи. Эту характеристику связи приня20
то называть арностью связи. Соответственно, можно выделить унарные, бинарные, тернарные и связи более высоких порядков. Унарная связь (кроме
случая рекурсии) обычно смысла не имеет. Наиболее часто для описания логической структуры применяются бинарные связи (связь между двумя объектами), поскольку связи более высоких порядков труднореализуемы, нелегки
для понимания и всегда могут быть представлены в виде совокупностей бинарных связей.
Следующий критерий классификации – кардинальность связи.
1. «один к одному»
Означает, что одному экземпляру объекта А соответствует один и только
один экземпляр объекта В, находящегося с ним в связи. На практике такой
тип связи встречается достаточно редко, поскольку в этом случае связываемые объекты можно объединить в один. Использование этого типа связи в
реальных БД, как правило, связано с искусственными требованиями к ее
структуре, например, необходимость хранить в одной БД открытые и конфиденциальные сведения об объекте – тогда, мы получаем два объекта, содержащие разные наборы атрибутов, но относящееся, по сути, к одному.
2. «один ко многим»
Одному экземпляру объекта А ставится в соответствие несколько экземпляров объекта В. Этот тип связи является наиболее распространенным.
Например, к одной кафедре может относиться множество студентов и преподавателей.
3. «многие к одному»
Нескольким экземплярам объекта А соответствует один экземпляр объекта В. Типы связей «один ко многим» и «многие к одному» являются взаимно обратимыми, поэтому на практике обычно используют тип связи «один ко
многим».
4. «многие ко многим»
Означает, что одному экземпляру объекта А может соответствовать несколько экземпляров объекта В и, наоборот, каждому экземпляру объекта В
ставиться в соответствие несколько экземпляров объекта А. Например, сведения об приписке студентов к факультативным курсам. Один студент может
посещать несколько курсов, и к каждому факультативному курсу приписано
несколько студентов.
Помимо связей между объектами, в модели данных можно выделить зависимости между атрибутами внутри одного или нескольких объектов.
Принято выделять функциональные, транзитивные и многозначные зависимости.
Понятие функциональной зависимости является базовым, т.к. на его основе могут быть сформулированы определения остальных видов зависимостей. Рассмотрим объект A, характеризуемый атрибутами a0 и a1. Атрибут
a1 (имя студента) функционально зависит от атрибута a0 (номер зачетной
книжки студента), если каждому значению атрибута a0 соответствует одно
и только одно значение атрибута a1. Т.е., если нам известно значение атри21
бута a0 (иначе – детерминанта), мы однозначно можем определить значение атрибута a1 (действительно, у зачетной книжки может быть только
один законный обладатель с вполне конкретным именем). Однако данному
значению атрибута a1 может соответствовать несколько различных значений атрибута a0. Другими словами, студентов с одинаковым именем в
учебном заведении может быть множество и каждому из них присвоен свой
номер зачетки. Математически функциональная зависимость a1 от a0 обозначается записью a0→a1. Если же между атрибутами a0 и a1 имеет место
функциональная зависимость вида a0→a1 и a1→a0 (случай взаимно однозначного соответствия), то говорят о функциональной взаимозависимости
(обозначается a0↔a1 или a1↔a0). Наличие функциональной взаимозависимости между атрибутами a0 и a1 (например. хранение в БД наряду с номером
зачетки студента номера и серии его паспорта) говорит о присутствии альтернативных (потенциальных) ключей.
Необходимо отметить, что атрибуты a0 и a1, вообще говоря, могут
быть составными, т. е. состоять из двух и более атрибутов. В связи с этим
функциональная зависимость может быть полной или частичной. Частичной
зависимостью (частичной функциональной зависимостью) называется зависимость атрибута a1 (проживание студента в Минске) от части составного
атрибута a0 (адрес студента). Полная функциональная зависимость определяется зависимостью атрибута a1 (имя студента) от всего составного атрибута a0 (номер и серия паспорта студента).
Атрибут a2 находится в транзитивной зависимости от атрибута a0,
если для атрибутов a0, a1, a2 выполняются условия a0→a1 и a1→a2, но при
этом зависимость a0→a2 отсутствует. Например, a0(номер зачетки)→ a1(ср.
балл) и a1(ср. балл)→a2(размер стипендии). Т.е. конкретный студент обладает вполне определенным баллом, согласно которому ему установят стипендию. Однако сразу сказать какую стипендию будет иметь студент с номером
зачетки 29877453 затруднительно, поскольку размер стипендии определяется
не номером зачетки, а средним баллом студента.
Между атрибутами в отношении может иметь место и многозначная зависимость. Атрибут a1 многозначно зависит от атрибута a0, если каждому
значению a0 соответствует множество значений a1, не связанных с другими
атрибутами. Многозначные зависимости могут подразделяться на следующие
виды: «один ко многим»(1:М), «многие к одному»(М:1) и «многие ко многим»(М:М) – обозначаемые a0=>a1, a0<=a1 и a0<=>a1 соответственно.
Например, одному значению атрибута a0 (номер зачетки студента) может сопоставляться несколько значений атрибута a1(иностр. язык студента),
что составит многозначную зависимость «один ко многим»(1:М) или
a0=>a1, т.е. каждый конкретный студент может владеть двумя и более иностранными языками. Пусть каждый преподаватель ведет несколько предметов, и за каждый предмет отвечают несколько преподавателей, тогда мы получим пример многозначной зависимости «многие ко многим» - a0 (номер
удостоверения преподавателя) <=> a1 (название предмета).
22
Зависимость между атрибутами может полностью отсутствовать, например, в случае, если они относятся к разным объектам. Другими словами, два
атрибута будут взаимно независимыми, если ни один из этих атрибутов не
является функционально зависимым от другого.
После того, как мы рассмотрели основные аспекты моделирования данных, логичным продолжением будет рассмотреть первые исторически сложившиеся модели данных, к которым, прежде всего, относят иерархическую
и сетевую. Также, в рамках данной темы, будет рассмотрен подход инвертирования списков, который изначально развивался как альтернативный способ
хранения записей, однако в дальнейшем послужил толчком к развитию реляционной модели данных.
2.3 Иерархическая модель
Исторически первой была разработана и воплощена иерархическая модель данных. Первым коммерческим решением БД на основе иерархической
модели данных стала СУБД IMS фирмы IBM, выпущенная в 1968 г. В иерархической модели связи между данными можно описать с помощью упорядоченного графа, обладающего древовидной структурой. Упрощенно представление связей показано на рисунке.
Для описания структуры (схемы) иерархической БД в некоторых языках
программирования используется тип данных «дерево». В нем допускается
вложенность типов, каждый из которых находится на некотором уровне. Тип
«дерево» является составным, он включает в себя подтипы («поддеревья»),
каждый из которых, в свою очередь, является типом «дерево». Каждый из
типов «дерево» состоит из одного «корневого» типа и упорядоченного набора (возможно, пустого) подчиненных типов. Каждый из элементарных типов,
включенных в тип «дерево», является простым или составным типом «запись». Простая «запись» состоит из одного типа, например числового, .а составная «запись» объединяет некоторую совокупность типов, например, число, строку символов и указатель (ссылку). Пример типа «дерево» как совокупности типов показан на рис. 3а.
Корневым называется тип,
который имеет подчиненные типы
и сам при этом не является подтипом. Подчиненный тип (подтип)
является потомком по отношению
к типу, который выступает для него в роли предка (родителя). Потомки одного и того же типа являются близнецами по отношению
друг к другу. В целом тип «дерево» представляет собой иерархически организованный набор типов «запись».
Рисунок 3а. Пример типа «дерево»
23
Иерархическая БД представляет собой упорядоченную совокупность экземпляров данных типа «дерево» (деревьев), содержащих экземпляры типа
«запись» (записи). Часто отношения родства между типами переносят на отношения между самими записями. Поля записей хранят собственно числовые
или символьные значения, составляющие основное содержание БД. Обход
всех элементов иерархической БД обычно производится сверху вниз и слева
направо. Данные, организованные в соответствии с требованиями иерархической модели могут выглядеть следующим образом, см. рисунки 3б, 3в.
Рисунок 3б. Данные, организованные в соответствии с требованиями иерархической модели
Рисунок 3в. Пример иерархической модели данных
Для организации физического размещения иерархических данных в памяти компьютера могут использоваться следующие группы методов:
• представление линейным списком с последовательным распределением
памяти (адресная арифметика, левосписковые структуры);
• представление связными линейными списками (методы, использующие
указатели и справочники).
24
К основным операциям манипулирования иерархически организованными данными относятся следующие:
• поиск указанного экземпляра БД (например, дерева с заданным значением в определенном поле);
• переход от одного дерева к другому;
• переход от одной записи к другой внутри дерева;
• вставка новой записи в указанную позицию;
• удаление текущей записи и т. д.
В соответствии с определением типа «дерево», можно заключить, что
между предками и потомками автоматически поддерживается контроль целостности связей. Основное правило контроля целостности формулируется
следующим образом: потомок не может существовать без родителя, а у некоторых родителей может не быть потомков. Механизмы поддержания целостности связей между записями различных деревьев отсутствуют.
К достоинствам иерархической модели данных относятся эффективное
использование памяти ЭВМ и неплохие показатели времени выполнения основных операций над данными. Иерархическая модель данных удобна для
работы с иерархически упорядоченной информацией.
Недостатками иерархической модели являются ее громоздкость для
обработки информации с достаточно сложными логическими связями, значительная избыточность хранимых данных, отсутствие логической гибкости
структуры.
2.4 Сетевая модель
Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов данных в виде произвольного графа, обобщая тем самым
иерархическую модель данных. Если в отношении между данными потомок
имеет более одного предка, такое отношение уже нельзя описать в виде древовидной структуры. В этом случае используется сетевая структура
(рисунок 4).
Для описания схемы сетевой БД
используется две группы типов: «запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка и
потомка. Переменные типа «связь» являются экземплярами связей. Сетевая
БД состоит из набора записей и набора
соответствующих связей. На формирование связи особых ограничений не
накладывается. Если в иерархических
структурах запись-потомок могла иметь
только одну запись-предка, то в сетеРисунок 4. Сетевая модель данных
вой модели данных запись-потомок
может иметь произвольное число записей-предков (сводных родителей).
25
Пример схемы простейшей сетевой БД показан на рисунке. Типы связей
здесь обозначены надписями на соединяющих типы записей линиях.
Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах данных.
К достоинствам сетевой модели можно отнести повышенную логическую гибкость системы, снижение избыточности данных, а также неплохие
показатели эффективности работы.
Недостатки представлены громоздкостью и трудностью восприятия
структуры данных пользователями, дополнительно, за счет произвольности
характера устанавливаемых связей, ослабляется контроль целостности и корректности записей.
2.5 Инвертированные списки
Способ организации данных в виде инвертированных списков задумывался как альтернатива структуре линейных списков физической организации данных (применявшейся в иерархических и сетевых моделях). Во многом
он явился предтечей реляционных СУБД, которые позаимствовали отсюда
основные подходы к индексированию данных.
Рисунок 5. Инвертированные списки
Инвертированный список представляет собой двухуровневую индексную структуру (см. рис. 5). На первом уровне содержатся упорядоченные
26
значения вторичных ключей, на втором – цепочка блоков, содержащих номера записей, имеющих одно и то же индексное значение вторичного ключа.
Основной файл представляет собой совокупность унифицированных записей,
содержащих как уникальные, так и повторяющиеся значения полей.
Инвертированные списки позволяют существенно ускорить процесс поиска необходимой информации по сравнению с линейными списками. Это достигается с помощью упорядочивания (сортировки) записей исходного файла
по значениям данных в одном из неключевых полей. Инвертирование исходного списка можно выполнить для отдельных (частичное инвертирование)
или всех (полное инвертирование) неключевых полей исходного файла. При
этом вторичным ключом объявляется набор значений полей, которому соответствует набор искомых записей. Это означает, что существует множество
записей, имеющих одинаковые значения вторичного ключа. Для обеспечения
ускорения доступа по вторичным ключам создаются соответствующие инвертированные списки, которые в дальнейшее служат основой для организации индексных файлов, реализующих доступ к данным по соответствующим
значениям вторичных ключей.
Механизм доступа к записям по вторичному ключу при подобной организации записей весьма прост. На первом шаге мы ищем в области первого
уровня заданное значение вторичного ключа, а затем по ссылке считываем
блоки второго уровня, содержащие номера записей с заданным значением
вторичного ключа, а далее уже прямым доступом загружаем в рабочую область пользователя содержимое всех записей, содержащих заданное значение
вторичного ключа. Для одного основного файла может быть создано несколько инвертированных списков по разным вторичным ключам. При модификации основного файла:
- изменяется запись основного файла;
- исключается старая ссылка на предыдущее значение вторичного ключа;
- добавляется новая ссылка на новое значение вторичного ключа.
При этом следует отметить, что два последних шага выполняются для
всех вторичных ключей, по которым созданы инвертированные списки, что ,
безусловно, является существенным недостатком для модифицируемых баз
данных, т.к, такой процесс требует гораздо больше временных затрат, чем
просто изменение содержимого записи основного файла без поддержки всех
инвертированных списков.
Таким образом, основными достоинствами инвертированных списков
являются увеличение скорости поиска данных по произвольным неключевым
полям и более гибкий подход к размещению информации ни физическом носителе. Данный подход показывает хорошие результаты при использовании
его для организации стабильных баз данных (библиотечных, архивных систем).
27
Однако, основой недостаток при этом – необходимость обновления
всей структуры инвертированных списков при даже незначительном изменении в хранимой информации.
Тема 3. Семантическое моделирование БД
3.1 Семантические модели данных
Потребность проектировщиков баз данных в удобных и мощных средствах моделирования предметной области вызвали к жизни направление семантических моделей данных. Хотя любая развитая семантическая модель
данных включает структурную, манипуляционную и целостную части, главным назначением семантических моделей является обеспечение возможности
выражения семантики данных.
Прежде, чем мы коротко рассмотрим особенности двух распространенных семантических моделей, остановимся на их возможных применениях.
Наиболее часто на практике семантическое моделирование используется на
первой стадии проектирования базы данных. При этом в терминах семантической модели воспроизводится концептуальная схема базы данных, которая
затем вручную преобразуется к реляционной (или какой-либо другой) схеме.
Этот процесс выполняется под управлением методик, в которых достаточно
четко оговорены все этапы такого преобразования. Основным достоинством
этого подхода является отсутствие потребности в дополнительных программных средствах, поддерживающих семантическое моделирование. Требуется только владение основами выбранной семантической модели и правилами преобразования концептуальной схемы в схему используемой модели
данных.
Следует заметить, что многие начинающие проектировщики баз данных
недооценивают важность семантического моделирования вручную. Зачастую
эта процедура воспринимается как дополнительная и излишняя работа, потребность в которой с развитием современных средств проектирования отпадает. Эта точка зрения является абсолютно неверной. Во-первых, построение
мощной и наглядной концептуальной схемы БД позволяет более полно оценить специфику моделируемой предметной области и избежать возможных
ошибок на стадии проектирования схемы БД. Во-вторых, на этапе семантического моделирования разрабатывается важная документация (хотя бы в виде вручную нарисованных диаграмм и комментариев к ним), которая может
оказаться очень полезной не только при проектировании схемы БД, но и при
эксплуатации, сопровождении и развитии уже заполненной БД.
В жизни неоднократно приходилось наблюдать ситуации, когда отсутствие такого рода документации существенно затрудняло выполнение даже
небольших изменений в схеме существующей реляционной БД. В основном,
это относится к случаям, когда проектируемая БД имеет достаточно сложную
и разветвленную структуру. Скорее всего, можно обойтись без семантического моделирования, если число таблиц не превышает десяти, но семанти28
ческое моделирование совершенно необходимо, если БД включает несколько
десятков таблиц.
3.2 Модель сущность-связь (ER-модель)
В 1976 г. для задач упрощения проектирования БД Питером Ченом (Рeter
Chen) была предложена модель сущность-связь (entity-relationship), представляющая собой высокоуровневую концептуальную модель данных, которая базируется на использовании графических диаграмм с небольшим числом разнородных компонентов.
Основными понятиями метода сущность-связь являются следующие:
• сущность,
• атрибут сущности,
• ключ сущности,
• связь между сущностями,
• степень связи,
• диаграммы ER-экземпляров,
• диаграммы ER-типа.
Сущность представляет собой реально существующий либо абстрактный объект, информацию о котором предполагается хранить в БД. Экземпляры сущности отличаются друг от друга и однозначно идентифицируются
ключевыми атрибутами. Названиями сущностей являются, как правило, существительные, например: ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА,
ГРУППА. Различаются сильные и слабые типы сущностей. Слабый тип сущности (в противоположность сильному) определяется как тип, существование
которого зависит от какого-то другого типа сущности. Слабые сущности могут быть дочерними, подчиненными и зависимыми, а сильные, в свою очередь, - родительскими, владельцами или доминантными.
Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении. Так, атрибутами сущности ПРЕПОДАВАТЕЛЬ может быть его Фамилия, Должность, Стаж (преподавательский)
и т. д.
Ключ сущности - атрибут или набор атрибутов, используемый для однозначной идентификации экземпляра сущности. Как видно из определения,
понятие ключа сущности аналогично понятию ключевого атрибута объекта.
Связь двух или более сущностей - предполагает зависимость между сущностями. Название связи обычно представляется глаголом. В качестве примеров связей между сущностями можно упомянуть следующие: ПРЕПОДАВАТЕЛЬ ВЕДЕТ ДИСЦИПЛИНУ (Иванов ВЕДЕТ «Базы данных»), ПРЕПОДАВАТЕЛЬ ПРЕПОДАЕТ-В ГРУППЕ (Иванов ПРЕПОДАЕТ-В 256 группе).
Степень связи – характеристика кардинальности связи между сущностями, а также показателя степени их участия. Как правило, наиболее общеупотребимы следующие: 1:1, 1:М, М:1, М:N. Особенностью ER-модели является возможность наложения структурных ограничений, определяющих количество экземпляров сущности, участвующей в связи, в виде двух чисел
29
(min, max), которые обозначают минимальное и максимальное число участвующих экземпляров соответственно. Степень участия может быть полной и
частичной. Полной она будет в том случае, если для существования объекта,
участвующего в связи, требуется существование другого объекта (иначе - зависимость существования). Например, если правила требуют, чтобы любой
преподаватель работал на некоторой кафедре, то экземпляр сущности ПРЕПОДАВАТЕЛЬ будет существовать, только если он участвует в связи РАБОТАЕТ-НА с сущностью КАФЕДРА, что говорит о полном участии сущности
ПРЕПОДАВАТЕЛЬ в данной связи. В то же время, только некоторые преподаватели могут руководить кафедрами. Значит, участие сущности ПРЕПОДАВАТЕЛЬ в связи РУКОВОДИТ будет только частичным.
С целью повышения наглядности и удобства проектирования для представления сущностей, экземпляров сущностей и связей между ними используются следующие графические средства:
• диаграммы ER-экземпляров,
• диаграммы ER-типа, или ER-диаграммы.
Например, обсуждаемые объекты для случая связи 1:М и неполного участия в ней сущности
ПРЕПОДАВАТЕЛЬ будут выглядеть следующим образом.
Рисунок 6. Модель сущность-связь
Основные графические обозначения, применяемые в ER-диаграммах:
30
Рисунок 7. Система обозначений, принятая в ER-модели
ER-модель простейшей БД факультета университета может выглядеть
следующим образом.
Рисунок 8. Пример ER-модели
3.3 Ловушки разветвления и разрыва в ER-модели
Несмотря на универсальность и абстрактность ER-модели, ей свойственны некоторые недостатки, к которым можно отнести возможность появления
«ловушек» при недостаточном определении связей между объектами. К таким ловушкам можно отнести ловушки разветвления и разрыва.
Ловушка разветвления имеет место в том случае, если модель отображает связи между типами сущностей, но путь между отдельными сущностями
этих типов указан недостаточно однозначно. Например, ловушка разветвления может возникать, когда две и более связи
Рисунок 9а. Пример случая возникновения
ловушки разветвления
Рисунок 9б. Схема с реорганизованными
связями между типами сущностей
1:М разветвляются из одной сущности. В данном примере схема данных,
представленная на рисунке 9а, не позволяет однозначно ответить на вопрос к
каким группам относятся студенты. Устранить такую ловушку можно с помощью реорганизации связей между типами сущностей, как это показано на
рисунке 9б.
31
Ловушка разрыва появляется в том случае, когда в модели предполагается наличие связи между типами сущностей, но не существует пути между отдельными сущностями этих типов. Ловушка разрыва может возникать между
тремя и более сущностями, связанными между собой отношениями 1:М при
наличии связи с частичным: участием.
Рисунок 10а. Пример случая возникновения ловушки разрыва
Рисунок 10б. Устранение ловушки
разрыва
Из схемы видно, что на кафедре работает несколько сотрудников и за
ними закреплены определенные дипломники. Но не за каждым сотрудником
должен быть закреплен дипломник и не все дипломники должны быть закреплены за сотрудниками в данный момент времени. Такая схема не позволяет ответить на вопрос, какие дипломники числится за кафедрой. Такая ловушка устраняется введением дополнительной связи между типами сущностей.
3.4 Возможности объектно-ориентированного языка UML для проектирования БД
Язык UML (Unified Modeling Language) разработан и развивается консорциумом OMG (Object Management Group) и имеет много общего с объектными моделями, на которых основана технология распределенных объектных систем CORBA, и объектной моделью ODMG (Object Data Management
Group). UML позволяет моделировать разные виды систем, чисто программные, аппаратные, смешанные программно-аппаратные и т.д. Но, помимо прочего, язык UML активно используется в проектировании БД, для чего применяется небольшая часть языка (диаграммы классов), да и то не в полном объеме. С точки зрения проектирования реляционных БД модельные возможности UML не слишком отличаются от возможностей ER-диаграмм. Но все же
мы кратко опишем диаграммы классов UML, поскольку их пользование при
проектировании реляционных БД дает возможность оставаться общем контексте UML и применять другие виды диаграмм для проектирования приложений баз данных, выходящих за рамки реляционной модели.
Диаграммой классов в терминологии UML называется диаграмма, на которой показан набор классов (и некоторых других сущностей, не имеющих
явного отношения к проектированию БД), а также связей между этими классами. Кроме того, диаграмма классов может включать комментарии и огра32
ничения. Ограничения могут неформально задаваться на естественном языке
или же могут формулироваться на языке OCL (Object Constraints Language). К
основным понятиям диаграмм классов UML можно отнести:
• класс;
• атрибут класса;
• операция класса;
• связи.
Классом называется именованное описание совокупности объектов с
общими атрибутами, операциями, связями и семантикой. Графически класс
изображается в виде прямоугольника. У каждого класса должно иметься имя
(текстовая строка), уникально отличающее его ото всех других классов. При
формировании имен классов в UML допускается использование произвольной комбинации букв, цифр и даже знаков препинания. Однако на практике
рекомендуется использовать в качестве имен классов короткие и осмысленные прилагательные и существительные, каждое из которых начинается с заглавной буквы.
Атрибутом класса считается именованное свойство класса, описывающее множество значений, которые могут принимать экземпляры этого свойства. Класс может иметь любое число атрибутов (в частности, не иметь ни
одного атрибута). Свойство, выражаемое атрибутом, является свойством моделируемой сущности, общим для всех объектов данного класса. Таким образом, атрибутом является абстракция состояния объекта. Любой атрибут любого объекта класса должен иметь некоторое значение. Имена атрибутов
представляются в разделе класса, расположенном под именем класса. Хотя
UML не накладывает ограничений на способы формирования имен атрибутов
(имя атрибута может быть произвольной текстовой строкой), на практике рекомендуется использовать короткие прилагательные и существительные,
смысл которых соответствует смыслу соответствующего свойства класса.
Первое слово в имени атрибута рекомендуется писать с прописной буквы, а
все остальные слова – с заглавной буквы.
Операцией класса называется именованное действие, которое можно запросить для любого объекта этого класса. Операция – это абстракция возможных действий над объектами. Класс может содержать любое число операций (в частности, не содержать, ни одной). Набор операций класса является
общим для всех объектов данного класса. Операции класса определяются в
разделе, расположенном ниже раздела с атрибутами. При этом можно ограничиться только указанием имен операций, оставив более детальную спецификацию выполнения операций на поздние этапы моделирования. Для именования операций рекомендуется использовать глагольные обороты, соответствующие ожидаемому поведению объектов данного класса. Описание
операции может также содержать ее сигнатуру, т.е. имена и типы всех параметров, а если операция является функцией, то – тип ее значения. Пример
определения класса Преподаватель показан на рисунке 11.
33
Для класса Преподаватель мы определили
три операции. В операции
выдатьВозраст
используются значение
атрибута датаРождения и
Рисунок 11. Класс преподаватель
значение текущей даты.
Операция сохранитьТекущийДоход позволяет зафиксировать в состоянии
объекта сумму и дату поступления дохода данного человека. Операция выдатьОбщийДоход выдает суммарный доход данного человека за указанное
время. Заметим, что состояние объекта меняется при выполнении только
второй операции. Результаты первой и третьей операций формируется на основе текущего состояния объекта.
В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоцирование (association).
Рисунок 12.Иерархия одиночного исследования
Зависимостью называют связь, обусловленную использованием объектов одного класса для изменения в спецификации другого, ссылающегося на
первый класс. Чаще всего зависимости применяются в диаграммах классов,
чтобы отразить в сигнатуре операции одного класса то факт, что параметром
этой операции могут быть объекты другого класса. Понятно, что, если интерфейс первого класса изменяется, это влияет на поведение объектов второго класса.
34
Связью обобщением называется связь между общей сущностью, называемой суперклассом или родителем, и более специализированной разновидностью этой сущности, называемой подклассом или потомком. Обобщения
иногда называют связями «is a», имея в виду, что класс-потомок является
частным случаем класса-предка. Класс-потомок наследует все атрибуты и
операции класса-предка, но и нем могут быть определены дополнительные
атрибуты и операции. Объекты класса-потомка могут использоваться везде,
где могут использоваться объекты класса-предка. Это свойство называют полиморфизмом по включению, имея в виду, что объекты потомка можно считать включаемыми в класс-предок. Одиночное наследование является достаточным в большинстве практических случаев применения связи-обобщения.
Однако в UML допускается и множественное наследование, когда один подкласс определяется на основе нескольких суперклассов.
Ассоциацией называется структурная связь, показывающая, что объекты
одного класса некоторым образом связаны с объектами другого или того же
самого класса. В ассоциации могут связываться два класса, и тогда она называется бинарной. Допускается создание ассоциаций, связывающих сразу n
классов (они называются n-арными ассоциациями) – аналогия показателя арности связи в ER-модели.
Рисунок 13. Ассоциации
С понятием ассоциации связаны четыре важных дополнительных понятия: имя, роль, кратность и агрегация. Ассоциации может быть присвоено
имя, характеризующее природу связи, например, Студент учится в Университете.
Роль класса может пояснять сторону объекта, задействованную в данной
связи, например, Университет по отношению к Преподавателю, является
НАНИМАТЕЛЕМ, а для Студента – ОБУЧАЮЩИМ.
Понятие кратности имеет много общего с кардинальностью связи в ERмодели, однако, в UML более широко представлены способы задания возможных диапазонов количества участвующих в связи объектов классов с одной и другой стороны.
Обычная ассоциация между двумя классами характеризует связь между
равноправными сущностями: оба класса находятся на одном концептуальном
уровне. Иногда в диаграмме классов требуется отразить тот факт, что ассоциация между двумя классами имеет специальный вид «часть-целое». В этом
случае класс «целое» имеет более высокий концептуальный уровень, чем
класс «часть». Ассоциация такого рода называется агрегатной.
35
Таким образом, можно заключить, что функциональные возможности
применения языка UML для концептуального проектирования БД значительно расширены по сравнению с ER-моделью за счет широкого набора объектно-ориентированных подходов представления информации. Однако, при
этом приходится констатировать, что схема данных при этом значительно
усложняется и, как правило, не может быть реализована в рамках стандартных платформ, не основанных на UML. Этот факт значительно снижает универсальность процедуры семантического моделирования с применением
средств UML, при этом, оставляя ее мощнейшим инструментом реализации
информационных систем.
3.5 Критерии выбора модели данных
В рамках настоящего раздела были рассмотрены несколько дореляционных моделей данных, а также два семантических подхода к моделированию
концептуальной схемы данных. На основании приведенного анализа можно
заключить, что все рассмотренные методы обладают своими преимуществами и недостатками и могут быть применены для решения определенных
практических задач. Однако открытым остается вопрос эффективности применения того или иного способа для реализации конкретной БД. Попытаемся
сформулировать базовые критерии выбора модели для некоторого приложения. Итак, применяемая модель данных должна обеспечивать следующие характеристики:
• внутренняя логичность и легкость восприятия. Разработанная схема
данных должна иметь четкую логическую структуру для облегчения восприятия ее персоналом, принимающим участие, как в процессе разработки БД,
так и во время отладки и сопровождения;
• достаточная полнота базиса. Подход должен обладать достаточным
количеством логических концептов для выражения сущностей, атрибутов,
связей и ограничений моделируемых объектов, обеспечивая при этом минимальность набора не перекрывающихся элементов;
• эвристический потенциал. Схема данных должна допускать возможность дальнейшего усовершенствования, как путем внутренних изменений в
БД, так и интеграции ее в более крупные логические структуры.
• формализуемость. Для организации эффективной манипуляционной
части БД желательно применение универсальных программных средств
(например, в виде высокоуровневых языков программирования), что, в свою
очередь, влечет за собой требование возможности приведения концептуальной схемы данных к набору математических, семантических или пр. формализмов, используемых конкретным языком (SQL, UML);
• наглядность. Безусловно, положительной чертой модели данных является присутствие возможностей для выразительного графического ее представления.
Всеми этими преимуществами обладает реляционная модель данных
(РМД), в рамках которой в настоящее время реализовано большинство хра36
нилищ данных. Основные положения и подходы этой модели данных подробно изложены в следующей части пособия.
ЧАСТЬ II. ОРГАНИЗАЦИЯ РЕЛЯЦИОННЫХ БД
Данная часть учебного пособия посвящена детальному рассмотрению
реляционной модели данных как наиболее распространенной технологии
хранения данных. Вводятся понятия реляционной алгебры и реляционного
исчисления – основных средств манипулирования РБД. Подробно обсуждаются критерии соответствия реляционной структуре данных.
Тема 4. Реляционная модель данных
4.1 Основные понятия реляционной модели данных
Основными понятиями реляционных БД являются тип данных, домен, отношение, схема отношения, атрибут, кортеж, первичный ключ, внешний
ключ. Наглядно смысл этих терминов можно пояснить на примере отношения
СТУДЕНТЫ, содержащего информацию об учащихся некоторого ВУЗа
(рис.14).
Рисунок 14. Соотношение основных понятий реляционного подхода
Понятие типа данных в РМД полностью адекватно понятию типа данных в языках программирования. Напомним, что традиционное (нестрогое)
определение типа данных состоит из трех основных компонентов: определение множества значений данного типа; определение набора операций, применимых к значениям типа; определение способа внешнего представления
значений типа (литералов). Обычно в современных реляционных базах дан37
ных допускается хранение символьных, числовых данных, битовых строк,
специализированных числовых данных (таких как «деньги»), а также специальных «темпоральных» переменных (дата, время, временной интервал). Достаточно активно развивается подход к внедрению в реляционные системы
возможностей определения пользователями собственных типов данных.
Понятие домена эквивалентно рассматривавшемуся ранее в рамках
определения моделей данных.
Схема отношения – это именованное множество упорядоченных пар
<имя_атрибута, имя_домена>, относящихся к одному объекту (или
<имя_атрибута, имя_ типа_данных>, если понятие домена не поддерживается). По определению степенью или. «арностью» схемы отношения является
мощность этого множества. Например, степень отношения СТУДЕНТЫ равна четырем, то есть оно является 4арным. Графически схему отношения принято представлять следующим образом (см. рис. 15):
Кортеж,
соответствующий
данной схеме отношения, – это
множество упорядоченных пар
<имя_атрибута, значение>, которое содержит одно вхождение кажРисунок 15. Класс студенты
дого имени атрибута, принадлежащего схеме отношения. Значение атрибута должно соответствовать интервалу допустимых значений домена (или типа данных, если понятие домена не
поддерживается), на котором определен данный атрибут. Тем самым, степень или «арность» кортежа, т.е. его мощность, или число элементов в нем,
совпадает с «арностью» соответствующей схемы отношения. Попросту говоря, кортеж — это набор именованных значений заданных доменов или типов,
соответствующий схеме отношения.
Отношение — это множество кортежей, соответствующих одной схеме
отношения. Иногда, чтобы не путаться, говорят про «отношение-схему» - заголовок отношения (метаданные) и «отношение-экземпляр» - тело отношения (данные).
По определению, первичным ключом отношения является непустое подмножество o множества атрибутов O его схемы такое, что в любое время
значение первичного ключа (составное, если в состав первичного ключа входит более одного атрибута) в любом кортеже тела отношения отличается от
значения первичного ключа в любом другом кортеже тела этого отношения, а
никакое собственное подмножество o, таким свойством не обладает. Первичный ключ в схеме отношения обычно следует первым и графически выделяется (см. рис.)
Внешний ключ – это атрибут отношения (или несколько атрибутов в случае составного внешнего ключа), значения которого однозначно характеризуют кортежи некоторого другого отношения. Основным назначением внеш38
него ключа является организация связей между отношениями, разговор о которых пойдет далее.
Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками – кортежи отношения-экземпляра; в этом случае атрибуты именуют столбцы этой таблицы.
Поэтому иногда говорят про «столбцы таблицы», имея в виду «атрибуты отношения». Конечно, это достаточно грубая терминология, поскольку у обычных таблиц и строки, и столбцы упорядочены, тогда как атрибуты и кортежи
отношений являются элементами неупорядоченных множеств.
Остановимся теперь на некоторых важных свойствах отношений, которые следуют из приведенных ранее определений.
Отсутствие кортежей-дубликатов.
Свойство отсутствия кортежей-дубликатов в теле любого отношения
следует из определения тела отношения как множества кортежей. Согласно
классической теории множеств, любое множество по определению состоит
из различных элементов. Именно из этого свойства вытекает наличие у каждого отношения первичного ключа – минимального набора атрибутов, составное значение которых уникально определяет кортеж отношения. Действительно, поскольку в любое время все кортежи тела любого отношения
различны, у любого отношения свойством уникальности обладает, по крайней мере, полный набор его атрибутов. Однако при формальном определении
первичного ключа требуется обеспечение его «минимальности», т.е. в набор
атрибутов первичного ключа не должны входить такие атрибуты, которые
можно отбросить без ущерба для основного свойства – однозначного определения кортежа.
Заметим, что хотя формально существование первичного ключа отношения является следствием того, что тело отношения – это множество, на практике первичные (и возможные) ключи появляются в результате явных указаний проектировщика отношения. Определяя схему отношения, проектировщик моделирует часть предметной области, данные из которой будет в будущем содержать база данных. И конечно, проектировщик должен знать
природу этих данных. Например, ему должно быть известно, что никакие два
студента ни в какой момент времени не могут иметь удостоверение с одним и
тем же номером. Поэтому он может явно объявить атрибут {СТУД_НОМЕР}
возможным ключом. Однако, если в ВУЗе установлено, что у всех учащихся
должны быть разные полные имена, то проектировщик может объявить возможным ключом и {СТУД_ИМЯ}. Затем проектировщик должен оценить, какой из возможных ключей является более надежным (свойство его уникальности никогда не будет отменено) и выбрать наиболее надежный возможный
ключ в качестве первичного. В нашем случае естественным выбором был бы
ключ {СТУД_НОМЕР}, потому что решение об уникальности полных имен
сотрудников выглядит искусственным и странным, и руководство в дальнейшем может легко его отменить.
39
Отсутствие упорядоченности кортежей
Формально свойство отсутствия упорядоченности кортежей отношения
также является следствием определения отношения-экземпляра как множества кортежей. Это облегчает построение полного манипуляционного механизма реляционной модели данных, включая базовые средства манипулирования данными – реляционные алгебру и исчисление.
Однако на это свойство можно взглянуть и с другой стороны. Достаточно часто у пользователей реляционных БД и разработчиков информационных
систем вызывает раздражение тот факт, что они не могут хранить кортежи
отношений на физическом уровне в нужном им порядке. И ссылки на требования реляционной теории здесь не очень уместны. Можно было бы разработать другую теорию, в которой допускались бы упорядоченные отношения.
Однако хранить упорядоченные списки кортежей в условиях интенсивно обновляемой базы данных гораздо сложнее технически, и даже сама поддержка
упорядоченности вызывает серьезные накладные расходы. Отсутствие требования к поддержанию порядка на множестве кортежей отношения придает
БД дополнительную гибкость при хранении баз данных во внешней памяти и
при выполнении запросов к базе данных.
Отсутствие упорядоченности атрибутов.
Атрибуты отношений не упорядочены, поскольку по определению схема
отношения есть множество пар <имя атрибута, имя домена>. Данное свойство позволяет организовывать наиболее эффективное хранение данных на
физическом носителе, так же обеспечивает гибкость схемы отношения при
ее модификации.
Атомарность значений атрибутов.
Значения всех атрибутов являются атомарными. Это следует из определения домена как потенциального множества значений простого типа данных, т.е. среди значений домена не могут содержаться множества значений
(отношения). Принято говорить, что в реляционных базах данных допускаются только нормализованные отношения, которые более подробно будут
рассмотрены далее. Нормализованные отношения составляют основу классического реляционного подхода к организации баз данных. Они обладают некоторыми ограничениями (не любую информацию удобно представлять в
виде плоских таблиц), но существенно упрощают процедуры манипулирования данными.
4.2 Организация связей между отношениями
Согласно рассмотренным ранее (в теме 2) типам связей между объектами, в РМД также можно выделить две классификации связей: арность и кардинальность.
По количеству отношений, входящих в связь можно выделить унарные,
бинарные, тернарные и связи более высоких порядков. Исходя из тех же
предпосылок (тема 2), унарная (рекурсивная) и связи с порядком выше двух
40
практически не используются. Для описания схемы РБД применяются бинарные связи (связь между двумя отношениями).
Понятие кардинальности связи также весьма близко к обсуждавшемуся
во 2 теме. В РМД принято выделять следующие типы связей: «многие ко
многим», «один ко многим», «многие к одному», «один к одному».
1. «один к одному»
Означает, что одному кортежу отношения А соответствует один и только один кортеж отношения В, находящегося с ним в связи. На практике такой тип связи встречается достаточно редко, поскольку в этом случае связываемые отношения можно объединить в одно. Использование этого типа связи в реальных БД, как правило, связано с искусственными требованиями к ее
структуре, например, необходимость хранить в одной БД открытые и конфиденциальные сведения об объекте – тогда, мы получаем два объекта, содержащие разные наборы атрибутов, но относящееся, по сути, к одному. В реализации этого типа связи в обоих отношениях участвуют уникальные ключи
(см. рис. 16)
Рисунок 16. Связь «один к одному»
2. «один ко многим», «многие к одному»
Согласно ранее обсуждавшимся особенностям этих типов связей, нет
необходимости рассматривать их раздельно. В соответствии с определением,
тип связи «один ко многим» означает, что одному кортежу отношения А
ставится в соответствие несколько кортежей отношения В (и наоборот для
связи «многие к одному»). На практике данный тип связи обеспечивается
установлением соответствия между уникальным ключом одного отношения и
внешним ключом другого. При этом первое отношение является родительским (соответственно, второе – дочерним) по отношению к другому, т.е. одно отношение оказывается подчиненным другому. На рис. 17 приведен пример организации связи «один ко многим» между отношениями КАФЕДРА и
СТУДЕНТЫ. Означает, что одному кортежу отношения А может соответствовать несколько кортежей отношения В и, наоборот, каждому кортежу
отношения В ставится в соответствие несколько кортежей отношения А.
Номинально данный тип связи реализуется установлением соответствия
между внешними ключами отношений (см. рис.18а).
41
Рисунок 17. Связь «один ко многим»
3. «многие ко многим»
Рисунок 18а. Связь «многие ко многим»
Однако на практике такой порядок связи затрудняет контроль целостности БД, поэтому большинство реляционных СУБД для реализации связи
«многие ко многим» рекомендуют применять промежуточную таблицу, связанную с начальными посредством связей «один ко многим» (например см.
рис. 18б). Также в полной аналогии с темой 2 можно ввести понятие зависимости между атрибутами отношения.
Рисунок 18б. Реализация связи «многие ко многим» в РСУБД
4.3 Средства манипулирования отношениями
В реляционной модели данных определены два базовых механизма манипулирования данными, содержащимися в отношениях – основанная на
42
теории множеств реляционная алгебра и базирующееся на математической
логике (точнее, на исчислении предикатов первого порядка) реляционное исчисление. В свою очередь, обычно выделяют два вида реляционного исчисления – исчисление кортежей и исчисление доменов.
Все эти механизмы обладают одним важным свойством: они замкнуты
относительно понятия отношения. Другими словами, выражения реляционной алгебры и формулы реляционного исчисления определены над отношениями реляционных БД, и результатом их выполнения также являются отношения. Т.е. операторы, разрешенные в реляционной алгебре и реляционном
исчислении, не выводят элементы множества отношений за рамки этого математического формализма.
Реляционные алгебра и исчисление обладают большой выразительной
мощностью: даже достаточно сложные запросы к БД могут быть выражены с
помощью одного выражения реляционной алгебры или одной формулы реляционного исчисления.
Известно, что механизмы реляционной алгебры и реляционного исчисления эквивалентны, т.е. для любого допустимого выражения реляционной
алгебры можно построить равносильную формулу реляционного исчисления
и наоборот. Различаются эти подходы уровнем процедурности. Выражения
реляционной алгебры строятся на основе особых алгебраических операций и
подобно тому, как интерпретируются арифметические и логические выражения для скалярных вычислений, выражение реляционной алгебры также имеет процедурную реализацию. Другими словами, запрос, представленный на
языке реляционной алгебры, может быть выполнен на основе последовательного вычисления особых алгебраических операций с учетом их приоритетности. Для формул реляционного исчисления однозначная вычислительная интерпретация, вообще говоря, отсутствует. Формула только ставит условия,
которым должны удовлетворять кортежи результирующего отношения. Поэтому языки реляционного исчисления считаются непроцедурными или декларативными.
Конкретный язык манипулирования реляционными БД называется реляционно полным, если любой запрос, выражаемый с помощью одного выражения реляционной алгебры или одной формулы реляционного исчисления,
может быть выражен с помощью одного оператора этого языка. Поскольку
механизмы реляционной алгебры и реляционного исчисления эквивалентны,
то в конкретной ситуации для проверки степени реляционности некоторого
языка БД можно пользоваться любым из этих механизмов. В качестве примера такого языка может рассматриваться SQL.
4.4 Реляционная алгебра
Поскольку отношения являются множествами (строгий математический
формализм), то средства манипулирования отношениями могут базироваться
на традиционных теоретико-множественных операциях, дополненных некоторыми специальными операциями, свойственными для РМД.
43
Существует несколько подходов к определению реляционной алгебры,
которые различаются наборами операций и способами их интерпретации, но
все они, в принципе, являются эквивалентными. В данном разделе будет описан расширенный начальный вариант алгебры, который был предложен Коддом (E.F. Codd) в 70-х годах XX века. В этом варианте набор основных алгебраических операций состоит из восьми операций, которые делятся на два
класса – теоретико-множественные операции и специальные реляционные
операции.
В состав теоретико-множественных входят следующие операции:
• объединения отношений (UNION).
При выполнении операции объединения двух отношений производится
отношение, включающее все кортежи, входящие хотя бы в одно из отношений-операндов. Смысл операции объединения в реляционной алгебре в целом остается теоретико-множественным, однако, если в теории множеств
операция объединения определена для любых двух множеств-операндов, то в
случае реляционной алгебры результатом операции объединения должно
быть отношение (чтобы удовлетворять свойству замкнутости). Если допустить в реляционной алгебре возможность объединения двух произвольных
отношений (с разными схемами), то, результатом операции будет множество
разнотипных кортежей, не удовлетворяющее определению отношения. Поэтому для корректного выполнения данного оператора мы должны требовать
совместимости, т.е. наличия одинаковых схем объединяемых отношений,
т.е. A{a1, a2,… an} и B{a1, a2,… an} . Тогда для совместимых отношений A с
кортежами <v1, v2, v3, v4, v5> и B с кортежами <v3, v4, v5, v6, v7> можно записать:
A<v1, v2, v3, v4, v5> UNION B <v3, v4, v5, v6, v7>=C< v1, v2, v3, v4, v5, v6, v7>
Указанное ограничение совместимости отношений-операндов должно
выполняться и для следующих двух операторов реляционной алгебры: пересечения и разности отношений.
• пересечение отношений (INTERSECT).
Операция пересечения двух отношений производит отношение, включающее все кортежи, входящие в оба отношения-операнда. Согласно обозначениям предыдущего примера:
A<v1, v2, v3, v4, v5> INTERSECT B <v3, v4, v5, v6, v7>=C<v3, v4, v5>
• взятия разности отношений (MINUS).
Отношение, являющееся разностью двух отношений включает все кортежи, входящие в отношение - первый операнд, такие, что ни один из них не
входит в отношение, являющееся вторым операндом. Т.е.:
A<v1, v2, v3, v4, v5> MINUS B <v3, v4, v5, v6, v7>=C< v1, v2>
• взятия декартова произведения отношений (TIMES).
В результате декартова (прямого) произведения появляется отношение,
кортежи которого являются конкатенацией (сцеплением) кортежей первого и
второго операндов. В этом случае, опять же из соображений замкнутости
операций реляционной алгебры, мы должны требовать совместимости опе44
рандов по произведению, которая, на этот раз, включает в себя условие полной несовместимости схем перемножаемых отношений т.е. A{a1, a2,… an} и
B{b1, b2,… bn}, причем aj ≠bi для любых i,j. Тогда для двух отношений со своими наборами кортежей A<v1, v2, v3, v4, v5> и B <w1, w2, w3, w4, w5> получим
отношение, содержащее всевозможные варианты сцепления кортежей:
A<v1, v2, v3, v4, v5> TIMES B <w1, w2, w3, w4, w5> = C<v1w1…v1w5, v2w1
…v2w5, …v5w1…v5w5>
Специальные реляционные операции включают:
• ограничение отношения (WHERE).
Результатом ограничения (селекции) отношения по некоторому условию
является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому условию. На интуитивном уровне операцию ограничения
можно представить как своеобразную «горизонтальную вырезку» из тела отношения-операнда или выделения нескольких строк из таблицы.
Рисунок 19а. Пример ограничения
• проекцию отношения (PROJECT).
При выполнении проекции отношения на заданный набор его атрибутов
производится отношение, кортежи которого содержат значения только заданного набора атрибутов, т.е.
B{b1, b2, b3, b4, b5} PROJECT {b3, b4,}=B’{b3, b4,}.
Продолжая аналогию предыдущего примера, эта операция напоминает
«вертикальную вырезку» по всем значениям определенного атрибута или
выделение столбцов таблицы.
Рисунок 19б. Пример проекции
• соединение отношений (JOIN).
При соединении двух отношений по некоторому условию образуется результирующее отношение, кортежи которого являются конкатенацией кортежей первого и второго отношений и удовлетворяют этому условию.
• деление отношений (DIVIDE BY).
Эта операция наименее очевидна из всех операций реляционной алгебры
Кодда и поэтому нуждается в более подробном объяснении. Пусть заданы
45
два отношения - A{а1, а2,… аn, b1, b2… bm} и B{b1, b2… bm}. Будем считать, что
атрибут bi (i= 1, 2,...., m) отношения А и атрибут bi отношения B не только
обладают одним и тем же именем, но и определены на одном и том же домене. Назовем множество атрибутов {аi} составным атрибутом а, а множество атрибутов {bi} – составным атрибутом b. После этого будем говорить о
реляционном делении бинарного отношения А {а, b} на унарное отношение
B{b}.
Результатом деления А на В является унарное отношение С{а}, тело которого состоит из кортежей v таких, что в теле отношения А содержатся кортежи <v,w> и множество кортежей <w> включает множество значений атрибута b в отношении В.
Кроме того, в состав алгебры включается операция присваивания (:=),
позволяющая сохранить в базе данных результаты вычисления алгебраических выражений, и операция переименования атрибутов (RENAME), дающая
возможность корректно сформировать заголовок (схему) результирующего
отношения.
Из всех рассмотренных восьми операций только пять являются базовыми: селекция, проекция, декартово произведение, объединение и разность.
Остальные три операции могут быть определены через первые пять.
4.5 Реляционное исчисление
Реляционное исчисление является прикладной ветвью формального механизма исчисления предикатов первого порядка. В его основе находятся понятие переменной с определенной для нее областью допустимых значений и
понятие правильно построенной формулы, опирающейся на переменные,
предикаты и кванторы.
В зависимости от того, что является областью определения переменной
различаются исчисление кортежей и исчисление доменов. В исчислении кортежей областями определения переменных являются тела отношений базы
данных, т.е. допустимым значением каждой переменной является кортеж некоторого отношения. В исчислении доменов областями определения переменных являются домены, на которых определены атрибуты отношений БД,
т.е. допустимым значением каждой переменной является значение некоторого домена.
При построении формулы реляционного исчисления указывается лишь
характеристики результирующего отношения, но ничего не говорится о способе его формирования. В этом случае система должна сама решить, какие
операции и в каком порядке нужно выполнить над отношениями. Как мы уже
указывали в лекции, реляционные алгебра и исчисление эквивалентны и существуют не очень сложные правила преобразования одного формализма в
другой. Конкретные примеры построения формул реляционного исчисления
будут даны в IV части пособия при рассмотрении языка запросов SQL.
46
Тема 5. Критерии РМД
5.1 Ограничения организации данных в РМД
После того, как мы при рассмотрении предыдущей темы определили содержательную и манипуляционную части РМД, логически встает вопрос о
том, какими свойствами должна обладать конкретная структура данных для
того, чтобы соответствовать РМД. В теории БД процесс последовательного
приближения исходной структуры данных к реляционной называется нормализацией схем отношений. Наглядно его можно представить как пошаговое
удовлетворение требований нормальных форм, причем каждая последующая
нормальная форма обладает свойствами, в некотором смысле лучшими, чем
предыдущие, и при переходе к следующей нормальной форме свойства
предыдущих нормальных форм сохраняются.
В теории реляционных баз данных обычно выделяют следующую последовательность нормальных форм:
-первая нормальная форма (1NF);
-вторая нормальная форма (2NF);
-третья нормальная форма (3NF);
-нормальная форма Бойса-Кодда (BCNF);
-четвертая нормальная форма (4NF);
-пятая нормальная форма, или нормальная форма проекции-соединения
(5NF или PJ/NF).
В основе процесса нормализации лежит метод декомпозиции отношения,
находящегося в предыдущей нормальной форме, в два или более отношения,
удовлетворяющих требованиям следующей нормальной формы.
Процесс нормализации структуры данных позволяет решить вопрос о
наиболее эффективной их организации, обладающей минимальной избыточностью. Наличие повторяющейся информации приводит к возможной потере
согласованности данных, что проявляется в появлении аномалий обновлений
и неоправданном раздувании размера БД.
Аномалии обновления можно разделить на три разновидности:
- Аномалии добавления. Возникают в случаях, когда информацию в таблицу нельзя поместить до тех пор, пока она не полная. Например, мы хотели
бы добавить информацию о поступившем в ВУЗ студенте. При этом нам
придется оставить незаполненной часть кортежа, касающуюся его успеваемости. Но если некоторые поля были объявлены обязательными (например,
средний балл), то либо в них придется ввести что-нибудь номинальное, либо
вообще отказаться от записи.
- Аномалии удаления. Состоят в том, что при удалении некоторой информации могут исчезнуть данные, не связанные напрямую с удаляемыми.
Например, при изъятии последней записи о продаже некоторого товара све47
дения о нем могут быть утеряны, хотя это никак не будет означать, что данного вида товара нет в наличии.
- Аномалии модификации. Появляются в случае, когда изменение значения некоторого атрибута в одном кортеже может привести к просмотру всего
отношения и последующему обновлению других его кортежей. Например,
такая аномалия может возникнуть при изменении не всех кортежей, относящихся к одному студенту при смене его адреса, фамилии и пр.
5.2 Нормальные формы РМД
Итак, рассмотрим требования нормальных форм.
Первая нормальная форма (1NF)
Условия первой нормальной формы:
1. Отсутствие кортежей-дубликатов.
2. Атомарность атрибутов.
Первое требование достаточно просто удовлетворяется назначением
ключевого атрибута, однозначно определяющего остальные атрибуты отношения. В предыдущей теме мы вскользь коснулись этого вопроса при рассмотрении понятия первичного ключа. Необходимо осознавать, что выбор некоторого атрибута на роль ключевого – процедура, имманентная для каждой
конкретной предметной области и схемы отношения. В качестве ключевого
можно использовать один из атрибутов отношения (или несколько атрибутов
в случае составного ключа). В некоторых случаях более уместно ввести дополнительный идентификационный атрибут.
Для примера рассмотрим отношение, описывающее человека для какойлибо отрасли деятельности. Кортеж подобного отношения, помимо профессиональной информации, обязательно будет содержать личные данные о
имени, номере и серии паспорта, номере социального страхования и пр. Из
общих соображений понятно, что именно эта часть кортежа может наиболее
вероятно рассматриваться на роль поставщика ключевого атрибута. При
этом очевидно, что полное имя для однозначной идентификации экземпляра
человека не пригодно. Далее, можно рассмотреть номер и серию паспорта –
при всей кажущейся привлекательности этих атрибутов для роли составного
ключа, присутствуют, как минимум, два недостатка: во-первых, паспорт может быть заменен при достижении определенного возраста или смене фамилии, а, во-вторых, использование составных ключей затрудняет индексацию
данных и увеличивает время выполнения манипуляций над кортежами (поскольку во всех связанных таблицах эти составные значения придется повторять). Остается номер социального страхования. В существующих условиях
учета государством отдельных граждан он оказывается наиболее подходящим для роли уникального ключа. Основным недостатком является его форма
представления – символьная строка, что также отрицательно влияет на скорость выполнения запросов. Оптимальным ключом отношения является положительное целочисленное значение, чем, как правило, и являются табельные номера различных организаций. Таким образом, в данном конкретном
48
случае существует два решения: либо использовать имеющийся атрибут (номер соц. страхования), либо ввести дополнительный целочисленный идентификационный атрибут.
Второе требование постулирует, чтобы значение каждого атрибута было
представлено в виде неделимого элемента данных. Соответственно, составные атрибуты должны быть разделены на простые, а многозначные – вынесены в отдельные отношения. Для примера, атрибут АДРЕС должен быть
разделен на простые атрибуты СТРАНА, ГОРОД, УЛИЦА, ДОМ. Атрибут
ТЕЛЕФОН может являться многозначным и, в таком случае, должен быть
выделен в отдельное связанное отношение.
Вторая нормальная форма (2NF)
Требования второй нормальной формы:
1. Отношение находится в первой нормальной форме.
2. Каждый неключевой атрибут минимально функционально зависит от
первичного ключа.
Проще говоря, вторая нормальная форма требует от отношения, чтобы
его схема содержала только характерные для него атрибуты. Например, для
предметной области, представляющей собой, кафедру ВУЗа могут быть
свойственны следующие атрибуты СТУД_ИМЯ, СТУД_ФАМ, СТУД_ОТЧ,
СР_БАЛЛ, НОМ_ЗАЧЕТКИ, ПРЕПОД_ИМЯ, ПРЕПОД_ФАМ, ПРЕПОД_ОТЧ, ПРЕПОД_ЗАРПЛ, НОМ_УДОСТ. Очевидно, что атрибуты
СТУД_ИМЯ, СТУД_ФАМ, СТУД_ОТЧ, СР_БАЛЛ находятся в функциональной зависимости от атрибута НОМ_ЗАЧЕТКИ (который логично назначить
ключевым). В свою очередь атрибуты ПРЕПОД_ИМЯ, ПРЕПОД_ФАМ,
ПРЕПОД_ОТЧ, ПРЕПОД_ЗАРПЛ, функционально зависят от потенциального ключа НОМ_УДОСТ. Условия второй нормальной формы требуют в этом
случае разделения (декомпозиции) первоначальной совокупности атрибутов
на два отношения СТУДЕНТЫ {СТУД_ИМЯ, СТУД_ФАМ, СТУД_ОТЧ,
СР_БАЛЛ, НОМ_ЗАЧЕТКИ} и ПРЕПОДАВАТЕЛИ {ПРЕПОД_ИМЯ, ПРЕПОД_ФАМ, ПРЕПОД_ОТЧ, ПРЕПОД_ЗАРПЛ, НОМ_УДОСТ}, где жирным
шрифтом обозначены ключевые атрибуты.
Третья нормальная форма (3NF)
Критерии третьей нормальной формы:
1. Отношение находится во второй нормальной форме.
2. Каждый неключевой атрибут нетранзитивно зависит от первичного
ключа.
Сведение отношения к третьей нормальной форме предполагает его декомпозицию с целью помещения в отдельное отношение (или несколько отношений) атрибутов, которые не зависят напрямую от первичного ключа, но
находятся в транзитивной зависимости от него. В результате такого разделения каждый из атрибутов, не входящих в первичный ключ, должен оказаться
независимым от любого другого неключевого атрибута этого отношения.
49
Третья нормальная форма также постулирует отсутствие полей, которые могут быть вычислены на основе других.
Пример возможной транзитивной зависимости между атрибутами был
нами рассмотрен в теме 2 (на примере НОМ_ЗАЧЕТКИ→ СР_БАЛЛ→
СТУД_СТИП). В данном случае критерии третьей нормальной формы требуют выведения атрибута СТУД_СТИП из отношения СТУДЕНТЫ и помещения его в другое отношение, где будет установлена связь между средним
баллом и размером стипендии.
Нормальная форма Бойса-Кодда (BCNF)
До сих пор в определениях нормальных форм мы предполагали, что у
декомпозируемого отношения имеется простой уникальный ключ, и на практике чаще всего бывает именно так. Но имеется один частный случай, который (почти) удовлетворяет требованиям 2NF и 3NF, но, тем не менее, порождает аномалии обновления. Этот тот случай, когда у отношения имеется составной ключевой атрибут, и присутствует функциональная зависимость части составного ключа от неключевого атрибута. Т.е. пусть некоторое отношение содержит свой набор атрибутов A{a,b,c}, при этом {a,b} – составной
ключ отношения A. Может возникнуть ситуация, когда {a,b}→с и одновременно с→b.
В качестве примера можно привести следующую ситуацию. Пусть каждый отдел организации имеет свою табельную нумерацию сотрудников. В
каждом отделе выполняется несколько своих проектов, но каждый сотрудник
может участвовать только в одном. Для описания подобной предметной области можно использовать отношение СОТРУДНИКИ {ТАБ_НОМЕР;
ОТД_НОМЕР; КОД_ПРОЕКТА}. При этом в качестве уникального ключа в
данном случае мы вынуждены объявить составной атрибут {ТАБ_НОМЕР;
ОТД_НОМЕР}. И действительно, эта пара значений однозначно идентифицирует как сотрудника, так и код проекта в котором занят сотрудник, т.е.
{ТАБ_НОМЕР; ОТД_НОМЕР}→КОД_ПРОЕКТА. Однако, поскольку каждый
отдел разрабатывает только свои проекты, по коду проекта можно однозначно установить номер отдела: КОД_ПРОЕКТА→ОТД_НОМЕР. В данном случае рекомендуется продолжать декомпозицию отношения.
Итак, можно сформулировать, следующие ограничения, накладываемые
нормальной формой Бойса-Кодда:
1. Отношение находится в третьей нормальной форме.
2. Отсутствуют зависимости атрибутов составного ключа от неключевых атрибутов.
На этом процесс нормализации обычно заканчивается. Если же необходима более детальная проработка данных, то дополнительно рассматривают
требования нормальных форм более высокого порядка.
50
Четвертая нормальная форма (4NF)
Четвертая нормальная форма требует вырождения всех многозначных
зависимостей в функциональные (наряду с условиями BCNF).
В случае возникновения многозначных зависимостей между атрибутами
отношения необходимо прибегнуть к дальнейшей декомпозиции отношения
для уменьшения избыточности информации и устранения возможности появления несогласованного состояния данных.
Пятая нормальная форма, или нормальная форма проекции-соединения
(5NF или PJ/NF)
Пятая нормальная форма основывается на концепции устранения зависимостей объединения. Возможна ситуация, когда нельзя произвести декомпозицию отношения на два таким образом, чтобы получить эквивалентное
решение (некоторые кортежи могут оказаться утерянными или, наоборот,
проявляются ранее не существовавшие). Однако, при этом, для выполнения
требований нормализации это отношение можно разделить на три и более
связанных отношений, равносильных начальному. На практике такую ситуацию очень трудно априорно обнаружить и, следовательно, заранее устранить.
5.3 Пример нормализации отношений
В качестве примера нормализации отношений рассмотрим неоднократно
нами использовавшуюся предметную область, соответствующую учебной
кафедре ВУЗа. Выберем свойственные ей атрибуты, достаточные для описания учебного процесса: КАФЕДРА {НОМ_УДОСТ, ФИО_ПРЕП,
СПЕЦ_КУРС,
КУРАТОР_ГРУППЫ,
НОМ_ЗАЧЕТКИ,
ФИО_СТУД,
СР_БАЛЛ, НОМ_ГРУППЫ, ФАМ_КУРАТОРА}. Итак, на кафедре работают
преподаватели, которые имеют удостоверения с уникальными номерами.
Преподаватели обеспечивают обучение в рамках читаемых спецкурсов, а
также некоторые из них являются кураторами учебных групп. Кроме того, на
кафедре проходят обучение студенты определенных учебных групп, для которых читаются кафедральные спецкурсы и над которыми осуществляется
кураторство. Учащиеся однозначно идентифицируются номером зачетки, а
также имеют средний балл.
Приступим к нормализации. Требования 1NF подразумевают атомарность атрибутов и отсутствие дублирования информации в кортежах. Для
удовлетворения первого условия необходимо состоящие из нескольких слов
сложные атрибуты ФИО_ПРЕП и ФИО_СТУД разложить на более простые
ФАМ_ПРЕП, ИМЯ_ПРЕП, ОТЧ_ПРЕП и ФАМ_СТУД, ИМЯ_СТУД,
ОТЧ_СТУД. Выполнить второе требование можно, назначив первичный ключ
этого отношения. На его роль, казалось бы, может рассматриваться
НОМ_ЗАЧЕТКИ, однако, поскольку студент может посещать несколько
спецкурсов, атрибут СПЕЦ_КУРС окажется многозначным, что недопустимо. Поэтому мы вынуждены предварительно ввести положительно определенный идентификационный атрибут НОМ_ЗАПИСИ, который позволит нам
51
пронумеровать все возможные комбинации значений атрибутов, сложившиеся на кафедре. Таким образом, схема рассматриваемого отношения в первой
нормальной форме может
быть представлена следующим образом (рис.20)
Для трансформации отношения в 2NF, необходимо
обеспечить
минимальную
функциональную
зависимость неключевых атрибутов
от первичного ключа. Для
этого мы должны выделить
несколько отношений, в рамках которых это требование
будет выполняться. Наиболее
логичным видится декомпозиция начального отношения на два ПРЕПОДАВАТЕЛИ {НОМ_УДОСТ,
ФАМ_ПРЕП, ИМЯ_ПРЕП, ОТЧ_ПРЕП, СПЕЦ_КУРС, КУРАТОР_ГРУППЫ}
и СТУДЕНТЫ {НОМ_ЗАЧЕТКИ, ФАМ_СТУД, ИМЯ_СТУД, ОТЧ_СТУД,
СР_БАЛЛ, НОМ_ГРУППЫ, ФАМ_КУРАТОРА}. Необходимость в старом
ключе НОМ_ЗАПИСИ отпадает, поскольку новые первичные ключи однозначно идентифицируют кортежи, однако, если есть возможность, что один
преподаватель читает несколько спецкурсов, атрибут СПЕЦ_КУРС в отношении ПРЕПОДАВАТЕЛИ опять таки оказывается многозначным, поэтому
нам необходимо еще одно отношение, описывающее расписание. Для него
можно предложить следующую схему: РАСПИСАНИЕ {КОД_ПРЕДМЕТА,
СПЕЦ_КУРС, НОМ_УДОСТ, НОМ_ГРУППЫ}. Тогда схема БД будет выглядеть следующим образом (см. рис 21). Теперь все требования 2NF удовлетворены, однако, забегая немного вперед, стоит отметить, что между отношениями СТУДЕНТЫ и РАСПИСАНИЕ установилась связь «многие ко многим», что обусловлено условиями организации работы на кафедре (много
групп и много спецкурсов для каждой группы). При практической реализации такой РБД большинство стандартных платформ будут требовать дальнейшей декомпозиции этих отношений для установления одних лишь связей
«одни ко многим».
Условия 3NF требуют отсутствия транзитивных зависимостей между атрибутами отношений, а также вычисляемых атрибутов. В полученных нами
отношениях прослеживается одна очевидная транзитивная связь:
НОМ_ГРУППЫ→КУРАТОР_ГРУППЫ→ФАМ_КУРАТОРА, поэтому атрибут ФАМ_КУРАТОРА из отношения СТУДЕНТЫ необходимо удалить. Вычисляемые атрибуты в рассматриваемых отношениях отсутствуют. Очевидно, также, что вследствие отсутствия составных ключей, требования BCNF
будут удовлетворены автоматически. Результат нормализации представлен
на рис. 22
Рисунок 20. Первая нормальная форма
52
Рисунок 21. Вторая нормальная форма
Рисунок 22. Третья нормальная форма
5.4 Преимущества и недостатки РМД
Для начала рассмотрим основные особенности РМД, отличающие ее от
остальных моделей данных:
а) Основной функциональной единицей хранения данных является отношение, состоящее из схемы отношения (набора атрибутов) и тела отношения (совокупности кортежей).
б) Отдельные значения атрибутов внутри кортежа (элементы данных)
задаются атомарными (неделимыми) значениями, однородными для данного
атрибута.
в) РБД представляет собой совокупность связанных отношений, причем
связи задаются при помощи явных значений ключевых атрибутов (уникальных и внешних).
г) Манипуляционная часть РМД представлена эквивалентными механизмами: реляционной алгеброй и реляционным исчислением, являющимися
строгими математическим формализмами и отличающимися уровнем процедурности. Любое действие, производимое над отношениями в рамках этих
механизмов, обладает свойством замкнутости для множества отношений.
д) В рамках РМД отсутствует упорядоченность кортежей и атрибутов,
каждый конкретный кортеж однозначно характеризуется значением своего
первичного ключа (простого или составного).
е) Для приведения определенного набора данных в соответствие с требованиями РМД используется процедура нормализации отношений.
Ключевые атрибуты играют ведущую роль в РМД и используются для
решения следующих задач:
53
1) Исключение дублирования кортежей, что позволяет однозначно идентифицировать, а, значит, и осуществлять адресацию кортежей. Для этого
применяются уникальные (первичные) ключевые атрибуты.
2) Организация связей между отношений. В зависимости от типа связи
для этого используют первичные или внешние ключевые атрибуты.
В рамках темы 3 мы рассмотрели набор критериев, которым должна соответствовать оптимальная модель данных. Теперь можно проанализировать
насколько им соответствует РМД:
• внутренняя логичность и легкость восприятия. Схема РБД представляет собой совокупность схем отношений и связей между ними. Как правило,
схемы РБД отличаются логической простотой и доступностью для понимания.
• достаточная полнота базиса. РМД оперирует своим набором понятий,
которые позволяют в той или иной степени описать любую предметную область, эти понятия неизбыточны и просты для интерпретации;
• эвристический потенциал. Схема РБД легко трансформируется путем
установления новых или удаления старых связей между отношениями, что
позволяет, как сокращать существующую БД, так и интегрировать ее в более
крупные информационные объединения.
• формализуемость. Манипуляционная часть РМД представлена строгими математическими формализмами, что позволяет использовать языки программирования высокого уровня (SQL, QBE);
• наглядность. Графическое представление схемы РБД позволяет на интуитивном уровне сформировать представление даже о сложной и разветвленной БД.
Из недостатков РМД можно выделить следующие:
1) Требования однородности и атомарности и значений атрибутов не
позволяют хранить данные со сложной внутренней структурой в одном кортеже отношения. Такие данные либо вообще невозможно представить в РМД,
либо приходится порождать множество дополнительных отношений.
2) Сложность описания других типов связей – рекурсивных, иерархических и сетевых.
3) Достаточно жестко фиксированный набор операций, исчерпывающийся возможностями реляционной алгебры. Трудность определения новых
специальных операций.
ЧАСТЬ III. СОВРЕМЕННЫЕ ТЕХНОЛОГИИ ОБЕСПЕЧЕНИЯ
ДОСТУПА К ДАННЫМ
Раздел посвящен обсуждению современных подходов к организации
хранения данных и эффективной работы с ними. Особое внимание уделяется
описанию новых моделей данных – постреляционной, объектноориентированной, многомерной, XML, колоночной. Детально рассмотрены
54
основные аспекты организации работы информационных систем в сетях различного уровня. Обсуждаются способы организации многопользовательского
режима работы БД на основе транзакций. Подробно описаны основные методики организации индексных структур для оптимизации выполнения поисковых запросов.
Тема 6. Современные модели данных
6.1 Постреляционная модель данных
Классическая реляционная модель предполагает неделимость данных,
хранящихся в кортежах отношений. Это означает, что информация в отношении представлена в первой нормальной форме (1NF). Однако существует
ряд случаев, когда это ограничение препятствует эффективной реализации
приложений.
Постреляционная модель данных представляет собой расширенную реляционную модель, снимающую ограничение неделимости данных, хранящихся в кортежах отношений. Постреляционная модель данных допускает
сложные атрибуты – атрибуты, значения которых имеют внутреннюю структуру, при этом набор значений таких атрибутов считается самостоятельным
отношением, встроенным в основное. Вследствие этого, ее часто называют
вложенной (Nested) реляционной моделью. Поскольку атомарность данных
постулируется первой нормальной формой, то исходя из этого определения,
ее также можно называть Non-First Normal Form (NFNF или NF2).
Помимо обеспечения вложенности отношений, постреляционная модель
поддерживает ассоциированные многозначные атрибуты (множественные
группы). Совокупность ассоциированных атрибутов называется ассоциацией.
При этом в кортеже первое значение одного атрибута ассоциации соответствует первым значениям всех других атрибутов ассоциации. Аналогичным
образом связаны все вторые значения атрибутов и т. д.
В постреляционной модели на значения атрибутов отношения не накладывается требование постоянства. Это означает, что структура данных и отношений имеет большую гибкость. Однако, поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает
проблема контроля целостности и непротиворечивости данных. Эта проблема решается включением в СУБД дополнительных механизмов, обеспечивающих необходимую функциональность. Для описания функций контроля
значений атрибутов в кортежах имеется возможность создавать процедуры
(коды конверсии и коды корреляции), автоматически вызываемые до или после обращения к данным. Коды корреляции выполняются сразу после чтения
данных, перед их обработкой. Коды конверсии, наоборот, выполняются после обработки данных.
Достоинством постреляционной модели является возможность представления совокупности связанных реляционных отношений одним постре55
ляционным. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки.
Недостатком этой модели является сложность решения проблемы контроля целостности и непротиворечивости хранимых данных.
К полноценным постреляционным СУБД можно отнести uniVers, Bubba
и DasDB.
6.2 Многомерная модель данных
Многомерный подход к представлению данных появился практически
одновременно с реляционным, но реально работающих многомерных СУБД
(МСУБД) до середины 90-х годов было очень мало. В настоящее время интерес к ним стал приобретать массовый характер. Толчком к развитию этого
направления послужила программная статья одного из основоположников
реляционного подхода Э. Кодда, вышедшая в свет в 1993 году. В ней сформулированы 12 основных требований к системам класса OLAP (OnLine Analytical Processing - оперативная аналитическая обработка), важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных. Многомерные системы позволяют оперативно обрабатывать информацию для проведения анализа данных и принятия на его
основе оптимального решения.
В развитии концепций информационных систем можно выделить следующие два направления:
• системы оперативной (транзакционной) обработки;
• системы аналитической обработки (более подробно о подобных системах будет рассказано в заключительном разделе данного пособия, посвященном организации экспертных систем).
РМД изначально предназначалась для информационных систем оперативной обработки информации и в этой области была весьма эффективной. В
системах аналитической обработки она показала себя несколько неповоротливой и недостаточно гибкой, более эффективны здесь МСУБД.
МСУБД являются узкоспециализированными СУБД, предназначенными
для интерактивной аналитической обработки информации. Основными свойствами МСУБД являются агрегируемость, историчность и прогнозируемость данных.
Агрегируемость данных означает рассмотрение информации на различных уровнях ее обобщения. В информационных системах степень детальности представления информации для пользователя зависит от его уровня: аналитик, пользователь-оператор, администратор.
Историчность данных предполагает обеспечение высокого уровня статичности (неизменности) собственно данных и их взаимосвязей, а также обязательность привязки данных ко времени. Статичность данных позволяет использовать при их обработке специализированные методы загрузки, хранения, индексации и выборки.
56
Временная привязка данных необходима для частого выполнения запросов, имеющих значения времени и даты в составе выборки. Необходимость
упорядочения данных по времени в процессе обработки и представления
данных пользователю накладывает требования на механизмы хранения и доступа к информации. Так, для уменьшения времени обработки запросов желательно, чтобы данные всегда были отсортированы в том порядке, в котором они наиболее часто запрашиваются.
Прогнозируемость данных подразумевает возможность задания функций аналитического прогнозирования для различных временных интервалов.
Многомерность модели данных означает не столько многомерность визуализации цифровых данных, сколько многомерное логическое представление структуры информации при ее описании, а также в операциях манипулирования данными.
По сравнению с РМД многомерная организация данных обладает более
высокой наглядностью и информативностью. Для иллюстрации на рис. 23
приведены реляционное (а) и многомерное (двухмерное) (б) представления
одних и тех же данных о руководстве курсовым проектированием на кафедре. Если речь идет о многомерной модели с мерностью больше двух, то информация не обязательно должна быть представлена визуально в виде многомерных объектов (трех-, четырех- и более мерных гиперкубов, тем более
что размерность больше трех трудно представить графически). Пользователю
и в этих случаях более удобно иметь дело с двухмерными таблицами или
графиками. Данные при этом представляют собой «срезы» (или проекции) из
многомерного хранилища данных, выполненные с разной степенью детализации.
а
б
Рисунок 23. а – реляционное, б – многомерное (двумерное)
представление данных
Рассмотрим основные понятия многомерных моделей данных, к числу
которых относятся измерение и ячейка.
Измерение (Dimension) — это множество однотипных значений атрибута, образующее одно из ребер гиперкуба. Примерами наиболее часто используемых временных измерений являются Дни, Месяцы, Кварталы и Годы. В
качестве географических измерений широко употребляются Города, Районы,
Регионы и Страны. В многомерной модели данных измерения играют роль
индексов, служащих для адресации значений в ячейках гиперкуба.
Ячейка (Cell) или показатель — это поле, значение которого однозначно
определяется фиксированным набором измерений. Тип поля чаще всего
определен как цифровой. В зависимости от того, как формируются значения
57
некоторой ячейки, обычно она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам
электронных таблиц, вычисляются по заранее заданным формулам).
Рисунок 24. Трехмерный гиперкуб
В примере на рис. 24 каждое значение ячейки КОЛИЧЕСТВО РУКОВОДИМЫХ однозначно определяется комбинацией временного измерения (Год)
и измерения Фамилия руководителя. На практике зачастую требуется большее количество измерений. Пример трехмерной модели данных приведен на
рис. 24
В существующих МСУБД используются два основных варианта (схемы)
организации данных: гиперкубическая и поликубическая.
В поликубической схеме предполагается, что в БД может быть определено несколько гиперкубов с различной размерностью и с различными измерениями в качестве ребер. Примером системы, поддерживающей поликубический вариант БД, является Oracle Express Server.
В случае гиперкубической схемы предполагается, что все показатели
определены одним и тем же набором измерений. Это означает, что при наличии нескольких гиперкубов БД все они имеют одинаковую размерность и
совпадающие измерения. Очевидно, в некоторых случаях информация в БД
может быть и избыточной (если требовать обязательное заполнение ячеек).
В рамках многомерной модели к данным применяется ряд специальных
операций, к которым относятся: формирование «среза», «вращение», агрегация и детализация.
«Срез» (Slice) представляет собой подмножество гиперкуба, полученное
и результате фиксации одного или нескольких измерений. Формирование
«срезов» выполняется для ограничения используемых пользователем значений, так как все значения гиперкуба практически никогда одновременно не
используются. Например, если ограничить значения измерения Фамилия руководителя в гиперкубе (рис. 24) фамилией «Петров», то получится двухмерная таблица отражающая количество руководимых Петровым студентов в
разрезе курсов и годов.
58
Операция «вращение» (Rotate) заключается в изменении порядка измерений при визуальном представлении данных. Так, «вращение» гиперкуба,
показанного на рис. 24, приведет к изменению порядка следования измерений.
Операции агрегация (Drill Up) и детализация (Drill Down) означают соответственно переход к более общему и более детальному представлению
информации пользователю.
Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных,
связанных со временем. При организации обработки аналогичных данных в
рамках РМД происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной
памяти на индексацию.
Недостатком многомерной модели данных является ее громоздкость
для простейших задач обычной оперативной обработки информации.
Примерами систем, поддерживающих многомерные модели данных, явEssbase, Media Multi-matrix, Oracle Express Server и Cache В СУБД Cache, в
которой внутренней моделью данных является многомерная модель, реализованы три способа доступа к данным: прямой (на уровне узлов многомерных массивов), объектный и реляционный.
6.3 Колоночные БД
Еще одним технологическим решением, позволяющим оптимизировать
процессы интерактивной аналитической обработки информации, являются
колоночные БД. В данном случае предлагается особенная организация данных на физическом носителе, позволяющая ускорить некоторые аналитические процедуры.
Как правило, в РМД используется построчное хранение элементов
данных на носителе. Под этим обычно понимается физическое хранение
кортежа отношения в виде одной записи, в которой поля идут
последовательно одно за другим, а за последним полем записи в общем
случае идет первое следующей записи. Такой подход удобен для частых
операций добавления новых строк в базу данных, хранящуюся на жестком
диске, и в этом случае новая запись может быть добавлена целиком всего за
один проход головки накопителя. Однако подобный способ хранения не
всегда удобен для формирования выборок – чтобы исключить просмотр всех
записей подряд, РСУБД поддерживают значительное количество
вспомогательных индексов и других структур. В итоге, среднестатистическая
РБД может занимать на диске в 5-7 раз больше места, чем полезный объем
хранимых данных.
С распространением аналитических информационных систем и хранилищ
данных, применявшихся для анализа накопленных в учетных системах
сведений, стало понятно, что характер нагрузки в них радикально отличается
от систем транзакционной обработки данных. Если транзакционным
59
приложениям свойственны частые мелкие операции добавления или
изменения одной или нескольких записей, то в случае аналитических систем
картина прямо противоположная – наибольшая нагрузка создается
сравнительно редкими, но тяжелыми выборками большого числа записей,
часто с агрегированием. Здесь следует отметить, одну важную особенность
аналитических выборок – как правило, они содержат всего несколько полей.
Однако что произойдет, если выбрать, например, только 3 атрибута из
отношения, в котором их несколько десятков (произвести проекцию
отношения)? В силу построчного хранения данных, в РБД будут прочитаны
абсолютно все кортежи. Далее данные будут пропущены через контроллер
дискового ввода-вывода и переданы процессору, который отберет
информацию, необходимую для удовлетворения запроса. Как результат,
полезная нагрузка на систему при выполнении данного запроса может
составлять 7-10% от общей из-за неминуемого чтения лишних данных.
Решением подобной проблемы могут послужить колоночные СУБД.
Основная идея этого подхода – это хранение данных не в строках (кортежах),
как это делает РБД, а в колонках. Это означает, что с точки зрения внешнего
пользователя структура хранимых данных соответствует РБД, но физически
отношения являются совокупностью колонок, каждая из которых по сути
представляет собой таблицу из одного поля. При этом физически на диске
значения одного поля хранятся последовательно друг за другом. Такая
организация данных приводит к тому, что при выполнении выборки, в
которой фигурируют только 3 атрибута отношения, физически будут
прочитаны только нужные 3 колонки. Это обеспечит снижение нагрузки на
информационную систему и, как следствие, существенно повысит ее
эффективность. Кроме того, при колоночном хранении данных появляется
возможность значительно сжимать данные, поскольку в одной колонке
таблицы содержаться однородные данные. Это, в свою очередь, позволяет
заметно снизить объем хранимой информации, что немаловажно для
архивных аналитических систем.
Не лишены колоночные СУБД и недостатков – они медленно работают
на запись, не подходят для транзакционных систем и, как правило, имеют ряд
функциональных ограничений по сравнению с развитыми РСУБД.
К числу колоночных СУБД можно отнести Sybase IQ, Vertica, ParAccel,
Kognito, Infobright, SAND.
6.4 Объектно-ориентированные БД
В объектно-ориентированной модели при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями
базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектноориентированных языках программирования.
Стандартизованная объектно-ориентированной модель описана в рекомендациях стандарта ODMG-93 (Object Database Management Group). Логи60
ческая структура объектно-ориентированной БД внешне похожа на структуру иерархической БД и является ее логическим продолжением. Основное отличие между ними состоит в методах манипулирования данными. Для выполнения действий над данными в рассматриваемой модели БД применяются
логические операции, усиленные объектно-ориентированными механизмами
инкапсуляции, наследования и полиморфизма. Ограниченно могут примениться операции, подобные командам SQL (например, для создания компонентов БД). Создание и модификация БД сопровождается автоматическим
формированием и последующей корректировкой индексов (индексных таблиц), содержащих информацию для быстрого поиска данных.
Некоторые особенности объектно-ориентированной модели данных были нами рассмотрены в теме 3 при описании возможностей языка UML для
построения семантической модели. Поэтому в данном разделе мы остановимся лишь на отличительных понятиях объектно-ориентированной технологии работы с данными применительно к БД.
Инкапсуляция ограничивает область видимости имени свойства пределами того объекта, в котором оно определено. Так, у объекта типа СТУДЕНТ
и объекта типа ПРЕПОДАВАТЕЛЬ имеется одноименное свойство НОМЕР
разных типов данных в зависимости от объекта. Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.
Наследование, наоборот, распространяет область видимости свойства на
всех потомков объекта. Если необходимо расширить действие механизма
наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем
предке определяется абстрактное свойство типа abs. Так, определение абстрактного свойства факультет в объекте КАФЕДРА приводит к наследованию этого свойства всеми дочерними объектами СТУДЕНТ, ПРЕПОДАВАТЕЛЬ. Не случайно поэтому значение свойства факультет классов СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, показанных на рисунке, будут одинаковыми –
РФиКТ.
Полиморфизм в объектно-ориентированных языках программирования
означает способность одного и того же программного кода работать с разнотипными данными. Другими словами, он означает допустимость в объектах
разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента. Применительно к нашей объектно-ориентированной БД полиморфизм означает, что
объекты класса НАУЧНЫЙ ТРУД, имеющие разных родителей из класса
ПРЕПОДАВАТЕЛЬ, могут иметь разный набор свойств. Следовательно, программы работы с объектами класса НАУЧНЫЙ ТРУД могут содержать полиморфный код.
Поиск в объектно-ориентированной БД состоит в выяснении сходства
между объектом, задаваемым пользователем, и объектами, хранящимися в
БД. Определяемый пользователем объект, называемый объектом-целью
61
(свойство объекта имеет тип goal), в общем случае может представлять собой
подмножество всей хранимой в БД иерархии объектов.
Основным достоинством объектно-ориентированной модели данных по
сравнению с реляционной является возможность отображения информации о
сложных взаимосвязях объектов. Объектно-ориентированная модель данных
позволяет идентифицировать отдельную запись базы данных и определять
функции их обработки.
Рисунок 25. Пример объектно-ориентированной БД кафедры
Недостатками объектно-ориентированной модели являются высокая
понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов.
Наиболее распространенные СУБД, использующие объектноориентированную модель: G-Base, GemStone, ObjectStore, O2, ODB-Jupiter,
Iris, Orion, Postgres.
6.5 XML БД
XML (eXtensible Markup Language – расширяемый язык разметки) – язык
разметки, фактически представляющий собой свод общих синтаксических
правил представления информации. XML предназначен для хранения структурированных данных (по аналогии с файлами баз данных), для обмена информацией между приложениями различного уровня, а также для создания
на его основе более специализированных языков разметки (например,
XHTML), иногда называемых словарями. XML является упрощённым подмножеством языка SGML.
62
Целью создания XML явилось обеспечение совместимости при передаче структурированных данных между разными системами обработки информации, особенно при передаче данных со сложной структурой посредством сети Интернет.
XML-документы имеют особую структуру. Первая строка XMLдокумента называется объявлением XML (XML declaration) – это необязательная строка, указывающая версию стандарта XML, также здесь может
быть указана кодировка символов и внешние зависимости.
Остальная часть XML-документа состоит из вложенных элементов данных, некоторые из которых имеют атрибуты и содержимое. Элемент
обычно состоит из открывающего и закрывающего тегов (меток), обрамляющих текст и другие элементы. Открывающий тег состоит из имени элемента в угловых скобках, например «<step>»; закрывающий тег состоит из
того же имени в угловых скобках, но перед именем ещё добавляется косая
черта, например «</step>». Содержимым элемента (content) называется всё,
что расположено между открывающим и закрывающим тегами, включая
текст и другие (вложенные) элементы.
Кроме содержания элементу могут быть свойственны атрибуты – пары
имя-значение, добавляемые в открывающий тег после названия элемента.
Значения атрибутов всегда заключаются в кавычки (одинарные или двойные), одно и то же имя атрибута не может встречаться дважды в одном элементе. Не рекомендуется использовать разные типы кавычек для значений
атрибутов одного тега.
В XML определены два метода записи специальных символов: ссылка
на сущность и ссылка по номеру символа. Сущностью (entity) в XML называются именованные данные, обычно текстовые, в частности спецсимволы.
Ссылка на сущность (entity references) указывается в месте, где должна
быть определена сущность и состоит из амперсанда («&»), имени сущности
и точки с запятой («;»).
Ссылка по номеру символа (numeric character reference) выглядит как
ссылка на сущность, но вместо имени сущности указывается символ # и
число (в десятичной или шестнадцатеричной записи), являющееся номером
символа в кодовой таблице Юникод. Это обычно символы, которые невозможно закодировать напрямую, например буква арабского алфавита в
ASCII-кодированном документе.
Одно из достоинств XML состоит в том, что в разрабатываемых с его помощью документах описание структуры хранимых данных отделено от собственно данных. В связи с этим XML представляет собой удобное средство
обмена данными между различными приложениями. Он позволяет обеспечить согласованный обмен данными между приложениями, с отличными
структурами хранимых данных. Кроме того, с помощью XML может быть
упрощен доступ к данным, хранимым в базах данных различных СУБД.
Например, для доступа к данным персональных СУБД или табличного процессора Excel пользователю требуется установка соответствующих инстру63
ментальных средств. В этом случае можно создать обозреватель в виде активных серверных страниц (ASP) или сценария на языке JScript или VBScript,
которые выполняют извлечение данных из базы данных и помещение их в
документ XML (см. рис 26).
Информацию из полученного таким образом документа XML можно легко использовать в других приложениях или отображать на страницах HTML.
Таким образом, полученные в результате данные становятся доступными для
всех пользователей, имеющих соответствующий обозреватель, независимо
от наличия или отсутствия конкретной СУБД или табличного процессора.
Рисунок 26. Схема взаимодействия БД с внешним
окружением по средствам стандарта XML
К числу достоинств языка XML как модели представления данных можно отнести:
- возможность описания основные структуры данных – записей, списков
и деревьев;
- XML – это самодокументируемый формат, который сам описывает
структуру и имена полей;
- XML имеет строго определённый синтаксис и требования к анализу, что
позволяет ему оставаться простым, эффективным и непротиворечивым;
- XML – формат, основанный на международных стандартах;
- иерархическая структура XML подходит для описания практически любых типов документов;
- XML-документ не зависит от платформы, создающей или использующей его;
Недостатками этого подхода являются:
- избыточность синтаксиса XML, снижающая эффективность приложения
и увеличивающая стоимость хранения, обработки и передачи данных;
- размер XML документа существенно больше бинарного представления
тех же данных. В грубых оценках величину этого фактора принимают за 1
порядок (в 10 раз).
- XML не содержит встроенной в язык поддержки типов данных. В нём
нет понятий «целых чисел», «строк», «дат», «булевых значений» и т. д.
- иерархическая модель данных, предлагаемая XML, ограничена по сравнению с реляционной моделью и объектно-ориентированными графами.
64
Тема 7. Архитектура клиент-сервер в БД
7.1 Архитектура распределенной информационной системы
Эффективность функционирования информационной системы во многом
зависит от ее архитектуры. В настоящее время самой перспективной является
архитектура клиент-сервер. В наиболее распространенном варианте она
предполагает наличие компьютерной сети и распределенной БД, включающей корпоративную БД (КБД) и персональные БД (ПБД). КБД размещается
на компьютере-сервере, ПБД размещаются на ПК сотрудников, являющихся
клиентами корпоративной БД.
Сервером определенного ресурса в компьютерной сети называется приложение, управляющее этим ресурсом, в свою очередь клиентом – приложение, использующее этот ресурс. В качестве ресурса компьютерной сети могут выступать, к примеру, БД, файловые системы, службы печати, почтовые
службы. Тип сервера определяется видом ресурса, которым он управляет.
Например, если управляемым ресурсом является БД, то соответствующий
сервер называется сервером БД.
Достоинством организации информационной системы в соответствии с
архитектурой клиент-сервер является удачное сочетание централизованного
хранения, обслуживания и коллективного доступа к общей корпоративной
информации с индивидуальной работой пользователей над корпоративной
информацией. Архитектура клиент-сервер допускает различные варианты
своей реализации.
Исторически первыми появились распределенные информационные системы с применением архитектуры файл-сервер (рис. 27а). В этом случае по
запросам пользователей файлы базы данных передаются на ПК конечных
пользователей, где и производится их обработка. Недостатком такого варианта архитектуры является повышенная интенсивность передачи обрабатываемых данных. При этом, зачастую передаются избыточные данные: вне зависимости от того какие элементы записей требуется пользователю, массивы
БД передаются целиком.
а
б
Рисунок 27. Структура ИС а – с файл сервером, б – с сервером баз
данных
65
Структура информационной системы, построенной по архитектуре клиент-сервер с использованием сервера БД, показана на рис. Такой тип организации БД обеспечивает выполнение основного объема обработки данных на
стороне сервера БД. Формируемые пользователем или приложением запросы
поступают к серверу БД в виде инструкций высокоуровневого языка БД
(например, SQL). Сервер БД выполняет поиск и извлечение нужных данных,
которые затем передаются на компьютер пользователя. Достоинством такого подхода в сравнении предыдущим является заметно меньший объем передаваемых данных. Основным недостатком в этом случае является повышенная нагрузка на сервер БД. Выходом из этой ситуации может быть гибкое
разделение полномочий между сервером БД и ПК пользователей.
Чтобы охарактеризовать основные схемы процессов взаимодействия
между компонентами информационной системы, основанной на БД, воспользуемся Эталонной моделью Архитектуры открытых систем OSI. Согласно
этой модели, функция управления БД относится к прикладному уровню.
Остановимся на двух самых верхних уровнях организации информационной системы: прикладном и представительном, которые в наибольшей
степени являются предметом внимания со стороны разработчика и пользователя. Остальные функции будем считать связными функциями, необходимыми для реализации двух первых. При этом будем придерживаться широкого
толкования термина СУБД, понимая под ним все приложения, которые используют информацию из БД.
Как приложение, поддерживающее диалог с пользователем, СУБД, в
общем случае, реализует следующие основные функции:
• управление данными, находящимися в базе;
• обработка информации с помощью прикладного ПО;
• представление информации в удобном для пользователя виде.
При организации распределенной информационной системы возможны
различные варианты разделения функций между ее компонентами. В зависимости от числа узлов сети, между которыми выполняется распределение
функций СУБД, можно выделить двухзвенные модели, трехзвенные модели и
т.д. Место разрыва функций соединяется коммуникационными функциями
(средой передачи информации в сети).
7.2 Двухзвенные модели архитектуры клиент-сервер
Двухзвенные модели соответствуют распределению функций СУБД между двумя узлами сети. ПК (узел сети), на котором обязательно присутствует
функция управления данными, будем называть компьютером-сервером. ПК
пользователя, занимающийся вопросами конечного представления информации, определим как компьютер-клиент.
Наиболее типичными вариантами (рис. 28) разделения функций между
компьютером-сервером и компьютером-клиентом являются следующие:
• распределенное представление;
• удаленное представление;
66
• распределенная функция;
• удаленный доступ к данным;
• распределенная БД.
Перечисленные способы распределения функций в системах с архитектурой клиент-сервер иллюстрируют различные варианты: от мощного сервера, выполняющего практически всю обработку данных, до мощного (толстого) клиента, когда большая часть функций выполняется на рабочей станции,
а сервер лишь обрабатывает поступающие к нему по сети простые SQLзапросы на выборку.
Рисунок 28. Спектр моделей архитектуры клиент-сервер
В моделях удаленного доступа к данным и удаленного представления
производится строгое распределение функций между компьютеромклиентом и компьютером-сервером. В других моделях имеет место выполнение одной из следующих функций одновременно на двух компьютерах:
управления данными (модель распределенной БД), обработки информации
(модель распределенной функции), представления информации (модель распределенного представления).
Рассмотрим сначала модели удаленного доступа к данным и удаленного
представления (сервера БД) как наиболее широко распространенные.
В модели удаленного доступа к данным (Remote Data Access – RDA)
приложения, реализующие функции представления информации и логику
прикладной обработки, совмещены и выполняются на компьютере-клиенте.
Обращение за сервисом управления данными происходит через среду передачи с помощью операторов языка SQL или вызовом функций специальной
библиотеки API (Application Programming Interface – интерфейса прикладного
программирования).
67
Основное достоинство RDA-модели состоит в обилии стандартных
СУБД, имеющих SQL-интерфейсы, и существующих инструментальных
средств, обеспечивающих быстрое создание программ клиентской части.
Средства разработки чаще всего поддерживают графический интерфейс
пользователя в MS Windows, стандарт интерфейса ODBC и средства автоматической генерации кода. Подавляющее большинство средств разработки использует языки четвертого поколения.
Недостатками этой модели являются, во-первых, довольно высокая загрузка системы передачи данных вследствие того, что вся логика обработки
сосредоточена в приложении клиента, а обрабатываемые данные расположены на удаленном узле. Во-вторых, системы, построенные на основе модели
RDA, неудобны с точки зрения разработки, модификации и сопровождения.
Основная причина состоит в том, что в получаемых приложениях прикладные функции и функции представления тесно взаимосвязаны. Поэтому даже
при незначительном изменении функций системы требуется переделка всей
прикладной ее части, усложняющая разработку и модификацию системы.
Модель удаленного представления или сервера БД (DataBaseServer DBS) отличается от предыдущей модели тем, что функции компьютераклиента ограничиваются функциями представления информации, в то время
как прикладные функции обеспечиваются приложением, находящимся на
компьютере-сервере. Эта модель является более технологичной чем RDAмодель и применяется в таких СУБД, как Ingress, Sybase, Oracle. При этом
приложения реализуются в виде хранимых процедур. Процедуры обычно
хранятся в словаре БД и разделяются несколькими клиентами. В общем случае хранимые процедуры могут выполняться в режимах компиляции и интерпретации.
Достоинствами модели DBS являются: возможность хорошего централизованного администрирования приложений на этапах разработки, сопровождения и модификации, а также эффективное использование вычислительных и коммуникационных ресурсов. Последнее достигается за счет того,
что выполнение приложений в режиме коллективного пользования требует
существенно меньших затрат на пересылку данных в сети.
Один из недостатков модели DBS связан с ограничениями средств разработки хранимых процедур. Основное ограничение – сильная привязка операторов хранимых процедур к конкретной СУБД. Язык написания хранимых
процедур, по сути, является процедурным расширением языка SQL, и не может соперничать по выразительным средствам и функциональным возможностям с традиционными языками третьего поколения, такими как Pascal и C.
Кроме того, в большинстве СУБД нет удовлетворительных средств отладки и
тестирования хранимых процедур, что делает их механизм достаточно опасным инструментом – некорректно построенные процедуры могут приводить
к повреждению БД, зависаниям серверных и клиентских приложений во время работы системы и т. п.
68
Другим недостатком DBS-модели является низкая эффективность пользования вычислительных ресурсов ПК, поскольку не удается организовать
упраправление входным потоком запросов к приложениям компьютерасервера, а также обеспечить перемещение процедур на другие компьютерысерверы.
В модели распределенного представления имеется мощный компьютерсервер, а клиентская часть системы практически вырождена (тонкий клиент).
Функцией клиентской части зачастую является просто отображение информации на экране пользовательского монитора и связь с сервером через локальную сеть.
СУБД подобного рода могут иметь место в сетях, поддерживающих работу так называемых X-терминалов. В них основной ПК (хост-машина)
должен иметь достаточную мощность, чтобы обслуживать несколько Xтерминалов. Х-терминал, при этом тоже должен обладать достаточно быстрым процессором и иметь необходимый объем оперативной памяти (поскольку дисковые накопители, как правило, отсутствуют). Часто Хтерминалы создают на базе RISC-компьютеров (Restricted [Reduced] Instruction Set Computer) – компьютеров с сокращенным набором команд. Все программное обеспечение находится на хост-машине. ПО Х-терминалов, выполняющее функции управления представлением и сетевые функции, загружается с сервера при включении Х-терминала в сеть.
Модель распределенного представления имели СУБД ранних поколений,
которые работали на малых, средних и больших ЭВМ. В роли Х-терминалов
выступали дисплейные станции и абонентские пункты (локальные и удаленные). В этом случае основную часть функций представления информации реализовывали СУБД компьютера-сервера, а окончательное построение изображений на терминалах пользователя выполнялось на конечных устройствах.
По модели распределенного представления построены системы обслуживания пользователей БД в гетерогенной (неоднородной) среде. Серверная
часть таких систем обычно обеспечивает некоторый унифицированный интерфейс, а клиентские части реализуют функции учета специфики клиентского оборудования или преобразования одного формата представления информации в другой.
Модель распределенного представления реализует централизованную
схему управления вычислительными ресурсами. Отсюда следуют ее основные достоинства – простота обслуживания и управления доступом к системе и относительная дешевизна (ввиду невысокой стоимости клиентских терминалов). Недостатками модели являются уязвимость системы при невысокой надежности центрального узла, а также высокие требования к серверу по
производительности при большом числе клиентов.
В модели распределенной функции логика обработки данных распределена по двум узлам. Такую модель могут иметь информационные системы, в
которых общая часть прикладных функций реализована на компьютересервере, а специфические функции обработки информации выполняются на
69
компьютере-клиенте. Функции общего характера могут включать в себя
стандартное обеспечение целостности данных, например, в виде хранимых
процедур, а оставшиеся прикладные функции реализуют специальную прикладную обработку. Подобную модель имеют также сложные информационные системы, использующие информацию из нескольких неоднородных БД.
Модель распределенной БД предполагает использование мощного компьютера-клиента, причем БД физически расположена как на компьютереклиенте, так и на компьютере-сервере. Взаимосвязь частей БД может быть
организована двумя способами: а) в локальной и удаленной базах хранятся
отдельные части единой БД (фрагментация); б) локальная и удаленная БД
являются синхронизируемыми друг с другом копиями (репликация). Более
подробно особенности организации распределенных БД будут рассмотрены в
теме 8.
Достоинством модели распределенной БД является гибкость создаваемых на ее основе информационных систем, позволяющих компьютеруклиенту обрабатывать локальные и удаленные БД. При наличии механизмов
координации соответствия копий система в целом, кроме того, обладает высокой живучестью, так разрыв соединения клиента и сервера не приводит к
краху системы, а ее работа может быть восстановлена с возобновлением соединения. К недостатку модели можно отнести высокие затраты при выполнении большого числа одинаковых приложений на компьютерах-клиентах.
7.3 Трехзвенная модель архитектуры клиент-сервер
Трехзвенная модель распределения функций представляет собой типовой
вариант, при котором каждая из трех функций приложения, поддерживающего диалог с пользователем, реализуется на отдельном узле. Варианты распределения функций приложения на большее число компьютеров могут иметь
место, но ввиду их редкого практического применения рассматриваться не
будут.
Рассматриваемая нами модель имеет название модель сервера приложений или AS-модель (Application Server), и показана на рис. 29
Согласно трехзвенной AS модели, процесс, отвечающий за
организацию диалога с конечным
пользователем, реализует функции представления информации и
взаимодействует с компонентом
приложения так же, как в модели
DBS. Компонент приложения,
располагаясь на отдельном ПК, в
Рисунок 29. Трехзвенная модель сервера
свою очередь, связан с компоприложений
нентом управления данными подобно модели RDA.
70
Центральным звеном AS-модели является сервер приложений. На сервере
приложений реализуется несколько прикладных функций, каждая из которых
оформлена как служба предоставления услуг всем требующим этого внешним потребителям. Серверов приложений может быть несколько, причем
каждый из них предоставляет свой вид сервиса. Любой пользователь, запрашивающий услугу у сервера приложений, является для него клиентом. Поступающие от клиентов к серверам запросы помещаются в общую очередь,
из которой далее выбираются в соответствии с некоторой дисциплиной обслуживания, например, по приоритету.
Компонент, реализующий функции представления и являющийся клиентом для сервера приложений, в этой модели трактуется более широко, чем
обычно. Он может служить для организации интерфейса с конечным пользователем, обеспечивать прием данных от устройств, например, датчиков, или
быть произвольным ПО.
Достоинством AS-модели является гибкость и универсальность вследствие разделения функций приложения на три независимые составляющие.
Во многих случаях эта модель оказывается более эффективной по сравнению
с двухзвенными. Основной недостаток модели — более высокие затраты
ресурсов системы на обмен информацией между компонентами приложения
по сравнению с двухзвенными моделями.
Примерами программных продуктов, реализующих среду функционирования приложений на ПК серверов приложений, являются BEA WebLogic
Server, Inprise Application Server, IBM WebSphere Application Server.
7.4 Сложные схемы взаимодействия
Возможны более сложные схемы взаимодействия, например, схемы, в
которых элемент, являющийся сервером для некоторого клиента, в свою очередь, выступает в роли клиента по отношению к другому серверу (рис. 30а).
Пример этого мы наблюдали в AS-модели.
а
б
Рисунок 30. а – цепочка взаимодействий, б - множественные
связи взаимодействия типа клиент-сервер
71
Возможно также, что в распределенной вычислительной системе при работе с БД имеются множественные связи (статические), когда один объект
по отношению к одним является клиентом, а по отношению к другим – сервером (рис. 30б).
При рассмотрении взаимодействия объектов в динамике получаются еще
более сложные схемы взаимодействия. Примером такой схемы является случай, когда в процессе работы роли объектов меняются: объект, являющийся в
некоторый момент времени клиентом по отношению к другому объекту, в
последующем становится сервером для другого объекта.
7.5 Модель монитора транзакций
Как уже отмечалось, наиболее гибкой и универсальной моделью распределения функций СУБД является AS-модель. Она описывает взаимодействие
трех основных элементов: клиента, сервера приложений и сервера БД, но не
затрагивает вопросы организации функционирования ПО при обработке информации, в частности при выполнении транзакций. Для преодоления этого
недостатка предложена модель монитора транзакций.
Мониторы обработки транзакций (Transaction Processing Monitor –
TPM), или мониторы транзакций, представляют собой программные системы категории промежуточного слоя (Middleware), обеспечивающие эффективное управление информационно-вычислительными ресурсами в распределенной вычислительной системе. Основное их назначение – организация
гибкой, открытой среды для разработки и управления мобильными приложениями, оперативно обрабатывающими распределенные транзакции. Применение мониторов транзакций наиболее эффективно в гетерогенных вычислительных системах.
Приложение ТРМ позволяет выполнять масштабирование системы, поддерживать функциональную полноту и целостность приложений а также повышать производительность обработки данных при невысокой стоимости
вычислительных ресурсов.
Принципы организации обработки информации с помощью монитора
транзакций описываются моделью монитора транзакций X/Open DTP (Distributed Transaction Processing – обработка распределенных транзакций). Эта
модель (рис. ) включает в себя три объекта: приложение, менеджер ресурсов
(Resource Manager – RM) и монитор, или менеджер транзакций (Transaction
Manager – TM).
В качестве приложения может выступать произвольное клиентское ПО.
RM выполняет функции сервера ресурса некоторого вида. Приложение взаимодействует с RM с помощью набора специальных функций либо посредством операторов SQL (в случае, когда сервером является сервер БД).
Интерфейс ATMI (Application Transaction Monitor Interface — интерфейс
монитора транзакций приложения) позволяет вызывать функции ТРМ на
некотором языке программирования, например С.
72
Функции менеджера ресурсов обычно выполняют серверы БД или
СУБД. В задачах управления обработкой распределенных транзакций (транзакций, затрагивающих программные объекты вычислительной сети) ТМ
взаимодействует с RM, который должен поддерживать протокол двухфазной
фиксации транзакций (более подробно об этом – в теме 9) и удовлетворять
стандарту X/Open XA. Примерами СУБД, поддерживающих протокол двухфазной фиксации транзакции, являются Oracle 7.0, Open INGRES и InformixOnline 5.0.
Понятие транзакции в ТРМ несколько шире, чем в СУБД, где транзакция
включает в себя элементарные действия над данными базы (см. тему 9).
Здесь транзакция может охватывать и другие необходимые действия: передачу сообщения, запись информации в файл, опрос датчиков и т. д. Это значит,
что ТРМ предоставляет более мощные средства управления вычислительным
процессом. Транзакции, которые применяются в ТРМ, называют также прикладными или бизнес-транзакциями.
Модель X/Open DTP не
раскрывает структуру ТМ в деталях, а определяет состав компонентов распределенной системы обработки информации и
способ взаимодействия этих
компонентов. Практические реализации этой модели, естеРисунок 31. Модель обработки транзакций ственно, могут отличаться друг
X/Open DTP
от друга. В числе примеров реализаций мониторов транзакций можно назвать ACMS, CICS и TUXEDO System.
Для разработчиков приложений мониторы обработки транзакций ТРМ
предоставляют удобства, связанные с возможностью декомпозиции приложений по нескольким функциональным уровням со стандартными интерфейсами, что позволяет создавать гибкие информационные системы со стройной
архитектурой.
Приложения становятся практически независимыми от конкретной реализации пользовательского интерфейса и внутренней организации менеджера
ресурсов. Первое означает, что для реализации функций представления можно выбрать любое удобное и привычное для разработчика средство (от языка
С до какой-либо CASE-системы). Независимость от менеджера ресурсов
подразумевает возможность легкой замены одного менеджера ресурсов на
другой, лишь бы они поддерживали стандарт взаимодействия с прикладной
программой (для РСУБД – язык SQL). Поскольку ТРМ поддерживает множество аппаратно-программных платформ, как, например, TUXEDO System, то
разрабатываемые приложения становятся, кроме того, мобильными.
Сосредоточение всех прикладных функций в серверах приложений и
наличие богатых возможностей управления и администрирования суще73
ственно упрощает обновление прикладных функций (бизнес-функций) и контроль за их непротиворечивостью. Изменения в прикладных функциях при
этом никак не отражаются на приложениях-клиентах.
Для пользователей распределенных систем ТРМ позволяют улучшить
показатели пропускной способности и времени отклика, снизить стоимость
обработки данных в оперативном режиме на основе эффективной организации вычислительного процесса.
Улучшение показателей функционирования достигается благодаря осуществлению статической и динамической балансировки нагрузки. Управление загрузкой состоит в запуске или остановке AS-процессов (программных
компонентов AS-модели) в зависимости от заранее установленных параметров и текущего состояния системы. При необходимости ТРМ может тиражировать копии AS-процессов на этом или других узлах сети.
Администраторы распределенных систем, имея ТРМ, получают возможность легкого масштабирования информационных систем и увеличения
производительности обработки информации. Здесь, кроме вертикального и
горизонтального масштабирования, можно обеспечить так называемое матричное масштабирование. Суть его – введение дополнительных ресурсов в
любую точку гетерогенной вычислительной среды без изменения архитектуры приложения, выполняемого в новой среде. Это означает, что без остановки серверов приложений в любое время может быть добавлен, например, ПК
или менеджер ресурсов.
Кроме того, администраторы систем получают возможность снизить
общую стоимость программного обеспечения систем клиент-сервер. Этот
эффект можно достигнуть простым уменьшением количества подключений к
серверам БД. Стоимость серверов БД (или СУБД) в сильной степени зависит
от предполагаемого числа одновременных подключений к БД. Уменьшение
количества подключений к серверу БД достигается путем мультиплексирования запросов или, что то же самое, логического преобразования потока запросов от множества источников к потоку от одного или нескольких источников. Выигрыш в стоимости и производительности при эффективной реализации самих ТРМ может оказаться весьма существенным.
Тема 8. Информационные системы в сетях
8.1 Информационные системы в локальных сетях
Локальная сеть дает ее пользователям прежде всего возможность более
эффективной организации коллективных работ и совместного использования
аппаратных ресурсов: принтеров, факсов, модемов, сканеров, дисков и т. д., а
также программно-информационных ресурсов, в том числе БД. Рассмотрим
основные схемы организации работы с данными в локальных компьютерных
сетях. Как и на отдельном компьютере, в локальной сети пользователь может
управлять БД с помощью средств некоторой СУБД, либо работая с отдельным приложением. Для удобства в дальнейшем под СУБД будем понимать
74
любой из этих вариантов. В локальной сети ПК выделяют следующие три варианта создания информационной системы:
• типа файл-сервер;
• типа клиент-сервер;
• основанные на технологии интранет;
Первые два варианта организации распределенных информационных систем были нами подробно рассмотрены в предыдущей теме. Интранет по
существу представляет собой технологию Internet, перенесенную в среду
корпоративных информационных систем. С этой точки зрения логично рассматривать эти две технологии совместно, что и будет сделано в следующем
разделе. Здесь же будут обсуждены некоторые существующие технологии
доступа к данным, позволяющие унифицировать процедуры работы с информацией, находящейся в различных БД.
Технология открытого доступа к данным Open Database Connectivity
(ODBC) была разработана фирмой MS для обеспечения возможности взаимосвязи между различными SQL-совместимыми БД, причем в этой технологии
SQL используется как стандартный механизм доступа к данным. Необходимость создания ODBC появилась вследствие того, что каждая фирмаразработчик РСУБД использовала свой диалект SQL, что делало невозможным обмен данными между двумя РБД, организованных при помощи различных СУБД. Поэтому вначале был разработан общий стандарт на SQL, получивший название CLI (Call Level Interface). В его основу были положены
уже существующие стандарты X/Open и ISO. Затем каждой фирмеразработчику РСУБД было предписано разработать драйвер перевода своего
диалекта SQL в CLI, и наоборот. Таким образом, основное назначение ОDВС
состоит в абстрагировании приложения от особенностей ядра используемой
БД.
ОDВС представляет собой интерфейс прикладного программирования в
виде библиотеки функций, вызываемых из различных программных сред и
позволяющих приложениям унифицировано обращаться на SQL к базам данных различных форматов.
Функции интерфейса ОDВС включают следующие шесть основных
групп:
• назначение идентификаторов окружения, соединения и SQLоператоров;
• соединение;
• выполнение SQL-операторов;
• получение результатов;
•управление транзакциями;
• идентификация ошибок и смешанные функции.
При выполнении приложений, использующих ОDВС, предусматриваются следующие этапы:
• инициализация (назначение идентификаторов окружения и соединений, соединеннее сервером, назначение идентификаторов SQL-операторам);
75
• выполнение SQL-операторов с анализом результатов;
• завершение (освобождение идентификаторов SQL-операторов, разрыв
соединения, освобождение идентификаторов соединений и окружения).
Интерфейс ОDВС поддерживает общий набор функций языка SQL для
доступа к базам данных и позволяет работать в так называемом прозрачном
режиме по соглашениям конкретной БД. Это позволяет создавать распределенные (преимущественно клиент-серверные) гетерогенные приложения без
учета особенностей конкретных РСУБД. В качестве сервера может выступать
любой сервер БД, имеющий драйвер ODBC. ODBC требует от разработчика
указания только имени источника данных (Data Source Name – DSN), при
этом функции, драйверы, адреса серверов, сети и шлюзы скрыты от пользователя (см. рис. 32).
Достоинством технологии ODBC
является простота разработки приложений,
обусловленная
высоким
уровнем абстрактности интерфейса
доступа к данным практически любых существующих типов РСУБД.
Основной недостаток технологии
ODBC связан с необходимостью
трансляции запросов, что снижает
скорость доступа к данным.
Рисунок 32. Схема доступа к БД с
Реляционные БД – не единственпомощью
ODBC
ный источник
данных.
Данные могут быть представлены в любом виде и
формате. Например, в качестве данных могут – выступать объектноориентированные БД, электронные таблицы, документы в RTF, XML формате, почтовые системы и т. д. Соответственно возникла потребность либо создать единый формат хранения данных, что дорого и неэффективно, либо
нарастить имеющиеся технологии интерфейсами доступа к любым типам
данных. Технология OLE DB (Object Linking and Embedding Database) реализует это требование, являясь более универсальной нежели стандартные технологии OLE и СОМ.
В технологии OLE DB используется механизм провайдеров, под которыми понимают поставщиков данных, находящихся в надстройке над физическим форматом данных. Провайдер OLE DB представляет собой компонент
СОМ (Component Object Model), позволяющий принимать вызовы OLE DB
API (Application Program Interface) и выполнять все необходимое для обработки запроса к источнику данных. Кроме поставщиков данных, имеются
также сервис-провайдеры, реализующие самые различные сервисные функции. Технология OLE DB может использовать ОDВС для доступа к реляционным БД. В этом случае применяется OLE DB-провайдер для доступа к
ODBC данным.
Хотя ODBC и OLE DB считаются хорошими интерфейсами передачи
данных, но как программный интерфейс они имеют много ограничении, по76
скольку являются низкоуровневыми. Для снятия этих ограничений были
предложены технологии Data Access Objects (DAO) и ActiveX Data Objects
(ADO). Данные технологии представляют собой высокоуровневые объектные
модели (библиотеки функций) и создают еще один уровень абстракции между пользовательским приложением, ODBC и OLE DB (см. рис. 33). Технология DAO предназначена преимущественно для создания БД с помощью
СУБД Access, так как кроме замены совокупности низкоуровневых функций
ODBC несколькими высокоуровневыми, осуществляет также прямой доступ
к функциям ядра Microsoft Jet базы данных Access. Технология ADO предоставляет иерархическую модель объектов для доступа к различным ODBCпровайдерам данных и характеризуется еще более высоким уровнем абстракции.
Объектная модель ADO включает объекты, обеспечивающие соединение с провайдером данных, создание запросов
SQL к данным, создание набора записей
на основе запроса и т. д. Особенностью
технологии ADO является возможность
ее использования в Приложениях Интранет/Интернет для доступа к различным
источникам данных. В целом ADO можно охарактеризовать как наиболее современную технологию разработки приложений для работы с распределенными
Рисунок 33. Архитектура доступа БД по архитектуре клиент-сервер.
к данным Microsoft
8.2 БД в сети Internet
Обработка информации в среде Internet существенно отличается оперирования данными в локальной сети и, тем более, на отдельном ПК. Перечислим наиболее важные особенности:
1. Значительная протяженность коммуникационных линий, накладывает
принципиальные ограничения на временные характеристики обмена. Кроме
того, удаленность лишает смысла загрузку всех приложений с одного ПК на
другой и не позволяет выполнять пересылку больших объемов данных в реальном масштабе времени, в отличие от корпоративных БД локальных сетей.
2. Взаимодействие распределенных элементов информационных систем
происходит с помощью обмена пакетами или сообщениями. Отдельные программные компоненты информационной системы могут иметь разных производителей. В этом случае особую роль приобретает решение проблемы поддержки стандартов на сетевые протоколы и на язык SQL.
3. Internet отличает от остальных сетей то, что по масштабам она больше
всех других сетей (объединяет другие сети) и принципы ее организации оказывают существенное влияние на использование БД.
77
Работа Internet основана на использовании протокола TCP/IP (Transmission Control Protocol / Internet Protocol – Протокол управления передачей
данных/Протокол Интернет), который используется для передачи данных в
глобальной сети и во многих локальных сетях. TCP/IP в основном реализует
функции транспортного и сетевого уровней модели OSI. Он представляет собой семейство коммуникационных протоколов, которые по назначению
можно разделить на следующие группы:
• транспортные протоколы, служащие для управления передачей данных
между двумя узлами;
• протоколы маршрутизации, обрабатывающие адресацию данных и
определяющие кратчайшие доступные пути к адресату;
• протоколы поддержки сетевого адреса, предназначенные для идентификации узла по его уникальному номеру или имени;
• прикладные протоколы, обеспечивающие получение доступа к различным сетевым услугам;
• шлюзовые протоколы, помогающие передавать по сети сообщения о
маршрутизации и информацию о состоянии сети, а также обрабатывать данные для локальных сетей;
• другие протоколы, не относящиеся к указанным категориям, но обеспечивающие клиенту удобство работы в сети.
Доступ пользователей к ресурсам Internet обычно производится с помощью приложений-навигаторов, или обозревателей (browser). Обозреватель,
обеспечивая доступ пользователя к ресурсам сети, по существу является приложением-клиентом (или Web-клиентом). Приложением, предоставляющим
информационные ресурсы, является Web-сервер. Именно он осуществляет
основную работу по сбору и получению информации из разных источников,
после чего в стандартном виде предоставляет ее Web-клиенту. Рассмотрим
организацию выбора информации для пользователя, если она находится в базах данных.
Рисунок 34. Централизованная многопользовательская система
Архитектура информационных систем в Internet и интранете является
результатом эволюционного перехода от первых многопользовательских
централизованных вычислительных систем (мэйнфреймов) через системы
78
типа клиент-сервер к распределенным системам с централизованной обработкой и подготовкой информации к непосредственному потреблению. Рассмотрим кратко указанные этапы эволюции.
1. В мэйнфреймах (рис. 34) вычислительные ресурсы, хранимые данные
и программы обработки информации сконцентрированы в одной ЭВМ. Основным средством доступа был алфавитно-цифровой терминал (дисплей),
управляемый ЭВМ. Вся обработка информации и подготовка ее к выдаче выполнялись на центральной ЭВМ. С терминалов, как правило, в машину передавались коды нажатия клавиш или содержимое буфера экрана, а обратно на
терминал – отображаемые экраны с соответствующими кодами управления
отображением (аналог X-терминалов распределенного представления).
Достоинством системы является простота администрирования, защиты
информации и модификации системы, к недостаткам можно отнести высокую загрузку процессоров и линий связи (как следствие – невысокую реакцию системы при большом количестве пользователей), низкую надежность
(выход из строя ЭВМ приводит к полному отказу всей системы), сложность
масштабирования системы и некоторые другие.
2. Исторически следующим решением в области глобальных информационных систем явилась архитектура клиент-сервер (рис. 35). В этих системах место терминала занял ПК, а мэйнфрейма – сервер. Исходя из особенностей рассмотренных ранее конфигураций архитектуры клиент-сервер можно
полагать, что подобные информационные системы в среде Internet будут
иметь следующие достоинства: высокая живучесть и надежность, легкость
масштабирования, качественный пользовательский интерфейс, возможность
одновременной работы с несколькими приложениями, высокие характеристики оперативности обработки информации.
Основным недостатком клиент-серверных систем является то, что они
ориентированы на данные, а не на информацию. Это требует от пользователя
знания не только предметной области, а и специфики используемой прикладной программы. Существенным недостатком можно считать также сложность переноса этих систем на другие компьютерные платформы и интеграцию с другими пакетами из-за «закрытости» используемых протоколов взаимодействия компонентов систем. Еще один недостаток заключается в сложности администрирования системы и ее уязвимости при непредсказуемых
или злонамеренных действиях пользователя или компьютерных вирусов.
Рисунок 35. Система типа клиент-сервер
79
3. Корпоративные системы интранет, в отличие от систем клиентсервер, ориентированы не на данные, а на информацию в ее окончательном и
пригодном для использования неквалифицированным пользователем виде
(рис. 36).
Рисунок 36. Корпоративная система интранет
Новые системы объединяют в себе преимущества централизованных многопользовательских систем и систем типа клиент-сервер. Им присущи следующие черты:
• на сервере порождается информация, пригодная для использования, а
не данные (например, в случае СУБД – элементы данных БД);
• при обмене между клиентской и серверной частями используется протокол открытого стандарта, а не какой-то конкретной фирмы;
• прикладная система находится на сервере, и поэтому для работы пользователя на клиентском ПК достаточно иметь приложение-навигатор (могут
быть и другие решения, когда часть обработки производится на ПК клиента).
В случае, когда источником информации в Internet или интранет являются БД, имеет место взаимодействие компонентов WWW и традиционных
СУБД. Типовыми простейшими схемами организации функционирования
программных компонентов, использующих данные из некоторой БД в настоящее время можно считать следующие три: на стороне Web-клиента (рис.
37а), на стороне Web -сервера (рис. 37б) и на стороне сервера приложений
(рис. 37в).
А а
б
вв
Рисунок 37. Модели доступа к базе данных в Интернете
80
При доступе к БД на стороне клиента основным средством реализации
механизмов взаимодействия Web-клиента и сервера БД является язык Java.
Кроме того, могут использоваться элементы управления ActiveX. В качестве
вспомогательных средств обработки информации на клиентской стороне (но,
не для взаимодействия с БД) часто используются языки сценариев JavaScript,
Jscript и VBScript, разработанные для расширения возможностей декларативного языка HTML (в HTML нет операторов присваивания, сравнения, математических функций и пр.) на основе добавления процедурных средств. Приложения-сценарии выполняются на ПК Web-браузером в режиме интерпретации.
Для обращений к серверам БД из Java-приложений разработан стандарт
JDBC (Java DataBase Connectivity - совместимость БД для Java), основанный
на концепции ODBC. Стандарт JDBC разработан фирмами Sun/JavaSoft: и
обеспечивает универсальный доступ к различным БД на языке Java.
В модели доступа к БД на стороне сервера обращение к серверу БД
обычно производится путем вызова приложениями Web-сервера внешних по
отношению к ним сценариев в соответствии с соглашениями одного из интерфейсов: CGI (Common Gateway Interface – общий шлюзовый интерфейс),
FastCGI или API (Application Program Interface – интерфейс прикладного программирования). При этом, уже сами сценарии организовывают взаимодействие с сервером БД на языке SQL, либо непосредственно обращаясь к конкретному серверу БД, либо используя драйвер ODBC.
Внешние сценарии пишутся на обычных языках программирования типа
С, С++ и Паскаль или специализированных языках типа Perl или РНР. приложения, разработанные в соответствии с интерфейсом CGI, называются
CGI-сценариями.
Кроме того, для организации доступа серверных программ к информации из БД могут использоваться технологии динамического построения Webстраниц (ASP, РНР и IDC/HTX-страницы) на основе информации БД.
Доступе к БД на стороне сервера приложений обычно применяется при
использовании серверов приложений. Основным языком разработки распределенных приложений в этом случае можно считать язык Java, а также технологии CORBA и Enterprise JavaBeans.
Из трех рассмотренных схем однозначного предпочтения тому или иному варианту отдать нельзя. Все зависит от целей и условий разработки клиент-серверных приложений (наиболее существенными критериями оказываются используемая аппаратно-программная платформа, вид Web-сервера,
нагрузка на Web -сервер, а также характер решаемых задач).
Недостатком первой модели является то, что клиентская часть системы
оказывается более нагруженной, чем во второй модели. Кроме того, в некоторых случаях (например, при использовании технологии ActiveX) повышается угроза нарушения защиты информации на клиентской стороне. В то же
время разгружается Web-сервер, что является достоинством.
81
Достоинством модели доступа на стороне сервера является сравнительная простота клиентских программ и удобство администрирования системы, так как основная часть программного обеспечения находится на машине Web-сервера. Очевидным недостатком системы является возможное
ухудшение характеристик оперативности получения информации при большой нагрузке на Web-сервер и нехватке его мощности.
В третьей схеме предпринята попытка преодолеть недостатки второй
схемы в том случае, когда планируется большая нагрузка на Web-сервер.
8.3 Организация распределенных БД
В современных распределенных системах информация может храниться
централизованно или децентрализованно. В первом случае проблемы идентичности представления информации для всех пользователей не существует,
так как все последние изменения хранятся в одном месте. На практике чаще
информация изменяется одновременно в нескольких узлах распределенной
системы. В этом случае возникает проблема контроля за всеми изменениями
в данных и их предоставления в достоверном и целостном виде для всех
пользователей.
Существуют две основные технологии децентрализованного управления
БД: распределеных БД (Distributed DB) и тиражирования, или репликации,
БД (Data Replication).
Распределенная БД состоит из нескольких фрагментов, размещенных на
разных узлах сети и, возможно, управляемых разными СУБД. С точки зрения
приложений и пользователей, обращающихся к распределенной БД, последняя воспринимается как единая локальная БД. Информация о местоположении каждой из частей распределенной БД и другая служебная информация
хранится в так называемом глобальном словаре данных. В общем случае этот
словарь может храниться на одном из
узлов или тоже быть распределенным.
Основным достоинством модели распределенной БД является то, что пользователи всех узлов (при исправных
коммуникационных средствах) получают информацию с учетом всех последних изменений. Второе достоинство состоит в экономном использовании внешней памяти компьютеров, что
позволяет организовывать БД больших
объемов.
Рисунок 38. Модель распределенной К недостаткам модели распределенной БД относится следующее: жесткие
БД
требования к производительности и
надежности каналов связи, а также большие затраты коммуникационных и
вычислительных ресурсов из-за их связывания на все время выполнения
82
транзакций. При интенсивных обращениях к распределенной БД, большом
числе взаимодействующих узлов, низкоскоростных и ненадежных каналах
связи обработка запросов по этой схеме становится практически невозможной.
Модель тиражирования данных, в отличие от технологии распределенных БД, предполагает дублирование данных (создание точных копий) в узлах
сети (рис. 39). Данные всегда обрабатываются как обычные локальные. Поддержку идентичности копий друг другу в асинхронном режиме обеспечивает
компонент системы, называемый репликатором (replicator). При этом между
узлами сети могут передаваться как отдельные изменения, так и группы изменений. В течение некоторого времени копии БД могут отличаться друг от
друга.
К основным достоинствам модели
тиражирования БД (в сравнении с
предыдущей моделью) относятся: более высокая скорость доступа к данным, так как они всегда есть в узле;
существенное уменьшение передаваемого по каналам связи потока информации, поскольку происходит передача не всех операций доступа к
данным, а только изменений в БД;
повышение надежности механизмов
доступа к распределенным данным,
Рисунок 39. Модель тиражирования
поскольку нарушение связи не привоБД
дит к потере работоспособности системы (предполагается буферизация потока изменений, позволяющая корректно возобновить работу после восстановления связи).
Основной недостаток модели тиражирования БД заключается в том,
что на некотором интервале времени возможно «расхождение» копий БД.
Если отмеченный недостаток некритичен для прикладных задач, то предпочтительно иметь схему с тиражированием БД.
8.4 Облачные БД
Распределенные БД в последнее время получили самое широкое распространение в связи с процессами глобализации бизнес-процессов и могут
представлять собой обширные хранилища данных на децентрализованных
серверных ресурсах какой-либо корпорации. Однако наряду с преимуществами подобных информационных систем, такие БД очень ресурсоемки и
дорогостоящи. Во-первых, развертывание и поддержание распределенных
БД требует наличие немалого штата высокопрофессиональных ITспециалистов. Во-вторых, достаточно велика стоимость серверных ресурсов,
которые приходится приобретать независимо от срока эксплуатации проекта.
В-третьих, само программное обеспечение распределенных БД в рамках
83
стандартных платформ может оцениваться в сотни тысяч долларов. В связи с
этим в настоящее время возрастающую популярность приобретают так называемые «облачные» БД.
Cloud computing («облачные вычисления») – инновационная технология,
которая предоставляет динамично масштабируемые вычислительные ресурсы и приложения через Интернет в качестве сервиса под управлением поставщика услуг. «Облаком» метафорически называют Интернет, который
скрывает все технические детали доступа к данным.
Преимущества «облачных» БД заключаются в том, что аренда определенных функций у поставщика услуг обходится дешевле построения, обслуживания и сопровождения аналогичных систем внутри организации. Технология «облачных» БД позволяет свести затраты на модернизацию и поддержку сложной IT-инфраструктуры к обычной оплате «подписки» на услугу. Аккредитованный пользователь автоматически получает доступ к последним
версиям программного обеспечения. При этом данные будут храниться на
распределенных серверах и обладать более высокой надежностью – пользователям не нужно будет самостоятельно обеспечивать резервное копирование своих данных. Выделяют несколько разновидностей сервиса «облачных
вычислений».
IaaS (Infrastructure as a Service) – предложение развернутой компьютерной инфраструктуры (вычислительные ресурсы и системы хранения) в качестве услуги. Вместо приобретения серверов, программного обеспечения, места в центрах обработки данных или сетевого оборудования, можно купить
эти ресурсы в полном объеме как внешний сервис при требуемом качестве
обслуживания, с возможностью исполнения произвольной операционной системы и программ. Обычно такой сервис оплачивается исходя из обслуживания вычислительной базы и суммы использованных ресурсов.
PaaS (Platform as a Service) – модель, при которой поставщик предоставляет заказчику услугу по аренде вычислительной платформы, которая включает вычислительные ресурсы и системы хранения, а также операционные
системы и сопутствующие сервисы. Этот сервис значительно упрощает развертывание web-приложений без дополнительных затрат. Эта модель позволяет разработчикам масштабировать предоставляемое ПО, организовывать
его хостинг и продавать веб-приложения.
Одной из самых популярных моделей является SaaS (Software as a
Service). Это модель распространения программного обеспечения, при которой поставщик услуги размещает его у себя на сервере, организуя к нему доступ множества клиентов через Интернет. Поставщик обеспечивает поддержку и обновление web-приложений, а заказчики оплачивают доступ к
ним.
dSaaS (data Storage as a Service – хранилище как сервис) – модель, при
которой поставщик предоставляет заказчику место для хранения. При этом
обычно размер оплаты услуги зависит от максимального объема хранилища
и условий доступа, определяемых пропускной способностью канала.
84
Основные преимущества технологии «облачных вычислений»:
- Быстрое внедрение новых технологий.
- Уменьшение риска внедрения новых технологий.
- Глобальная протяженность и глобальная доступность платформы.
- Экономное расходование средств на IT – технологии.
Основными недостатками облачной платформы являются:
- Передача данных постороннему провайдеру.
- Хранение информации за пределами Вашей организации.
- Возможная несовместимость ПО облачной платформы с некоторыми
сервисами, используемыми организацией-заказчиком (т.н. вендорский замок).
Тема 9. Режим транзакций в БД
9.1 Понятие транзакции в БД
Транзакцией называется логическая единица работы в БД, состоящая из
совокупности высокоуровневых процедур, которая с точки зрения воздействия на БД рассматривается и обрабатывается системой как единое неделимое действие. Результаты действия процедур, входящих в транзакцию, либо
полностью принимаются, либо полностью отвергаются.
Понятие транзакции имеет непосредственную связь с понятием целостности БД. В системах с развитыми средствами контроля целостности каждая
транзакция начинается при целостном состоянии БД и должна оставить это
состояние целостным после своего завершения. Несоблюдение этого условия
приводит к тому, что вместо фиксации результатов транзакции происходит
ее откат, и БД остается в таком состоянии, в котором находилась к моменту
начала транзакции, т. е. в целостном состоянии. Часто БД могут обладать такими ограничениями целостности, которые просто невозможно не нарушить,
выполняя операцию изменения данных. Поэтому для поддержания подобных
ограничений целостности допускается их нарушение внутри транзакции с
тем условием, чтобы к моменту завершения транзакции условия целостности
были соблюдены.
Различаются два вида ограничений целостности: немедленно проверяемые и откладываемые. К немедленно проверяемым ограничениям целостности относятся такие ограничения, проверку которых бессмысленно или даже
невозможно откладывать. Немедленно проверяемые ограничения целостности соответствуют уровню отдельных операторов языкового уровня СУБД.
При их нарушениях не производится откат всей транзакции, а лишь отвергается соответствующий оператор. Откладываемые ограничения целостности –
это ограничения на БД, а не на какие-либо отдельные операции. По умолчанию такие ограничения проверяются при конце транзакции, и их нарушение
вызывает автоматическую замену оператора принятия изменений (COMMIT)
на оператор отката транзакции (ROLLBACK). Однако в некоторых системах
поддерживается специальный оператор принудительной проверки ограниче85
ний целостности внутри транзакции. Если после выполнения такого оператора обнаруживается, что условия целостности не выполнены, пользователь
может сам выполнить оператор ROLLBACK. или постараться устранить причины нецелостного состояния БД внутри транзакции.
9.2 Организация совместного доступа к общим данным
Важнейшей целью создания БД является организация параллельного доступа многих пользователей к общим данным, используемым ими совместно.
Обеспечить параллельный доступ несложно, если все пользователи будут
только читать данные, помещенные в базу. В этом случае работа каждого из
них не оказывает никакого влияния на работу остальных пользователей. Но
если два или больше пользователей одновременно обращаются к БД и хотя
бы один из них имеет целью обновить хранимую в базе информацию, возможно взаимное влияние процессов друг на друга, способное привести к потере согласованности данных. Существуют два подхода решения проблем
совместного доступа к общим данным: установка блокировок и управление
параллельностью выполнения транзакций.
В первом случае на время выполнения какой-либо операции в БД доступ
к используемому объекту со стороны других пользователей временно запрещается или ограничивается. Во втором случае при одновременном доступе к
одним и тем же данным операции манипулирования данными, заключенные
в рамки транзакции, чередуются, и таким образом достигается их параллельное выполнение. Однако, несмотря на то, что каждая из транзакций сама по
себе может быть выполнена вполне корректно, подобное чередование операций способно приводить к неверным результатам, из-за чего целостность и
согласованность базы данных будет нарушена. В большинстве случаев эти
два подхода применяются совместно.
Различают оптимистический и пессимистический подходы в управлении параллельностью выполнения транзакций. Пессимистический подход
обеспечивает более высокий уровень безопасности, поскольку откладывается
выполнение любых транзакций, потенциально способных войти в конфликт с
другими транзакциями. Оптимистический подход разрешает асинхронное
выполнение транзакций в предположении, что вероятность конфликта невысока. Проверка на наличие конфликта откладывается до завершения транзакции и ее фиксации в БД.
Блокировки.
Для организации многопользовательского доступа в СУБД применяется
механизм блокировок. Суть блокировки состоит в том, что на время выполнения какой-либо операции в БД доступ к используемому объекту со стороны
других пользователей временно запрещается или ограничивается. Например,
при копировании таблицы она блокируется от изменения, хотя и разрешено
просматривать ее содержимое. Блокировки устанавливаются СУБД автоматически, но возможно и их явное определение.
86
Рассмотрим четыре вида блокировок, перечисленные в порядке убывания строгости ограничений на возможные действия.
1. Полная блокировка. Означает полное запрещение любых операций над
объектами БД. Обычно применяется при изменении структуры объектов.
2. Блокировка от записи. Накладывается в случаях, когда можно читать
данные, но не изменять их. Изменение структуры данных также запрещается.
3. Предохраняющая блокировка от записи. Предохраняет объект от
наложения на него со стороны других операций полной блокировки либо
блокировки от записи. Этот вид блокировки позволяет тому, кто раньше «захватил» объект, успешно завершить модификацию объекта. Такая блокировка обычно применяется при совместном изменении данных несколькими
пользователями.
4. Предохраняющая полная блокировка. Предохраняет объект от наложения на него со стороны других операций полной блокировки. Обеспечивает
максимальный уровень совместного использования объектов. Используется,
например, для обеспечения одновременного просмотра несколькими пользователями одной таблицы. Тогда никому не будет позволено изменить структуру общей таблицы.
При одновременном выполнении различных операций над одним и тем
же объектом производится попытка их совмещения. Совмещение возможно
тогда, когда совместимыми сказываются блокировки, накладываемые конкурирующими операциями. В отношении перечисленных выше блокировок
действуют следующие правила совмещения:
• полная блокировка несовместима с другими блокировками, т. е. при
наличии полной блокировки над объектом нельзя производить другие операции, накладывающие со своей стороны любую блокировку;
• блокировка от записи совместима с аналогичной блокировкой и предохраняющей полной блокировкой;
• предохраняющая блокировка от записи совместима с обоими видами
предохраняющих блокировок;
• предохраняющая полная блокировка совместима со всеми видами блокировок, кроме полной.
В связи со свойством сохранения целостности БД транзакции являются
подходящими единицами изолированности. Действительно, если с каждым
сеансом работы с БД ассоциируется транзакция, то каждый пользователь
начинает работу с согласованным состоянием БД, т.е. с таким состоянием, в
котором БД могла бы находиться, даже если бы пользователь работал с ней в
одиночку. Следовательно, требуется, чтобы обновления, выполняемые некоторой транзакцией Т1, не были доступны для любой другой транзакции Т2 до
тех и только до тех пор, пока не будет завершено выполнение транзакции Т1,
т.е. другими словами необходима изолированность транзакций. Завершение
выполнения транзакции открывает доступ ко всем обновлениям, выполненным данной транзакцией.
87
9.3 Уровни изолированности транзакций
Существует несколько уровней изолированности транзакций. По приоритету их можно расположить в следующем порядке:
- READ UNCOMMITED (чтение незафиксированных данных)
- READ COMMITED (чтение зафиксированных данных)
- REPEATABLE READ (гарантия повторяемости считывания)
- SERIALIZABLE (способность к упорядочению).
Далеко не каждая СУБД поддерживает все уровни изолированности
транзакций. Последний уровень имеется лишь у наиболее развитых.
Если все транзакции выполняются на уровне способности к упорядочению, то чередующееся выполнение любого множества параллельных транзакций может быть упорядочено. Однако, если любая транзакция выполняется на более низком уровне изоляции, то существует множество различных
способов нарушения упорядоченности выполнения транзакций. Существуют
четыре особых случая нарушения способности к упорядочению.
1. Потерянные изменения. Результаты успешно завершенной операции
обновления одной транзакции могут быть перекрыты результатами выполнения другой транзакции. Допустим, транзакция T1 изменяет объект базы данных А. До завершения транзакции T1 транзакция T2 также изменяет объект
А, перекрывая таким образом результат предыдущей транзакции. Чтобы избежать такой ситуации, явно противоречащей требованию изолированности
пользователей, требуется до завершения транзакции T1 запретить любой
другой транзакции изменять объект А. Отсутствие потерянных изменений
является минимальным требованием к многопользовательской СУБД, поскольку в этом случае обеспечивается требование целостности БД при завершении любой транзакции.
2. Неаккуратное считывание или чтение «грязных данных». Допустим,
транзакция T1 изменяет объект базы данных А, а транзакция T2 читает объект А. Поскольку операция изменения еще не завершена, транзакция T2 видит несогласованные «грязные» данные, поскольку в следующий момент
времени транзакция T1 может быть отвергнута вследствие нарушения немедленно проверяемого ограничения целостности. Чтобы избежать ситуации
чтения «грязных» данных, до завершения транзакции T1, изменившей объект
А, никакая другая транзакция не должна иметь возможности читать объект
А.
3. Неповторяемое считывание. Допустим, транзакция T1 читает объем
А. До завершения транзакции T1 транзакция Т2 изменяет объект А и успешно завершается. Транзакция Т1 повторно читает объект А и видит его измененное состояние. Чтобы избежать неповторяющихся чтений, до завершения
транзакции Т1 никакая другая транзакция не должна иметь возможность изменять объект А. Отсутствие неповторяющихся чтений часто является мак88
симальным требованием изолированности транзакций, хотя это еще не гарантирует реальной изолированности пользователей.
4. Наличие фиктивных элементов. Допустим, что транзакция Т1 извлекает множество всех записей, которые удовлетворяют некоторому условию
(например, записи всех поставщиков из Москвы). Затем транзакция Т2 вставляет новую строку, которая удовлетворяет тому же условию и успешно завершается. Если транзакция Т1 вновь повторит ту же операцию извлечения,
что и раньше, то ею будет обнаружена ранее отсутствовавшая - «фиктивная»
строка. Данная ситуация также противоречит идее изолированности пользователей и может возникнуть даже на третьем уровне изолированности транзакций. Для ее устранения требуется более высокий уровень синхронизации
транзакций.
Возможности возникновения этих нарушений при различных уровнях
изоляции транзакций приведены в табл.1
X
S
X
да
нет
нет
S
да
нет
да
Таблица 1.
Для обеспечения реальной изолированности транзакций в СУБД применяется метод сериализации транзакций. Сериализиция транзакций – это определение последовательности выполнения транзакций, когда результат совместного выполнения транзакций эквивалентен результату последовательного выполнения этих же транзакций. Система, в которой поддерживается сериализация транзакций, обеспечивает реальную изолированность пользователей. Основная проблема состоит в выборе такого метода сериализации, который не слишком ограничивал бы их параллельность
Тривиальным решением является действительно последовательное выполнение транзакций. Но существуют ситуации, в которых можно выполнять
операторы разных транзакций в любом порядке с сохранением сериальности.
Примерами могут служить только читающие транзакции, а также транзакции, не конфликтующие по доступу к объектам БД.
9.4 Методы сериализации транзакций
Существуют два базовых подхода к сериализации транзакций: подход,
основанный на синхронизационных захватах (блокировках) объектов БД, и
подход, основанный на использовании временных меток. Суть обоих подходов состоит в обнаружении конфликтов транзакций и их устранении. Практические методы сериализации транзакций основываются на учете этих конфликтов. Для каждого из подходов имеются две разновидности - пессимистическая и оптимистическая. При применении пессимистических методов
(ориентированных на ситуации, когда конфликты возникают часто) конфликты распознаются и разрешаются немедленно при их возникновении (реаль89
ном или подразумеваемом). Оптимистические методы основываются на том,
что результаты всех операций модификации БД сохраняются в рабочей памяти транзакций. Реальная модификация БД производится только на стадии
фиксации транзакции. Тогда же проверяется, не возникают ли конфликты с
другими транзакциями.
Наиболее распространенным в централизованных СУБД (включающих
системы, основанные на архитектуре клиент-сервер) является подход, основанный на соблюдении двухфазного протокола синхронизационных захватов
объектов БД. В общих чертах протокол состоит в том, что перед выполнением любой операции в транзакции T над объектом базы данных r от имени
транзакции T запрашивается синхронизационный захват объекта r в соответствующем режиме (в зависимости от вида операции).
Основными режимами синхронизационных захватов являются:
 совместный режим - S (Shared), означающий разделяемый захват объекта и требуемый для выполнения операции чтения объекта;
 монопольный режим - X (eXclusive), означающий монопольный захват
объекта и требуемый для выполнения операций занесения, удаления и модификации.
Захваты объектов несколькими транзакциями по чтению совместимы,
т.е. нескольким транзакциям допускается читать один и тот же объект, захват
объекта одной транзакцией по чтению не совместим с захватом другой транзакцией того же объекта по записи, и захваты одного объекта разными транзакциями по записи не совместимы. Правила совместимости захватов одного
объекта разными транзакциями изображены на следующей таблице:
Для обеспечения условий третьего уровня изолированности синхронизационные захваты объектов, произведенные по инициативе транзакции, можно снимать только при ее завершении. Это требование порождает двухфазный протокол синхронизационных захватов - 2PL. В соответствии с этим
протоколом выполнение транзакции разбивается на две фазы:
 первая фаза транзакции - накопление захватов;
 вторая фаза (фиксация или откат) - освобождение захватов.
Достаточно легко убедиться, что при соблюдении двухфазного протокола синхронизационных захватов действительно обеспечивается сериализация
транзакций на третьем уровне изолированности. Основная проблема состоит
в том, что следует считать объектом для синхронизационного захвата?
В контексте реляционных баз данных возможны следующие альтернативы:
 файл - физический (с точки зрения базы данных) объект, область хранения нескольких отношений и, возможно, индексов;
 отношение - логический объект, соответствующий множеству кортежей данного отношения;
 страница данных - физический объект, хранящий кортежи одного или
нескольких отношений, индексную или служебную информацию;
 кортеж - элементарный физический объект базы данных.
90
На самом деле, когда мы говорим про операции над объектами базы
данных, то любая операция над кортежем, фактически, является и операцией
над страницей, в которой этот кортеж хранится, и над соответствующим отношением, и над файлом, содержащем отношение. Поэтому действительно
имеется выбор уровня объекта захвата.
Понятно, что чем крупнее объект синхронизационного захвата (неважно,
какой природы этот объект - логический или физический), тем меньше синхронизационных захватов будет поддерживаться в системе, и на это, соответственно, будут тратиться меньшие накладные расходы. Более того, если выбрать в качестве уровня объектов для захватов файл или отношение, то будет
решена даже проблема фантомов (если это не ясно сразу, посмотрите еще раз
на формулировку проблемы фантомов и определение двухфазного протокола
захватов). Но вся беда в том, что при использовании для захватов крупных
объектов возрастает вероятность конфликтов транзакций и тем самым
уменьшается допускаемая степень их параллельного выполнения. Фактически, при укрупнении объекта синхронизационного захвата мы умышленно
огрубляем ситуацию и видим конфликты в тех ситуациях, когда на самом деле конфликтов нет.
Разработчики многих систем начинали с использования страничных захватов, полагая это некоторым компромиссом между стремлениями сократить накладные расходы и сохранить достаточно высокий уровень параллельности транзакций. Но это не очень хороший выбор. Мы не будем останавливаться на деталях, но заметим, что использование страничных захватов
в двухфазном протоколе иногда вызывает очень неприятные синхронизационные проблемы, усложняющие организацию СУБД. В большинстве современных систем используются покортежные синхронизационные захваты.
Но при этом возникает очередной вопрос. Если единицей захвата является кортеж, то какие синхронизационные захваты потребуются при выполнении таких операций как уничтожение отношения? Было бы довольно нелепо
перед выполнением такой операции потребовать захвата всех существующих
кортежей отношения. Кроме того, это не предотвратило бы возможности параллельной вставки в другой транзакции нового кортежа в уничтожаемое отношение.
Подобные рассуждения привели к разработки аппарата гранулированных
синхронизационных захватов. При применении этого подхода синхронизационные захваты могут запрашиваться по отношению к объектам разного уровня: файлам, отношениям и кортежам. Требуемый уровень объекта определяется тем, какая операция выполняется (например, для выполнения операции
уничтожения отношения объектом синхронизационного захвата должно быть
все отношение, а для выполнения операции удаления кортежа - этот кортеж).
Объект любого уровня может быть захвачен в режиме S или X.
Теперь наиболее важное отличие, на котором, собственно, держится соответствие захватов разного уровня. Вводится специальные протокол гранулированных захватов и новые типы захватов: перед захватом объекта в ре91
жиме S или X соответствующий объект более верхнего уровня должен быть
захвачен в режиме IS, IX или SIX. Что же из себя представляют эти режимы
захватов?
IS (Intented for Shared lock) по отношению к некоторому составному объекту O означает намерение захватить некоторый входящий в O объект в совместном режиме. Например, при намерении читать кортежи из отношения R
это отношение должно быть захвачено в режиме IS (а до этого в таком же
режиме должен быть захвачен файл).
IX (Intented for eXclusive lock) по отношению к некоторому составному
объекту O означает намерение захватить некоторый входящий в O объект в
монопольном режиме. Например, при намерении удалять кортежи из отношения R это отношение должно быть захвачено в режиме IX (а до этого в таком же режиме должен быть захвачен файл).
SIX (Shared, Intented for eXclusive lock) по отношению к некоторому составному объекту O означает совместный захват всего этого объекта с намерением впоследствии захватывать какие-либо входящие в него объекты в монопольном режиме. Например, если выполняется длинная операция просмотра отношения с возможностью удаления некоторых просматриваемых кортежей, то экономичнее всего захватить это отношение в режиме SIX (а до
этого захватить файл в режиме IS).
Довольно трудно описать словами все возможные ситуации. Мы ограничимся приведением полной таблицы совместимости захватов, анализируя которую можно выявить все случаи (таблица 2):
X
S
IX
IS
SIX
да
да
да
да
да
X
нет
нет
нет
нет
нет
S
нет
да
нет
да
нет
IX
нет
нет
да
да
нет
IS
нет
да
да
да
да
SIX
нет
нет
нет
да
нет
Таблица 2.
Несмотря на привлекательность метода гранулированных синхронизационных захватов, следует отметить что он не решает проблему фантомов
(если, конечно, не ограничиться использованием захватов отношений в режимах S и X). Давно известно, что для решения этой проблемы необходимо
перейти от захватов индивидуальных объектов базы данных, к захвату условий (предикатов), которым удовлетворяют эти объекты. Проблема фантомов
не возникает при использовании для синхронизации уровня отношений
именно потому, что отношение как логический объект представляет собой
неявное условие для входящих в него кортежей. Захват отношения - это простой и частный случай предикатного захвата.
92
Поскольку любая операция над реляционной базой данных задается некоторым условием (т.е. в ней указывается не конкретный набор объектов базы данных, над которыми нужно выполнить операцию, а условие, которому
должны удовлетворять объекты этого набора), идеальным выбором было бы
требовать синхронизационный захват в режиме S или X именно этого условия. Но если посмотреть на общий вид условий, допускаемых, например, в
языке SQL, то становится абсолютно непонятно, как определить совместимость двух предикатных захватов. Ясно, что без этого использовать предикатные захваты для синхронизации транзакций невозможно, а в общей форме
проблема неразрешима.
К счастью, эта проблема сравнительно легко решается для случая простых условий. Будем называть простым условием конъюнкцию простых предикатов, имеющих вид
имя-атрибута { =, >, < } значение;
В типичных СУБД, поддерживающих двухуровневую организацию
(языковой уровень и уровень управления внешней памяти), в интерфейсе
подсистем управления памятью (которая обычно заведует и сериализацией
транзакций) допускаются только простые условия. Подсистема языкового
уровня производит компиляцию исходного оператора со сложным условием
в последовательность обращений к ядру СУБД, в каждом из которых содержатся только простые условия. Следовательно, в случае типовой организации
реляционной СУБД простые условия можно использовать как основу предикатных захватов. Заметим, что предикатные захваты простых условий описываются таблицами, немногим отличающимися от таблиц традиционных
синхронизаторов.
Одним из наиболее чувствительных недостатков метода сериализации
транзакций на основе синхронизационных захватов является возможность
возникновение тупиков (deadlocks) между транзакциями. Тупики возможны
при применении любого из рассмотренных нами вариантов.
Вот простой пример возникновения тупика между транзакциями T1 и T2:
 транзакции T1 и T2 установили монопольные захваты объектов r1 и r2
соответственно;
 после этого T1 требуется совместный захват r2, а T2 – совместный захват r1;
 ни одна из транзакций не может продолжаться, следовательно, монопольные захваты не будут сняты, а совместные - не будут удовлетворены.
Поскольку тупики возможны, и никакого естественного выхода из тупиковой ситуации не существует, то эти ситуации необходимо обнаруживать и
искусственно устранять.
Основой обнаружения тупиковых ситуаций является построение (или
постоянное поддержание) графа ожидания транзакций. Граф ожидания
транзакций - это ориентированный двудольный граф, в котором существует
два типа вершин - вершины, соответствующие транзакциям, и вершины, соответствующие объектам захвата. В этом графе существует дуга, ведущая из
93
вершины-транзакции к вершине-объекту, если для этой транзакции существует удовлетворенный захват объекта. Дуга из вершины-объекта к вершине-транзакции определена при условии, если транзакция ожидает удовлетворения захвата объекта. Легко показать, что в системе существует ситуация тупика, если в графе ожидания транзакций имеется хотя бы один цикл.
Традиционной техникой (для которой существует множество разновидностей) нахождения циклов в ориентированном графе является редукция графа.
Не вдаваясь в детали, редукция состоит в том, что прежде всего из графа
ожидания удаляются все дуги, исходящие из вершин-транзакций, в которые
не входят дуги из вершин-объектов. (Это как бы соответствует той ситуации,
что транзакции, не ожидающие удовлетворения захватов, успешно завершились и освободили захваты). Для тех вершин-объектов, для которых не осталось входящих дуг, но существуют исходящие, ориентация исходящих дуг
изменяется на противоположную (это моделирует удовлетворение захватов).
После этого снова срабатывает первый шаг и так до тех пор, пока на первом
шаге не прекратится удаление дуг. Если в графе остались дуги, то они обязательно образуют цикл (см. рис 40).
Рисунок 40. Редукция графа ожидания транзакций
Предположим, что нам удалось найти цикл в графе ожидания транзакций. Что делать теперь? Нужно каким-то образом обеспечить возможность
продолжения работы хотя бы для части транзакций, попавших в тупик. Разрушение тупика начинается с выбора в цикле транзакций так называемой
транзакции-жертвы, т.е. транзакции, которой решено пожертвовать, чтобы
обеспечить возможность продолжения работы других транзакций.
Грубо говоря, критерием выбора является стоимость транзакции;
жертвой выбирается самая дешевая транзакция. Стоимость транзакции определяется на основе многофакторной оценки, в которую с разными весами
входят время выполнения, число накопленных захватов, приоритет.
После выбора транзакции-жертвы выполняется откат этой транзакции,
который может носить полный или частичный характер. При этом, естественно, освобождаются захваты и может быть продолжено выполнение других транзакций. Естественно, такое насильственное устранение тупиковых
ситуаций является нарушением принципа изолированности пользователей,
которого невозможно избежать.
Заметим, что в централизованных системах стоимость построения графа
ожидания сравнительно невелика, но она становится слишком большой в понастоящему распределенных СУБД, в которых транзакции могут выполнять94
ся в разных узлах сети. Поэтому в таких системах обычно используются другие методы сериализации транзакций.
Еще одно замечание. Чтобы минимизировать число конфликтов между
транзакциями, в некоторых СУБД (например, в Oracle) используется следующее развитие подхода. Монопольный захват объекта блокирует только изменяющие транзакции. После выполнении операции модификации предыдущая версия объекта остается доступной для чтения в других транзакциях.
Кратковременная блокировка чтения требуется только на период фиксации
изменяющей транзакции, когда обновленные объекты становятся текущими.
Альтернативный метод сериализации транзакций, хорошо работающий в
условиях редких конфликтов транзакций, основан на использовании временных меток. Основная идея метода (у которого существует множество разновидностей) состоит в следующем: если транзакция T1 началась раньше транзакции T2, то система обеспечивает такой режим выполнения, как если бы T1
была целиком выполнена до начала Т2. Для этого каждой транзакции Т
предписывается временная метка t, соответствующая времени начала Т. При
выполнении операции над объектом r транзакция T помечает его своей временной меткой и типом операции (чтение или изменение). Перед выполнением операции над объектом r транзакция T1 проверяет, не закончилась ли
транзакция Т, пометившая этот объект. Если Т закончилась, T1 помечает
объект r и выполняет свою операцию. Если транзакция Т не завершилась, то
T1 проверяет конфликтность операций. Если операции неконфликтны, при
объекте r остается или проставляется временная метка с меньшим значением,
и транзакция T1 выполняет свою операцию. Если операции T1 и T конфликтуют, то при t(Т) > t(T1) (т. е. транзакция T является более «молодой», чем
T1), производится откат T, и T1 продолжает работу. Если же t(T) < t(T1), то
T1 получает новую временную метку и начинается заново. К недостаткам
метода временных меток относятся потенциально более частые откаты транзакций, чем в случае использования синхронизационных захватов. Это связано с тем, что конфликтность транзакций определяется более грубо. Кроме того, в распределенных системах не очень просто вырабатывать глобальные
временные метки. Но все эти недостатки окупаются тем, что не нужно распознавать и устранять тупики, реализация чего в распределенных системах стоит очень дорого.
9.5 Протоколы фиксации транзакций
В настоящее время наиболее широко используются два протокола фиксации транзакции: двухфазный и трехфазный. Рассмотрим их вкратце.
Прежде всего, будем считать, что выполняется распределенная транзакция, с которой связан некоторый узел, функционирующий как координатор
(диспетчер транзакции). Обычно координатором является узел сети, где
транзакция была инициирована. Узлы, на которых глобальная транзакция создает агентов, назовем участниками (диспетчерами ресурсов). Координатор
транзакции знает идентификаторы всех участников, а каждый участник знает
95
идентификатор координатора, но не обязан знать идентификаторы других
участников.
Двухфазный протокол фиксации транзакций выполняется в два этапа:
голосование (voting phase) и принятие решения (decision phase). Этот протокол предполагает, что каждый узел имеет свой собственный журнал, с помощью которого можно зафиксировать или отменить транзакцию. Для этого в
журналы координатора и участников вносятся записи о приеме и посылке
команд (сообщений). Во избежание блокирования из-за бесконечного ожидания ответов от других участников протокола в протоколе используется механизм тайм-аутов.
На первом этапе координатор опрашивает всех участников командой
PREPARE , готовы ли они к фиксации транзакции, и переходит к ожиданию
ответов.
На втором этапе если хотя бы один из участников потребует отката (команда ABORT) или не ответит на запрос в течение установленного интервала
времени, координатор указывает всем участникам на необходимость выполнения отката данной транзакции (команда GLOBAL_ABORT). В случае получения подтверждений о фиксации транзакций от всех участников (команды
READY_COMMIT), координатор отправляет всем участникам команду глобальной фиксации транзакции GLOBAL_COMMIT). Если участник не получает от координатора в установленное время команды GLOBAL_COMMIT
или GLOBAL_ABORT, то он просто выполняет откат транзакции. Когда некоторый участник требует отката транзакции, то он имеет право выполнить его
немедленно. По существу каждый участник имеет право вы полнить откат
своей субтранзакции в любое время до отправки согласия на ее фиксацию.
Такой тип отката называют односторонним откатом.
Действия, которые выполняются в случае возникновения тайм-аутов,
описываются протоколом аварийного завершения (termination protocol).
Предпринимаемые при этом действия зависят от того, у кого возникло это
событие (у координатора или участника), в каком состоянии был объект, а
также какое сообщение было получено. Например, в случае появления таймаута на стороне координатора во время ожидания поступления от всех участников уведомлений о принятом глобальном решении по некоторой транзакции, координатор просто повторяет рассылку о принятом решении на те узлы, которые не прислали ожидаемого подтверждения.
Действия, которые выполняются отказавшими узлами после перезапуска, описываются протоколом восстановления. Предпринимаемые действия
системы после отказа также зависят от обстоятельств, и, главным образом, от
этапа обработки транзакции координатором или участником. Пусть, например, отказ произошел у участника в его начальном состоянии (до момента
получения им команды PREPARE). Поскольку координатор не может принять решение о глобальной фиксации транзакции в случае, когда хотя бы
один узел не отвечает, поэтому для этого участника целесообразно выполнить откат транзакции в одностороннем порядке.
96
Протокол двухфазной фиксации транзакций позволяет управлять процессом обработки распределенных транзакций в достаточно широком диапазоне реальных ситуаций. Так, в случае отказа основного управляющего объекта-координатора, у участника имеется возможность обратиться за информацией о принятом глобальном решении к другим участникам взаимодействия. Если же отказал только узел координатора, а все остальные узлы «живы», то участники могут выбрать на роль координатора один из имеющихся
узлов. Эти процедуры описываются протоколами проведения выборов. Одним из простых и эффективных протоколов проведения выборов является
протокол, при котором все узлы упорядочены и имеют идентификаторы, а
роль координатора выполняет узел с наименьшим идентификационным номером из числа функционирующих в произвольный момент времени. Согласно протоколу, каждый узел должен послать сообщения на узлы с большими порядковыми номерами. Тогда координатором будет тот узел, который
не получит сообщений от узлов с меньшими, чем у него порядковыми номерами.
Существует несколько способов обмена сообщениями при реализации
протокола двухфазной фиксации транзакций: централизованный (через узелкоординатор), линейный (каждый узел взаимодействует только с узлами,
имеющими ближайшие меньшие и большие номера) и распределенный (сообщения пересылаются по схеме «каждый – каждому»). Эти способы имеют
свои достоинства и недостатки, которые влияют на живучесть системы, а
также количество рассылаемых сообщений или время принятия решения.
Протокол двухфазной фиксации транзакций не гарантирует отсутствие
блокировок в некоторых случаях. Блокировка, например, может иметь место
в случае, когда на некотором узле истек тайм-аут после отправки своего согласия на фиксацию транзакции, но так и не получена информация о принятом глобальном решении от координатора, а те узлы, с которыми данный
узел может обмениваться сообщениями, также не имеют информации о решении координатора. Подобные проблемы решаются в усовершенствованном варианте – трехфазном протоколе фиксации транзакций.
Протокол трехфазной фиксации транзакций не приводит к блокировкам
в условиях отказа узлов, за исключением случая отказа всех узлов. Однако
отказы линий связи могут привести к тому, что на разных узлах будут приняты разные решения, что является нарушением принципа неразрывности глобальной транзакции. Для использования протокола необходимо соблюдение
трех условий: сеть является неразделяемой, всегда доступен по крайней мере
один узел и отказать одновременно могут не более К узлов сети (такие системы называют К-устойчивыми).
Основным преимуществом протокола является устранение периода ожидания в состоянии неопределенности с момента подтверждения участниками
своего согласия о фиксации транзакции до момента получения от координатора сообщения о фиксации или отмене транзакции. Для этого в протоколфиксации транзакций введена дополнительная фаза – предфиксации. Таким
97
образом протокол включает в себя три фазы: голосование, предфиксация
транзакции и принятие глобального решения.
В целом взаимодействие координатора с участниками происходит следующим образом. После получения результатов голосования от всех участников координатор рассылает сообщение о предфиксации PRE-COMMIT, извещающее о готовности всех участников зафиксировать результаты транзакции. В ответ на него каждый участник подтверждает получение этого сообщения. После приема подтверждений от всех участников координатор рассылает команду глобальной фиксации транзакции. Обработка ситуации, когда некоторый участник потребовал отката транзакции, выполняется так же,
как и в протоколе двухфазной фиксации транзакции.На этапе предфиксации
координатор и участники также переходят на некоторое время в состояние
ожидания, однако все функционирующие процессы получают информацию о
глобальном решении зафиксировать транзакцию еще до того, как первый
процесс выполнит фиксацию результатов транзакции. Это позволяет участникам действовать независимо друг от друга в случае отказа.
Тема 10. Индексирование в БД
10.1 Понятие индекса в БД
Как отмечалось выше (см. тему 5), для обеспечения адресации кортежей
внутри отношения (отсутствия их дублирования), а также организации связей
между отношениями, используются явные значения уникальных атрибутов
(ключей). Для физической реализации этих функций в БД применяют индексирование.
Индекс - это внутренняя таблица БД, имеющая два столбца: упорядоченные значения выражения, содержащего все поля, необходимые для идентификации конкретной записи-кортежа, и физический адрес области на носителе, содержащей элементы данных этой записи. Ключевые атрибуты отношений, как правило, индексируются автоматически. Формируемый при этом
индекс называется первичным.
Вторым, не менее важным назначением индексов является ускорение доступа к данным и, как следствие, повышение скорости выполнения запросов
на выборку данных. Этот эффект достигается заменой последовательного
или пошагового сканирования записей при поиске нужных данных на более
эффективные алгоритмы, учитывающие существующую индексную структуру. В этом случае индекс играет роль оглавления отношения, просмотр значений индексного поля предшествует обращению к элементам данных кортежей отношения. Для реализации ускоренного доступа к данным пользователи
могут задавать собственные индексы для неключевых атрибутов отношений.
В этом случае соответствующие индексные структуры принято называть
вторичными.
Варианты решения проблемы организации физического доступа к информации зависят в основном от следующих факторов:
98
• вида содержимого в столбце ключа записей;
• типа используемых ссылок (указателей) на кортеж основного отношения;
• метода поиска нужных элементов данных.
В поле ключа индексного файла можно хранить значения ключевых полей индексируемого отношения либо свертку ключа (так называемый хешкод).
Для организации ссылки на запись таблицы могут использоваться три
типа адресов: абсолютный (действительный), относительный и символический (идентификатор).
10.2 Схемы организации индексации БД
Проиллюстрируем организацию первичного индексирования отношений
двумя схемами: одноуровневой и двухуровневой. При этом примем ряд предположений, обычно выполняемых в современных вычислительных системах.
Пусть операционная система поддерживает прямую организацию данных на
физических дисках, основные отношения и индексные файлы хранятся в отдельных файлах. Информация файлов хранится в виде совокупности блоков
фиксированного размера, например целого числа кластеров.
При одноуровневой схеме в индексном файле хранятся короткие записи,
имеющие два поля: поле содержимого старшего ключа или хеш-кода ключа
адресуемого блока и поле адреса начала этого блока (рис. 41).
Рисунок 41. Одноуровневая схема индексации
В каждом блоке записи располагаются в порядке возрастания значения
ключа или свертки. Старшим ключом каждого блока является ключ его последней записи.
Основным недостатком одноуровневой схемы является то, что ключи
(свертки) записей хранятся вместе с записями. Это приводит к увеличению
99
времени поиска записей из-за большой длины просмотра (значения данных в
записях приходится пропускать).
В этой схеме индекс основной таблицы распределен по совокупности
файлов: одному файлу главного индекса и множеству файлов с блоками
ключей.
Двухуровневая схема в ряде случаев оказывается более рациональной, к
ней ключи (свертки) записей отделены от содержимого записей (рис. 42)
.
Рисунок 42. Двухуровневая система индексации
Одна из возможностей организации вторичного индексирования (определяющего значения неуникальных атрибутов) проиллюстрирована нами во
время рассмотрения модели инвертированных списков (см. тему 2)
Если в отношениях БД поиск часто ведется по значениям нескольких атрибутов одновременно, то для его ускорения необходимо определить составной индекс. Данный вид индексирования по типу своей организации от
обычных индексов отличается незначительно. Разница состоит в том, что
первое поле индекса содержит свертку значений всех полей, входящих в индекс. К примеру, нам требуется часто искать некоторое предприятие по
стране регистрации, городу и собственно по его имени. Тогда при создании
индекса вначале производится сортировка по всем полям, включенным в индекс, в порядке их следования (т. е. будет произведена сортировка по стране
регистрации, затем внутри каждой страны по городу и, наконец, внутри каждого города по названию предприятия). Затем па основе отсортированных
значений происходит создание первого поля индекса и заполнение второго
поля указателями на блоки данных физического носителя, содержащими записи со значениями индексированных полей. Очевидно, что совокупность
вторичных индексов, созданных для каждого из полей, входящих в составной индекс, не сможет его заменить, поскольку результат вложенной сортировки не равен результату последовательной сортировки.
Главная причина повышения скорости выполнения различных операций
в индексированных отношениях состоит в том, что основная часть работы
производится с небольшими индексными файлами, а не с самими таблицами.
100
Наибольший эффект повышения производительности работы с индексированными таблицами достигается для значительных по объему таблиц. Индексирование требует небольшого дополнительного места на диске и незначительных затрат процессора на изменение индексов в процессе работы. Индексы в общем случае могут изменяться перед выполнением запроса к БД,
после выполнения запросов к БД, по специальным командам пользователя
или программным вызовам приложений.
Наряду со схемами индексирования отношений можно также рассматривать следующие типы организации (структуры) индексов: T-деревья, Bдеревья и хеширование. Общей идеей любой организации индекса, поддерживающего прямой доступ по ключу и последовательный просмотр в порядке возрастания или убывания значений ключа, является хранение упорядоченного списка значений ключа с привязкой к каждому значению ключа
списка идентификаторов кортежей. Одна организация индекса отличается от
другой главным образом в способе поиска ключа с заданным значением.
10.3 T-деревья
Исторически один из самых первых подходов к упорядочиванию индексов. Также с небольшими оговорками для этой структуры можно использовать названия: АВЛ-деревья и бинарные (двоичные) деревья.
Кратко подобную структуру можно описать следующим образом. Тдерево представляет собой граф без циклов, в каждой вершине (узле) которого будем хранить значения индексов. Фиксируем некоторую вершину и назовем ее корнем дерева. Соседние с ней вершины назовем сыновними и расположим чуть ниже. У этих вершин могут быть свои сыновние вершины. Каждая вершина может обладать только двумя сыновьями. Если вершина не имеет сыновей, то назовем ее листом. У всякой вершины, кроме корня, должен
быть единственный отец (корень отца не имеет). Важным свойством Тдеревьев является их сбалансированность, это означает, что длина пути от
корня дерева к любому его листу одна и та же (см. рис. 43).
Рисунок 43. Т-дерево
Внутри Т-дерева можно выделить три типа узлов. Если узел имеет двух
потомков, его называют внутренним. При наличии у узла одного потомкалиста и одной ветви его называют полулистьевым, а в случае присутствия
101
двух потомков-листьев – листьевым соответственно. Для примера, структура
внутреннего узла показана на рис. 44.
Алгоритм поиска можно записать в рекурсивном виде, пользуясь свойством бинарности. Если искомый элемент меньше граничного элемента узла,
то поиск продолжается в левом поддереве, если равен – то поиск считается
успешным (найден соответствующий лист, содержащий адрес нужного элемента данных БД), если больше – поиск продолжается в правом поддереве;
поиск считается неудачным, если мы дошли до пустого поддерева, а элемент
найден не был.
Рисунок 44. Структура внутреннего узла Т-дерева
10.4 B-деревья
Видимо, наиболее популярным подходом к организации индексов в БД
является использование техники B-деревьев. С точки зрения внешнего логического представления B-дерево – это сбалансированное сильно ветвистое
дерево во внешней памяти. Ветвистость дерева – это свойство каждого узла
дерева ссылаться на большое число узлов-потомков (см. рис. 45).
С точки зрения физической организации B-дерево представляется
как мультисписочная структура
страниц внешней памяти, т.е. каждому узлу дерева соответствует
блок внешней памяти (страница).
Внутренние и листовые узлы
Рисунок 45. В-дерево
обычно имеют разную структуру.
В типовом случае структура
внутреннего узла выглядит следующим образом:
Рисунок 46. Узел М
102
При этом выдерживаются следующие свойства:
 kM(1) <= kM(2) <= ... <= kM(n);
 в узле дерева Ni находятся ключи kN со значениями kM(i)<=kN
<=kM(i+1).
Листовая страница обычно имеет следующую структуру:
Рисунок 47. Листовой узел
Листовой узел обладает следующими свойствами:
 k(1) < k(2) < ... < k(t);
 id(1), id(2)… id(t) – упорядоченный список идентификаторов кортежей,
включающих значение соответствующих ключей;
 листовые страницы связаны одно- или двунаправленным списком.
Поиск в B-дереве – это прохождение от корня к листу в соответствии с
заданным значением ключа. Заметим, что поскольку деревья сильно ветвистые и сбалансированные, то для выполнения поиска по любому значению
ключа потребуется одно и то же (и обычно небольшое) число обменов с
внешней памятью. Более точно, в сбалансированном дереве, где длины всех
путей от корня к листу одни и те же, если во внутренней странице помещается n ключей, то при хранении m записей требуется дерево глубиной logn(m).
Если n достаточно велико (обычный случай), то глубина дерева невелика, и
производится быстрый поиск. Для сравнения эта величина для Т-дерева –
log2(m)
Основной "изюминкой" B-деревьев является автоматическое поддержание свойства сбалансированности.
Однако при этом следует заметить, что при организации многопользовательского доступа к БД с организацией индексов в виде B-деревьев, приходится решать ряд нетривиальных проблем, связанных с размером захватываемого объекта (объект блокировки). Наиболее очевидный способ предполагает блокировать доступ ко всему дереву целиком даже для внесения одной записи, что неэффективно.
10.5 Хеширование.
Как мы уже определили раньше, индекс представляет собой внутреннюю
таблицу, хранящую все значения атрибутов, включенных в индекс и идентификаторы (адреса) кортежей, соответствующие этим индексным значениям.
Вместо явных значений ключевых атрибутов в индексных полях таблицы
можно хранить результат их математического преобразования с помощью
хеш-функции (так называемый хеш-код). Преимущество хранения хеш-кода
103
вместо соответствующих значений состоит в том, что длина свертки не зависит от длины исходных значений и имеет достаточно малую величину
(например, 4 байта), что существенно снижает время поиска.
Записи в хешированием файле распределены произвольным образом по
всему доступному для него физическому пространству. По этой причине хешированные файлы иногда называют файлами с произвольным или прямым
доступом (random file или direct file).
Хеш-функция выбирается таким образом, чтобы записи внутри файла
были распределены наиболее равномерно. Один из методов создания хешфункции называется сверткой (folding) и основан на выполнении некоторых
арифметических действий над различными частями ключевого поля. При
этом символьные строки преобразуются в целые числа с использованием некоторой кодировки (на основе расположения букв в алфавите или кодов символов ASCII). Например, можно преобразовать в целое число элементы символьного атрибута составного уникального ключа (если рассматривать серию
и номер паспорта как уникальный ключ), а затем сложить полученное значение с остальными цифрами этого номера. Вычисленная сумма используется в
качестве адреса дисковой страницы, на которой будет храниться запись, характеризующая данного человека.
Более популярный альтернативный метод основан на хешировании с
применением остатка от деления. В этом методе используется функция MOD,
которой передается значение поля. Функция делит полученное значение на
некоторое заранее заданное целое число, после чего остаток от деления используется в качестве адреса на диске.
Недостатком большинства хеш-функций является то, что они не гарантируют получение уникального адреса, поскольку количество возможных
значений поля хеширования может быть гораздо больше количества адресов,
доступных для записи. Случай, когда один и тот же адрес генерируется для
двух или более записей, называется конфликтом (collision), a подобные записи – синонимами. В этой ситуации одну из записей (последнюю добавленную) необходимо вставить в другую позицию, поскольку место с вычисленным для нее хеш-адресом уже занято. Разрешение конфликтов усложняет сопровождение хешированных файлов и снижает общую производительность
их работы. Для разрешения конфликтов можно использовать следующие методы:

открытая адресация;

несвязанная область переполнения;

связанная область переполнения;

многократное хеширование.
Открытая адресация.
При возникновении конфликта система выполняет линейный поиск первого доступного слота для вставки в него новой записи. После неудачного
поиска пустого слота в последнем сегменте поиск продолжается с первого
сегмента. При выборке записи используется тот же метод, который приме104
нялся при сохранении записи, за исключением того, что запись в данном случае рассматривается как не существующая, если до обнаружения искомой записи будет обнаружен пустой слот.
Основным недостатком подхода является то, что при использовании открытой адресации конфликты, устраненные с помощью первого свободного
слота, могут вызвать дополнительные конфликты с записями, которые будут
иметь хеш-значение, равное адресу этого прежде свободного слота. Таким
образом, количество конфликтов будет возрастать, а производительность –
падать. С другой стороны, если количество конфликтов удастся свести к минимуму, то линейный поиск в малой области переполнения будет выполняться достаточно быстро.
Несвязанная область переполнения
Вместо поиска пустого слота для разрешения конфликтов можно использовать область переполнения, предназначенную для размещения записей, которые не могут быть вставлены по вычисленному для них адресу хеширования.
Преимущества:
- Высокая эффективность операций вставки.
- Нефиксированный размер БД.
- Высокая эффективность операций поиска и удаления в случае небольшого количества конфликтов (при малом количестве записей в области переполнения, которая представляет собой неупорядоченный последовательный
файл со всеми его преимуществами и недостатками).
Основной недостаток: значительная потеря производительности в случае
большого количества конфликтов, количество которых увеличивается по мере заполнения БД.
Связанная область переполнения
Как и в предыдущем методе, в этом методе для разрешения конфликтов
с записями, которые не могут быть размещены в слоте с их адресом хеширования, используется область переполнения. Однако в данном методе каждому
сегменту выделяется дополнительное поле, которое иногда называется указателем синонима. Оно определяет наличие конфликта и указывает страницу в
области переполнения, использованную для его разрешения. Если указатель
равен нулю, то никаких конфликтов нет.
Для более быстрого доступа к записи переполнения можно использовать
указатель синонима, который указывает на адрес слота внутри области переполнения, а не на адрес сегмента. Записи внутри области переполнения также
имеют указатели синонима, которые содержат в области переполнения адрес
следующего синонима для такого же адреса, поэтому все синонимы одного
адреса могут быть извлечены с помощью цепочки указателей.
Многократное хеширование
Альтернативный способ разрешения конфликтов заключается в применении второй хеш-функции, если первая функция приводит к возникновению
конфликта. Цель второй хеш-функции заключается в получении нового адре105
са хеширования, который позволил бы избежать конфликта. Вторая хешфункция обычно используется для размещения записей в области переполнения.
При работе с хешированными файлами запись может быть достаточно
эффективно найдена с помощью первой хеш-функции, а в случае возникновения конфликта для определения ее адреса следует применить один из перечисленных выше способов. Прежде чем обновить хешированную запись, ее
следует найти. Если обновляется значение поля, которое не является хешключом, то такое обновление может быть выполнено достаточно просто,
причем обновленная запись сохраняется в том же слоге. Но если обновляется
значение хеш-ключа, то до размещения обновленной записи потребуется вычислить хеш-функцию. Если при этом будет получено новое хеш-значение,
то исходная запись должна быть удалена из текущего слота и сохранена по
вновь вычисленному адресу.
Перечисленные выше методы хеширования являются статическими, в
том смысле, что пространство хеш-адресов задается непосредственно при создании файла. Считается, что пространство файла уже насыщено, когда оно
уже почти полностью заполнено и администратор базы данных вынужден
реорганизовать его хеш-структуру. Для этого может потребоваться создать
новый файл большего размера, выбрать новую хеш-функцию и переписать
старый файл во вновь отведенное место. В альтернативном подходе, получившем название динамического хеширования, допускается динамическое
изменение размера файла с целью его постоянной модификации в соответствии с уменьшением или увеличением размеров базы данных.
Основной принцип динамического хеширования заключается в обработке числа, выработанного хеш-функцией в виде последовательности битов, и
распределении записей по сегментам на основе так называемой прогрессирующей оцифровки (progressive digitization) этой последовательности. Динамическая хеш-функция вырабатывает значения в широком диапазоне, а
именно b-битовые двоичные целые числа, где b обычно равно 32.
Использование метода хеширования для извлечения записей основано на
полностью известном значении хеш-поля. Поэтому, как правило, хеширование не подходит для операций извлечения данных по заданному шаблону или
диапазону значений. Более того, хеширование не подходит для поиска и извлечения данных по любому другому полю, отличному от поля хеширования.
ЧАСТЬ IV. РЕАЛИЗАЦИЯ БД НА СТАНДАРТНЫХ
ПЛАТФОРМАХ
Данная часть посвящена обсуждению основных аспектов разворачивания БД с помощью стандартных программных средств. Типизированы СУБД,
присутствующие на рынке современного ПО. Особое внимание уделено
106
CASE-системам как наиболее эффективному средству проектирования и реализации БД. Достаточно подробно рассматривается вопрос организации безопасной работы БД. Значительная часть раздела отнесена к тематике реализации РБД с помощью SQL-совместимых платформ.
Тема 11. Системы управления БД
11.1 Классификация и функции СУБД
В общем случае под СУБД можно понимать любой программный продукт, поддерживающий процессы создания, ведения и использования БД. В
качестве основных классификационных признаков можно использовать следующие: вид программы, характер использования, модель данных. Названные классификаторы существенно влияют на целевой выбор СУБД и эффективность использования разрабатываемой информационной системы. Рассмотрим, какие из имеющихся на рынке приложений имеют отношение к БД,
и в какой мере они связаны с базами данных.
К СУБД относятся следующие основные виды ПО:
• полнофункциональные СУБД;
• серверы БД;
• клиенты БД;
• средства разработки программ работы с БД.
Полнофункционалъные СУБД представляют собой традиционные СУБД,
которые сначала появились для больших машин, затем для мини-машин и,
наконец, для ПК. Из массива всех СУБД этот вид ПО является наиболее многочисленным и мощным по своим возможностям. К Полнофункционалъным
СУБД относятся, например, такие пакеты, как Clarion Database Developer, DataEase, dBase IV, MS Access, MS FoxPro, Paradox R:BASE.
Обычно полнофункционалъные СУБД имеют развитый интерфейс, позволяющий с помощью команд меню выполнять основные действия с БД: создавать и модифицировать структуры таблиц, вводить данные, формировать
запросы, разрабатывать отчеты, выводить их на печать и т. п. Многие полнофункционалъные СУБД включают развитые средства программирования
для профессиональных разработчиков.
Некоторые системы имеют в качестве вспомогательных и дополнительные средства проектирования схем БД или CASE-подсистемы. Для обеспечения доступа к другим БД или к данным SQL-серверов полнофункциональные
СУБД имеют факультативные модули.
Серверы БД предназначены для организации центров обработки данных
в сетях ПК. Эта группа СУБД менее многочисленна, но в последнее время
она быстро развивается. Серверы БД реализуют функции управления базами
данных, запрашиваемые другими (клиентскими) программами, с помощью
высокоуровневых операторов (см. тему 7). Примерами серверов БД являются
следующие программы: NetWare SQL, MS SQL Server, MySQL, InterBase, Oracle.
107
В роли клиентских программ для серверов БД в общем случае могут использоваться различные программы: полнофункционалъные СУБД, электронные таблицы, текстовые процессоры, приложения электронной почты и т. д.
При этом элементы пары «клиент – сервер» могут принадлежать одному или
разным производителям ПО. В случае, когда клиентская и серверная части
выполнены одной фирмой, естественно ожидать, что распределение функций
между ними выполнено рационально. В остальных случаях обычно преследуется цель обеспечения доступа к данным «любой ценой».
Средства разработки программ работы с БД могут использоваться для
создания разновидностей следующих приложений:
• клиентского ПО;
• серверов БД и их отдельных компонентов;
• пользовательских приложений.
Программы первого и второго вида довольно малочисленны, так как
предназначены, главным образом, для системных программистов. Пакетов
третьего вида гораздо больше, но меньше, чем полнофункциональных СУБД.
К средствам разработки пользовательских приложений относятся системы программирования, например Clipper, разнообразные библиотеки процедур для различных языков программирования, а также пакеты автоматизации
разработок (в том числе систем типа клиент-сервер). В числе наиболее распространенных можно назвать следующие инструментальные системы: Delphi, Power Builder, Visual Studio, SILVERRUN, S-Designor.
Если говорить о конкретных системах программирования (для языков
С++, С#, Visual Basic, Java и др.), то все они содержат некоторые средства
доступа к наиболее широко используемым БД.
Кроме перечисленных средств, для управления данными и организации
обслуживания БД используются различные дополнительные средства, к примеру, мониторы транзакций (см. подраздел 7.5).
По характеру использования СУБД делят на персональные и многопользовательские.
Персональные СУБД обычно обеспечивают возможность создания персональных БД и недорогих приложений, работающих с ними. Персональные
СУБД или разработанные с их помощью приложения зачастую могут выступать в роли клиентской части многопользовательской СУБД. К персональным СУБД, например, относятся Visual FoxPro, Paradox, dBase, MS Access и
др.
Многопользовательские СУБД включают в себя сервер БД и клиентскую
часть и, как правило, могут работать в неоднородной вычислительной среде
(с разными типами ПК и операционными системами). К многопользовательским относятся, например, СУБД Oracle и Informix.
В зависимости от способа хранения и обработки данных СУБД можно
разделить на два класса: централизованные (или обычные) и децентрализованные (или распределенные). В обычных СУБД данные хранятся в том же
месте, где и приложения для управления ими. В распределенных СУБД как
108
программное обеспечение, так и данные распределены по узлам сети (см. тему 8). Распределенные СУБД могут быть однородными или неоднородными.
Неоднородность СУБД может проявляться в различиях у ее компонентов таких характеристик как, поддерживаемые модели данных, типы данных, языки запросов, фирмы-разработчики и т. д.
Одной из разновидностей распределенных СУБД являются мультибазовые системы, в которых управление каждым из узлов осуществляется автономно. В мультибазовых СУБД производится такая интеграция локальных
систем, при которой не требуется изменение существующих СУБД и в то же
время конечным пользователям предоставляется доступ к совместно используемым данным. Пользователи локальных СУБД получают возможность
управлять данными собственных узлов без централизованного контроля, который присутствует в обычных распределенных СУБД. Примером мультибазовой СУБД является система UniSQL.
В зависимости от возможности распараллеливания процесса обработки
данных выделяют СУБД с последовательной и параллельной обработкой
(параллельные СУБД). Параллельные СУБД функционируют в многопроцессорной вычислительной системе (как правило, со множеством устройств
хранения данных) или в сети компьютеров.
По используемой модели данных СУБД (как и БД), разделяют на иерархические, сетевые, реляционные, объектно-ориентированные и другие типы.
Некоторые СУБД могут одновременно поддерживать несколько моделей
данных (например, Cache).
С точки зрения пользователя, СУБД реализует функции хранения, изменения (пополнения, редактирования и удаления) и обработки информации, а
также разработки и получения различных выходных документов.
Для работы с хранящейся в базе данных информацией СУБД предоставляет приложениям и пользователям следующие два типа языков:
• язык описания данных (Data Definition Language – DDL) – высокоуровневый непроцедурный язык декларативного типа, предназначенный для описания логической структуры данных;
• язык манипулирования данными (Data Manipulation Language – DML) –
совокупность конструкций, обеспечивающих выполнение основных операций по работе с данными: ввод, модификацию и выборку данных по запросам.
Перечисленные выше функции СУБД, в свою очередь, используют следующие основные функции более низкого уровня, которые назовем низкоуровневыми:
• управление данными во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями;
• ведение журнала изменений в БД;
• обеспечение целостности и безопасности БД.
109
11.2 Архитектура СУБД
СУБД представляет собой сложную систему, состоящую из многих компонентов. Структурно схему построения СУБД можно представить следующим образом (рис. 48).
База данных и словарь данных (системный каталог, хранящий метаданные) хранятся на внешних носителях. Операции доступа к данным на низком
уровне (запись/чтение) контролируются, как правило, операционной системой, но если требуется высокая производительность, то эти операции может
контролировать и сама СУБД. На более высоком уровне операции доступа
контролируются ядром БД, которое использует для этого информацию, содержащуюся в словаре данных (т.е. ядро БД имеет дело с логической структурой данных). Практически всегда для каждой операции доступа в оперативной памяти выделяется область, называемая буфером. Необходимость
буферизации обусловлена тем, что объем оперативной памяти всегда меньше
объема внешней памяти. Буферизация данных повышает производительность
системы и позволяет предоставить доступ к одной и той же информации разным процессам (а в конечном итоге пользователям). Ядро БД также ответственно за поддержку безопасности и целостности БД.
Рисунок 48. Структурная схема СУБД
Интерпретатор DDL обрабатывает инструкции определения/изменения
структуры данных и сохраняет результаты в словаре БД. Запросы от пользователей транслируются интерпретатором DML и затем обрабатываются ядром БД. Так как чаще всего запросы формируются через высокоразвитый интерфейс и могут представлять собой декларативные процедуры, то они проходят предварительную предкомпиляцию в инструкции DML. Операции
управления и администрирования выполняются непосредственно ядром БД и
промежуточной обработки, как правило, не требуют.
110
11.3 Задачи администрирования СУБД
К числу основных задач администрирования БД можно отнести следующие:
• размещение данных на физическом носителе и управление ими;
• управление буферами оперативной памяти;
• управление транзакциями;
• резервное копирование БД;
• обеспечение целостности и безопасности БД
В данном контексте задача управления буферами оперативной памяти
несколько выходит за рамки нашего курса, поскольку по определению является низкоуровневой. Как правило, она возлагается на ядро БД и явному
управлению со стороны пользователей не подлежит.
Основные подходы к управлению транзакциями нами рассмотрены в
рамках темы 9. Задача обеспечения целостности и безопасности БД является
важной и обширной областью, обсуждение которой будет вынесено в отдельную тему. В данном подразделе более подробно рассмотрим вопросы,
связанные с размещением данных на физическом носителе и резервным копированем БД.
Большинство СУБД позволяют администратору системы выбрать один
из двух способов размещения файлов БД на физических носителях: на «чистых» дисках или в файловой системе действующей операционной системы.
В первом случае управление данными, хранящимися на отдельных носителях, производится низкоуровневыми средствами самих СУБД. Некоторые
СУБД, например Ingres и Interbase, требуют обязательного использования
файловой системы (в среде ОС UNIX). Рассмотрим достоинства и недостатки
обоих вариантов размещения файлов на диске.
Достоинством хранения информации на «чистых» дисках является то,
что внешняя память используется более эффективно и, как правило, увеличивается производительность обмена с дисками. Экономия внешней памяти
от 10 до 20% достигается на основе устранения необходимости организации
самой файловой системы. Так, в ОС UNIX служебная информация файловой
системы составляет примерно 10% от емкости дисков. Примерно столько же
памяти резервируется для последующего возможного расширения файлов.
Производительность (обычно порядка 10%) повышается на основе удаления
дополнительного слоя программного обеспечения при обращении к дискам.
Многие СУБД предпочитают работать с дисками через файловую систему, которая со своей стороны также обеспечивает следующие достоинства. Во-первых, использование файловой системы обладает большей гибкостью, так как дает администратору стандартные средства обслуживания
файлов: утилиты резервного копирования, архивации, восстановления, а
также возможность пользования другими программами работы с файлами
(редакторами, антивирусными программами, утилитами контроля качества
носителя и т. д.). Во-вторых, в некоторых случаях выполнение операций вво111
да/вывода через файловую систему обеспечивает оптимизацию, которую
СУБД не может реализовать. В частности, в системе UNIX происходит кластеризация данных в более крупные физические единицы, чем в большинстве
СУБД, что часто приводит к повышению производительности.
При определении требуемого объема дисковой памяти следует учитывать, что для обработки данных СУБД использует большой объем служебной
информации, размещаемой на дисках. К служебной информации относится
следующее: описание схемы базы данных, табличные индексы, временные
таблицы, заранее выделенное пространство для хеш-таблиц и индексов, пространство для сортировки, файлы журнала, архивы и многое другое.
Рациональным и довольно экономичным способом распределения ни
формации БД на дисках является обеспечение основных задач обработки
данных одним или несколькими дисками. Примером такого распределения
является использование четырех дисков: одного - для операционной системы
и области подкачки (swap), другого – для тела БД, третьего – для журнала
транзакций и четвертого – для индексных структур.
Технически возможно разместить несколько функциональных дисковых
областей на одних и тех же (физических или логических) дисках. Так практически всегда делается на СУБД, работающих на ПК. Однако совместное
хранение разнородной информации на одних и тех же дисках приводит к перегрузке подсистемы ввода/вывода и, соответственно, к потере производительности.
Перегрузка возникает из-за существенных временных затрат на позиционирование головок на диске. Например, пусть приложением выполняется
обновление данных базы. Поскольку запись в журнал должна вестись синхронно с обновлением основных данных, головка диска в процессе выполнения операции все время перемещается от области размещения данных к области журнала и обратно.
Резервное копирование баз данных необходимо, чтобы в случае сбоев
операционной системы, файловой системы или разрушения физических носителей информации существовала возможность восстановления данных из
резервной копии и продолжения работы с минимальными потерями. В современных СУБД предусматривается множество способов резервного копирования данных, так что вы можете выбрать наиболее подходящий для вас.
Рекомендуется использовать стратегию резервного копирования, которая
сочетает два взаимодополняющих метода:
1. периодическое полное резервное копирование базы данных;
2. ведение двоичных журналов, в которых регистрируются все изменения данных в промежутках между резервными копированиями.
Слишком частое полное резервирование неэффективно, поскольку занимает много времени, а значительная часть данных в базе не успевает измениться. Поэтому наряду с полным резервированием используется промежуточное, которое заключается в копировании двоичных журналов на резервный носитель. Таким образом, даже в случае полного разрушения диска, на
112
котором располагается база данных, возможно восстановить не только информацию, сохраненную при полном копировании, но и последующие изменения вплоть до момента последнего промежуточного копирования.
В зависимости от назначения и интенсивности эксплуатации БД можно
подобрать оптимальную частоту полного и промежуточного резервирования.
Например, полное резервное копирование может выполняться еженедельно,
промежуточное – ежедневно.
Двоичные журналы.
Файл двоичного журнала накапливает историю изменений в базе данных
за некоторый промежуток времени и позволяет в случае необходимости воспроизвести изменения. Очередной файл журнала создается в следующих
случаях:
1. при достижении предельного размера предыдущего файла;
2. при запуске (перезапуске) сервера БД;
3. при принудительном «сбросе» журналов.
«Сброс» журналов необходим при выполнении полного резервного копирования, чтобы изменения с момента резервирования отражались в новом
файле (старые файлы журналов при этом становятся не нужны). Кроме того,
принудительный «сброс» осуществляется перед промежуточным резервным
копированием, поскольку сервер БД начнет протоколировать изменения в
новом файле, а предыдущие файлы будут скопированы на резервный носитель.
11.4 Критерии выбора СУБД
Перед администратором БД, руководителем предприятия и обычным
пользователем проблема выбора СУБД возникает чаще всего перед ее приобретением и при переходе на новые аппаратно-программные средства.
Основным принципом выбора СУБД логично считать определение программного продукта, в наибольшей мере соответствующего предъявляемым
требованиям. Практически решить эту задачу не очень просто. Во-первых, к
СУБД предъявляется большое число требований и, главное, они с течением
времени изменяются – по мере освоения системы требуются новые возможности. Во-вторых, СУБД имеют большое число параметров, что затрудняет
их сравнение. Кроме того, информация о СУБД часто носит рекламный характер, не позволяющий сделать правильное суждение.
Рассмотрим технологию оценки характеристик СУБД и определения
степени их соответствия предъявляемым требованиям. При выборе продукта
внимание следует сосредоточить на основных параметрах, а по остальным –
проследить, чтобы не было «выпадения из области допустимости». Примером такого «выпадения» является невозможность работы с используемой ОС
или отсутствие средств поддержки интерфейса ODBS.
Процедуру выбора СУБД удобно проводить в три этапа. Сначала на качественном уровне оценить предлагаемые программные продукты на предмет пригодности, сузив область выбора. Затем оценить технические характе113
ристики отобранных систем более детально. И, наконец, оценить производительность оставшихся продуктов для принятия окончательного решения.
К числу основных показателей пригодности СУБД можно отнести следующие:
1. Вид программного продукта.
2. Категории пользователей.
3. Удобство и простота использования.
4. Модель представления данных.
5. Качество средств разработки.
6. Качество средств защиты и контроля корректности базы данных.
7. Качество коммуникационных средств.
8. Фирма-разработчик.
9. Стоимость.
Виды СУБД и их классификация обсуждались в начале темы, рассмотрим остальные показатели.
Категории пользователей. Программный продукт, относящийся к классу
СУБД, в общем случае, может быть предназначен для следующих категорий
пользователей:
• профессиональных программистов – разработчиков СУБД, серверов БД
и других программ;
• администраторов БД;
• квалифицированных пользователей, разрабатывающих приложения; .
• конечных (неквалифицированных) пользователей;
• различных комбинаций перечисленных категорий.
При выборе программных продуктов следует отдавать предпочтение
программам более широкого назначения. Не случайно многие популярные
полнофункциональные СУБД имеют средства как для пользователей и администраторов, так и для разработчиков.
Удобство и простота использования. Понятие удобства и простоты использования довольно расплывчатое, со временем изменяется и, кроме того,
ужесточается с точки зрения предъявляемых требований. Удобство и простоту использования программ качественно характеризует следующее:
• понятные процедуры установки программных продуктов;
• удобный и унифицированный интерфейс конечного пользователя;
• простота выполнения обычных операций: создания БД, навигации, модификации данных, подготовки и выполнения запросов и отчетов и пр.;
•наличие интеллектуальных подсистем поддержки, помощи в процессе
работы и обучения.
Модель представления данных. В настоящее время наиболее распространенной и отработанной теоретически и практически является РМД (см.
часть II). Перспективными являются модели с объектной ориентацией, поскольку они обладают большими возможностями отражения семантики
предметной области. Поэтому в большинстве случаев предпочтение отдают
системам с реляционной и объектно-ориентированной моделью данных (ли114
бо их комбинациям). Специфические задачи, разумеется, могут диктовать
необходимость использования других моделей представления данных.
Качество средств разработки. При оценке качества средств разработки
учитывается следующее: возможности создания пользовательских интерфейсов; мощность языка создания программ (автоматическая генерация кода, отладка, обеспечение целостности данных на уровне процессора БД, а не с помощью команд языка); автоматизация разработки различных объектов:
экранных форм, отчетов, запросов. Предпочтение отдается системам, имеющим полнофункциональные генераторы (Мастера, Построители и т. п.) и
обеспечивающим удобство работы пользователя.
Качество средств защиты и контроля корректности базы данных. Актуальное требование защиты информации в современных информационных
системах требует принятия адекватных мер в СУБД. Доступ к функциям защиты должен предусматриваться на уровне средств разработки программ на
уровне. К важнейшим функциям контроля корректности БД относятся следующие:
• обеспечение уникальности записей БД по первичному ключу;
• автоматический контроль целостности связей (ссылочная целостность)
между таблицами во время выполнения операций обновления, вставки и удаления записей;
• проверка корректности значений в БД (контроль типа данных, совпадение с шаблоном, определение диапазона допустимых значений, контроль
значения по справочной таблице и др.).
Качество коммуникационных средств. При оценке качества коммуникационных средств обращают внимание на следующие свойства программных
продуктов:
• поддержку сетевых протоколов, обеспечивающих работу продукта в
различных сетях;
•поддержку стандартных интерфейсов работы с БД: SQL, ODBC, OLE
DB, IDAPI, SAA;
• наличие средств групповой работы с информацией БД (языковые средства разработки; функции интерфейса пользователя; функции администратора БД по организации групп, разграничению полномочий, защите от несанкционированного доступа и т. д.);
• способность использовать и модифицировать БД других форматов без
импортирования или преобразования.
Фирма-разработчик. При отборе программных продуктов немаловажное
значение имеет авторство продукта. Солидность фирмы-разработчика пакета,
как правило, дает следующие преимущества:
• высокое качество продукта;
• наличие документации и методических материалов;
• наличие «горячей линии» для консультаций по возникающим проблемам;
115
• высокую уверенность в появлении более совершенной версии. Заметим, что очередные версии СУБД в среднем появляются достаточно быстро.
При выборе продукта следует обратить внимание на дату его появления.
Возможно, что в данный момент на подходе очередная версия фирмыконкурента, которая по многим параметрам лучше рассматриваемой. В дальнейшем ситуация может измениться в обратную сторону.
Следует отдавать предпочтение фирмам с твердым финансовым положением и перспективной динамикой развития аппаратно-программных
средств. В качестве показателей «благополучия» можно использовать годовой оборот, численность состава, объем продаж вообще и интересующего
продукта в частности и т. д.
Стоимость. На стоимость программных продуктов в основном влияют
вид программного продукта и фирма-разработчик. Стоимость СУБД может
колебаться от нескольких сотен до сотен тысяч долларов. Основным фактором, определяющим общую стоимость системы, чаще всего является число
поддерживаемых пользователей.
С появлением сети Интернет стало возможно бесплатно приобретать
программные продукты, в том числе СУБД. Примером таких продуктов являются свободно распространяемые СУБД с открытым кодом: MySQL, PostgreSQL и Firebird. Такие системы очень популярны в среде малого и среднего
бизнеса, обычно поддерживают только основные функции СУБД (хотя перечень этих функций от версии к версии расширяется), могут функционировать
на различных ОС.
11.5 Перспективы развития СУБД
Анализ современных СУБД и реализованных на их основе приложений
позволяет предположить следующие направления их развития:
1) поиск более совершенных моделей представления и типов данных в
БД;
2) разработка новых архитектур СУБД;
3) расширение областей применения БД;
4) улучшение сервиса конечных пользователей, администраторов и разработчиков.
В рамках первого направления интерес представляют СУБД, поддерживающие несколько моделей или одну интегрированную модель и позволяющие удобно программировать вычисления, обрабатывать символьную и графическую информацию, работать со знаниями, аудио- и видеоинформацией,
осуществлять доступ к распределенной информации, организовывать телеконференции, обучение и выполнять другие операции. На пути к решению
этой проблемы находится попытка поддержки во многих современных СУБД
различных типов двоичных данных и типа гиперссылка.
Новые архитектуры СУБД. Современные информационные системы в
ряде случаев требуют от СУБД возможности хранить и обрабатывать данные
объемом порядка Петабайтов. Несмотря на значительный рост возможностей
116
по объему магнитных и магнитооптических дисков, вряд ли их будет достаточно для информационных систем, работающих со сверхбольшими объемами данных. В связи с этим говорят о необходимости организации нового
уровня иерархии носителей - «третичной памяти». Устройствами третичной
памяти могут быть устройства в виде стоек магнитных дисков или лент с автоматически сменяемыми носителями.
К новым областям применения СУБД можно отнести следующие два
класса задач: обработки сверхбольших объемов информации и распределенной обработки информации в сетях ПК.
Примером системы, решающей одну из задач первого класса, является
проектируемая информационная система наблюдения Земли EOS (Earth Observing System), основным элементом которой является база данных EOSDIS
(EOS Data and Information System - система данных и информации).
Примерами задач второго типа являются задачи поиска и отбора ни
формации в Интернете (data mining), организации коллективного проектирования и территориально разнесенных организациях, обмена материальными,
им формационными, денежными и другими ресурсами с электронным
оформлением.
Если брать качество сервиса в широком смысле, то перспективные
СУБД позволят решать стоящие прикладные задачи с лучшим качеством.
Для этого они будут опираться на более совершенную элементную базу (повышение объема хранимых данных, увеличение производительности обработки запросов), иметь более совершенную программную организацию (Распределенная обработка, безопасность хранимой информации, защита прав
собственности), обладать более гибкими и удобными интерфейсами для программистов, пользователей и администраторов БД.
Осознание необходимости хранения в базах данных не только информации о предметной области, но и информации разработчиков приложений
привела к тому, что некоторые крупные фирмы (Oracle, Microsoft) заявили о
скором появлении программных продуктов управления метаданными –
объектно-ориентированных репозиториях. Такие репозитории полезны администраторам БД в управлении метаданными, а также разработчикам, так
как позволяют при разработке приложений многократно использовать готовые компоненты.
Одним из новых требований в области информационных технологий является обеспечение безостановочной работы. Раньше существовали «окна»
ночного времени, в которых выполнялось резервное копирование, исправление ошибок, реорганизация БД, установка новых версий ПО, модернизация
компьютера и ОС. Теперь это требуется делать в «горячем» режиме, совмещая с текущим обслуживанием пользователей. Решение этих задач требует
новых подходов к организации вычислительных работ и управлению БД, при
котором допустимо параллельное и бесконфликтное решение задач пользователей и администратора БД.
117
В современных условиях появляется потребность в обеспечении информационного обслуживания мобильного пользователя. Примером реализации
средства работы с БД мобильного пользователя является СУБД Oracle Lite,
функционирующая в карманных компьютерах с операционной системой
Windows CE. Эта СУБД, называемая клиентской, обеспечивает доступ через
сеть к данным и приложениям, поддерживаемым системой Oracle 8.
Тема 12. Проектирование и сопровождение БД
12.1 Этапы проектирования БД
Выделяют два основных подхода к проектированию схемы БД: нисходящий и восходящий. При восходящем подходе работа начинается с нижнего
уровня детализации - уровня определения атрибутов (свойств экземпляров
объектов), которые па основе анализа существующих закономерностей группируются в объекты, между которыми устанавливаются характерные связи.
Процесс пошаговой нормализации отношений в соответствии с требованиями РМД является типичным примером этого подхода. Этот подход удобен
для проектирования относительно простых БД с малым числом сущностей.
При увеличении числа атрибутов до нескольких сотен и даже тысяч более
приемлемой стратегией проектирования является нисходящий подход. Начинается он с определения нескольких высокоуровневых обобщенных сущностей и связей между ними. Затем эти объекты детализируются до необходимого уровня. Примером такого подхода проектирования является использование семантических моделей (ER-модели или языка UML). На практике эти
подходы обычно комбинируются, В таком случае можно говорить о смешанном подходе проектирования.
Итак, рассмотрим основные этапы проектирования (см.
рис. 49).
Первый этап. Планирование разработки БД. На этом
этапе выделяется наиболее эффективный способ реализации
этапов жизненного цикла системы.
Второй этап. Определение требований к системе. На
основании анализа требований
перспективных пользователей
производится
определение
функционального наполнения
информационной системы с
целью оптимизации использования доступных системных
Рисунок 49. Схема проектирования СУБД
118
ресурсов.
Третий этап. Проектирование концептуальной модели БД. Процесс создания непосредственно БД начинается с определения концептуальной модели, представляющей объекты и их взаимосвязи без указания способов их физического хранения. Усилия на этом этапе должны быть направлены на
структуризацию данных и выявление взаимосвязей между ними. Этот процесс можно разбить еще на несколько подэтапов.
а) Уточнение задачи. Перед началом работы над конкретным приложением разработчик должен явно представлять то, что он будет разрабатывать.
В случаях, когда разрабатывается небольшая персональная БД, такие представления могут быть достаточно полными. В других случаях, когда разрабатывается сложная БД с развитой структурой, таких представлений или может
быть очень мало, или они будут поверхностными. Поэтому следует затратить
некоторое время на составление списка всех основных задач, которые должны решаться этим приложением на настоящем этапе, а также постараться
учесть возникновение возможных проблемы в будущем.
б) Уточнение последовательности выполнения задач. Чтобы информационная система работала логично и понятно, лучше всего объединить основные функциональные задачи в группы и затем упорядочить задачи каждой
группы так, чтобы они следовали в порядке их выполнения. Группировка и
графическое представление последовательности выполнения помогут определить оптимальный порядок выполнения задач.
в) Анализ данных. После определения списка задач для каждой необходимо составить полный перечень данных, требуемых для ее решения. После
анализа данных можно приступать к разработке концептуальной модели, т. е.
к выделению объектов, атрибутов и связей.
Четвертый этап. Построение логической модели. Этап начинается с выбора модели данных. При выборе модели важную роль играет ее простота,
наглядность и сравнение естественной структуры данных с моделью, ее
представляющей (см. тему 2). Но часто этот выбор определяется успехом
(или наличием) той или иной СУБД. То есть, как правило, разработчик выбирает СУБД, а не модель данных. Таким образом, на этом этапе концептуальная модель транслируется в модель данных, совместимую с выбранной
СУБД. Возможно, что отображенные в концептуальной модели взаимосвязи
между объектами либо некоторые атрибуты объектов окажутся впоследствии
нереализуемыми средствами выбранной СУБД. Это потребует изменения
концептуальной модели. Версия концептуальной модели, которая может
быть обеспечена конкретной СУБД, называется логической моделью. Иногда
процесс определения концептуальной и логической модели называется определением структуры данных.
Пятый этап. Построение физической модели. Физическая модель определяет размещение данных, методы доступа и подходы к индексированию (см.
тему 10). На этапе физического проектирования мы привязываемся к конкретном СУБД и расписываем схему данных более детально, с указанием ти119
пов, размеров полей и ограничений. Кроме разработки таблиц и индексов,
производится также определение основных функциональных возможностей
информационной системы. При построении физической модели приходится
решать две взаимно противоположные по своей сути задачи. Первой из них
является минимизация места хранения данных, а второй – достижение максимальной производительности, целостности и безопасности данных.
Например, для обеспечения высокой скорости поиска необходимо определить индексные структуры, причем их число будет определяться всеми возможными комбинациями атрибутов, участвующими во вторичных индексах.
Для обеспечения безопасной работы БД требуется ведение журнала всех изменений (для восстановления данных после сбоя) и создание резервных копий БД. Для эффективной работы транзакций требуется резервирование дополнительного физического пространства под временные объекты, что приводит к увеличению (иногда значительному) размера файлов БД.
Шестой этап. Оценка физической модели. На этом этапе проводится
оценка эксплуатационных характеристик. Здесь можно проверить эффективность выполнения запросов, скорость поиска, правильность и удобство выполнения операций с БД, целостность данных и эффективность расхода ресурсов компьютера. При неудовлетворительных эксплуатационных характеристиках возможен возврат к пересмотру физической и логической модели
данных, выбору СУБД и типа компьютера.
Седьмой этап. Реализация БД. При удовлетворительных эксплуатационных характеристиках можно перейти к созданию макета приложения, т. е.
набору основных таблиц, запросов, форм и отчетов. Этот предварительный
макет можно продемонстрировать перед заказчиком и получить его одобрение перед детальной реализацией приложения.
Восьмой этап. Тестирование и оптимизация. Обязательным этапом является проведение испытаний разработанного приложения с целью поиска и
устранения возможных конфликтных ситуаций и некорректной работы.
Девятый этап. Сопровождение и эксплуатация. Поскольку выявить и
устранить все ошибки на этапе тестирования не получится, то этап сопровождения является обычным для разработчиков сложных БД.
12.2 CASE-системы
Для автоматизации проектирования и разработки информационных систем в 70-80-е гг. широко применялась структурная методология, означающая использование формализованных методов описания разрабатываемой
системы и принимаемых технических решений. При этом использовались
графические средства описания различных моделей информационных систем
с помощью схем и диаграмм. При ручной разработке информационных систем такие графические модели разрабатывать и использовать весьма трудоемко.
Отмеченные обстоятельства послужили одной из причин появления программно-технологических средств, получивших название CASE-средств и
120
реализующих CASE-технологию создания и сопровождения информационных систем. Кроме структурной методологии, в ряде современных CASEсредств используется объектно-ориентированная методология проектирования.
Термин CASE (Computer Aided Software Engineering) дословно переводится как разработка программного обеспечения с помощью компьютера. В
настоящее время этот термин получил более широкий смысл, означающий
автоматизацию разработки информационных систем.
CASE-средства представляют собой программные средства, поддерживающие процессы создания и/или сопровождения информационных систем,
такие как: анализ и формулировка требований, проектирование БД и приложений, генерация кода, тестирование, обеспечение качества, управление
конфигурацией и проектом.
CASE-систему можно определить как набор CASE-средств, имеющих
определенное функциональное предназначение и выполненных в рамках
единого программного продукта.
CASE-технология обычно определяется как методология проектирования информационных систем плюс инструментальные средства, позволяющие наглядно моделировать предметную область, анализировать ее модель
на всех этапах разработки и сопровождения информационной системы и разрабатывать приложения для пользователей.
CASE-индустрия объединяет сотни фирм и компаний различной ориентации. Практически все серьезные зарубежные программные проекты осуществляются с использованием CASE-средств, а общее число распространяемых пакетов превышает 500 наименований.
Основная цель CASE-систем и средств состоит в том, чтобы отделить
проектирование программного обеспечения от его кодирования и последующих этапов разработки (тестирование, документирование и пр.), а также автоматизировать весь процесс создания программных систем, или инжиниринг (engineering).
В последнее время все чаще разработка программ начинается с некоторого предварительного варианта системы. В качестве такого варианта может
выступать специально для этого разработанный прототип, либо устаревшая
и не удовлетворяющая новым требованиям система. В последнем случае для
восстановления знаний о программной системе с целью последующего их
использования применяют повторную разработку - реинжиниринг.
Повторная разработка сводится к построению исходной модели программной системы путем исследования ее программных кодов. Имея модель,
можно ее усовершенствовать, а затем вновь перейти к разработке. Так часто
и поступают при проектировании. Одним из наиболее известных принципов
та кого типа является принцип «возвратного проектирования» – Round Trip
Engineering (RTE).
121
Современные CASE-системы не ограничиваются только разработкой, а
чаще всего обеспечивают и повторную разработку. Это существенно ускоряет разработку приложений и повышает их качество.
12.3 Классификация CASE-средств
При классификации CASE-средств используют следующие признаки:
• ориентацию на этапы жизненного цикла;
• функциональную полноту;
• тип используемой модели;
• степень независимости от СУБД;
• допустимые платформы.
Рассмотрим классификацию CASE-средств по наиболее часто используемым признакам.
По ориентации на этапы жизненного цикла выделяют следующие основные типы CASE-средств:
• средства анализа, предназначенные для построения и анализа моделей
предметной области, например: Design/IDEF и BPwin.
средства анализа и проектирования обеспечивающие создание проектных спецификаций, например: Vantage Team Builder, Silverrun, PRO-IV и
CASE.Аналитик;
• средства проектирования БД, обеспечивающие моделирование данных
и разработку схем баз данных для основных СУБД, например: ERwin, SDesignor, DataBase Designer;
• средства разработки приложений, например: Uniface, JAM, PowerBuilder, Developer/2000, New Era и Delphi.
По функциональной полноте CASE-системы и средства можно условно
разделить на следующие типы:
• системы, предназначенные для решения частных задач на одном или
нескольких этапах жизненного цикла,
• интегрированные системы, поддерживающие весь жизненный цикл
информационных систем и связанные с общим репозиторием.
По типу используемых моделей CASE-системы условно можно разделить на три основные разновидности: структурные, объектноориентированные и комбинированные.
Исторически первые структурные CASE-системы основаны на методах
структурного и модульного программирования, структурного анализа и синтеза, например, система Vantage Team Builder.
Объектно-ориентированные методы и CASE-системы получили массовое использование с начала 90-х годов. Они позволяют сократить сроки разработки, а также повысить надежность и эффективность функционирования
информационных систем. Примерами объектно-ориентированных CASEсистем являются Rational Rose, Object Team.
122
Комбинированные инструментальные средства поддерживают одновременно структурные и объектно-ориентированные методы, например: Designer/2000.
По степени независимости от СУБД CASE-системы можно разделить
па две группы:
• независимые системы;
• встроенные в СУБД.
Независимые CASE-системы поставляются в виде автономных систем,
не входящих в состав конкретной СУБД. Обычно они поддерживают несколько форматов баз данных через интерфейс ODBC. К числу независимых
CASE-систем относятся S-Designer, ERwin, Silverrun .
Встроенные CASE -системы обычно поддерживают главным образом
формат баз данных СУБД, в состав которой они входят. При этом возможна
поддержка и других форматов баз данных. Примером встроенной системы
является Designer/2000, входящая в состав СУБД ORACLE.
12.4 Модели жизненного цикла информационных систем
Модель жизненного цикла программного обеспечения информационной
системы при автоматизированном проектировании играет достаточно важную роль. Это обусловлено тем, что каждая из CASE-систем ориентирована
на (поддерживает) определенную модель жизненного цикла.
Жизненный цикл ПО информационной системы представляет собой непрерывный процесс, начинающийся с
момента принятия решения о создании
БД и заканчивающийся при завершении
ее эксплуатации. Основным нормативным документом, регламентирующим
жизненные циклы, является международный стандарт ISO/IEC 12207. В нем
определяется структура жизненных
Рисунок 50. Спиральная модель
циклов, содержащая процессы, дейжизненного цикла
ствия и задачи, которые должны быть
выполнены при создании ПО.
Под моделью жизненных циклов ПО понимается структура, определяющая последовательность выполнения и взаимосвязи процессов, действий и
задач на протяжении всего времени эксплуатации. Наибольшее распространение получили следующие модели жизненных циклов ПО: каскадная, с
промежуточным контролем и спиральная.
Модели каскадная и с промежуточным контролем включают следующие этапы жизненного цикла ПО: анализ, проектирование, реализация, внедрение и сопровождение.
Каскадная модель предполагает строго последовательную реализацию
перечисленных этапов жизненного цикла. Достоинствами такой модели яв123
ляются: формирование на каждом этапе законченного комплекта документации и возможность планирования сроков завершения работ и соответствующих затрат. Недостатком модели является ее несоответствие реальному
процессу создания ПО, который обычно не укладывается в жесткую схему и
требует возврата к предыдущим этапам для уточнения или пересмотра принятых решений.
Модель с промежуточным контролем приближает жизненный цикл к
реальному процессу создания и применения ПО. В отличие от каскадной модели, она допускает возврат с каждого этапа жизненного цикла на любой
предыдущий этап для выполнения межэтапной корректировки. При этом
обеспечивается большая надежность ПО, но вместе с тем увеличивается длительность периода разработки.
Спиральная модель жизненного цикла (рис. 50) позволяет устранить недостатки предыдущих моделей. Основной упор в ней делается на начальные
этапы: анализ и проектирование. На них реализуемость технических решений
проверяется с помощью создания прототипов.
При спиральной схеме разработки неполное завершение работ на очередном этапе позволяет переходить на следующий этап. Незавершенная работа может выполняться на следующем витке спирали. Тем самым обеспечивается возможность предъявить пользователям системы ее некоторый работоспособный вариант для уточнения требований.
Тема 13. Защита информации в информационных системах
13.1 Основные определения
Проблему защиты информации в БД целесообразно рассматривать совместно с проблемой защиты информационных систем в целом. Действительно, средой функционирования СУБД - основного инструмента управления
данными, является среда информационной системы. Кроме того, известные
из литературы методы и средства защиты программ и данных в равной мере
относятся к ПО (СУБД, приложения, хранимые процедуры и т. д.) и данным
(БД, словари данных и т.д.).
Знание принципов построения систем защиты и возможностей, предоставляемых различными компонентами информационной системы (операционной системой, приложениями, СУБД, специализированными пакетами защиты и отдельными устройствами) позволяет оценить уязвимость информационной системы и грамотно организовать в ней защиту конфиденциальной
информации. Поскольку сетевой режим является наиболее общим случаем
использования ПК, при обсуждении вопросов защиты информации предположим наличие сетевых связей между узлами информационной системы.
Целью защиты информационной системы является обеспечение безопасности хранимой и обрабатываемой информации, а также используемых
программных средств.
124
Для обеспечения качественной защиты недостаточно организовать охрану помещений и установить программные средства защиты. Здесь требуется
комплексный (системный) подход, предполагающий организацию защиты
информационной системы в соответствии с ее структурой, задачами, решаемыми в ней, а также целями и возможностями защиты.
Систему защиты нужно закладывать с начала разработки информационной системы и выполнять на всех этапах жизненного цикла. На практике же,
в силу ряда причин, создание системы защиты часто начинается, когда основные компоненты информационной системы уже разработаны.
Создаваемая система защиты должна быть многоуровневой, адаптируемой к новым условиям функционирования, включать в себя рационально организованную совокупность имеющихся средств, методов и мероприятий.
Защита должна быть предусмотрена как от злоумышленников, так и от некомпетентных действий пользователей и обслуживающего персонала.
Для эффективного построения системы защиты необходимо:
• выделить уязвимые элементы вычислительной системы;
• выявить угрозы для выделенных элементов;
• сформировать требования к системе защиты;
•выбрать методы и средства удовлетворения предъявленным требованиям.
Безопасность информационной системы нарушается вследствие реализации одной или нескольких потенциальных угроз. Под угрозой понимается
возможность преднамеренного или случайного действия, которое может
привести к нарушению безопасности хранимой и обрабатываемой информации, в том числе и ПО.
В числе основных видов угроз в информационных можно указать следующие:
1. Несанкционированного использования ресурсов:
• использование данных (копирование, модификация, удаление, печать и
т. д.);
• копирование и модификация ПО;
• исследование ПО для последующего вторжения в систему.
2. Некорректного использования ресурсов:
• случайный доступ клиентских приложений к чужим разделам основной
памяти;
• случайный доступ к системным областям дисковой памяти;
• некорректное изменение БД (ввод ошибочных данных, нарушение ссылочной целостности данных и структуры БД);
• ошибочные действия пользователей и персонала.
3. Проявления ошибок в программных и аппаратных средствах.
4. Перехвата данных в линиях связи и системах передачи.
5. Несанкционированной регистрации электромагнитных излучений.
6. Хищения накопительных устройств информационных систем (носителей информации и документов).
125
7. Несанкционированного изменения состава компонентов информационных систем, средств передачи информации или их вывода из строя и т. д.
Потенциальными последствиями нарушения защиты являются:
• получение секретных сведений;
• повреждение хранящихся данных и метаданных;
• снижение производительности или остановка системы;
• материальный ущерб;
Основные задачи защиты данных в информационных системах заключаются в предотвращении угроз нарушения безопасности. Исходя из возможных угроз безопасности можно выделить три основные задачи защиты:
• защита информации от хищения;
• защита информации от повреждения;
• защита информационной системы от сбоев и отказов.
Защита информации от хищения подразумевает предотвращение физического хищения устройств и носителей хранения информации, несанкционированного получения информации (копирования, подсмотра, перехвата и т.
д.) и несанкционированного распространения ПО.
Защита информации от повреждения подразумевает поддержание целостности и корректности информации, что означает обеспечение физической, логической и семантической целостности информации. Информация в
системе может быть повреждена как вследствие несанкционированного доступа в систему посторонних пользователей, приложений (в том числе и
компьютерных вирусов), некорректных действий аккредитованных пользователей и их ПО, обслуживающего персонала, так и в случаях сбоев и отказов в
самой информационной системы.
Защита от сбоев и отказов аппаратно-программного обеспечения информационных систем является одним из необходимых условий нормального
функционирования системы. Основная нагрузка на обеспечение хорошей защиты от сбоев и отказов в системе ложится на системные аппаратнопрограммные компоненты: процессор, основную память, внешние запоминающие устройства, устройства ввода-вывода и другие устройства, а также
ПО операционной системы. При недостаточно надежных системных средствах защиту от сбоев следует предусматривать в ПО.
Под надежностью ПО понимается способность точно и своевременно
выполнять возложенные на него функции. Степень надежности ПО определяется качеством и уровнем автоматизации процесса разработки, а также организацией его сопровождения. Так как достичь 100%-й надежности приложений на практике почти не удается, необходимо предусматривать средства
быстрого восстановления работоспособности приложений и данных после
восстановления аппаратуры и ПО от сбоев и отказов.
Для организации комплексной защиты информации в общем случае может быть предусмотрено 4 защитных уровня.
1. Внешний уровень, охватывающий всю территорию расположения физических компонентов информационной системы.
126
2. Уровень отдельных сооружений или помещений расположения
устройств информационной системы и линий связи с ними.
3. Уровень компонентов информационной системы и внешних носителей
информации.
4. Уровень технологических процессов хранения, обработки и передачи
информации.
Первые три уровня обеспечивают в основном физическое препятствие
доступу путем ограждения, системы сигнализации, организации пропускного
режима, экранирования проводов и т. д. Последний уровень предусматривает
логическую защиту информации в том случае, когда физический доступ к
ней имеется.
13.2 Методы и средства защиты
Существующие методы защиты информации можно разделить на четыре основных класса:
• физические;
• аппаратные;
• программные;
• организационные.
Физическая защита используется в основном на верхних уровнях защиты и состоит в физическом преграждении доступа посторонних лиц в помещения, где содержатся аппаратные компоненты информационной системы.
Для физической защиты применяются следующие средства:
• сверхвысокочастотные, ультразвуковые и инфракрасные системы обнаружения движущихся объектов, определения их размеров, скорости и
направления перемещения;
• лазерные и оптические системы, реагирующие на пересечение нарушителями световых лучей;
• телевизионные системы наблюдения за охраняемыми объектами;
• кабельные системы, в которых небольшие объекты окружают кабелем,
чувствительным к приближению нарушителя;
• системы защиты окон и дверей от несанкционированного проникновения, а также наблюдения и подслушивания;
• механические и электронные замки на двери и ворота;
• системы нейтрализации излучений.
Аппаратная защита реализуется аппаратурой в составе компьютера или
с помощью специализированных устройств. Основными аппаратными средствами защиты являются средства защиты процессоров и основной памяти,
устройств ввода-вывода, систем передачи данных по каналам связи, систем
электропитания, устройств внешней памяти (зеркальные диски) и т. д.
Аппаратные средства защиты процессоров производят контроль допустимости выдаваемых из программ команд. Средства защиты памяти обеспечивают режим совместного использования и разграничения оперативной памяти при выполнении программ. К аппаратным средствам защиты устройств
127
ввода-вывода относятся различные схемы блокировки от несанкционированного использования. Средства защиты передачи данных по каналам связи
представляют собой схемы засекречивания (шифрования) информации.
Программная защита реализуется с помощью различнго ПО: операционных систем, программ обслуживания, антивирусных пакетов, инструментальных систем (СУБД, электронных таблиц, текстовых процессоров, систем
программирования и т. д.), специализированных программ защиты и готовых
приложений.
Организационная защита реализуется совокупностью направленных на
обеспечение защиты информации организационно-технических мероприятий, разработкой и принятием законодательных актов по вопросам защиты
информации, утверждением морально-этических норм использования информации в обществе и т. д. Остановимся более подробно на наиболее гибких и мощных методах защиты – программно-аппаратных методах, реализуемых в информационных системах.
13.3 Программно-аппаратные методы защиты
С помощью программно-аппаратных средств можно в определенной
мере решать как основные задачи защиты информации (от хищения, повреждения, сбоев и отказов оборудования), так и защиту от ошибок в приложениях.
Решение этих задач в системах защиты обеспечивается следующими
способами:
1) защитой от несанкционированного доступа (НСД) к ресурсам со стороны пользователей и программ;
2) защитой от несанкционированного использования (НСИ) ресурсов
при I Наличии доступа;
3) защитой от некорректного использования ресурсов;
4) внесением структурной, функциональной и информационной избыточности;
5) высоким качеством разработки программно-аппаратных средств.
Рассмотрим перечисленные способы более подробно и укажем методы
их реализации.
1. Для защиты от НСД прежде всего необходима эффективная система
регистрации попыток доступа в систему со стороны пользователей и приложений, а также мгновенная сигнализация о них отвечающим за безопасность
информационной системы лицам. Чтобы регистрировать события подключения к системе, в информационных системах обычно ведется специальный
электронный журнал или вспомогательная БД.
Защита от НСД со стороны пользователей в современных системах в основном реализуется двумя основными способами: парольной защитой, а
также путем идентификации и аутентификации.
Простейшая парольная защита является достаточно слабым средством,
особенно если пароль не шифруется. Основной ее недостаток состоит в том,
128
что все пользователи, использующие одинаковый пароль, с точки зрения информационной системы неразличимы. Неудобство парольной защиты со стороны пользователя состоит в том, что надо запоминать пароль. Если он простой и короткий, значит, его легко подобрать, если сложный - его нужно куда-нибудь записать. При небрежном отношении к записям такой пароль может стать достоянием других. Наиболее уязвимой при этом оказывается система полного доступа по одному паролю.
Несколько улучшить ситуацию можно определением нескольких паролей, за каждым из которых закреплены соответствующие права доступа. Еще
более серьезный контроль доступа в систему получается, если каждого подключающегося пользователя сначала идентифицировать, затем убедиться,
что это именно он, а не другой (аутентифицировать), и при запросе ресурсов контролировать полномочия (проверять право запрашивать ресурсы системы). Идентификация пользователей может выполняться с помощью персональных паролей. Для аутентификации, или проверки подлинности пользователя, часто используют следующие способы:
• запрос дополнительного секретного пароля;
• запрос какой-либо информации сугубо индивидуального характера;
• проверка наличия физического объекта, представляющего собой электронный аналог обычного ключа (электронный ключ);
• применение микропроцессорных карточек;
• активные средства опознавания;
• биометрические средства.
Все перечисленные средства, за исключением последнего, обладают различными уровнями защиты, внутренней сложности и удобством для использования, однако имеют один общий недостаток: в случае их утраты аккредитованной персоной, они могут быть использованы посторонними лицами для
НСД.
При этом наиболее надежными (но и дорогими) считаются биометрические средства. В них опознание личности осуществляется по отпечаткам
пальцев, форме ладони, сетчатке глаза, подписи, голосу и другим физиологическим параметрам человека, которые трудно утерять или разгласить. Некоторые системы идентифицируют человека по манере работы на клавиатуре.
Основным достоинством систем такого класса является высокая надежность
аутентификации. Недостатки систем включают в себя высокую стоимость
оборудования, временную задержку распознавания некоторых средств (десятки секунд) и неудобство для пользователя.
Уверенность в том, что подключающийся к системе пользователь или
программа, не являются злоумышленными, не дает гарантии безопасности
последующего поведения во время работы, поэтому во многих системах защиты предусматривается разграничение доступа к ресурсам в течение сеанса.
По завершении сеанса работы информация о параметрах подключения, в
том числе пароли, должна удаляться, чтобы ею не могли воспользоваться не129
санкционированные приложения и пользователи. Если же «прощание с системой после реального прекращения работы затянулось» (это может быть
забывчивость пользователя выполнить процедуру отключения или некорректное завершение работы программы), система защиты должна предусматривать механизмы принудительного завершения работы и закрытия каналов
доступа от посторонних пользователей и приложений. Отключение объектов
можно выполнять, например, после анализа их активности в течение некоторого времени, отсутствия ответов на предупреждения об отключении пользователей, либо по истечении продолжительности сеанса работы.
Одной из разновидностей несанкционированных приложений являются
компьютерные вирусы. Количество известных компьютерных вирусов постоянно возрастает. Появилась даже новая инженерная дисциплина - компьютерная вирусология. Последствия воздействия компьютерных вирусов могут быть разнообразными: от внешне необычных эффектов на мониторе компьютера и простого замедления работы ПК до краха вычислительной системы или сети. Отсюда возникает необходимость защиты от компьютерных
вирусов на всех стадиях их развития и в особенности на стадиях их проникновения в систему и размножения. Для этого в систему защиты включают
средства диагностирования состояния программно-аппаратных средств, локализации и удаления вирусов, устранения последствий их воздействия.
2. Обеспечение защиты от НСИ ресурсов, как и от НСД, требует применения средств регистрации запросов защищаемых ресурсов и сигнализации в
случаях попыток незаконного их использования. Заметим, что речь ведется о
важнейших с точки зрения защиты ресурсах. Если постоянно регистрировать
все события обо всех запросах на ресурсы, на остальную работу не хватит
процессорного времени.
Для защиты информационно-программных ресурсов от НСИ применяются следующие варианты защиты: от копирования, исследования, просмотра (данных и проложений), модификации и удаления. Приведем примеры их
применения.
Для защиты БД от несанкционированного копирования можно и исполняемом коде выполнить привязку к оборудованию. Тогда копия БД не будет
работать на другом компьютере.
Под защитой от исследования приложений понимаются такие средства,
которые не позволяют или затрудняют изучение системы их защиты. Например, после нескольких неудачных попыток подключения к приложению,
имеющему парольную защиту, целесообразно блокировать дальнейшие попытки подключения к ней либо предусмотреть средства самоликвидации.
Защиту файлов с исполняемыми программами или данными от модификации можно сделать путем сверки некоторой характеристики файла (контрольной суммы) с эталоном. Тогда, если кто-нибудь изменит содержимое
файла, изменится его контрольная сумма, что сразу же обнаружится. Средства проверки контрольной суммы можно вставить в приложение (для про130
граммных файлов) либо поместить в программную систему контроля модификации файлов (программ и данных).
Защитить от: удаления программы или данные можно путем предотвращения несанкционированных операций удаления файлов в вычислительной системе. К сожалению, широко распространенные операционные системы MS DOS и MS Windows стандартных эффективных средств такого рода
не имеют. С этой целью можно разработать или подобрать из имеющихся резидентное приложение контроля функции удаления файла с носителя.
Достаточно мощным средством защиты данных от просмотра является
их шифрование. Расшифровка информации требует знания ключа шифрования. Подбор последнего даже при современном уровне компьютерной техники представляет трудоемкую задачу. Шифрование незаменимо для защиты
информации от раскрытия ее содержания при хранении информации в файлах или базах данных, а также при передаче по линиям связи: проводным,
кабельным и радиоканалам.
Шифрование данных осуществляется в темпе поступления информации
(On-Line) и в автономном режиме (Off-Line). Первый способ применяется в
основном в системах приема-передачи информации, а второй - для засекречивания хранимой информации. В современных системах защиты в основном
применяется два алгоритма: DES и RSA.
3. Защита от некорректного использования ресурсов традиционно выполняется средствами ОС. Функции защиты от некорректного использования
ресурсов информационных систем предусматривают, по крайней мере, следующие действия: изолирование друг от друга участков оперативной памяти, выделенных различным приложениям, защиту системных областей
внешней памяти и контроль допустимости команд ЦП.
В более высокоуровневом чем ОС программном обеспечении необходимо обеспечить корректность использования прикладных ресурсов: документов, изображений, БД, сообщений и т. п. На практике возможны ситуации,
когда корректные с точки зрения операционной системы файлы содержат не
совсем верную или противоречивую информацию из предметной области.
Другими словами, прикладное программное обеспечение тоже должно обеспечивать целостность и непротиворечивость данных.
4. Одним из важнейших методов устранения или сведения к минимуму
последствий сбоев и отказов в работе ВС является внесение структурной,
функциональной и информационной избыточности (резервирования).
Структурная избыточность означает резервирование аппаратных компонентов информационной системы на различных уровнях: ПК (дублирование серверов обработки), отдельных устройств (дублирование процессоров
или накопителей на магнитных дисках - зеркальные диски) и схем устройств
(мажоритарные схемы выполнения операций). При резервировании следует
обеспечить прежде всего стабильное и бессбойное питание, к примеру, с помощью источников бесперебойного питания.
131
Функциональное резервирование означает организацию вычислительного
процесса, при которой функции управления, хранения и обработки информации реализуются несколькими элементами системы. При отказе функционального элемента его заменяет другой элемент. Примером функционально м
избыточности может служить запуск нескольких одинаковых приложений в
многозадачной операционной системе.
Информационное резервирование используется для предотвращения
полной потери информации и реализуется путем одноразового или периодического копирования и архивирования наиболее ценной информации. К нему
прежде всего можно отнести прикладные программы пользователя, а также
данные различных видов: документы, БД, файлы и т. д., а также основные
программы ОС, типовое ПО (СУБД, текстовые, табличные и графические
процессоры и т. п.).
Своевременное выявление сбоев и отказов оборудования, а также физических и логических дефектов на носителях информации невозможно без организации тестирования аппаратно-программных средств. Тестировать может выполняться в специально отведенное время и в процессе работы
(например, в интервалы простоя оборудования).
При выявлении в системе ошибок, требуется проведение восстановительных операций. Восстановление искаженных или потерянных данных и
программ обычно выполняется после тестирования. В ответственных случаях
применяют самотестирование и самовосстановление программ, при котором перед началом вычислений программа проверяет наличие и корректность исходных данных и при обнаружении ошибок производит восстановление данных.
5. Многие причины потери информации в процессе обычного функционирования системы, а также в результате происходящих в системе сбоев и
отказов, кроются в наличии ошибок или неточностей, заложенных на этапах
проектирования информационной системы. Для устранения или сведения к
минимуму ошибок, которые существенно снижают общую защищенность
информационной системы, следует использовать современные методы защиты на всех этапах жизненного цикла аппаратно-программного обеспечения:
системного анализа, проектирования, эксплуатации и сопровождения.
13.4 Средства защиты БД
Средства защиты БД в различных СУБД несколько отличаются друг от
друга. На основе анализа современных СУБД фирм Borland и Microsoft;
можно утверждать, что средства защиты БД условно делятся на две группы:
основные и дополнительные.
К основным средствам защиты информации можно отнести следующие
средства:
• парольной защиты;
• шифрования данных и программ;
• установления прав доступа к объектам БД;
132
• защиты полей и записей таблиц БД.
Парольная защита представляет простой и эффективный способ защиты
БД от несанкционированного доступа. Пароли устанавливаются конечными
пользователями или администраторами БД. Учет и хранение паролей производится самой СУБД. Обычно пароли хранятся в определенных системных
файлах СУБД в зашифрованном виде. Поэтому просто найти и определить
пароль невозможно. После ввода пароля пользователю СУБД предоставляются все возможности по работе с защищенной БД.
Шифрование данных (всей базы или отдельных таблиц) применяют для
того, чтобы другие программы, «знающие формат БД этой СУБД», не могли
прочитать данные. Такое шифрование (применяемое в MS Access), повидимому, дает немного, поскольку расшифровать БД может любой с помощью этой СУБД. Если шифрация и дешифрация требуют задания пароля, то
дешифрация становится возможной при верном вводе пароля.
Шифрование исходных текстов программ позволяет скрыть от несанкционированного пользователя описание соответствующих алгоритмов.
В целях контроля использования основных ресурсов СУБД во многих
системах имеются средства установления прав доступа к объектам БД. Права доступа определяют возможные действия над объектами. Владелец объекта (пользователь, создавший объект), а также администратор БД имеют все
права. Остальные пользователи к разным объектам могут иметь различные
уровни доступа.
По отношению к таблицам в общем случае могут предусматриваться
следующие права доступа:
• просмотр (чтение) данных;
• изменение (редактирование) данных;
• добавление новых записей;
• добавление и удаление данных;
• все операции, в том числе изменение структуры таблицы.
К данным, имеющимся в таблице, могут применяться меры защиты по
отношению к отдельным полям и отдельным записям.
Применительно к защите данных в полях таблиц можно выделить следующие уровни прав доступа:
• полный запрет доступа;
• только чтение;
• разрешение всех операций (просмотр, ввод новых значений, удаление и
изменение).
По отношению к формам могут предусматриваться две основные операции: вызов для работы и разработка (вызов Конструктора). Запрет вызова
Конструктора целесообразно делать для экранных форм готовых приложений, чтобы конечный пользователь случайно не испортил готовое приложение. В самих экранных формах отдельные элементы могут быть тоже защищены. Например, некоторые поля исходной таблицы вообще могут отсут133
ствовать или скрыты от пользователя, а некоторые поля – доступны для просмотра.
Отчеты во многом похожи на экранные формы, за исключением следующего. Во-первых, они не позволяют изменять данные в таблицах, а вовторых, основное их назначение – вывод информации на печать. На отчеты,
так же как и на экранные формы, может накладываться запрет на вызов
средств их разработки.
Для исключения просмотра и модификации (случайной и преднамеренной) текстов программ, используемых в приложениях СУБД, помимо шифрации, может применяться их парольная защита.
К дополнительным средствам защиты БД можно отнести такие, которые нельзя прямо отнести к средствам защиты, но которые непосредственно
влияют на безопасность данных. Их составляют следующие средства:
• встроенные средства контроля значений данных в соответствии с типами;
• повышения достоверности вводимых данных;
• обеспечения целостности связей таблиц;
• организации совместного использования объектов БД в сети.
Редактируя БД, пользователь может случайно ввести такие значения, которые не соответствуют типу поля, в которое это значение вводится. Например, в числовое поле пытаться занести текстовую информацию. В этом случае СУБД с помощью средств контроля значений блокирует ввод и сообщает пользователю об ошибке звуковым сигналом, изменением цвета вводимых
символов или другим способом.
Средства повышения достоверности вводимых значений в СУБД служат для более глубокого контроля, связанного с семантикой обрабатываемых
данных. Они обычно обеспечивают возможность при создании таблицы указывать следующие ограничения на значения: минимальное и максимальное
значения; значение, принимаемое по умолчанию (если нет ввода), требование
обязательного ввода; задание маски (шаблона) ввода; указание дополнительной сверочной таблицы, по которой ведется контроль вводимых значений и
т. д.
Более совершенной формой организации контроля достоверности информации в БД является разработка хранимых процедур (макросов, триггеров). Механизм хранимых процедур применяется в БД, размещенных на сервере. Сами хранимые процедуры представляют собой программы, алгоритмы
которых предусматривают выполнение некоторых функций (в том числе
контрольных) над данными. Процедуры хранятся вместе с данными и при
необходимости вызываются из приложений либо при наступлении некоторых событий в БД.
Функции поддержания логической целостности связанных таблиц берет на себя СУБД. Данная мера подразумевает, прежде всего, обеспечение
ссылочной целостности (подробнее будет обсуждена в следующей теме).
134
Организация совместного использования объектов БД в сети основана на
режиме выполнения транзакций (см. тему 9).
Тема 14. Языки запросов к РБД (SQL и QBE)
14.1 Структура языка SQL
Язык SQL для взаимодействия с РБД появился в середине 70-х и был
разработан в рамках проекта экспериментальной реляционной СУБД System
R. Исходное название языка SEQUEL (Structered English Query Language)
только частично отражает суть этого языка. Конечно, язык был ориентирован
главным образом на удобную и понятную пользователям формулировку запросов к РБД, но на самом деле уже являлся полным языком БД, содержащим помимо операторов формулирования запросов и манипулирования БД
средства определения и манипулирования схемой БД; определения ограничений целостности и триггеров; представлений БД; возможности определения структур физического уровня, поддерживающих эффективное выполнение запросов; авторизации доступа к отношениям и их полям; точек сохранения транзакции и откатов. В языке отсутствовали средства синхронизации
доступа к объектам БД со стороны параллельно выполняемых транзакций: с
самого начала предполагалось, что необходимую синхронизацию неявно выполняет СУБД.
Структурированный язык запросов SQL позволяет выполнять операции
над отношениями (создание, удаление, изменение структуры) и над данными
отношений (выборка, изменение, добавление и удаление), а также производить некоторые сопутствующие операции. SQL основан на реляционном исчислении кортежей и является непроцедурным языком, т. е. не содержит
операторов управления, организации подпрограмм, ввода-вывода и т. п. В
связи с этим SQL автономно не используется, обычно он погружен в среду
языка программирования СУБД, т.е. является встроенным. Язык имеет несколько стандартов, наиболее распространенными из которых являются SQL89 и SQL-92.
Различают два основных метода использования встроенного SQL: статический и динамический.
При статическом использовании языка (статический SQL) в тексте
программы имеются вызовы функций языка SQL, которые жестко включаются в выполняемый модуль после компиляции. Изменения в вызываемых
функциях могут быть на уровне отдельных параметров вызовов с помощью
переменных языка программирования.
При динамическом использовании языка (динамический SQL) предполагается динамическое построение вызовов SQL-функций и интерпретация
этих вызовов, например, обращение к данным удаленной базы, в ходе выполнения программы. Динамический метод обычно применяется в случаях,
когда в приложении заранее неизвестен вид SQL -вызова и он строится в
диалоге с пользователем.
135
Выделяют пять составляющих языка SQL (см. табл. 3):
1) Data Definition Language (DDL – язык описания данных) состоит из
команд, создающих объекты БД: отношения, атрибуты, первичные и вторичные ключи, индексы и т.д.
2) Data Manipulation Language (DML – язык манипулирования данными)
состоит из команд, позволяющих изменять информацию в БД – добавлять,
удалять, изменять.
3) Data Control Language (DCL – язык управления данными) – команды,
определяющие права доступа на получение и модификацию информации в
БД.
4) Transaction Control Language (TCL – язык управления транзакциями) –
команды предназначены для управления транзакциями.
5) Data Retrieval Language (DRL – язык получения данных) – вывод данных.
Вид
Название
СREATE TABLE
DROP TABLE
ALTER TABLE
CREATE INDEX
DROP INDEX
CREATE VIEW
DROP VIEW
CREATE DOMAIN
ALTER DOMAIN
DROP DOMAIN
RENAME
Назначение
Создание отношения
Удаление отношения
Изменение структуры отношения
Создание индекса
Удаление индекса
Создание представления
Удаление представления
Создание домена
Изменение домена
Удаление домена
Переименование
DRL
SELECT
TRANSFORM
UNION
Выборка записей
Создание перекрестного запроса Создание запроса на объединение
DML
UPDATE
INSERT
DELET
Изменение записей
Вставка новых записей
Удаление записей
TCL
START TRANSACTION Начало транзакции
COMMIT
Успешное завершение транзакции
ROLLBACK
Откат транзакции
DCL
GRANT
REVOKE
DDL
Передача привилегий
Изъятие привилегий
Таблица 3.
При создании отношений необходимо явно указывать тип данных для
каждого атрибута. Для различных версий реляционных СУБД доступные
136
разработчику типы данных могут значительно отличаться, однако для большинства современных приложений характерны типы данных для хранения
чисел, даты/времени и символьных строк (текстов). Кроме того могут быть
предусмотрены типы данных для хранения пространственных (spatial) объектов и OLE-контейнеры.
14.2 Запросы определения данных (DDL)
Запросы SQL представляют собой строго структурированные декларативные инструкции, состоящие из определенных служебных слов (операторов), имеющих, в свою очередь, некоторые аргументы. Запрос SQL начинается с соответствующего служебного слова и завершается знаком «;».
На основе запросов определения данных возможно описание схемы БД,
а также создание особых объектов – представлений.
Создание представлений.
На основе запроса выборки можно построить представление. В SQL
представление является виртуальной таблицей, построенной на основе данных одного или нескольких отношений. По одним и тем же отношениям
можно построить несколько представлений. Представление всегда содержит
только «свежие» данные. Любые изменения в отношениях немедленно отражаются и в представлении. Забота об обновлении данных лежит на СУБД.
Таким образом, представление дает возможность работы с выделенными
данными как с некоторой локальной таблицей. Представления не всегда могут быть редактируемыми. Как правило, редактируемыми могут быть только
представления, основанные на одной таблице, без использования предикатов,
группировки и агрегатных функций.
Само представление описывается путем указания идентификатора представления и запроса, который должен быть выполнен для его получения. Инструкция создания представления имеет следующий формат:
CREATE VIEW <имя представления>
[(<имя поля> [,<имя поля> ]...)] AS <инструкция SELECT>;
Если имена столбцов в представлении не указываются, то будут использоваться имена столбцов из запроса, описываемого соответствующим оператором SELECT. Инструкция удаления представления имеет формат вида:
DROP VIEW <имя представления>;
Для многопользовательской сетевой СУБД представления играют ключевую роль в определении доступа к данным и защите информации. Использование представлений дает следующие преимущества.
1. Независимость от данных. С помощью представлений можно создать
согласованную, неизменную картину структуры БД, которая будет оставаться стабильной даже в случае изменения (незначительного) исходных таблиц.
2. Актуальность. Представление содержит только актуальные данные.
3. Повышение защищенности данных. Каждому пользователю может
быть предоставлен ограниченный набор представлений, дающих доступ
только к необходимой информации.
137
4. Возможность индивидуальной настройки. Каждый пользователь может варьировать состав набора данных необходимых ему для работы.
Определение доменов.
Некоторые РСУБД (например, ORACLE) поддерживают возможность
определения доменов. Инструкция создания домена имеет формат вида:
CREATE DOMAIN <имя домена> [AS] тип данных [DEFAULT <значение по умолчанию>] [CHECK (<условия целостности>)];
Условие проверки СНЕСК позволяет задать ограничители целостности
на значения, которые может принимать домен. Например:
CREATE DOMAIN sex_type AS CHAR СНЕСК (VALUE IN (‘M’, ‘F’));
Значения в операторе IN могут также выбираться и из некоторой таблицы.
Изменить созданный домен можно с помощью инструкции ALTER DOMAIN. Удалить домен можно с помощью инструкции DROP DOMAIN, имеющей следующий формат записи:
DROP DOMAIN <имя домена> [RESTRICT/CASCADE];
Опция CASCADE позволяет после удаления домена изменить все типы
полей, основанных на этом домене, на соответствующий тип данных и произвести необходимую их конвертацию, насколько это будет возможно.
Ключевые столбцы и индексы.
Как это было показано в теме 4, одним из основных элементов схемы
данных РБД являются первичные (уникальные) и вторичные (внешние) ключи, которые используются для реализации свойства уникальности кортежей и
установления связей между отношениями соответственно. Для определения
первичного ключа можно использовать следующую конструкцию:
PRIMARY KEY (<Имя атрибута>);
В случае составного ключевого атрибута, вместо одного имени, указываем список имен атрибутов, входящих в ключ. В отношении может быть
только один первичный ключ. Столбцам, входящим в первичный ключ, как
правило, автоматически присваивается свойство NOT NULL (недопустимость неопределенных значений).
Вторичный (внешний) ключ может быть определен с помощью инструкции:
[CONSTRAINT <Имя внешнего ключа>]
FOREIGN KEY (<Имя атрибута или их список>)
REFERENCES <Имя родительской таблицы> (<Список столбцов первичного ключа родительской таблицы>)
[<Правила поддержания целостности связи>];
Имя внешнего ключа явно указывать не обязательно – если вы не зададите его, оно будет автоматически сгенерировано. Атрибут или атрибуты,
составляющие внешний ключ, должны иметь типы данных, аналогичные типам данных атрибута или атрибутов первичного ключа в родительской таблице. Для числовых атрибутов должен совпадать размер и знак, для символьных – кодировка и правило сравнения значений.
138
В конце инструкции можно явно указать правила поддержания целостности в разрабатываемой БД. В зависимости от того, какие операции со связанными данными необходимо выполнять при изменении или удалении записей в родительском отношении можно указать одно из следующих выражений:
ON UPDATE(DELETE) CASCADE – каскадное обновление(удаление)
кортежей дочернего отношения, когда кортеж родительского отношения обновляется(удаляется) вместе со всеми ссылающимися на него кортежами дочернего отношения;
ON UPDATE(DELETE) SET NULL — обнуление значений внешнего
ключа в соответствующих кортежах дочернего отношения;
ON UPDATE(DELETE) RECTRICT или ON UPDATE(DELETE) NO ACTION – запрет обновления(удаления) кортежей родительского отношения
при наличии ссылающихся на них кортежей дочернего отношения. Если вы
не задали правило поддержания целостности для этих операций, по умолчанию используется правило ON UPDATE(DELETE) RECTRICT.
Для столбцов внешнего ключа автоматически создается индекс, поэтому
проверки значений внешних ключей в ходе контроля целостности связи выполняются быстро.
В качестве примера определения внешнего ключа можно использовать
следующую инструкцию:
FOREIGN KEY (product_id) REFERENCES Products (id)
ON DELETE RECTRICT ON UPDATE CASCADE;
Это выражение означает, что атрибут product_id некоторого дочернего
отношения является его внешним ключом, который ссылается на ключевой
атрибут id родительского отношения Products, реализуя тем самым связь
«многие к одному». При этом запрещается удаление кортежа отношения
Products, если на него ссылается хотя бы один кортеж дочернего отношения,
а изменение значения атрибута id отношения Products приводит к автоматическому обновлению значений атрибута product_id дочернего отношения.
Создание индексов
В соответствии с определением, данным в теме 10, индекс – это вспомогательная структура, позволяющая значительно повысить производительность запросов, которые используют значения входящих в индекс атрибутов.
Для определения индекса используется следующая инструкция:
INDEX [<Имя индекса>] (<Список столбцов>);
Имя индекса указывать не обязательно. Если вы его не зададите, имя
сгенерируется автоматически. Вместо ключевого слова INDEX можно использовать его синоним – слово KEY.
UNIQUE [<Имя индекса>] (список столбцов>);
Создает уникальный индекс для указанных столбцов. Уникальный индекс отличается от обычного наличием дополнительного ограничения: наборы значений в атрибутах, включенных в уникальный индекс, должны быть
различны (т.е. фактически это альтернативный уникальный ключ). В ряде со139
временных РСУБД при задании индексов можно выбирать тип организации
индексной структуры.
Создание и изменение отношений
Инструкция создания связанного отношения имеет формат вида:
CREATE TABLE <имя отношения> (<имя атрибута> <тип данных> [опции], …)
PRIMARY KEY (<список атрибутов>)
[INDEX (<список атрибутов>)]
FOREIGN KEY (<список атрибутов внешнего ключа>) REFERENCES
<имя родительского отношения> (<список атрибутов первичного ключа родительского отношения>)
[ON UPDATE <действие>]
[ON DELETE < действие >];
Обязательными операндами этой инструкции являются имя создаваемого отношения и имя хотя бы одного атрибута с указанием его типа данных.
При создании отношения для отдельных атрибутов могут указываться некоторые дополнительные правила контроля вводимых в них значений (опции).
В качестве примера подобных правил можно указать: NOT NULL (запрет на
использование неопределенных значений), NULL (разрешение неопределенных значений), DEFAULT <Значение> (установка значения по умолчанию),
AUTO_INCREMENT (автоматическое присваивание значений) и т.д.
Инструкция изменения структуры существующего отношения имеет
формат вида:
ALTER TABLE <имя отношения> ({ADD, MODIFY, DROP} <имя атрибута> <тип данных> [опции]...);
Изменение структуры отношения может состоять в добавлении (ADD),
изменении (MODIFY) или удалении (DROP) одного или нескольких атрибутов. Правила записи инструкции ALTER TABLE соответствуют инструкции
CREAT TABLE, разве что при удалении атрибута указывать тип данных не
требуется. Аналогично выглядят инструкции создания, изменения и удаления
ключей и индексов.
Инструкция удаления отношения имеет формат вида:
DROP TABLE <имя отношения>;
В качестве примера инструкции создания отношения приведен листинг
соответствующей процедуры для СУБД MySQL 5.0:
СREATE TABLE Orders
( id SERIAL,
date DATE,
product_id BIGINT UNSIGNED NOT NULL,
qty INT UNSIGNED,
amount DECIMAL(10,2),
customer_id BIGINT UNSIGNED NOT NULL)
PRIMARY KEY (id)
FOREIGN KEY (product_id) REFERENCES Products (id)
140
ON DELETE RESTRICT ON UPDATE CASCADE
FOREIGN KEY (customer_id) REFERENCES Customers (id)
ON DELETE RESTRICT ON UPDATE RESTRICT
ENGINE InnoDB CHARACTER SET utf8;
Исходя из анализа этой инструкции можно заключить, что создаваемое
отношение Orders будет содержать 6 атрибутов:
id – целочисленный положительно определенный автозаполняемый атрибут,
date – темпоральный атрибут,
product_id – целочисленный положительно определенный атрибут с запрещенными неопределенными значениями,
qty – целочисленный положительно определенный атрибут,
amount – десятичная дробь, отражающая до десяти значащих цифр слева
от запятой и две справа,
customer_id – целочисленный положительно определенный атрибут с запрещенными неопределенными значениями.
Первичным ключом объявляется атрибут id. Для реализации связи с родительским отношением Products, в качестве внешнего ключа используется
атрибут product_id. При этом запрещено удаление кортежей родительского
отношения Products, на которые ссылаются кортежи Orders, однако разрешено каскадное обновление внешнего ключа в Orders при изменении соответствующего значения первичного ключа Products. Аналогично для связи со
вторым родительским отношением Customers используется внешний ключ
customer_id. В этом случае запрещены каскадные удаление и обновление.
Дополнительные операторы в последней строчке индекса указываю на внутренний для СУБД тип отношения (ENGINE) и на применяемую для элементов данных кодировку (CHARACTER SET).
14.3 Запросы выборки данных (DRL)
Основу запросов выборки данных составляет инструкция SELECT.
Наиболее общий вид этой процедуры можно представить следующим образом:
SELECT [предикаты вывода] <список атрибутов либо выражений>
FROM <список отношений> [IN <имя базы данных>]
[<Отношение1> INNER|RIGHT|LEFT JOIN < Отношение2>]
[ON <Отношение1>.<Атрибут1> = <Отношение2>.<Атрибут2>]
[WHERE <условие отбора>]
[GROUP BY <список атрибутов >]
[HAVING <условие отбора>]
[ORDER BY <спецификация> …];
Инструкция SELECT позволяет производить выборку и вычисления над
данными из одного или нескольких отношений. Результатом выполнения инструкции является отношение. Простейшая форма инструкции SELECT
включает только операторы SELECT и FROM. Служебное слово SELECT
141
определяет атрибуты результирующего отношения, а инструкция FROM
определяет имена отношений, использующихся для выполнения запроса. Если в запросе участвует несколько отношений, то для исключения двузначности имена атрибутов следует записывать в полной форме: <Имя отношение>.<Имя атрибута> (например, Преподаватели.Адрес). Для повышения
эффективности вначале указываются меньшие по размеру отношения. Если
имена атрибутов и отношений включают пробелы, то их необходимо заключать в квадратные скобки. Список атрибутов следует задавать в той последовательности, в которой они должны быть представлены в выходном наборе.
Например:
SELECT Фамилия, Имя, Отчество, [Год рождения] FROM Преподаватели;
Для выбора всех полей применяется шаблон *:
SELECT * FROM Преподаватели;
Список атрибутов или выражений может содержать имена атрибутов,
участвующих в запросе, выражения над столбцами, а также строковые константы, заключенные в кавычки. В выражениях (вычисляемых атрибутах)
могут принимать участие имена атрибутов, знаки арифметических операций
(+, -, *,/,^), множество встроенных функций, константы и т.д.
Именам атрибутов и отношений можно назначать альтернативные имена
(псевдонимы). Псевдонимы записываются через ключевое слово AS (<имя
отношения> или <имя атрибута> AS <псевдоним>). Это особенно эффективно для замены длинных имен отношений, поскольку в многотабличных запросах приходится включать имена отношений в описание каждого атрибута.
Псевдонимы также используются при создании рекурсивных запросов, когда
приходится соединять кортежи из одного и того же отношения. Тогда для
различия копий отношений им приходится назначать псевдонимы.
Если в запрос включены не все атрибуты отношения, то выходной набор
может содержать одинаковые кортежи. Предикаты вывода ALL, DISTINCT,
DISTINCTROW (записываются сразу после оператора SELECT) служат для
управления выводом повторяющихся кортежей. По умолчанию принимается
предикат ALL, т. е. в ответное отношение включаются все кортежи, в том
числе и повторяющиеся. Предикат DISTINCT исключает кортежи, которые
содержат повторяющиеся значения в выбранных атрибутах. В выходной
набор включаются только уникальные значения каждого из атрибутов, находящихся в списке фразы SELECT. Если инструкция SELECT содержит более
одного атрибута, то для включения записи в результат выполнения запроса
необходимо, чтобы совокупность значений во всех этих атрибутах была уникальной. Предикат DISTINCTROW исключает полностью повторяющиеся
кортежи и применяется для многотабличных запросов. Он игнорируется, если запрос содержит только одно отношение или все атрибуты всех отношений. В СУБД MS Access может дополнительно применяться предикат ТОР,
возвращающий определенное число кортежей, находящихся в начале или в
конце диапазона, описанного с помощью фразы ORDER BY.
142
В одном запросе SQL позволяет обращаться к данным нескольких БД
различных форматов. Такие запросы получили название гетерогенных. В
разных СУБД синтаксис записи гетерогенных запросов несколько отличается.
Фраза WHERE не обязательна. Она задает условия, которым должны
удовлетворять кортежи в результирующем отношении. Выражение <условие
отбора> является логическим. Его элементами могут быть имена атрибутов,
операции сравнения <, <=, >, >=, =, <>, арифметические операции, логические операторы (NOT, AND, OR, XOR), скобки, функции IN, BETWEEN,LIKE, IS(NOT) NULL и множество встроенных функций.
Запрос может быть основан на нескольких отношениях. Простое включение атрибутов из нескольких отношений дает простой перебор всех их
возможных значений. Для двух отношений общее число кортежей будет равно произведению числа кортежей в первом и втором отношениях. Но так как
РБД практически всегда состоит из отношений, связанных между собой посредством совпадающих значений атрибутов, участвующих в связи, то для
правильного объединения данных необходимо включать в запрос явное
определение соответствующих связей. Связь можно задать с помощью двух
способов: с помощью оператора INNER|RIGHT|LEFT JOIN и с помощью дополнительного условия выборки во фразе WHERE. Причем в SQL объединение данных можно произвести даже по неравенству, т.е. поддерживаются
операции сравнения -, <>, < <=, >, >=. Оператор INNER|RIGHT|LEFT JOIN
не является обязательной частью инструкции SELECT и оформляется как
часть оператора FROM:
SELECT Товары.[Наименование товара], Заказы.Дата, Заказы.[Полная
цена] FROM Товары INNER JOIN Заказы ОN Товары.Код_товара = Заказы.Код_товара;
Этот же запрос можно записать следующим образом (второй способ задания связи): SELECT Товары.[Наименование товара], Заказы.Дата. Заказы.[Полная цена] FROM Товары, Заказы WHERE Товары.Код _товара = Заказы.Код_товара;
Запросы с группировкой
Иногда интерес представляет не каждый кортеж отношения в отдельности, а итоговые значения по группам данных. Например, может понадобиться
общая сумма продаж для клиентов, проживающих в определенном районе,
или интересно знать средний объем продаж но месяцам, чтобы выяснить,
тенденции сбыта. Получить ответы на такие вопросы можно с помощью итоговых запросов (запросов с группировкой). Фраза GROUP BY позволяет выделять группы в результирующем множестве кортежей. Группой являются
котрежи с совпадающими значениями в атрибутах, перечисленных во фразе
GROUP BY. Оператор перегруппирует отношение таким образом, чтобы в
каждой группе все котрежи имели одно и то же значение нужного атрибута.
Фраза SELECT затем применяется уже к группам перекомпонованного отношения. Группирование кортежей само по себе ничего не дает. Обычно
143
производятся вычисления для групп: Для этой цели имеется ряд групповых
(иначе агрегатных) функции, производящих следующие действия над значениями заданного атрибута (аргумента функции) для каждой группы: SUM,
AVG, STDEV, VAR, COUNT, MIN, МАХ, FIRST, LAST.
Фраза HAVING используется для дополнительной селекции кортежей во
время определения групп. Она выполняет те же функции, что и WHERE, но
уже в рамках выходного набора. Фраза HAVING устанавливает, какие кортежи, сгруппированные посредством GROUP BY, должны отображаться и
участвовать в групповых операциях.
Фраза ORDER BY замыкает инструкцию SELECT и задает порядок сортировки результирующего множества. Каждая спецификация сортировки
представляет собой пару вида: <имя атрибута> [ASC/DESC]. Необязательный
модификатор ASC задает сортировку по возрастанию, DESC – по убыванию.
Большинство СУБД требуют, чтобы поле, участвующее в сортировке, было
перечислено во фразе SELECT:
SELECT Товар, Цена FROM Товары ORDER BY Цена DESC;
Параметрические запросы
До сих пор условие отбора мы записывали явно во фразе WHERE. Но во
многих случаях оно становится известным только во время выполнения программы. SQL позволяет вводить условия отбора в виде параметров запроса. В
этом случае такие запросы называются параметрическими или динамическими. Для увеличения эффективности выполнения таких запросов в некоторых
СУБД можно вызвать операцию PREPARE, которая подготовит запрос к запуску, т. е. зарезервирует необходимую память и проведет его оптимизацию.
Тогда сразу после задания параметра запрос будет готов к запуску. Для освобождения зарезервированной памяти в таком случае применяется операция
UNPREPARE.
Имя параметра должно отличаться от названий атрибутов отношений,
включенных в запрос. Дополнительно можно явно определить типы параметров с помощью инструкции PARAMETERS в виде [имя параметра] тип данных, [имя параметра] тип данных, и т. д., что позволяет контролировать значения параметров на соответствие типу еще при их вводе. В таком случае инструкция PARAMETERS располагается перед описанием запроса:
PARAMETERS [Введите год:] INT;
SELECT Клиенты.Фамилия FROM Клиенты INNER JOIN Заказы ON
Клиенты.КодКлиента = Заказы.КодКлиента WHERE Year(Заказы.Дата) =
[Введите год:];
Вложенные запросы.
Инструкции SELECT могут многократно вкладываться друг в друга.
Вложенная инструкция SELECT записывается как часть фразы WHERE и
служит для отбора записей основного запроса. SQL выполняет вложенный
подзапрос и затем сравнивает каждую строку основного запроса с результатом вложенного. Вложенные запросы записываются внутри скобок. Например:
144
SELECT Фамилия, Имя FROM Клиенты WHERE Кредит < (SELECT
AVG(Кредит) FROM Клиенты);
Если подчиненный запрос возвращает набор кортежей, то вместо операторов сравнения можно использовать функции ALL, SOME, ANY, EXISTS,
IN, получившие по функции EXISTS название кванторов. Квантор существования EXISTS обычно записывается следующим образом: EXISTS (SELECT
* FROM ...). Перед ним можно поставить NOT для инверсии результата. Выражение EXISTS считается истинным тогда и только тогда, когда результат
вычисления подзапроса является непустым множеством.
Перекрестные запросы.
Инструкция TRANSFORM служит для создания перекрестных запросов.
Они позволяют создавать перекрестные (сводные) таблицы, в которых можно
было бы просмотреть зависимость некоторых данных от двух параметров,
один из них откладывается по строкам, а другой – по столбцам (аналог двухмерной модели данных). В общем случае инструкция TRANSFORM записывается следующим образом:
TRANSFORM <выражение с групповой функцией (вычисляет значения
ячеек)>;
SELECT <инструкция с применением GROUP BY (отбирает кортежи и
задает имена строк)>;
PIVOT< выражение, задающее имена столбцов>;
К примеру, нам надо определить объем выручки от продажи каждого товара по месяцам. Тогда каждая строка полученной таблицы будет соответствовать определенному товару, в качестве столбцов будут названия месяцев,
а в ячейках таблицы будут представлены соответствующие объемы продаж.
Товар
Молоко
Мясо
Птица
Рыба
Янв.2007
4363
34636
3363
33656
Февр.2007
674
8654
54375
34633
Март 2007 Апр. 2007
8555
12
22
436
25252
131
2554
0
Таблица 3.
Запрос на объединение.
Оператор UNION позволяет объединить выходные наборы нескольких
инструкций в одно результирующее отношение (так называемое вертикальное объединение). Этот запрос является аналогом операции объединения отношений в реляционной алгебре. При объединении кортежи, возвращаемые
второй и последующими инструкциями SELECT, будут дописываться в конец первой, причем из результата выборки всегда будут исключаться повторяющиеся записи. В выходных наборах всех инструкций SELECT должно
быть одинаковое количество атрибутов с одинаковыми характеристиками
(последнее требование в некоторых СУБД не является обязательным). В
145
крайнем случае некоторую инструкцию SELECT можно дополнить строковыми константами или вычисляемыми атрибутами.
Кроме UNION в стандарте SQL включены еще две операции реляционной алгебры: исключения - ЕХСЕРТ (аналог операции разности) и пересечения - INTERSECT(аналог операции пересечения) Как и для объединения,
операнды(отношения) этих операций должны содержать соответствующий
по типам набор атрибутов.
14.4 Запросы манипулирования данными (DML)
С помощью запросов действий пользователь может изменять или переносить данные в отношениях, обновлять, добавлять или удалять группы кортежей, а также создавать новые отношения. Некоторые возможности редактирования существуют и в запросах выборки, т. е. изменения, сделанные в
запросе, автоматически переносятся на базовые отношения запроса. Но редактируемыми могут быть только некоторые запросы. Это простые однотабличные запросы выборки без применения предикатов, группировки и агрегатных функций.
Существуют четыре запроса действий: на добавление, удаление, обновление записей и на создание таблицы.
С помощью запроса на обновление можно изменить группу кортежей,
отобранных по заданному критерию. Инструкция запроса на обновление
имеет формат вида:
UPDATE <имя отношения> SET <имя атрибута> = (<выражение>)
[WHERE <условие отбора>];
Новые значения атрибутов в кортежах могут быть пустыми (NULL) либо
вычисляться в соответствии с арифметическим выражением. Правила записи
арифметических и логических выражений аналогичны соответствующим
правилам для вычисляемых полей. Например:
UPDATE Товары
SET Наименование = "Pent-III 800", Цена = Цена + 250
WHERE Наименование = "Pent-III 350";
С помощью запроса на добавление можно добавить в отношение одну
запись, состоящую из литералов, либо результат выполнения запроса на выборку. Соответственно запрос па добавление имеет форматы двух видов:
INSERT INTO <имя отношения> [(<список атрибутов>)] VALUES
(<список значений>);
INSERT INTO <имя отношения> [(<список атрибутов>)] <инструкция
SELECT>;
В первом формате инструкция INSERT выполняет ввод одного кортежа,
для которого значения атрибутов задаются литерами или выражениями. Порядок перечисления атрибутов должен соответствовать порядку значений,
перечисленных в списке значений фразы VALUES. При явном перечислении
можно опускать задание некоторых атрибутов. Если список атрибутов опущен, то в списке значений должны быть перечислены все значения в порядке
146
следования атрибутов отношения. Во втором формате инструкция INSERT
предназначена для добавления кортежей, отобранных из другого отношения
с помощью инструкции SELECT (отношения должны быть разными). Здесь
также необходимо обеспечить соответствие атрибутов (типов и размеров
или, по крайней мере, возможность полноценной конвертации данных).
Запрос на удаление.
С помощью запроса на удаление можно удалить группу кортежей, удовлетворяющих определенному критерию. Этот запрос особенно эффективен
при удалении большого числа кортежей. С помощью запроса на удаление явно исключаются кортежи только из одной отношения. Но если было определено каскадное удаление, то будут также удалены связанные кортежи из подчиненных отношений. Запрос на удаление имеет форму вида:
DELET FROM <имя отношения>
[WHERE <условие отбора>];
Если необязательная фраза WHERE опущена, т. е. условие отбора удаляемых кортежей отсутствует, удалению подлежат все кортежи отношения.
Например:
DELET FROM Товары WHERE Наименование LIKE "Celeron*";
Запрос на создание новой таблицы
С помощью этого запроса можно создать новое отношение на основе
уже существующего и перенести в него все или удовлетворяющие некоторому критерию кортежи. Новое отношение будет иметь ту же структуру Обычно этот запрос применяется для создания архивных копий отношений. Запрос
на создание нового отношения имеет формат вида:
SELECT <список атрибутов> INTO <имя нового отношения>
FROM <имя отношения> [WHERE <условие отбора>];
14.5 Запросы администрирования доступа (DCL)
В предыдущей теме были подробно рассмотрены основные аспекты безопасности информационных систем. В данном разделе мы обсудим некоторые возможности SQL, касающиеся администрирования доступа к данным.
Язык SQL включает два оператора (GRANT и REVOKE), предназначенные
для защиты данных от неавторизованного доступа. Применяемый механизм
защиты основан на использовании идентификаторов пользователей, предоставляемых им прав владения и привилегий. Каждому пользователю БД
назначается собственный идентификатор (обычно определяется именем
пользователя и паролем), который применяется для определения того, на какие объекты БД может ссылаться данный пользователь, а также какие операции с этими объектами он имеет право выполнять. Таким образом, каждый
оператор SQL выполняется от имени некоторого пользователя исходя из
назначенных ему прав доступа (привилегий).
Каждый объект в SQL имеет своего владельца (часто пользователя, который его создал). Только владелец имеет полный доступ к объекту. Для
147
предоставления прав доступа другим пользователям к этому объекту применяется оператор GRANT, имеющий следующий формат:
GRANT <список привилегий>|ALL PRIVILEGES ON <имя объекта> ТО
<список идентификаторов пользователей>|PUBLIC [WITH GRANT
OPTIONS];
В SQL определен следующий набор привилегий, позволяющий:
SELECT- просматривать данные;
INSERT [<список полей>] - добавлять данные;
UPDATE [<список полей >] - обновлять данные;
DELETE - удалять данные;
REFERENCE [<список полей >] - ссылаться на указанные поля при делении ссылочной целостности;
USAGE - использовать домены и ограничители целостности.
После списка идентификаторов пользователей можно указать опцию
WITH GRANT OPTIONS, которая позволит этим пользователям в свою очередь назначать привилегии другим пользователям. Таким образом, владелец
может четко контролировать, кто получил права доступа к объекту и какие
права доступа ему предоставлены.
Для отмены указанных привилегий применяется оператор REVOKE:
REVOKE [GRANT OPTION FOR] <список привилегий>|ALL PRIVILEGES ON <имя объекта> FROM <список идентификаторов
пользователей>|PUBLIC [RESTRICT | CASCADE];
Опция GRANT OPTION FOR позволяет для всех заданных привилегий
отменять возможность их передачи другим пользователям.
Регистрация пользователя
Чтобы создать учетную запись пользователя, используется процедура
CREAT USER <Идентификатор пользователя> [IDENTIFIED BY
[PASSWORD] '<Пароль>'];
Обязательным параметром этой команды является идентификатор нового пользователя. Если не задан параметр IDENTIFIED BY, то будет использоваться пустой пароль. Параметр PASSWORD необходимо указать в том
случае, если вы вводите не реальный, а зашифрованный пароль (что позволяет избежать передачи незашифрованного пароля при отправке на сервер команды CREAT USER). Получить зашифрованное значение из реального пароля вы можете с помощью функции
PASSWORD ('<Реальный пароль>');
Пример:
CREAT USER 'anna' IDENTIFIED BY 'annapassword';
GRANT SELECT ON *.* TO 'anna';
GRANT INSERT ON SalesDept.* TO 'anna' WITH GRANT OPTION;
GRANT DELETE ON SalesDept.Customers TO 'anna';
148
14.6 Язык QBE
Теоретической основой языка QBE (Query By Example – запрос по образцу) является реляционное исчисление с переменными-доменами. Язык
QBE позволяет задавать сложные запросы к БД путем заполнения предлагаемой СУБД запросной формы. Такой способ задания запросов обеспечивает
высокую наглядность и не требует указания алгоритма выполнения операции
– достаточно описать образец ожидаемого результата. В каждой из современных реляционных СУБД имеется свой вариант языка QBE.
QBE позволяет описывать однотабличные и многотабличные запросы. С
помощью запросов на языке QBE можно выполнять следующие основные
операции:
• выборку данных;
• вычисление над данными;
• вставку новых кортежей;
• удаление кортежей;
• модификацию (изменение) данных.
Выборка, вставка, удаление и модификация могут производиться безусловно или в соответствии с условиями, задаваемыми с помощью логических выражений. Вычисления над данными задаются с помощью арифметических выражений и порождают в ответных отношениях новые вычисляемые
атрибуты.
Запросная форма имеет вид таблицы, имя и названия полей которой совпадают с именем и названиями атрибутов соответствующего исходного отношения. Чтобы узнать имена доступных отношений БД, в языке QBE
предусмотрен запрос на выборку имен отношений.
В современных СУБД, например в MS Access и Visual FoxPro, многие
действия по подготовке запросов с помощью языка QBE выполняются визуально с помощью развитого интерфейса. В частности, визуальное связывание
отношений при подготовке запроса выполняется не элементами примеров, а
просто «протаскиванием» мышью атрибута одного отношения к соответствующему атрибуту другого.
14.7 Связь между SQL-запросом и операциями реляционной алгебры
В теме 4 мы говорили о эквивалентности операций реляционной алгебры
и реляционного исчисления. SQL-запросы представляют собой унифицированные декларативные выражения реляционного исчисления. Как это упоминалось ранее, существуют простые правила преобразования процедур реляционного исчисления в операторы реляционной алгебры БД. Для примера
рассмотрим БД, обладающую схемой и содержанием, показанными на рис.
50. Пусть нам необходимо узнать имена и номера сотрудников, являющихся
начальниками отделов с количеством сотрудников больше 3.
149
Рисунок 50. Схема и тела отношений отделы и сотрудники
Соответствующий SQL-запрос будет выглядеть следующим образом:
SELECT Сотр_имя, Сотр_ном FROM Сотрудники
INNER JOIN Отделы ОN Сотрудники.Сотр_ном=Отделы.Отд_нач
WHERE Отд_кол>3;
Если бы для формулировки такого запроса использовалась реляционная
алгебра, то мы получили бы строгую последовательность операций над этими отношениями:
1.Выполнить соединение отношений Сотрудники и Отделы по условию
Сотр_ном=Отд_нач;
Рисунок 52. Соединение отношений сотрудники и отделы
по условию
2.Ограничить полученное отношение по условию Отд_кол>3;
Рисунок 53. Ограничение отношения по условию Отд_кол>3
150
3.Спроецировать результат предыдущей операции на атрибут Сотр_имя,
Сотр_ном.
Рисунок 54. Проекция отношения на Сотр_номер и Сотруд_имя
Тема 15. Реализация РБД с помощью MS SQL Server, MySQL, MS Access
15.1 Microsoft SQL Server
MS SQL Server относится к коммерческим СУБД, обеспечивающих широкий функциональный набор инструментов для разработки, разворачивания
и сопровождения РБД. К основным характеристикам ПО MS SQL Server
можно отнести:
Высокая производительность
Кроме возможностей индексации, параллельного и распределенного выполнения запросов, в состав SQL Server входят такие механизмы, как процессор запросов и производительный/интеллектуальный Ввод/Вывод (Big/Smart
I/O).
Процессор запросов обеспечивает обработку команд на языке TransactSQL - диалекта стандартного языка SQL применительно к SQL Server. Перечислим наиболее важные возможности этого механизма:
 Использование более одного индекса на таблицу. Отсутствие такого
ограничения в версиях начиная с 7.0 позволяет оптимизатору пользоваться
несколькими индексами, например, если условие поиска в запросе задано одновременно по нескольким полям. Над индексами могут осуществляться теоретико-множественные операции, например, объединение или пересечение
индексов, что упрощает обработку предикатов фильтрации с операторами or
или and, а также может применяться для динамического создания покрывающего индекса.
 Наряду с традиционным алгоритмом разрешения соединения таблиц
(JOIN) – вложенным циклом (nested loop), оптимизатор может применять зачастую более эффективные стратегии – слияние (merge join) и хеширование
(hash join). Слияние применяется, когда обе соединяемые таблицы отсортированы по ключу соединения. Хеширование применяется, в том случае, если
индексы задействовать не удается. Наиболее эффективная стратегия для
каждого запроса определяется оптимизатором самостоятельно в каждом конкретном случае.
151
В версии 7.0 процессор запросов обращается за данными к системе
хранения (Storage Engine) через интерфейс OLE DB. Через этот же интерфейс
он может обращаться за данными и к любым другим OLE DB-совместимым
источникам данных, как локальным (находящимся на этом же компьютере),
так и удаленным. Таким образом, стандартные операторы SELECT, INSERT,
UPDATE и DELETE могут теперь в одном запросе соединять таблицы из
разных источников данных. Этими источниками данных могут быть как
Microsoft SQL Server, так и другие СУБД, а также нереляционные источники
(например Exchange Server, Index Server и т.д.). В зависимости от возможностей OLE DB-провайдера возможны три варианта обращения к удаленным
данным - только чтение удаленных данных, их изменение и включение изменений в распределенную транзакцию.
 Полнотекстовый поиск. SQL Server обеспечивает возможности полнотекстового поиска за счет интеграции с системой полнотекстового индексирования. Взаимодействие с этой системой осуществляется через OLE DB.
Управление построением и поддержкой индексов осуществляется из главного средства администрирования SQL Server - SQL Enterprise Manager. Построение индекса возможно по символьным и текстовым полям таблиц.
Под Big/Smart I/O. понимается совокупность приемов, позволяющих оптимизировать обмен данными с физической подсистемой.
 Опережающее чтение - процессор запросов подсказывает подсистеме
хранения, как это делать.
 Сканирование строк в порядке физического размещения - при оценке
затрат на выполнение запроса может быть сочтено более эффективным не
использовать индексы, а просто читать данные в порядке их физического
размещения и хешировать их для реляционного соединения, затем соединять
и, наконец, сортировать небольшое число получившихся в результате строк.
 Неупорядоченное сканирование - когда данные расположены на нескольких дисководах, неупорядоченное сканирование их организуется параллельно и доступ происходит быстрее.
 Параллельные запросы - используют усовершенствованный механизм
организации очереди, позволяющий поднять производительность даже в тех
случаях, когда данные хранятся вместе.
 Управление кэшированием - переработано с целью повышения производительности при чтении большого количества данных.
Масштабируемость
Этот термин означает возможность улучшение системных характеристик
сервера путем увеличения доступных вычислительных ресурсов (количества
или быстродействия процессоров, числа дисков). К улучшениям системных
характеристик можно отнести, например:
 рост числа обслуживаемых пользователей с сохранением среднего времени отклика;
 ускорение обработки одного запроса;

152
сохранение того же времени обработки запроса при увеличении объема
участвующих в нем таблиц.
SQL Server обеспечивает достаточно высокие уровни масштабируемости
и доступности. Однако в данном случае здесь отсутствует масштабируемость
сервера в чистом виде, поскольку рост производительности сервера зависит
не только от аппаратного обеспечения, но и операционной среды, под управлением которой работает данная СУБД.
Доступность данных
Если сервер остановлен с целью выполнения определенных административных действий или просто произошел сбой в работе системы, данные могут быть недоступными для пользователей. К сожалению, при выполнении
некоторых операций администрирования в этой версии сервера рекомендуется проводить в однопользовательском режиме. Следовательно, время от времени пользователи не будут иметь доступ к информации в базе данных. Другое дело, что такие простои можно свести к минимуму. Однако факт остается
фактом.
Функциональные возможности сервера
В состав Microsoft SQL Server входит достаточно мощный язык работы с
данными: Transact SQL, который является расширением стандартного SQL.
Однако совместимость со стандартом ANSI/ISO SQL-92 не является полной,
хотя он и рассматривается как предпочтительный диалект SQL. Transact-SQL
поддерживает такие объекты БД, как хранимые процедуры, триггеры, представления, поддержка целостности и т.д. К сожалению, отсутствуют механизмы каскадного удаления и обновления данных по внешним ключам.
Средства безопасности
SQL Server может авторизовать пользователей двумя путями:
 на основе собственного списка пользователей (в версии SQL Server 6.5
это называлось "стандартный режим");
 на основе базы пользователей Windows NT (в версии SQL Server 6.5 это
называлось "интегрированный режим").
При управлении правами пользователей в базах данных применяются
роли. Пользователь может входить в одну или несколько ролей. Роль может
включать в себя другие роли. Существует такой механизм, как "роль приложения" (application role), который определяет контекст прав любого пользователя данного приложения, независимо от его прав в базе данных.
Открытость
Открытость данного продукта также, как и масштабируемость, весьма
относительная. MS SQL Server "открыт" для других продуктов Microsoft: MS
Office, MS Visual Studio, MS Internet Information Server и т.д. При этом делается упор на то, что поскольку все эти программные комплексы разработаны
одной компанией, то взаимодействие между ними осуществляется более эффективно, чем с аналогичными продуктами других фирм.

153
Средства разработки
MS SQL Server предоставляет широкие возможности для разработчика
баз данных.
SQL Server Query Analyzer. Используется для разработки и оптимизации
запросов. Конструкции языка SQL в тексте запроса выделяются разными
цветами на основе синтаксического анализа. Показываются относительные (в
процентах) стоимости выполнения этапов, а также отдельных запросов по
отношению к общей стоимости пакета. Результаты запроса могут быть представлены в табличной форме. Query Analyzer может также выдать рекомендации по построению индексов, оптимизирующих выполнение данного запроса.
SQL Server Profiler. Этот инструмент, пришедший на смену SQL Trace из
версии 6.5, позволяет собрать самые подробные данные для всестороннего
анализа работы пользователей и приложений. Отслеживается до 50 типов событий, в том числе транзакции, блокировки, исполняемые команды и т.д.
Index Tuning Wizard. Поток команд, захваченный SQL Server Profiler, так
же как и последовательность SQL-операторов, может быть проанализирован
при помощи мастера Index Tuning Wizard, который выдаст рекомендации по
построению индексов, оптимизирующих выполнение всего потока команд (а
не одного запроса, как в SQL Server Query Analyzer). При этом будут выданы
оценки выигрыша в производительности.
Visual Database Tools. Набор графических инструментальных средств
Microsoft Visual Database Tools предназначен для рисования диаграмм "сущности-связи" и разработки сложных запросов. С помощью Microsoft Visual
Database Tools вы сможете:
 присоединить и исследовать любую базу данных, совместимую с
ODBC (Open Database Connectivity);
 создавать и изменять базы данных, используя диаграммы;
 разрабатывать, выполнять и сохранять сложные запросы;
 добавлять, изменять и стирать данные, хранящиеся в таблицах баз данных;
 проектировать объекты, такие как таблицы, триггеры, хранимые процедуры для систем управления базами данных Microsoft SQL Server и Oracle;
 перетаскивать объекты баз данных на проектируемые носители интерфейсов (например, на заготовки страниц HTML) и связывать их с элементами
управления с помощью наглядных манипуляций.
Необходимо заметить, что SQL Server уступает другим СУБД по двум
важным показателям: программируемость и средства работы. При разработке
клиентских БД приложений на основе языков Java, HTML часто возникает
проблема недостаточности программных средств SQL Server и пользоваться
этой СУБД будет труднее, чем системами DB2, Informix или Oracle.
Одним из серьезнейших недостатков данной СУБД является ее зависимость от операционной среды – SQL Server функционирует исключительно в
среде Windows. Поэтому использование SQL Server целесообразно только в
154
том случае, когда для доступа к содержимому БД используется стандарт
ODBC, в противном случае лучше использовать другие СУБД. С другой стороны, такая зависимость может положительно сказаться на производительности системы, поскольку SQL Server является "родным" продуктом для операционных систем семейства Windows.
В комплект средств административного управления данной СУБД входит целый набор специальных мастеров и средств автоматической настройки
параметров конфигурации. Как и любой другой продукт от Microsoft, SQL
Server выглядит привлекательно и функционально. Также MS SQL Server
оснащен замечательными средствами тиражирования, позволяющими синхронизировать данные ПК с информацией БД и наоборот. Входящий в комплект поставки сервер OLAP дает возможность сохранять и анализировать
все имеющиеся у пользователя данные. В принципе данная СУБД представляет собой современную полнофункциональную базу данных, которая идеально подходит для малых и средних организаций.
15.2 Открытая платформа MySQL
Программное обеспечение MySQL представляет собой быстрый многопоточный, многопользовательский надежный SQL-сервер БД. Сервер MySQL
предназначен как для обслуживания сложных и разветвленных уникальных
производственных систем с большой нагрузкой, так и для встраивания в ПО
массового распространения.
MySQL имеет двойное лицензирование. Это означает, что пользователи
могут выбирать, использовать ли ПО MySQL бесплатно по общедоступной
лицензии GNU General Public License (GPL) или приобрести одну из стандартных коммерческих лицензий MySQLAB (организации-разработчика).
Ниже приведено описание важных характеристик программного обеспечения MySQL.
Внутренние характеристики и переносимость
 ПО написано на C и C++, исходный код открыт для изменений. MySQL
надежно протестирован на множестве различных компиляторов.
 MySQL совместим с широким кругом операционных систем и потоковых пакетов: AIX 4.x, 5.x, Amiga, DEC Unix 4.x., FreeBSD 2.х, 3.x и 4.x, Linux
2.0+, Mac OS X, NetBSD 1.3/1.4 Intel, OS/2 Warp 4, FixPack 4., Solaris 2.5 и
выше, SunOS 4.x, Tru64 Unix, Windows 9x, Me, NT, 2000 и XP.
 Поддерживает множество интерфейсов API для C, C++, Eiffel, Java,
Perl, PHP, Python, Ruby и Tcl.
 Полностью реализовано свойство многопоточности с использованием
потоков ядра. Это означает, что, если такая возможность аппаратно обеспечивается, можно легко организовать эффективную загрузку нескольких процессоров.
 Эффективная физическая организация данных на носителях на основе
В-деревьев со сжатием индексов.
155
Оптимальная система распределения памяти, базирующаяся на потоковом разделении.
 Скоростные соединения, использующие оптимизированный метод однопроходного мультисоединения (one-sweep multi-join).
 Хеш-таблицы в памяти, используемые как временные таблицы.
 SQL-функции реализованы при помощи хорошо оптимизированной
библиотеки классов, поэтому они выполняются настолько быстро, насколько
это возможно. Обычно после инициализации запроса распределения памяти
не происходит вообще.
Типы столбцов
 Большой выбор традиционных типов: целочисленные со знаком/беззнаковые, длиной в 1, 2, 3, 4 и 8 байтов, FLOAT, DOUBLE, CHAR,
VARCHAR,TEXT, BLOB, DATE, TIME, DATETIME, TIMESTAMP, YEAR,
SET и ENUM.
 Допустимы записи фиксированной и переменной длины.
 Все столбцы имеют значения по умолчанию. С помощью INSERT
можно вставить подмножество столбцов таблицы; столбцы, для которых явно не заданы значения, устанавливаются в значения по умолчанию.
Команды и функции
 Полная поддержка операторов и функций в SELECT- и WHERE- частях запросов.
 Полная поддержка для операторов SQL GROUP BY и ORDER BY с
выражениями
SQL.
Поддержка
групповых
функций
(COUNT(),COUNT(DISTINCT ...), AVG(), STD(), SUM(), MAX() и MIN()).
 Поддержка LEFT OUTER JOIN и RIGHT OUTER JOIN с синтаксисом
ANSI SQL и ODBC.
 Разрешены псевдонимы для таблиц и столбцов в соответствии со стандартом SQL92.
 DELETE, INSERT, REPLACE, and UPDATE возвращают число строк,
которые были изменены. Вместо этого можно задать возвращение совпавших
строк. Для этого следует установить флаг при соединении с сервером.
 Команду SHOW, которая является специфической для MySQL, можно
использовать для получения информации о базах данных, таблицах и индексах. Чтобы выяснить, как оптимизатор выполняет запрос, можно применять
команду EXPLAIN.
 Имена функций не конфликтуют с именами таблиц и столбцов. Например, ABS является корректным именем столбца. Для вызова функции существует только одно ограничение: между именем функции и следующей за
ним открывающей скобкой не должно быть пробелов.
 В одном и том же запросе могут указываться таблицы из различных баз
данных.
Безопасность
 Система безопасности основана на привилегиях и паролях, за счет чего
обеспечивается гибкость и безопасность. Присутствует возможность верифи
156
кации с удаленного компьютера. Пароли защищены, т.к. они при передаче по
сети при соединении с сервером шифруются.
Масштабируемость и ограничения
 Возможно управляет обширными БД. Например, компания MySQLAB.
использует ПО MySQL для работы с несколькими БД, которые содержат 50
миллионов записей, кроме того, известны пользователи, применяющие
MySQL для работы с 60000 таблицами, включающими около 5000000000
строк.
 Для каждой таблицы разрешается иметь до 32 индексов. Каждый индекс может содержать от 1 до 16 столбцов или частей столбцов. Максимальная ширина индекса 500 бит (это значение может быть изменено при компиляции MySQL). Для индекса может использоваться префикс поля CHAR или
VARCHAR.
Установка соединений
 Пользователи могут соединяться с MySQL, используя протокол
TCP/IP, Unix или именованные каналы (named pipes), под NT.
 Поддержка ODBC (Open-DataBase-Connectivity) для Win32 (с исходным кодом). Все функции ODBC 2.5 и многие другие. Например, для соединения с MySQL можно использовать MS Access.
Локализация
 Полная поддержка нескольких различных кодировок, включая ISO8859-1 (Latin1), немецкий, big5, ujis и многие другие. Например, скандинавские символы разрешены в именах таблиц и столбцов.
 Для хранения всех данных используется выбранный набор символов.
Все сравнения для столбцов с нормальными строками проводятся с учетом
регистра символов.
Транзакции
Поддержка транзакций в сервере MySQL реализуется при помощи обработчиков транзакционных таблиц типов InnoDB и BDB. Таблицы InnoDB
обеспечивают соответствие требованиям ACID.
Однако для таблиц нетранзакционных типов, таких как MyISAM, в
MySQL используется иная парадигма обеспечения целостности данных, получившая название «атомарные операции». Атомарные операции в сравнении с транзакциями часто обеспечивают такую же или даже лучшую целостность при более высокой производительности. Поскольку сервер MySQL
поддерживает обе парадигмы, пользователь может выбирать между скоростью, которую обеспечивают атомарные операции, и транзакционными возможностями для своих приложений. Такой выбор может быть сделан для
каждой таблицы отдельно.
Под термином «атомарные» имеется в виду следующее: гарантируется,
что при выполнении каждого конкретного обновления никакой другой пользователь не может повлиять на него и никогда не произойдет автоматического отката (который возможен на транзакционных таблицах, если не приняты
157
должные меры предосторожности). Сервер MySQL также гарантирует, что не
случится грязного чтения (dirty read).
15.3 Microsoft Access
Microsoft Access в настоящее время является одной из самых популярных среди настольных (персональных) программных СУБД. Среди причин
такой популярности следует отметить:
 высокую степень универсальности и продуманности интерфейса, который рассчитан на работу с пользователями самой различной квалификации.
В частности, реализована система управления объектами базы данных, позволяющая гибко и оперативно переходить из режима конструирования в режим их непосредственной эксплуатации;
 глубоко развитые возможности интеграции с другими программными
продуктами, входящими в состав Microsoft Office, а также с любыми программными продуктами, поддерживающими технологию OLE;
 богатый набор визуальных средств разработки;
В Access поддерживаются разнообразные всплывающие и многоуровневые меню, работа с окнами и мышью, реализованы функции низкоуровневого доступа к файлам, управление цветами, настройка принтера, данные могут
быть представлены в виде электронных таблиц и т. п. Система также обладает средствами быстрой генерации экранов, отчетов и меню, поддерживает
язык управления запросами SQL, имеет встроенный язык Visual Basic for
Applications (VBA), хорошо работает с сетевыми приложениями. СУБД
Access позволяет использовать другие компоненты пакета Microsoft Office,
такие, как текстовый процессор Word for Windows, электронные таблицы
Excel и т. д.
Средства MS Access, упрощающие разработку приложений:
1. Процедуры обработки событий и модули форм и отчетов. На встроенном языке VBA можно писать процедуры обработки событий, возникающих
в формах и отчетах. Процедуры обработки событий хранятся в модулях, связанных с конкретными формами и отчетами, в результате чего код становится частью макета формы или отчета. Кроме того, существует возможность
вызова функции VBA свойством события.
2. Свойства, определяемые в процессе выполнения. С помощью макроса
или процедуры обработки событий можно определить практически любое
свойство формы или отчета в процессе выполнения в ответ на возникновение
события в форме или отчете.
3. Модель событий, похожая на используемую в языке Microsoft Visual
Basic, позволяет приложениям реагировать на возникновение различных событий, например, нажатие клавиши, перемещение мыши или истечение
определенного интервала времени.
4. Обработка данных с помощью VBA. С помощью языка VBA можно
определять и обрабатывать различные объекты, в том числе, таблицы, запросы, поля, индексы, связи, формы, отчеты и элементы управления.
158
5. Построитель меню и создание подменю. Построитель меню предназначен для помощи при создании специальных меню в приложениях. Кроме
того, специальные меню могут содержать подменю.
6. Улучшенные средства отладки. Помимо установки точек прерывания
и пошагового выполнения программ на языке VBA, можно вывести на экран
список всех активных процедур.
7. Обработка ошибок. Помимо традиционных способов обработки ошибок, можно использовать процедуры обработки события «Error» для перехвата ошибок при выполнении программ и макросов.
8. Улучшенный интерфейс защиты. Команды окна диалога защиты
упрощают процедуру защиты и смены владельца объекта.
9. Программная поддержка механизма OLE. С помощью механизма OLE
можно обрабатывать объекты из других приложений, вызывая методы и
определяя свойства, точно так же, как и объекты Microsoft Access.
10. Создание и установка программ-надстроек. С помощью VBA можно
создавать программы-надстройки, например, нестандартные мастера и построители. Мастер – средство Microsoft Access, которое на основе диалога с
пользователем создает объект (таблицу, запрос, форму, отчет и т. д)
4. Мастера Access. Access позволяет даже мало подготовленному пользователю создать свою БД и обрабатывать данные с помощью форм, запросов и отчетов, проводить анализ таблиц БД и выполнять ряд других работ.
Практически для любых работ с БД в Access имеется свой Мастер, который
помогает их выполнять. Мастер по анализу таблиц позволяет повысить эффективность базы данных за счет нормализации данных. Мастера по созданию форм и отчетов упрощают и ускоряют процесс создания многотабличных форм и отчетов. Новая форма или отчет могут наследовать примененный к таблице-источнику записей фильтр. Мастера по разработке форм
и отчетов автоматически создают инструкцию SQL, определяющую источник
записей для формы или отчета, поэтому отпадает необходимость в явном
определении запроса. Мастер подстановок создает в поле таблицы раскрывающийся список значений из другой таблицы для выбора и ввода нужного
значения. Мастера по импорту/экспорту позволяют просматривать данные
при импорте/экспорте текста или электронных таблиц, а также при экспорте
данных Microsoft Access в текстовые файлы. Мастер защиты при необходимости эвакуирует данные, для чего создает новую базу данных, копирует в
нее все объекты из исходной базы данных, снимает все права, присвоенные
членам группы пользователей, и шифрует новую базу данных. После завершения работы мастера администратор может присвоить новые права доступа
пользователям и группам пользователей. Мастер по разделению базы данных
позволяет разделить базу данных на два файла, в первый из которых помешаются таблицы, а во второй – запросы, формы, отчеты, макросы и модули.
При этом пользователи, работающие в сети, будут иметь общий источник
данных, но смогут устраивать формы, отчеты и другие объекты по своему
усмотрению.
159
ЧАСТЬ V. ОРГАНИЗАЦИЯ ЭКСПЕРТНЫХ СИСТЕМ
Этот раздел посвящен обсуждению особого типа информационных комплексов – экспертных систем. Рассматриваются основные принципы организации и функционирования экспертного анализа на основе информационных
систем. Отдельное внимание уделено тематике автоматизированных систем
научных исследований.
Тема 16. Структура экспертных систем
16.1 Понятие экспертных систем
При выполнении каких условий компьютерную программу можно
назвать экспертом?
Вполне логично потребовать, чтобы такая программа обладала знаниями. Просто способность выполнять некоторый алгоритм, например производить анализ списка элементов на наличие какого-либо свойства, явно не отвечает этому требованию, Это все равно, что дать первому случайному прохожему список вопросов и ответов и ожидать от него успешного выполнения
поиска и устранения неисправностей в системах определенного типа. Раньше
или позже, но он обязательно столкнется с ситуацией, не предусмотренной в
том списке, которым его снабдили.
Знания, которыми обладает программа, должны быть сконцентрированы
на определенную предметную область. Случайный набор имен, дат и мест
событий, сентенций из классиков и т.п. — это отнюдь не те знания, которые
могут послужить основой для программы, претендующей на способность
выполнить экспертный анализ. Знания предполагают определенную организацию и интеграцию — то есть отдельные сведения должны соотноситься
друг с другом и образовывать нечто вроде цепочки, в которой одно звено
"тащит" за собой следующее.
И, наконец, из этих знаний должно непосредственно вытекать решение
проблем. Просто продемонстрировать свои знания, касающиеся, например,
технического обслуживания компьютеров, — это далеко не то же самое, что
привести компьютер в "чувство". Точно так же, получить доступ к оперативной документации — это совсем не то же самое, что заполучить в свое распоряжение специалиста (или программу), способного справиться с возникшими проблемами.
Теперь попробуем подытожить эти рассуждения в следующем формальном определении экспертной системы.
Экспертная система — это программный комплекс, которая оперирует
со знаниями в определенной предметной области с целью выработки рекомендаций или решения проблем.
Экспертная система может полностью взять на себя функции, выполнение которых обычно требует привлечения опыта человека-специалиста,
или играть роль ассистента для человека, принимающего решение. Другими
160
словами, система (техническая или социальная), требующая принятия решения, может получить его непосредственно от приложения или через промежуточное звено – человека, который общается с приложением. Тот, кто принимает решение, может быть экспертом со своими собственными правами, и
в этом случае программа может повысить эффективность его работы. Альтернативный вариант – человек, работающий в сотрудничестве с такой программой, может добиться с ее помощью результатов более высокого качества. Вообще говоря, правильное распределение функций между человеком и
машиной является одним из ключевых условий высокой эффективности
внедрения экспертных систем.
Технология экспертных систем является одним из направлений особой
области исследования, которая получила наименование искусственного интеллекта (Artificial Intellect). Исследования в этой области сконцентрированы на разработке и внедрении программ, способных эмулировать (имитировать, воспроизводить) те области деятельности человека, которые требуют
мышления, определенного мастерства и накопленного опыта. К ним относятся задачи принятия решений, распознавания образов и понимания человеческого языка. Экспертные системы успешно применяются в ряде областей
техники и жизни общества – органической химии, поиске полезных ископаемых, медицинской диагностике.
Перечень типовых задач, решаемых экспертными системами, включает:
- извлечение информации из первичных данных (потоков данных, БД и
т.д.);
- диагностика неисправностей (как в технических системах, так и в человеческом организме);
- структурный анализ сложных объектов (например, химических соединений);
- выбор конфигурации сложных многокомпонентных систем (например,
распределенных компьютерных систем);
- планирование последовательности выполнения операций, приводящих
к заданной цели (например, выполняемых промышленными роботами).
Четкого формального определения экспертной системы, которое всех
бы удовлетворило, не существует – приведенное выше тоже довольно расплывчато. Но тем не менее существует довольно много важных признаков,
присущих в той или иной степени всем экспертным системам.
1. Экспертные системы моделирует не столько физическую (или иную)
природу определенной проблемной области, сколько механизм мышления человека применительно к решению задач в этой проблемной области. Это существенно отличает экспертные системы от систем математического моделирования или компьютерной анимации. Нельзя, конечно, сказать, что программа полностью воспроизводит психологическую модель специалиста в
этой предметной области (эксперта), но важно, что основное внимание всетаки уделяется воспроизведению компьютерными средствами методики ре161
шения проблем, которая применяется экспертом, т.е. выполнению некоторой
части задач так же (или даже лучше), как это делает эксперт.
2. Система, помимо выполнения вычислительных операций, формирует
определенные соображения и выводы, основываясь на тех знаниях, которыми она располагает. Знания в системе представлены, как правило, на некотором специальном языке и хранятся отдельно от собственно программного
кода, который и формирует выводы и соображения. Этот компонент программы принято называть базой знаний.
3. При решении задач основными являются эвристические и приближенные методы, которые, в отличие от алгоритмических, не всегда гарантируют успех. Эвристика, по существу, является правилом влияния (rule of
thumb), которое в машинном виде представляет некоторое знание, приобретенное человеком по мере накопления практического опыта решения аналогичных проблем. Такие методы являются приблизительными в том смысле,
что, во-первых, они не требуют исчерпывающей исходной информации, и,
во-вторых, существует определенная степень уверенности (или неуверенности) в том, что предлагаемое решение является верным.
4. Экспертные системы имеют дело с предметами реального мира, операции с которыми обычно требуют наличия значительного опыта, накопленного человеком. Множество программ из области искусственного интеллекта
являются сугубо исследовательскими и основное внимание в них уделяется
абстрактным математическим проблемам или упрощенным вариантам реальных проблем (иногда их называют "игрушечными" проблемами), а целью
выполнения такой программы является "повышение уровня интуиции" или
отработка методики. Экспертные системы имеют ярко выраженную практическую направленность в научной или коммерческой области.
5. Одной из основных характеристик экспертной системы является ее
производительность, т.е. скорость получения результата и его достоверность
(надежность). Исследовательские программы искусственного интеллекта могут и не быть очень быстрыми, можно примириться и с существованием в
них отказов в отдельных ситуациях. А вот экспертная система должна за
приемлемое время найти решение, которое было бы не хуже, чем то, которое
может предложить специалист в этой предметной области.
6. Экспертная система должна обладать способностью объяснить, почему предложено именно такое решение, и доказать его обоснованность.
Пользователь должен получить всю информацию, необходимую ему для того, чтобы быть уверенным, что решение принято "не с потолка". В отличие от
этого, исследовательские программы "общаются" только со своим создателем, который и так (скорее всего) знает, на чем основывается ее результат.
Экспертная система проектируется в расчете на взаимодействие с разными
пользователями, для которых ее работа должна быть, по возможности, прозрачной.
Зачастую термин система, основанная на знаниях (knowledge-based system), используется в качестве синонима термина экспертная система, хотя,
162
строго говоря, экспертная система — это более широкое понятие. Система,
основанная на знаниях, - это любая система, процесс работы которой основан
на применении правил отношений к символическому представлению знаний,
а не на использовании алгоритмических или статистических методов. Таким
образом, программа, способная рассуждать о погоде, будет системой, основанной на знаниях, даже в том случае, если она не способна выполнить метеорологическую экспертизу. А вот чтобы иметь право называться метеорологической экспертной системой, программа должна быть способна давать
прогноз погоды (другой вопрос - насколько он будет достоверен).
16.2 Базовые функции экспертных систем
1. Приобретение знаний.
Бучанан следующим образом сформулировал функцию приобретения
знаний: «Приобретение знаний - это передача потенциального опыта решения проблемы от некоторого источника знаний и преобразование его в вид,
который позволяет использовать эти знания в программе».
Передача знаний выполняется в процессе достаточно длительных и пространных собеседований между специалистом по проектированию экспертной системы (будем в дальнейшем называть его инженером по знаниям) и
экспертом в определенной предметной области, способным достаточно четко
сформулировать имеющийся у него опыт. По существующим оценкам, таким
методом можно сформировать от двух до пяти "элементов знания" (например, правил влияния) в день. Конечно, это очень низкая скорость, поэтому
многие исследователи рассматривают функцию приобретения знаний в качестве одного из главных "узких мест" технологии экспертных систем.
Причин такой низкой производительности предостаточно. Ниже перечислены только некоторые из них.
- Специалисты в узкой области, как правило, пользуются собственным
жаргоном, который трудно перемести на общепринятый язык.
- Факты и принципы, лежащие в основе многих специфических областей
знания эксперта, не могут быть четко сформулированы в терминах математической теории или детерминированной модели, свойства которой хорошо
понятны.
- Для того чтобы решить проблему в определенной области, эксперту
недостаточно просто обладать суммой знаний о фактах и принципах в этой
области. Например, опытный специалист знает, какого рода информацией
нужно располагать для формулировки того или иного суждения, насколько
надежны различные источники информации и как можно расчленить сложную проблему на более простые, которые можно решать более или менее
независимо. Выявить в процессе собеседования такого рода знания, основанные на личном опыте и плохо поддающиеся формализации, значительно
сложнее, чем получить простой перечень каких-то фактов или общих принципов.
163
- Экспертный анализ даже в очень узкой области, выполняемый человеком, очень часто нужно поместить в довольно обширный контекст, который
включает и многие вещи, кажущиеся эксперту само собой разумеющимися,
но для постороннего отнюдь таковыми не являющиеся.
Неудовлетворительные результаты подобных собеседований пробудили
у некоторых исследователей интерес к автоматизации процесса передачи
знаний специалистом машине. Одно из направлений исследований в этой области – автоматизированное извлечение знаний (automated knowledge elicitation) – появилось как побочный продукт в развитии систем человекомашинного диалога. Другие исследователи полагают, что "расшить" это узкое место можно, двигаясь по пути машинного обучения (machine learning).
Идея состоит в том, чтобы машина училась решать проблемы примерно так,
как учится человек.
2. Представление знаний
Теория представления знаний – это отдельная область исследований,
тесно связанная с философией формализма и когнитивной психологией.
Предмет исследования в этой области – методы ассоциативного хранения
информации, подобные тем, которые существуют в мозгу человека. При этом
основное внимание, естественно, уделяется логической, а не биологической
стороне процесса, опуская подробности физических преобразований.
В области экспертных систем представление знаний интересует нас в
основном как средство отыскания методов формального описания больших
массивов полезной информации с целью их последующей обработки с помощью символических вычислений. Формальное описание означает упорядочение в рамках какого-либо языка, обладающего достаточно четко формализованным синтаксисом построения выражений и такого же уровня семантикой, увязывающей смысл выражения с его формой.
Символические вычисления означают выполнение нечисловых операций,
в которых могут быть сконструированы символы и символьные структуры
для представления различных концептов и отношений между ними. В области искусственного интеллекта ведется интенсивная работа по созданию
языков представления (representation languages). Под этим термином понимаются компьютерные языки, ориентированные на организацию описаний
объектов и идей, в противовес статическим последовательностям инструкций
или хранению простых элементов данных. Основными критериями доступа к
представлению знаний являются логическая адекватность, эвристическая
мощность и естественность, органичность нотации.
Логическая адекватность означает, что представление должно обладать
способностью распознавать все отличия, которые вы закладываете в исходную сущность.
Эвристическая мощность означает, что наряду с наличием выразительного языка представления должно существовать некоторое средство использования представлений, сконструированных и интерпретируемых таким образом, чтобы с их помощью можно было решить проблему. Часто оказывает164
ся, что язык, обладающий большей выразительной способностью в терминах
количества семантических отличий, оказывается и более сложным в управлении описанием взаимосвязей в процессе решения проблемы.
Естественность нотации. Выражения, которыми формально описываются знания, должны быть по возможности простыми для написания, а их
смысл должен быть понятен даже тому, кто не знает, как компьютер интерпретирует эти выражения. Примером может служить декларативный программный код, который сам по себе дает достаточно четкое представление о
процессе его выполнения даже тому, кто не имеет представления о деталях
реализации компьютером отдельных инструкций.
3. Управление процессом поиска решения
Использование разных стратегий перебора имеющихся знаний, как правило, оказывает довольно существенное влияние на характеристики эффективности программы. Эти стратегии определяют, каким способом программа
отыскивает решение проблемы в некотором пространстве альтернатив. Как
правило, не бывает так, чтобы данные, которыми располагает программа работы с базой знаний, позволяли точно "выйти" на ту область в этом пространстве, где имеет смысл искать ответ.
Большинство формализмов представления знаний может быть использовано в разных режимах управления, и разработчики экспертных систем продолжают экспериментировать в этой области.
4. Разъяснение принятого решения
Вопрос о том, как помочь пользователю понять структуру и функции некоторого сложного компонента программы, связан со сравнительно новой
областью взаимодействия человека и машины, которая появилась на пересечении таких областей, как искусственный интеллект, промышленная технология, физиология и эргономика. На сегодня вклад в эту область исследователей, занимающихся экспертными системами, состоит в разработке методов
представления информации о поведении программы в процессе формирования цепочки логических заключений при поиске решения.
Способность системы объяснить методику принятия решения иногда
называют прозрачностью системы. Эту характеристику системы следует
рассматривать в совокупности с режимом управления, поскольку последовательность этапов принятия решения тесно связана с заданной стратегией поведения. Отсутствие достаточной прозрачности поведения системы не позволит эксперту повлиять на ее производительность или дать совет, как можно
ее повысить.
16.3 Режимы функционирования экспертных систем
Экспертные системы функционируют в двух режимах:
• режим приобретения знаний;
• режим решения задачи, называемый также режимом консультации или
режимом использования экспертной системы;
165
В режиме приобретения знаний общение с системой осуществляет эксперт через посредничество инженера по знаниям. В этом режиме эксперт, используя компонент приобретения знаний, наполняет систему знаниями, которые позволяют экспертной системе в режиме консультации автономно решать задачи из проблемной области. Эксперт описывает проблемную область
в виде совокупности данных и правил. Режиму приобретения знаний в традиционном подходе к разработке программ соответствуют этапы алгоритмизации, программирования и отладки, выполняемые программистом
В режиме консультации общение с экспертной системой осуществляет
конечный пользователь, которого интересует результат и (или) способ его
получения. В режиме консультации данные о задаче через интерфейс пользователя поступают в рабочую память (здесь хранятся промежуточные данные
решаемой в текущий момент задачи). На основе входных данных из рабочей
памяти, общих данных о проблемной области и правил базы знаний с помощью механизма логического вывода формируется решение задачи. Экспертная система при решении задачи не только исполняет предписанную последовательность операций, но и предварительно формирует ее.
16.4 Типовая структура экспертных систем
Обобщенная структура экспертной системы представлена на рис. Следует учесть, что реальные экспертные системы могут иметь более сложную
структуру, однако блоки, изображенные на рис. непременно присутствуют в
любой действующей экспертной системе, поскольку представляют собой
стандарт структуры современной экспертной системы.
Рисунок 55. Типовая структура экспертных систем
16.5 Классификация экспертных систем
Для классификации экспертных систем можно предложить следующие
категории:
- назначение экспертного анализа;
- организация режима работы;
- тип используемой ЭВМ;
166
- степень интеграции с другими приложениями и системами.
Наглядно основные типы экспертных систем приведены на рис. 56
Рисунок 56. Классификация экспертных систем
В небольших пояснениях, видимо, нуждается только один пункт. По организации режима работы экспертные системы подразделяются на:
- статические, в которых экспертный анализ производится на основании
неизменной базы знаний;
- квазидинамические (с дискретным временем), где свойственно потактовое обновление базы знаний и соответственно изменяются правила влияния;
- динамические, практикующие непрерывное обновление базы знаний,
что может привести к изменению хода экспертного анализа в рамках одного
запроса.
Тема 17. Проектирование АСНИ на базе экспертных систем
17.1 АСНИ как информационная система
Повышение эффективности фундаментальных и прикладных научных
исследований становится важным фактором ускорения научно-технического
прогресса. Особое значение в данном контексте приобретает автоматизация
научных исследований, позволяющая получать более точные и полные модели исследуемых объектов и явлений, ускорять ход научных исследований и
снижать их трудоемкость, изучать сложные объекты и процессы, исследование которых традиционными методами затруднительно или невозможно.
Применение автоматизированных систем научных исследований и комплексных испытаний образцов новой техники (АСНИ) наиболее эффективно
в тех современных областях науки и техники, которые имеют дело с использованием больших объемов информации. К ним прежде всего относятся:
167
- ядерная физика (сбор и обработка экспериментальных данных, получаемых на реакторах, ускорителях и установках термоядерного синтеза);
 - физика плазмы и твердого тела;
 - радиофизика и электроника;
 - астрономия и радиоастрономия;
 - космические исследования (обработка информации, получаемой с искусственных спутников для нужд народного хозяйства);
 - геология и геофизика (разведка полезных ископаемых);
 - исследования Мирового океана, экологические исследования, прогнозирование погоды и стихийных бедствий;
 - биология и медицина (исследования в области молекулярной биологии, микробиологического синтеза, диагностики заболеваний);
 - химическая технология (моделирование технологических процессов,
получение материалов с заданными свойствами);
 - исследования сложных технологических процессов в промышленности;
 - исследования и разработки в области энергетики (электростанции, сети электропередачи, энергетические системы);
 - исследования и разработки в области транспортных коммуникаций,
сетей связи и сетей вычислительных машин;
 - натурные и стендовые испытания сложных технических объектов (летательных аппаратов, транспортных устройств, машин, сооружений);
 - экономика, социальные исследования, право и языкознание.
Автоматизированные системы научных исследований и комплексных
испытаний образцов новой техники обеспечивают получение значительного
экономического эффекта. Эффект экономии образуется за счет повышения
производительности труда в исследовательских и испытательных подразделениях, улучшения технико-экономических характеристик разрабатываемых
объектов на основе получения и использования более точных моделей этих
объектов, сокращения дорогостоящих натурных испытаний, исключения некоторых стадий опытно-конструкторских работ, что в конечном счете приводит к снижению затрат на разработку объектов новой техники.
АСНИ отличаются от других типов автоматизированных систем (АСУ,
АСУТП, САПР и т.д.) характером информации, получаемой на выходе системы. Прежде всего, это обработанные или обобщенные экспериментальные
данные, но главное – полученные на основе этих данных математические модели исследуемых объектов, явлений или процессов. Адекватность и точность таких моделей обеспечивается всем комплексом методических, программных и других средств системы. Эта характеристика АСНИ сближает ее
с классом экспертных систем.
В АСНИ могут использоваться также и готовые математические модели
для изучения поведения тех или иных объектов и процессов, а также для
уточнения самих этих моделей. АСНИ поэтому являются системами для получения, корректировки или исследования моделей, используемых затем в

168
других типах автоматизированных систем для управления, прогнозирования
или проектирования.
17.2 Понятие и функции АСНИ
Автоматизированная система научных исследований и комплексных испытаний образцов новой техники (АСНИ) - это программно-аппаратный
комплекс на базе средств вычислительной техники, предназначенный для
проведения научных исследований или комплексных испытаний образцов
новой техники на основе получения и использования моделей исследуемых
объектов, явлений и процессов.
Программно-аппаратный комплекс АСНИ состоит из средств методического, программного, технического, информационного и организационноправового обеспечения.
Взаимодействие исследуемого объекта, явления или процесса с АСНИ
осуществляется через аппаратуру сопряжения, входящую в состав программно-аппаратного комплекса.
Взаимодействие подразделений научно-исследовательской организации
или предприятия с АСНИ регламентируется средствами организационноправового обеспечения системы.
Основная функция АСНИ состоит в получении результатов научных исследований (комплексных испытаний) путем автоматизированной обработки
экспериментальных данных и другой информации, получения и исследования моделей объектов, явлений и процессов на основе применения математических методов, автоматизированных процедур, планирования и управления
экспериментом. Автоматизированные процедуры в АСНИ состоят в том, что
исследования (испытания) объектов, явлений и процессов, получение и исследование математических моделей осуществляется путем взаимодействия
пользователя с АСНИ в режиме диалога.
В АСНИ также могут осуществляться автоматические процедуры, при
которых обработка данных, идентификация или построение математических
моделей производятся без участия человека. Наряду с этим в АСНИ применяются процедуры планирования и управления экспериментом, при которых
использование моделирования корректирует условия эксперимента, а экспериментальная информация используется для выбора математической модели
из некоторого заданного множества таких моделей. Т.е. фактически реализуется одна из типовых задач экспертных систем.
Результатом функционирования АСНИ является подтверждение (отклонение) гипотез или совокупность законченных математических моделей,
удовлетворяющая заданным требованиям, а также обработанные результаты
исследований, наблюдений и измерений. Функционирование АСНИ должно
обеспечивать получение выходных документов, выполненных в заданной
форме и содержащих результаты научных исследований или испытаний, а
также рекомендации по использованию этих результатов для прогнозирования, управления или проектирования.
169
17.3 Структура АСНИ
Основными структурными звеньями АСНИ являются подсистемы.
Подсистемой АСНИ называется выделенная по некоторым признакам часть
АСНИ, обеспечивающая выполнение определенных автоматизированных
процедур исследований (испытаний) и получение соответствующей выходной информации.
По типу выполняемых функций их можно разделить на следующие:
- подсистема измерений – информационно-измерительный канал (ИИК);
- подсистема передачи данных;
- подсистема обработки данных и принятия решений;
- подсистема представления информации.
Различают также объектно-ориентированные (объектные) и обслуживающие подсистемы АСНИ.
Объектные подсистемы осуществляют получение и предварительного
обработку экспериментальных данных с некоторого объекта. В качестве
примера можно привести блок регистрации экспериментальных данных, получаемых со специализированных установок (ускорителей, спектрометров,
испытательных стендов);
Обслуживающая подсистема осуществляет функции управления и обработки информации, не зависящие от особенностей исследуемого явления,
объекта или процесса, т.е. работающая с абстрактными формализованными
данными. Т.е. фактически обслуживающие подсистемы АСНИ могут иметь
много общих элементов с соответствующими экспертными системами.
Обслуживающими могут быть, например, подсистемы:
 - управления АСНИ;
 - диалоговых процедур;
 - численного анализа;
 - планирования и оптимизации эксперимента;
 - ввода, обработки и вывода графической информации;
 - информационно-поисковых процедур.
Подсистема АСНИ состоит из компонентов, объединенных общей для
данной подсистемы процедурой.
Компонентом называется элемент средств обеспечения, выполняющий
определенную функцию в подсистеме АСНИ. Структурное единство подсистемы АСНИ обеспечивается связями между компонентами различных
средств обеспечения, образующими подсистему.
Структурное объединение подсистем АСНИ в систему обеспечивается
связями между компонентами, входящими в подсистемы. Средства обеспечения АСНИ состоят из следующих компонентов:
 - методического обеспечения;
 - ПО;
 - технического обеспечения;
 - информационного обеспечения;
170
- организационно-правового обеспечения.
Компонентами методического обеспечения являются документы, в которых изложены полностью или со ссылкой на первоисточники: теория, методы, способы, математические модели, алгоритмы, алгоритмические специальные языки для описания объектов, терминология, нормативы, стандарты и
другие данные, обеспечивающие методологию научных исследований или
испытаний в подсистемах АСНИ. Из состава методического обеспечения могут выделяться компоненты математического и лингвистического обеспечения.
Компонентами ПО являются документы с текстами программ, программы на машинных носителях и эксплуатационные документы, обеспечивающие функционирование соответствующих подсистем АСНИ.
ПО подразделяется на общесистемное и прикладное. Компонентами общесистемного ПО являются, например, ОС, стандартные управляющие приложения на базе операционных систем, трансляторы с алгоритмических языков и языков управления, эмуляторы.
Компонентами прикладного программного обеспечения являются программы и пакеты специализированных программ, непосредственно предназначенные для осуществления процедур исследований или испытаний.
Компонентами технического обеспечения являются устройства вычислительной и организационной техники, средства и устройства связи с объектом,
измерительные и другие устройства или их сочетания, обеспечивающие
функционирование соответствующих подсистем АСНИ. Совокупность компонентов технического обеспечения образует комплекс технических средств
АСНИ.
Компонентами информационного обеспечения являются документы, содержащие описания стандартных процедур, типовые математические модели,
основные законы, формулы, константы и другие данные, а также файлы и
блоки данных на машинных носителях с записью указанных документов,
обеспечивающие функционирование соответствующих подсистем АСНИ.
Совокупность компонентов информационного обеспечения образует
информационную базу (БД АСНИ).
Компонентами организационно-правового обеспечения АСНИ являются
методические и руководящие материалы, положения, инструкции, приказы,
штатные расписания, квалификационные требования, инструкции для пользователей и другие документы, обеспечивающие взаимодействие подразделений организации или предприятия при создании, эксплуатации и развитии
АСНИ.

17.4 Основные принципы построения АСНИ
При разработке и эксплуатации АСНИ рекомендуется применять следующие принципы:
 - последовательное расширение сферы автоматизации научных исследований;
171
- интеграция АСНИ;
 - типизация, унификация и стандартизация компонентов АСНИ;
 - тиражирование типовых подсистем и компонентов АСНИ;
 - применение единой методологии создания и развития АСНИ;
 - системный подход к проектированию;
 - адаптивность;
 - разработка критериев эффективности АСНИ;
 - ориентация на методики ведущих в тематике коллективов;
 - опережающее развитие базовых решений в головных организациях.
Последовательное расширение сферы автоматизации научных исследований предполагает:
- внедрение средств автоматизации в новые области научных исследований, в первую очередь в те области, где получение новых существенных результатов невозможно без использования средств автоматизации;
- расширение контингента пользователей автоматизированных систем
научных исследований - от экспериментаторов до руководителей крупных
научных программ;
- автоматизация всех этапов научных исследований от планирования и
управления экспериментами до анализа и перспективного планирования основных направлений научных исследований.
Тематическая, функциональная и территориальная интеграция АСНИ
должна быть направлена в первую очередь на создание систем коллективного
пользования:
- для крупных экспериментальных, исследовательских и опытных установок и комплексных производственных испытаний различных технических
объектов в исследовательских и проектных организациях, в ВУЗах, на предприятиях, полигонах и т.п.;
- для отдельных крупных научно-исследовательских организаций, проводящих комплексные исследования сложных объектов;
- для взаимосвязанных единой программой работ или родственных по
тематике групп исследовательских и проектных организаций;
- для территориально объединенных групп исследовательских и проектных организаций, некоторых республиканских академий наук, академических и ведомственных научных центров.
Интеграция АСНИ включает в себя:
создание
многомашинных
иерархических
измерительновычислительных комплексов коллективного пользования, обслуживающих
несколько экспериментов;
- развитие информационной базы (создание централизованных и распределенных банков научных данных, обмен научными данными по каналам
связи между АСНИ в согласованных форматах, унификацию структур данных и типизацию систем управления базами данных);
- развитие общесистемного программного обеспечения (унификацию
операционной среды, использование стандартных и создание специализиро
172
ванных телекоммуникационных методов доступа, создание систем реального
времени, работающих в режимах многопользовательского доступа).
В качестве основы для создания АСНИ должны использоваться типовые,
проблемно-ориентированные или специализированные измерительновычислительные комплексы (ИВК), включающие в себя серийные средства
измерительной техники, а также типовое программное обеспечение.
Особое внимание должно быть уделено типовой аппаратуре сопряжения
ЭВМ с объектом исследования, созданию типовых программно-управляемых
модульных систем для сбора информации и управления сложными объектами. Требования к этой аппаратуре формируются на основе соответствующих
государственных и международных стандартов с тем, чтобы обеспечить максимальную совместимость технических и программных средств АСНИ, производимых различными организациями и в различных странах.
Важнейшим условием унификации и типизации компонентов и подсистем АСНИ является широкое использование в них агрегатных средств измерительной и вычислительной техники, удовлетворяющих требованиям конструктивной, информационной, эксплуатационной, энергетической и других
видов совместимости.
В разработке новых компонентов АСНИ необходимо широко применять
аппаратную реализацию наиболее типовых функций обработки данных, операционных систем и других функций управления операционной средой.
Тиражирование типовых подсистем и компонентов АСНИ основано на
типизации, унификации и стандартизации проектных решений при создании
подсистем и компонентов АСНИ, что создает условия для массового промышленного производства этих компонентов.
Перспективно, например, создание и тиражирование:
- типовых АСНИ для экспериментальных исследований в подразделениях научно-исследовательских организаций, высших учебных заведений и
предприятий;
- типовых передвижных АСНИ для полевой разведки, для научноисследовательских судов и других подвижных объектов, а также полигонных
исследований;
- типовых проблемно-ориентированных измерительно-вычислительных
комплексов для сбора и обработки информации на исследовательских установках и в лаборатории.
Единая методология создания АСНИ должна учитывать достижения в
смежных областях науки и техники и использовать взаимное влияние тенденций развития техники, технологии и производства, с одной стороны, и автоматизации научных и производственных экспериментов - с другой. Это
требование обеспечивается:
- ориентацией развития автоматизации в научно-исследовательских организациях, а также министерств и ведомств на единую методологическую,
техническую и программную основу технологии открытых систем;
173
- типизацией, унификацией и стандартизацией проектных решений при
создании АСНИ независимо от области их применения;
- сближением принципов и технологии крупнейших научных и промышленных экспериментов;
- использованием опыта создания и эксплуатации автоматизированных
систем управления технологическими процессами (АСУ ТП);
- разработкой однотипных методов и средств автоматизации крупных
научных экспериментов, с одной стороны, и промышленных экспериментов,
испытаний технических объектов и систем и опытного производства - с другой.
Системный подход в проектировании предполагает проведение проектирования на основе системного анализа, включающего решение комплекса
технических, экономических, организационных вопросов, решение которых в
совокупности обеспечит создание АСНИ оптимальным способом.
Адаптивность предполагает легкую приспособляемость АСНИ к изменению решаемых с ее помощью задач - scalability.
Разработка критериев эффективности АСНИ должна позволить дать
объективную оценку экономического или иного эффекта, получаемого от
внедрения АСНИ.
При создании или заимствовании компонентов АСНИ должны обеспечиваться требования к этим компонентам, вытекающие из общесистемных
принципов, изложенных выше.
Компоненты методического обеспечения рекомендуется создавать на
основе:
- перспективных методов автоматизации научных исследований, поиска
новых принципов действия и технических решений;
- эффективных методов математического моделирования исследуемого
объекта и его элементов;
- использование методов формализованного описания и имитационного
моделирования;
- применения методов планирования и оптимизации эксперимента;
- использования типовых и стандартных процедур обработки данных;
- стандартных вычислительных и расчетных методов.
Компоненты ПО рекомендуется создавать с использованием следующих
требований:
- максимального применения стандартного и серийного программного
обеспечения технологии открытых систем;
- адаптируемости к различным конфигурациям ЭВМ и их операционным
системам - открытости, переносимости, взаимодействия;
- обеспечения мультипрограммной работы, режима разделения времени,
работы в режиме диалога;
- модульного построения, расширения и обновления;
- обеспечения контроля и диагностирования;
174
- применения языков и систем программирования, рекомендованных
ГКНТ;
- автоматизации оборота документов;
- в технических заданиях на разработку компонентов программного
обеспечения предусматривать требования, обязывающие разработчиков использовать рекомендованные ГКНТ технологии программирования, повышающие производительность труда программистов.
Компоненты технического обеспечения должны создаваться на базе:
- серийных средств вычислительной техники общего назначения;
- серийных агрегатных средств измерительной техники общего назначения;
- специализированных технических средств, если их применение в
АСНИ технически и экономически оправдано;
- современных технических средств общего назначения для сопряжения
ЭВМ с объектами исследования.
Компоненты информационного обеспечения должны создаваться на основе:
- максимального использования серийных технических и программных
средств;
- гибкой организации и открытой структуры, приспособленной к пополнению и объединению открытых систем;
- возможности логической структуризации данных по формальным признакам;
- возможности одновременного использования данных несколькими
подсистемами АСНИ;
- обеспечения точности стандартных и нормативных данных;
- разграничения доступа и защиты файлов и блоков данных;
- соответствия международным стандартам открытых систем.
Компоненты организационно-правового обеспечения АСНИ должны создаваться на основе:
- прогрессивных методов научных исследований и испытаний;
- стандартов и нормативных документов, регламентирующих научные
исследования в отрасли;
- современных методов планирования и управления;
- анализа экономической эффективности и применения мер материального стимулирования.
Развитие (совершенствование) компонентов АСНИ осуществляется путем создания новых модификаций (в том числе новых редакций, версий, типов) этих компонентов.
175
Рекомендуемая литература
Основная
1. Хомоненко, А.Д. Базы данных / А.Д. Хомоненко, В.М. Цыганков,
М.Г. Мальцев- СПб: КОРОНА-Век, 2011. – 736 с.
2. Скакун, В.В. Системы управления базами данных: пособие для
студентов фак. радиофизики и электроники / В.В. Скакун. - Минск: Изд.
центр БГУ, 2008. - 114 с. .
3. Горев, А. Эффективная работа с СУБД / А. Горев - СПб: Питер,
1998.
4. Гольцман, В. MySQL 5.0 / В. Гольцман - СПб: Питер, 2009. -256 с.
5. Бекаревич, Ю. Самоучитель Access 2007 / Ю. Бекаревич, Н. Пушкина - СПб: БХВ-Петербург, 2007. – 720 с.
6. Петкович, Д. Microsoft SQL Server 2008. Руководство для начинающих / Душан Петкович - СПб: БХВ-Петербург, 2009. – 752 с.
7. Кузнецов, С.Д. Базы данных. Модели и языки / С.Д. Кузнецов М.:
ООО «Бином-Пресс», 2008. – 720 с.
Дополнительная
1. Дейт, Дж. Введение в базы данных. Издание 6 / Дж. Дейт/ - СПб:
Питер, 2001.
2. Конолли, Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. Т. Конолли и К. Берг. - М, СПб, К: Вильяме,
2000.
3. Цикритзис, Д. Модели данных / Д. Цикритзис, Ф.М. Лоховски. - М:
Финансы и Статистика, 1985.
4. Джексон, П. Введение в экспертные системы / Питер Джексон - М:
ИД «Вильямс», 2001. – 624 с.
5. Гаврилова, Т.А. Базы знаний интеллектуальных систем / Т.А. Гаврилова, В.Ф. Хорошевский - СПб: Питер, 2001. – 384 с.
176