ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ
СИСТЕМ УПРАВЛЕНИЯ
Конспект лекций
Содержание
Введение ............................................................................................................................................... 4
1. Информационные системы и базы данных (лекция 1)........................................................... 5
1.1. Понятие информационной системы, информационное обеспечение ................................. 5
1.2. Понятие базы данных ............................................................................................................... 5
1.3. Понятие системы управления базами данных ....................................................................... 6
1.4. Категории пользователей базой данных .............................................................................. 16
2. Проектирование баз данных (лекция 2) .................................................................................. 22
2.1. Жизненный цикл информационной системы ...................................................................... 22
2.2. Подходы и этапы проектирования баз данных.................................................................... 24
3. Архитектуры СУБД (лекции 3-4).............................................................................................. 28
3.1. Телеобработка ......................................................................................................................... 28
3.2. Файловый сервер .................................................................................................................... 29
3.3. Технология «клиент/сервер» ................................................................................................. 29
3.4. Понятие независимости данных ........................................................................................... 31
4. Инфологическое проектирование базы данных (лекции 5-6) ............................................. 32
4.1. Модель «сущность-связь» ..................................................................................................... 32
4.2. Классификация сущностей, расширение ER-модели ......................................................... 37
4.3. Проблемы ER-моделирования............................................................................................... 39
5. Выбор СУБД (лекция 7) .............................................................................................................. 43
5.1. Метод ранжировки ................................................................................................................. 44
5.2. Метод непосредственных оценок ......................................................................................... 45
5.3. Метод последовательных предпочтений ............................................................................. 45
5.4. Оценка результатов экспертного анализа ............................................................................ 47
6. Даталогические модели данных (лекции 8-9)......................................................................... 50
6.1. Иерархическая модель ........................................................................................................... 50
6.2. Сетевая модель........................................................................................................................ 52
6.3. Реляционная модель ............................................................................................................... 53
6.4. Достоинства и недостатки даталогических моделей .......................................................... 54
7. Физическая организация данных в СУБД (лекции 10-11)................................................... 58
7.1. Списковые структуры ............................................................................................................ 58
7.2. Модель внешней памяти ........................................................................................................ 64
7.3. Методы поиска и индексирования данных .......................................................................... 66
8. Внутренний язык СУБД (лекции 12-13) .................................................................................. 72
8.1. Теоретические языки запросов.............................................................................................. 73
8.2. Определение реляционной полноты ..................................................................................... 83
8.3. Введение в язык SQL ............................................................................................................. 84
9. Распределенные СУБД (лекция 14) .......................................................................................... 90
9.1. Основные определения, классификация распределенных систем..................................... 90
9.2. Преимущества и недостатки распределенных СУБД ......................................................... 95
9.3. Функции распределенных СУБД .......................................................................................... 98
9.4. Архитектура распределенных СУБД.................................................................................... 98
9.5. Разработка распределенных реляционных баз данных .................................................... 101
9.6. Обеспечение прозрачности .................................................................................................. 111
2
10. Защита и секретность данных (лекции 15-16) .................................................................... 116
10.1. Понятие информационной безопасности. Основные составляющие ............................ 116
10.2. Распространение объектно-ориентированного подхода на информационную
безопасность ....................................................................................................................... 118
10.3. Наиболее распространенные угрозы ................................................................................ 121
10.4. Административный уровень информационной безопасности ....................................... 125
10.5. Управление рисками .......................................................................................................... 128
10.6. Процедурный уровень информационной безопасности ................................................. 131
10.7. Основные программно-технические меры....................................................................... 135
3
Введение
Предметом настоящего курса являются информационные системы, базы данных и системы
управления базами данных.
Границы применения вычислительной техники в различных сферах человеческой
деятельности с каждым годом определить все сложнее – они становятся необъятными. Это
объясняется рядом объективных причин [2, 5, 7, 8, 17]. Так, неоспоримы успехи в областях
технического и математического обеспечения ЭВМ, в развитии электроники и интегральной
схемотехники.
Повсеместное применение средств вычислительной техники связано и с информационным
взрывом [1, 11, 14, 15], сущность которого состоит в лавинообразном росте количества
информации,
которое
должно
воспринимать
и
перерабатывать
человечество
(экспоненциальный закон роста количества информации). Это касается всех сфер человеческой
деятельности. Информация, данные все чаще рассматриваются как стратегические
национальные ресурсы, которые должны быть организованы так, чтобы ценность их была
максимальной.
Революционный рост объемов перерабатываемой информации и накопленный опыт
использования электронно-вычислительной техники в различных областях привели в 60-70-х
годах XX века к необходимости пересмотреть такую традиционную область обработки
информации, как управление данными. Новый подход к обработке информации нашел
наиболее яркое отражение в концепции баз данных [17]. Автоматизированные
информационные системы на основе баз данных позволили обеспечить устранение излишней
избыточности хранимых данных, предоставили возможности многоаспектного поиска во
взаимосвязанной совокупности именованных данных.
С начала развития вычислительной техники образовались два основных направления ее
использования [2, 5, 9]. Первое направление – применение вычислительной техники для
выполнения численных расчетов, которые слишком долго или вообще невозможно производить
вручную. Становление этого направления способствовало интенсификации методов численного
решения сложных математических задач, развитию класса языков программирования,
ориентированных на удобную запись численных алгоритмов, становлению обратной связи с
разработчиками новых архитектур ЭВМ.
Второе направление – это использование средств вычислительной техники в автоматических
или автоматизированных информационных системах [17].
4
1. ИНФОРМАЦИОННЫЕ СИСТЕМЫ И БАЗЫ ДАННЫХ (ЛЕКЦИЯ 1)
1.1. Понятие информационной системы, информационное обеспечение
Информационные системы – системы обработки данных о какой-либо предметной области
со средствами накопления, хранения, обновления, поиска и выдачи данных [12].
Данные - информация (факты и идеи), представленная в формализованном виде,
позволяющем передавать или обрабатывать ее при помощи некоторого процесса (и
соответствующих технических средств).
Под «передачей» данных подразумевается и процесс их хранения, т.к. с теоретических
позиций – хранение равносильно передаче данных, но не в пространстве, а во времени.
В широком смысле под информацией понимают любые сведения о каком-либо событии,
сущности, процессе и т.п., являющиеся объектом некоторых операций: восприятия, передачи,
преобразования, хранения или использования.
Процесс осмысливания понятия информации и ее роли в жизни и деятельности человека
продолжается. Понятие информации вместе с другими научными понятиями позволяет глубже
познать законы развития материального мира. На современном этапе считается, что оно
является общим для всех видов и форм движения материи и связывается с тем или иным
неотъемлемым свойством или атрибутом материи [17].
Все многообразие информационных систем можно классифицировать по ряду признаков.
По средствам выполнения информационной задачи различают информационные системы
ручные, механизированные и автоматизированные; по выполняемой функции – информационнопоисковые, управляющие, моделирующие, обучающие, экзаменующие и др.; по области
применения – медицинские, финансовые, лингвистические и др.
Автоматизированная информационная система (АИС) – информационная система,
использующая ЭВМ на этапах ввода, обработки и выдачи информации по различным запросам
пользователей.
Представляя
собой
развитие
информационно-поисковых
систем,
обеспечивающих выполнение информационного поиска с помощью прикладных программ,
АИС характеризуется преимуществами системного направления развития ЭВМ:
1) многофункциональностью, т.е. способностью решать разнообразные задачи;
2) одноразовостью подготовки и ввода данных;
3) независимостью процесса сбора и обновления (актуализации) данных от процесса их
использования прикладными программами;
4) независимостью прикладных программ от физической организации базы данных;
5) развитыми средствами лингвистического обеспечения.
Для полного решения какой-либо информационной задачи в этих системах необходимо,
чтобы ЭВМ понимала смысл текста, написанного на естественном языке, что тесно связано с
проблемой искусственного интеллекта [17].
Таким образом, информационные системы служат информационному обеспечению
различных видов деятельности человека.
Информационное обеспечение – поддержка процессов управления, технологии, обучения,
научных исследований и др. средствами систем баз данных и знаний.
Качество информационного обеспечения гарантируется за счет концентрации информации в
базах данных, повышения интеллектуального уровня информационных систем средствами баз
знаний. Информационное обеспечение повышает производительность труда в десятки раз,
изменяет характер многих видов информационной и трудовой деятельности.
1.2. Понятие базы данных
База данных (БД) - именованная совокупность данных, отображающих состояние объектов и
их отношений в рассматриваемой предметной области. Организуется так, что данные
собираются однажды и централизованно хранятся (и модифицируются) в виде, доступном всем
специалистам или системам программирования, которые могут их использовать.
Особенности организации данных в БД по сравнению с файловыми системами обеспечивают
5
использование одних и тех же данных в различных приложениях, позволяют решать различные
задачи планирования, исследования и управления. БД сводят к минимуму дублирование
данных, прибегая к дублированию только для ускорения доступа к данным или для
обеспечения восстановления БД при ее разрушении. Одна из важных черт БД – независимость
данных от особенностей прикладных программ, которые их используют, а также возможность
создания этих программ в такой форме, что изменение особенностей хранения, логической
структуры или значений данных не требует изменения программ их обработки. Другой важной
чертой БД является возможность изменения физических особенностей хранения данных без
изменения их логической структуры.
Можно четко сформулировать требования к БД со стороны внешних пользователей [17]. База
данных должна:
1) удовлетворять актуальным информационным потребностям пользователей, обеспечивать
возможность хранения и модификации больших объемов многоаспектной информации;
2) обеспечивать заданный уровень достоверности хранимой информации и ее
непротиворечивость;
3) обеспечивать доступ к данным только пользователей с соответствующими полномочиями;
4) обеспечить возможность поиска информации по произвольной группе признаков;
5) удовлетворять заданным требованиям производительности при обработке запросов;
6) иметь возможность реорганизации и расширения при изменении границ предметной
области;
7) обеспечивать выдачу информации пользователям в различной форме;
8) обеспечивать простоту и удобство обращения внешних пользователей за информацией;
9) обеспечивать возможность одновременного обслуживания большого числа внешних
пользователей.
Соответственно двум понятиям – «информация» и «данные» – в базах данных различают два
аспекта рассмотрения вопросов: инфологический и даталогический [5, 17].
Инфологических аспект употребляется при рассмотрении вопросов, связанных со
смысловым содержанием данных независимо от способов их представления в памяти системы.
Даталогический аспект употребляется при рассмотрении вопросов представления данных в
памяти информационной системы.
Данные соответствуют зарегистрированным фактам об объектах реального мира. Чтобы в
дальнейшем использовать эти данные, требуется их смысловое содержание – семантика
данных. Поэтому в информационной системе должны быть сформулированы правила
смысловой интерпретации данных.
Основное средство представления семантики данных – естественный язык. Но существует
возможность использовать формализованные языки, которые позволяют более эффективно
организовать обработку данных на вычислительной технике и представить необходимую
семантику данных, удовлетворяющую практическим потребностям целого ряда прикладных
задач. К этому классу информационных систем (автоматизированных информационных систем)
относятся и системы на основе баз данных.
1.3. Понятие системы управления базами данных
Функционирование БД обеспечивается совокупностью языковых и программных средств,
называемых системой управления базами данных (СУБД).
Система управления базами данных – совокупность языковых и программных средств,
предназначенных для создания, ведения и использования базы данных многими
пользователями [12].
Основная особенность СУБД – это наличие процедур для ввода и хранения не только самих
данных, но и описаний их структуры. Файлы, снабженные описанием хранимых в них данных и
находящиеся под управлением СУБД, называются в свою очередь базами данных.
Создание и применение СУБД призвано к максимальному удовлетворению требований,
предъявляемых к эффективным базам данных. Это приводит к необходимости решения вопроса
централизованного управления данными.
6
Концепция централизованного управления данными имеет ряд неоспоримых преимуществ
по сравнению с файловыми системами (см. прил.1):
1. Минимальная избыточность хранимых данных.
2. Непротиворечивость хранимых данных.
3. Многоаспектное использование данных.
4. Комплексная оптимизация.
5. Возможность стандартизации представления и обмена данными.
6. Возможность обеспечения санкционированного доступа к данным.
Но, предоставляя весомые преимущества, централизованное управление данными
предъявляет к СУБД требование независимости данных от использующих их прикладных
программ.
Современные СУБД реализуют централизованное управление данными и, кроме того,
обеспечивают:
а) определение данных, подлежащих хранению в БД (определение логических свойств
данных, соответствующих представлениям пользователя и называемых структурами
данных в БД, а также физическая организация хранения данных, называемая структурами
хранения БД);
б) первоначальную загрузку данных в БД – так называемое создание БД;
в) обновление данных;
г) доступ к данным по различным запросам пользователя, отбор и извлечение некоторой
части БД, редактирование извлеченных данных и выдачу их пользователю.
Перечисленные действия принято называть процессом получения справок из БД.
Специальные средства СУБД обеспечивают секретность данных, т.е. защиту данных от
неправомочного воздействия, и целостность данных – защиту от непредсказуемого
взаимодействия конкурирующих процессов, приводящих к случайному или преднамеренному
разрушению данных, а также от отказов оборудования.
1.3.1. Обобщенная архитектура СУБД
Основной интерес применения СУБД заключается в том, чтобы предложить пользователям
(или прикладным процессам) абстрактное представление данных, скрыв особенности хранения
и управления ими.
Обобщенная структура связей программ и данных при использований СУБД представлена на
рис. 1.1 [5].
7
Рис. 1.1. Связь программ и данных при использовании СУБД
СУБД должна предоставлять доступ к данным посредством прикладных программ любым
пользователям, включая и тех, которые практически не имеют представления о:
1) физическом размещении в памяти данных и их описаний;
2) механизмах поиска запрашиваемых данных;
3) проблемах, возникающих при одновременном запросе одних и тех же данных многими
пользователями (прикладными программами);
4) способах обеспечения защиты данных от некорректных обновлений и (или)
несанкционированного доступа;
5) поддержании баз данных в актуальном состоянии и множестве других функций СУБД [5,
8, 17].
При выполнении основных из этих функций СУБД должна использовать различные
описания данных. Очевидно, что в таких описаниях обязательно должны быть учтены:
сущности интересующей предметной области;
атрибуты, характеризующие неотъемлемые свойства каждой сущности;
связи, ассоциирующие выделенные сущности.
С самых общих позиций, в архитектуре современных СУБД выделяют три уровня
абстракции, т.е. три уровня описания элементов хранимых данных. Эти уровни составляют
трехуровневую архитектуру, представленную на рис. 1.2, которая охватывает внешний,
концептуальный и внутренний уровни [7].
Представленный подход к описанию данных предложен комитетом ANSI/SPARC (Комитет
Планирования Стандартов и Норм Национального Института Стандартизации США) и имеет
целью отделение пользовательского представления о базе данных от ее физической
организации. Такое отделение обеспечивает независимость хранимых данных и применяется
по следующим причинам.
8

Каждый пользователь должен иметь возможность обращаться к данным, используя свое
представление о них, изменять свое представление о данных без влияния на
представления других пользователей.
 Пользователи не должны иметь дело с деталями физической организации данных, т.е. не
должны зависеть от особенностей физического хранения данных.
 Администратор базы данных (АБД) должен иметь возможность изменять структуру
хранения данных в базе так, чтобы эти изменения оставались «прозрачными» для
остальных пользователей.
 Структура базы данных не должна зависеть от физических аспектов хранения, например,
при переключении на новое устройство внешней памяти.
Рис. 1.2. Трехуровневая архитектура ANSI/SPARC
Внешний уровень – представление базы данных с точки зрения конкретных пользователей.
Указанный уровень может включать несколько различных представлений БД со стороны
различных групп пользователей. При этом каждый пользователь имеет дело с представлением
предметной области, выраженным в наиболее понятной и удобной для него форме. Такое
представление содержит только те сущности, атрибуты и связи, которые интересны ему при
решении профессиональных задач.
Различные представления на внешнем уровне могут пересекаться, т.е. использовать общие
описания абстракций предметной области.
На внешнем уровне создается инфологическая модель БД (внешняя схема), полностью
независимая от платформы (т.е. вычислительной системы, на которой будет использоваться).
Инфологическая модель является человеко-ориентированной: средой ее хранения может быть
память человека, а не ЭВМ. Инфологическая модель не изменяется до тех пор, пока какие-то
изменения в реальном мире не потребуют изменения в ней некоторого определения, чтобы эта
модель продолжала отражать предметную область.
Концептуальный уровень – обобщающее представление базы данных, описывающее то,
какие данные хранятся в БД, а также связи, существующие между ними.
Концептуальный уровень является промежуточным в трехуровневой архитектуре. Содержит
логическую структуру всей базы данных. Фактически, это полное представление требований к
данным со стороны организации, которое не зависит от соображений относительно способа их
хранения. На концептуальном уровне необходимо выделить:
9
1) сущности, их атрибуты и связи;
2) ограничения, накладываемые на данные;
3) семантическую информацию о данных;
4) информацию о мерах обеспечения безопасности.
Концептуальный уровень поддерживает каждое внешнее представление. Поэтому на этом
уровне содержатся любые доступные пользователю данные, за исключением сведений о
методах хранения этих данных.
На концептуальном уровне создается даталогическая модель (концептуальная схема БД),
представляющая собой описание инфологической модели (внешней схемы) на языке
определения данных конкретной СУБД. Эта модель является компьютеро-ориентированной
(зависит от применяемой на компьютере СУБД).
Внутренний уровень – физическое представление базы данных, описывающее методы их
хранения в вычислительной системе.
Данный уровень описывает физическую реализацию базы данных и предназначен для
достижения оптимальной производительности и обеспечения экономного использования
дискового пространства. Содержит описания структур данных и отдельных файлов,
используемых для хранения данных в запоминающих устройствах.
На внутреннем уровне осуществляется взаимодействие СУБД с методами доступа
операционной системы с целью эффективного размещения данных на носителях, создания
индексов и т.д. На этом уровне используется следующая информация:
 карта распределения дискового пространства для хранения данных и индексов;
 описание подробностей сохранения записей (с указанием реальных размеров
сохраняемых элементов данных);
 сведения о размещении записей;
 сведения о возможном сжатии данных и выбранных методах их шифрования.
Реализация перечисленной информации производится на физическом уровне
вычислительной системы, который контролируется операционной системой. В настоящее время
функции СУБД и операционной системы на физическом уровне строго не разграничиваются. В
одних СУБД используются все предусмотренные в данной операционной системе методы
доступа, в других применяются только основные и реализована собственная файловая система.
На внутреннем уровне создается физическая модель БД (внутренняя схема), которая также
является компьютеро-ориентированной (зависит от СУБД и операционной системы). С ее
помощью СУБД дает возможность программам и пользователям осуществлять доступ к
хранимым данным по именам, не заботясь об их физическом расположении. По этой модели
СУБД отыскивает необходимые данные на внешних запоминающих устройствах.
Соответствующие трехуровневой архитектуре ANSI/ SPARC три уровня моделей данных для
описания предметной области и реализации базы данных представлены на рис. 1.3 [5].
Для реализации рекомендаций ANSI/SPARC и выполнения сервисных функций, СУБД
строится по модульному принципу и является сложным программным продуктом. Конкретный
состав модулей и их взаимосвязей в реальных СУБД сильно различается, но можно выделить
ряд их обобщенных компонентов.
Основные программные компоненты СУБД представлены на рис. 1.4 [7].
 Процессор запросов. Это основной компонент СУБД, который преобразует запросы в
последовательность низкоуровневых инструкций для контроллера базы данных.
 Контроллер базы данных. Этот компонент взаимодействует с запущенными
пользователями прикладными программами и запросами. Контроллер базы данных
принимает запросы и проверяет внешние и концептуальные схемы для определения тех
концептуальных записей, которые необходимы для удовлетворения требований запроса.
Затем контроллер базы данных вызывает контроллер файлов для выполнения
поступившего запроса. Компоненты контроллера базы данных показаны на рис.1.5 [7].
Предметная область
(часть реального мира, отражаемая в базе данных)
10
Рис. 1.3. Уровни моделей данных
Рис. 1.4. Основные компоненты типичной СУБД

Контроллер файлов манипулирует предназначенными для хранения данных файлами и
отвечает за распределение доступного дискового пространства. Он создает и
поддерживает список структур и индексов, определенных во внутренней схеме. Если
используются хешированные файлы, то в его обязанности входит и вызов функций
хеширования для генерации адресов записей. Однако контроллер файлов не управляет
11
физическим вводом и выводом данных непосредственно, а лишь передает запросы
соответствующим методам доступа, которые считывают данные в системные буферы или
записывают их оттуда на диск.
Рис. 1.5. Компоненты контроллера БД

Препроцессор языка DML. Этот модуль преобразует внедренные в прикладные
программы DML-операторы в вызовы стандартных функций базового языка. Для
генерации соответствующего кода препроцессор языка DML должен взаимодействовать с
процессором запросов.
 Компилятор языка DDL. Компилятор языка DDL : преобразует DDL-команды в набор
таблиц, содержащих метаданные. Затем эти таблицы сохраняются в системном каталоге,
а управляющая информация – в заголовках файлов с данными.
 Контроллер словаря. Контроллер словаря управляет доступом к системному каталогу и
обеспечивает работу с ним. Системный каталог доступен большинству компонентов
СУБД.
Ниже перечислены основные программные компоненты, входящие в состав контроллера
базы данных.
• Контроль прав доступа. Этот модуль проверяет наличие у данного пользователя
полномочий для выполнения затребованной операции.
• Процессор команд. После проверки полномочий пользователя для выполнения
затребованной операции управление передается процессору команд.
• Средства контроля целостности. В случае операций, которые изменяют содержимое базы
данных, средства контроля целостности выполняют проверку того, удовлетворяет ли
затребованная операция всем установленным ограничениям поддержки целостности данных
(например, требованиям, установленным для ключей).
• Оптимизатор запросов. Этот модуль определяет оптимальную стратегию выполнения
запроса.
• Контроллер транзакций. Этот модуль осуществляет требуемую обработку операций,
поступающих в процессе выполнения транзакций.
12
• Планировщик. Этот модуль отвечает за бесконфликтное выполнение параллельных
операций с базой данных. Он управляет относительным порядком выполнения операций,
затребованных в отдельных транзакциях.
• Контроллер восстановления. Этот модуль гарантирует восстановление базы данных до
непротиворечивого состояния при возникновении сбоев. В частности, он отвечает за фиксацию
и отмену результатов выполнения транзакций.
• Контроллер буферов. Этот модуль отвечает за перенос данных между оперативной
памятью и вторичным запоминающим устройством – например, жестким диском или
магнитной лентой. Контроллер восстановления и контроллер буферов иногда (в совокупности)
называют контроллером данных.
Для воплощения базы данных на физическом уровне помимо перечисленных выше модулей
нужны некоторые другие структуры данных. К ним относятся файлы данных и индексов, а
также системный каталог (см. гл.З).
1.3.2. Достоинства и недостатки СУБД
СУБД призваны решить недостатки файловых систем (см. прил.1), но при этом имеют и ряд
специфических недостатков [7].
Достоинства СУБД
1. Контроль за избыточностью данных.
2. Непротиворечивость данных.
3. Больше полезной информации при том же объеме хранимых данных.
4. Совместное использование данных.
5. Поддержка целостности данных.
6. Повышенная безопасность.
7. Применение стандартов.
8. Повышение эффективности с ростом масштабов системы.
9. Возможность нахождения компромисса при противоречивых требованиях.
10. Повышение доступности данных.
11. Улучшение показателей производительности.
12. Упрощение сопровождения системы за счет независимости данных.
13. Улучшенное управление параллельностью.
14. Развитые службы резервного копирования и восстановления.
Контроль за избыточностью данных
Традиционные файловые системы неэкономно расходуют внешнюю память, сохраняя одни и
те же данные с нескольких файлах. При использовании базы данных предпринимается попытка
исключить избыточность данных за счет интеграции информации файлов. Однако реально
полностью избыточность информации в базах данных не исключается, а лишь контролируется
ее степень. В одних случаях ключевые элементы данных необходимо дублировать для
моделирования связей, а в других случаях некоторые данные потребуется дублировать из
соображений повышения производительности системы.
Непротиворечивость данных
Устранение избыточности данных или контроль над ней позволяют сократить риск
возникновения противоречивых состояний. Если элемент данных хранится в базе только в
одном месте, то для изменения его значения потребуется выполнить только одну операцию
обновления, причем новое значение станет доступным сразу всем пользователям. Если этот
элемент данных с ведома системы хранится в базе данных в нескольких местах, то такая
система сможет следить за тем, чтобы копии не противоречили друг другу.
13
Больше полезной информации при том же объеме хранимых данных
Благодаря интеграции рабочих данных организации на основе тех же данных можно
получать дополнительную информацию.
Совместное использование данных
Файлы обычно принадлежат отдельным лицам или отделам, которые используют их в своей
работе. База данных принадлежит всей организации в целом и может совместно использоваться
всеми зарегистрированными пользователями. При такой организации работы большее
количество пользователей может работать с большим объемом данных. Более того, при этом
можно создавать новые приложения на основе уже хранящейся в базе данных информации и
добавлять в нее только те данные, которые в настоящий момент еще не хранятся в ней, а не
определять заново требования ко всем данным, необходимым новому приложению.
Поддержка целостности данных
Целостность базы данных означает корректность и непротиворечивость хранимых в ней
данных. Целостность обычно описывается с помощью ограничений, т.е. правил поддержки
непротиворечивости, которые не должны нарушаться в базе данных. Ограничения можно
применять внутри одной записи или к связям между записями. Интеграция данных позволяет
АБД задавать. требования до поддержке целостности данных, а СУБД применять их,
Повышенная безопасность
Безопасность базы данных заключается в защите базы данных от несанкционированного
доступа со стороны пользователей. Без привлечения соответствующих мер безопасности
интегрированные данные становятся более уязвимыми, чем данные в файловой системе.
Однако интеграция позволяет АБД определить требуемую систему безопасности базы данных,
а СУБД привести ее в действие. Система обеспечения безопасности может быть выражена в
форме учетных имен и паролей для идентификации пользователей, которые зарегистрированы в
этой базе данных. Доступ к данным со стороны пользователя может быть ограничен только
некоторыми операциями (добавлением, удалением данных).
Применение стандартов
Интеграция позволяет АБД определять и применять необходимые стандарты. Например,
стандарты отдела и организации, государственные и международные стандарты могут
регламентировать формат данных при обмене между системами, соглашения об именах, форму
представления документации, процедуры обновления и правила доступа.
Повышение эффективности с ростом масштабов системы
Комбинируя все рабочие данные организации в одной базе данных и создавая набор
приложений, которые работают с одним источником данных, можно добиться существенной
экономии средств. В этом случае бюджет, который обычно выделялся каждому отделу для
разработки и поддержки собственных файловых систем, можно объединить с бюджетами
других отделов, что позволит добиться повышения эффективности при росте масштабов
производства.
Возможность нахождения компромисса при противоречивых требованиях
Потребности одних пользователей или отделов могут противоречить потребностям других
пользователей. Поскольку база данных контролируется АБД, он может принимать решения о
14
проектировании и способе использования базы данных, при которых имеющиеся ресурсы всей
организации в целом будут использоваться наилучшим образом. Эти решения обеспечивают
оптимальную производительность для самых важных приложений, причем чаще всего за счет
менее критичных.
Повышение доступности данных
Данные, которые пересекают границы отдела, в результате интеграции становятся
доступными конечным пользователям. Это повышает функциональность системы, что
используется для более качественного обслуживания конечных пользователей.
Улучшение показателей производительности
В СУБД предусмотрено много стандартных функций, которые программист обычно должен
самостоятельно реализовать в приложениях для файловых систем. На базовом уровне СУБД
обеспечивает все низкоуровневые процедуры работы с файлами, которую обычно выполняют
приложения. Наличие этих процедур дает возможность программисту сконцентрироваться на
разработке специальных пользовательских функций, не заботясь о подробностях их
воплощения на более низком уровне.
Упрощение сопровождения системы за счет независимости данных
В СУБД описания данных отделены от приложений, а потому приложения защищены от
изменений в описаниях данных. Эта особенность называется независимостью данных. Наличие
независимости данных от программ, использующих их, значительно упрощает обслуживание и
сопровождение приложений, работающих с базой данных.
Улучшенное управление параллельностью
В некоторых файловых системах при одновременном доступе к одному и тому же файлу
двух пользователей может возникнуть конфликт двух запросов, результатом которого будет
потеря информации или утрата ее целостности. В СУБД предусмотрена возможность
параллельного доступа к базе данных и гарантируется отсутствие подобных проблем.
Развитые службы резервного копирования и восстановления
Ответственность за обеспечение защиты данных от сбоев аппаратного и программного
обеспечения в файловых системах возлагается на пользователя. В современных СУБД
предусмотрены средства сокращения объема потерь информации от возникновения различных
сбоев.
Недостатки СУБД
1. Сложность.
2. Размер.
3. Стоимость.
4. Дополнительные затраты на аппаратное обеспечение.
5. Затраты на преобразование.
6. Производительность.
7. Серьезные последствия при выходе системы из строя.
Сложность
Обеспечение функциональности, которой должна обладать каждая хорошая СУБД,
сопровождается значительным усложнением программного обеспечения СУБД. Чтобы
воспользоваться всеми преимуществами СУБД разработчики и проектировщики баз данных,
15
администраторы баз данных, а также конечные пользователи должны хорошо понимать
функциональные возможности СУБД. Непонимание принципов работы системы может
привести к неудачным результатам проектирования, что будет иметь серьезные последствия
для всей организации.
Размер
Сложность и широта функциональных возможностей приводит к тому, что СУБД становится
чрезвычайно сложным программным продуктом, который может занимать много места на
диске и требовать большого объема оперативной памяти для эффективной работы.
Стоимость
В зависимости от имеющейся вычислительной среды и требуемых функциональных
возможностей, стоимость СУБД варьирует в очень широких пределах. Кроме того, следует
учитывать ежегодные расходы на сопровождение системы, которые составляют некоторый
процент от ее общей стоимости.
Дополнительные затраты на аппаратное обеспечение
Для удовлетворения требований, предъявляемых к дисковым накопителям со стороны СУБД
и базы данных, может понадобиться приобрести дополнительные устройства хранения
информации. Более того, для достижения требуемой производительности может понадобиться
более мощный компьютер.
Затраты на преобразование
В некоторых ситуациях стоимость СУБД и дополнительного аппаратного обеспечения
может оказаться несущественной по сравнению со стоимостью преобразования существующих
приложений для работы с новой СУБД и новым аппаратным обеспечением. Эти затраты также
включают стоимость подготовки персонала для работы с новой системой, а также оплату услуг
специалистов, которые будут оказывать помощь в преобразовании и запуске новой системы.
Производительность
Обычно файловая система создается для некоторых специализированных приложений» а
потому ее производительность может быть высока. Однако СУБД предназначены для решения
общих задач и обслуживания сразу нескольких приложений, что замедляет работу системы.
Серьезные последствия при выходе системы из строя
Централизация ресурсов повышает уязвимость системы. Поскольку работа всех
пользователей и приложений зависит от готовности к работе СУБД, выход из строя одного из
ее компонентов может привести к полному прекращению всей работы организации.
1.4. Категории пользователей базой данных
1.4.1. Общая классификация пользователей БД
Рассмотренные особенности СУБД позволяют создавать базы данных для обеспечения
информационных потребностей пользователей. Одним из аспектов этой задачи является
разработка системы, ориентированной на эффективное обслуживание запросов пользователей.
Исходя из этого, целесообразно проанализировать типы и виды предъявляемых к БД запросов.
16
Результаты такого анализа представлены на рис. 1.9 [17].
Постоянные пользователи – такие, которые регулярно пользуются услугами БД и для
которых можно заранее спрогнозировать типы запросов, определяющие круг их интересов.
Постоянные пользователи могут обращаться к БД и с произвольными по содержанию
запросами. Предварительное определение тематики запросов существенно помогает
организовать эффективную обработку запросов.
Рис. 1.9. Категории пользователей БД
Разовые пользователи – те, которые не имеют постоянных запросов, но могут обращаться к
системе с произвольными по содержанию запросами.
При разделении пользователей БД по уровню компетенции речь идет о защите определенной
части данных от тех пользователей, которые по различным причинам не должны иметь
возможность их получения или изменения. Следовательно, в архитектуре СУБД должны быть
предусмотрены специальные средства для обеспечения санкционированного доступа
пользователей к данным.
Пользователи-задачи обращаются к базе данных с регламентированными по форме и
содержанию запросами. Выдаваемая им информация соответствующим образом
обрабатывается и компонуется на основании принятых в системе формальных правил и
соглашений.
Пользователи-люди обращаются к БД с произвольными либо с регламентированными по
содержанию запросами. Выдаваемая им информация должна иметь удобную для человека
форму представления: в виде текста на естественном языке, таблиц с пояснениями, графиков и
т.п.
Пользователи – прикладные программисты – особая категория, которая выполняет работы
по программированию функциональных задач.
Пользователи-непрограммисты – наиболее многочисленная группа лиц, для удовлетворения
информационных потребностей которых создается база данных. Поэтому таких пользователей
часто называют конечными пользователями. Это специалисты в своей области деятельности,
которые обычно не имеют специальной подготовки по программированию.
Особо следует рассмотреть задачи и функции, выполняемые администратором базы данных.
17
1.4.2. Администратор базы данных
Администратор базы данных – человек (или группа лиц), имеющий' полное представление
об одной или нескольких базах данных и контролирующий их проектирование и
использование. Отвечает за состояние базы данных в организации (учреждении) на протяжении
ее жизненного цикла. Функциями АБД являются [12, 17]:
1) решение вопросов организации данных об объектах предметной области и установлении
связей между этими данными с целью объединения информации о различных объектах;
согласование представлений пользователей;
2) координация всех действий по проектированию, реализации и ведению БД; учет
перспективных и текущих требований пользователей;
3) решение вопросов, связанных с расширением БД в связи с изменением границ
предметной области;
4) разработка и реализация мер по обеспечению защиты данных от некомпетентного
использования, от сбоев технических средств, по обеспечению секретности определенной
части данных и разграничению доступа к данным;
5) выполнение работ по ведению словаря данных; контроль неизбыточности и
непротиворечивости данных, их достоверности;
6) обеспечение заданной производительности БД, чтобы обработка запросов выполнялась за
приемлемое время;
7) изменение при необходимости методов хранения данных, путей доступа к ним, связей
между данными, форматов данных; определение степени влияния изменений на всю БД;
8) координация вопросов технического обеспечения системы аппаратными средствами
исходя из требований, предъявляемых БД к оборудованию;
9) координация работы системных программистов, разрабатывающих дополнительное
программное обеспечение для улучшения эксплуатационных характеристик системы;
10) координация работы прикладных программистов, разрабатывающих новые пакеты
программ и выполнение их проверки и включение в состав программного обеспечения
системы.
Таким образом, при реализации достаточно сложных проектов, группа АБД может включать
ряд специалистов, представленных на рис. 1.10 [17].
1.4.3. Разделение функций администрирования
В некоторых очень сложных предметных областях функции администрирования
автоматизированной информационной системы могут быть распределены между
администратором данных (АД) и администраторам базы данных (АБД),
Рис. 1.10. Состав группы АБД
Специфика обязанностей АД к АБД на этапах жизненного цикла автоматизированной
информационной системы представлена в табл. 1.2 [7].
18
Таблица 1.2
Этап
Планирование разработки базы данных
Определение требований к системе
Сбор и анализ требований пользователей
Концептуальное проектирование базы данных
Выбор целевой СУБД
Логическое проектирование базы данных
Разработка приложений
Физическое проектирование базы данных
Создание прототипов
Реализация
Конвертирование и первичная загрузка данных
Тестирование
Эксплуатация и сопровождение
Основная роль
АД
АД
АД
АД
АБД
АБД
АБД
АБД
АБД
АБД
АБД
АБД
АБД
Вспомогательная роль
АБД
АБД
АБД
АБД
АД
АД
АД
АД
АД
АД
АД
АД
АД
При таком делении функций администрирования к задачам администрирования данных
относятся следующие.
 Разработка стратегии построения информационной системы.
 Предварительная оценка осуществимости и планирование процесса создания базы
данных.
 Разработка корпоративной модели данных.
 Определение требований организации к используемым данным.
 Определение стандартов сбора данных и выбор формата их представления.
 Оценка объемов данных и вероятности их роста.
 Определение способов и интенсивности использования данных.
 Определение правил доступа к данным и мер безопасности соответствующих правовым
нормам и внутренним требованиям организации.
 Концептуальное проектирование базы данных.
 Взаимодействие с АБД и разработчиками приложений.
 Обучение пользователей существующим стандартам обработки данных и юридической
ответственности за их некорректное применение.
 Постоянная модернизация используемых информационных систем и технологий.
 Обеспечение полноты всей требуемой документации.
 Поддержка словаря данных.
 Взаимодействие с конечными пользователями для определения новых требований и
разрешения проблем, связанных с доступом к данным и недостаточной
производительностью их обработки.
Деятельность АДБ по сравнению с АД является в большей мере технической. Основные
задачи администратора БД при наличии АД следующие [7].
 Оценка и выбор целевой СУБД.
 Логическое и физическое проектирование базы данных.
 Реализация физического проекта базы данных в среде целевой СУБД.
 Определение требований защиты и поддержки целостности данных.
 Взаимодействие с разработчиками приложений баз данных.
 Разработка стратегии тестирования.
 Обучение пользователей.
 Ответственность за сдачу в эксплуатацию готового приложения базы данных.
 Контроль текущей производительности системы и соответствующая настройка базы
данных.
 Регулярное резервное копирование.
 Разработка требуемых механизмов и процедур восстановления.
 Обеспечение полноты используемой документации, включая материалы, разработанные
внутри организации.
19

Поддержка актуальности используемого программного и аппаратного обеспечения,
включая заказ и установку пакетов обновлений в случае необходимости.
Результаты сравнительного анализа задач администрирования данных и администрирования
базы данных представлены в табл. 1.3 [7], из которой видно, что работа АД является в большей
степени управленческой, а работа АБД – технической.
СУБД должна иметь доступный конечным пользователям каталог, в котором хранится
описание элементов данных.
Словарь данных (системный каталог) – специальная система в составе БД, содержащая
информацию обо всех ресурсах системы (см. рис. 1.11).
В словаре данных (системном каталоге) интегрированы метаданные – данные об объектах
базы данных, позволяющие упростить способ доступа к ним и управление ими. Перед доступом
к реальным данным СУБД обращается к системному каталогу.
Ключевой особенностью архитектуры ANSI/SPARC является наличие интегрированного
системного каталога с данными о схемах, пользователях, приложениях и т.д. Предполагается,
что каталог доступен как пользователям, так и функциям СУБД. В зависимости от типа
используемой СУБД количество информации и способ ее применения могут варьироваться.
Обычно в системном каталоге хранятся следующие сведения:
 имена, типы и размеры элементов данных;
 имена связей;
 накладываемые на данные ограничения поддержки целостности;
 имена зарегистрированных пользователей, которым предоставлено право доступа к
данным;
 внешняя, концептуальная и внутренняя схемы и , отображения между ними;
 статистические данные, например частота транзакций и счетчики обращений к объектам
базы данных.
Рис. 1.11. Примерная структура словаря данных
Системный каталог позволяет достичь определенных преимуществ, перечисленных ниже.
 Информация о данных может быть централизованно собрана и сохранена, что позволит
контролировать доступ к этим данным, как и к любому другому ресурсу.
 Можно определить смысл данных, что поможет другим пользователям понять их
предназначение.
20

Упрощается сообщение, так как сохраняются точные определения смысла данных. В
системном каталоге также могут быть указаны один или несколько пользователей,
которые являются владельцами данных или обладают правом доступа к ним.
 Благодаря централизованному хранению избыточность и противоречивость описания
отдельных элементов данных могут быть легко обнаружены.
 Внесенные в базу данных изменения могут быть запротоколированы.
 Последствия любых изменений могут быть определены еще до их внесения, поскольку в
системном каталоге зафиксированы все существующие элементы данных, установленные
между ними связи, а также все их пользователи.
 Меры обеспечения безопасности могут быть дополнительно усилены.
 Появляются новые возможности организации поддержки целостности данных.
 Может выполняться аудит сохраняемой информации.
Системный каталог СУБД является одним из фундаментальных компонентов системы.
Многие перечисленные в разд. 1.3 [7] программные компоненты строятся на использовании
данных, хранящихся в системном каталоге. Например, модуль контроля прав доступа
использует системный каталог для проверки наличия у пользователя полномочий, необходимых
для выполнения запрошенных им операций. Для проведения подобной проверки системный
каталог должен включать следующие компоненты:
 имена пользователей, для которых разрешен доступ к базе данных;
 имена элементов данных в базе данных;
 элементы данных, к которым каждый пользователь имеет право доступа, и разрешенные
типы доступа к ним – для вставки, обновления, удаления или чтения.
Другим примером могут служить средства проверки целостности данных, которые
используют системный каталог для проверки того, удовлетворяет ли запрошенная операция
всем установленным ограничениям поддержки целостности данных. Для выполнения этой
проверки в системном каталоге должны храниться такие сведения:
 имена элементов данных из базы данных;
 типы и размеры элементов данных;
 ограничения, установленные для каждого из элементов данных.
Термин «словарь данных» часто используется для программного обеспечения более общего
типа, чем просто каталог СУБД. Система словаря данных может быть либо пассивной, либо
активной. Активная система всегда согласуется со структурой базы данных, поскольку она
автоматически поддерживается этой системой. Пассивная система может противоречить
состоянию базы данных из-за инициируемых пользователями изменений. Если словарь данных
является частью базы данных, то он называется интегрированным словарем данных.
Изолированный словарь данных обладает своей собственной специализированной СУБД. Его
предпочтительно использовать на начальных этапах проектирования базы данных для
некоторой организации, когда требуется отложить на какое-то время привязку к конкретной
СУБД. Однако недостаток этого подхода заключается в том, что после выбора СУБД и
воплощения базы данных изолированный словарь данных значительно труднее поддерживать в
согласии с состоянием базы данных.
Эту проблему можно было бы свести к минимуму, если преобразовать использовавшийся
при проектировании словарь данных непосредственно в каталог СУБД.
21
2. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ (ЛЕКЦИЯ 2)
2.1. Жизненный цикл информационной системы
Рассмотрение вопросов проектирования эффективных баз данных целесообразно начать с
обзора жизненного цикла автоматизированных информационных систем.
Типичная автоматизированная информационная система включает следующие компоненты
[7].
1. База данных.
2. Программное обеспечение базы данных.
3. Прикладное программное обеспечение.
4. Аппаратное обеспечение, в том числе устройства хранения.
5. Персонал, использующий и разрабатывающий систему.
База данных является фундаментальным компонентом информационной системы, а ее
разработку и использование следует рассматривать с точки зрения самых широких требований
организации. Таким образом, жизненный цикл ИС неотъемлемо связан с жизненным циклом
лежащей в основе базы данных.
Жизненный цикл любой сложной системы и, безусловно, ИС, основанной на базе данных,
обычно состоит из нескольких этапов:
1) планирование;
2) сбор и анализ требований к системе;
3) проектирование системы (в том числе проектирование базы данных);
4) создание прототипа;
5) реализация;
6) тестирование;
7) преобразование;
8) сопровождение.
Учитывая специфику разработки приложения базы данных, можно специфицировать этапы,
представленные на рис.2.1 [7]. Общепризнанным является тот факт, что указанные этапы не
являются строго последовательными, а подразумевают повторы предыдущих этапов с помощью
циклов обратной связи. Процесс разработки БД является итеративным, предполагает
многократные возвраты и анализ полученных результатов с целью максимально адекватного
описания предметной области. На рис.2.1 показаны наиболее очевидные циклы обратной связи,
и их множество не является окончательным.
Вкратце следует остановиться на действиях, выполняемых на каждом из указанных этапов
жизненного цикла приложения базы данных.
Планирование разработки базы данных
Планирование самого эффективного способа реализации этапов жизненного цикла системы.
Определение требований в системе
Определение диапазона действия и границ приложения базы данных, состава его
пользователей и областей применения.
22
Рис. 2.1. Жизненный цикл информационной системы на основе базы данных
Сбор и анализ требований пользователей
На этом этапе производится сбор и анализ требований пользователей из всех возможных
областей применения БД.
Проектирование базы данных
Полный цикл разработки
проектирование базы данных.
включает
концептуальное,
логическое
и
физическое
Выбор целевой СУБД
Выполняется подбор наиболее подходящей СУБД для приложения базы данных.
Разработка приложений
Определение пользовательского интерфейса и прикладных программ, которые используют и
обрабатывают базу данных.
Создание прототипа (необязательно)
Создается
рабочая
модель
приложения базы
данных, которая
дает
возможность
23
разработчикам и пользователям представить и оценить окончательный вид и способы
функционирования системы.
Реализация
Создание внешнего, концептуального и внутреннего определений базы данных и
прикладных программ.
Конвертирование и загрузка данных (первичное наполнение)
Преобразование и загрузка данных (и прикладных программ) из старой системы в новую.
Тестирование
Приложение базы данных тестируется с целью обнаружения ошибок, а также его проверки
на соответствие всем требованиям, выдвинутым пользователем.
Эксплуатация и сопровождение
База данных считается полностью разработанной и реализованной. Система наблюдается и
поддерживается. При этом по необходимости в приложение вносятся изменения, отвечающие
новым требованиям. Реализация изменений производится посредством повторного выполнения
некоторых вышеперечисленных этапов.
Сложность жизненного цикла зависит от сложности рассматриваемой системы, от
количества пользователей, приложений и запросов к базе данных.
2.2. Подходы и этапы проектирования баз данных
2.2.1. Цели и подходы к проектированию баз данных
Процесс проектирования БД представляет собой сложный процесс проектирования
отображения [17]:
«Описание предметной области» ↔ «схема внутренней модели базы данных».
Этот процесс представляется последовательностью более простых, обычно итеративных,
процессов проектирования менее сложных отображений между промежуточными моделями
данных, т.е. последовательностью проектирования моделей уровней абстрагирования.
Основные уровни абстрагирования в БД [17]:
 информационный,
 внешний,
 концептуальный,
 внутренний.
В процессе проектирования БД разрабатываются схемы моделей названных уровней,
проверяется возможность отображения объектов одной модели в объекты другой модели.
Только небольшие организации могут обобществить данные в одной полностью
интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа
лиц) практически не в состоянии охватить и осмыслить все информационные требования
сотрудников организации (т.е. будущих пользователей системы).
Наличие постоянных и разовых пользователей в автоматизированных информационных
системах, и, следовательно, наличие потока регламентированных и произвольных по
содержанию запросов требуют разработки специальных подходов к определению границ ПО и
проектированию состава элементов информационной модели. Поэтому информационные
системы больших организаций содержат несколько десятков БД, нередко распределенных
между несколькими взаимосвязанными ЭВМ различных подразделений [5, 17].
Если бы в АИС существовал только поток регламентированных запросов и не ожидалось
24
развитие системы, то можно было бы определить границы ПО и осуществить проектирование
исходя из анализа содержания всей совокупности запросов пользователей – это так называемый
подход к проектированию «от запросов пользователей» [17].
Базы данных, спроектированные по такому подходу, могут объединять все данные,
необходимые для решения одной или нескольких прикладных задач, и обычно называются
прикладными БД.
Наличие потока произвольных по содержанию запросов и развитие автоматизированных
информационных систем во времени не позволяют в полной мере использовать подход от
запросов. В этом случае необходим подход, позволяющий выполнить прогноз смыслового
содержания ожидаемой совокупности произвольных запросов. Таким является подход,
называемый «от реального мира». С помощью экспертов определяются границы предметной
области – состав объектов, их свойства и отношения с учетом развития системы, и затем
проектируется модель. Этот подход базируется на предположении, что произвольные запросы
пользователей соответствуют тематической направленности АИС.
Такие БД объединяют данные, относящиеся к какой-либо предметной области [5] (например,
финансам, обучению, торговле и т.п.) и называются предметными БД (соотносящимся с
предметами организации, а не с ее информационными приложениями).
Подход «от реального мира» предпочтительно использовать в качестве основного, подход
«от запросов пользователей» – для уточнения границ предметной области. Наибольшее
применение он должен получать в период использования АИС, когда при работе накапливается
достаточно информации о содержании произвольных запросов и необходимо выполнить
коррекцию границ ПО и состава элементов информационной модели.
Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений,
поскольку набор их элементов данных включает в себя наборы элементов данных прикладных
БД. Вследствие этого предметные БД создают основу для обработки неформализованных,
изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно
заранее определить требования к данным). Такая гибкость и приспосабливаемость позволяет
создавать на основе предметных БД достаточно стабильные информационные системы, т.е.
системы, в которых большинство изменений можно осуществить без вынужденного
переписывания старых приложений.
Основывая же проектирование БД на текущих и предвидимых приложениях, можно
существенно ускорить создание высокоэффективной информационной системы, т.е. системы,
структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Поэтому
прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере
роста числа приложений таких информационных систем быстро увеличивается число
прикладных БД, резко возрастает уровень дублирования данных и повышается стоимость их
ведения. Таким образом, каждый из рассмотренных подходов к проектированию воздействует
на результаты проектирования качественно по-разному.
Основная цель проектирования БД - это сокращение избыточности хранимых данных, а
следовательно, экономия объема используемой памяти, уменьшение затрат на многократные
операции обновления избыточных копий и устранение возможности возникновения
противоречий из-за хранения в разных местах сведений об одном и том же объекте [5, 8].
При проектировании базы данных решаются две основных проблемы.
1. Каким образом отобразить объекты предметной области в абстрактные объекты модели
данных, чтобы это отображение не противоречило семантике предметной области и было по
возможности лучшим (эффективным, удобным и т.д.)? Часто эту проблему называют
проблемой логического проектирования баз данных.
2. Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом,
имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание
каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему
называют проблемой физического проектирования баз данных [5, 8].
25
2.2.2. Этапы проектирования баз данных
На рис. 2.2 приведены основные этапы проектирования баз данных. Так, весь сложный
процесс создания БД может быть разбит на инфологическое и даталогическое проектирование.
Последнее подразделяется на логическое и физическое проектирование. В зависимости от
этапов проектирования различают: концептуальную инфологическую модель и концептуальную
даталогическую модель, внешнюю инфологическую модель и внешнюю даталогическую модель
[17].
Задача инфологического моделирования базы данных – получение семантических
(смысловых) моделей, отражающих информационное содержание конкретной ПО. На этом
этапе выполняется восприятие реальной действительности, абстрагирование, изучение и
описание предметной области. Вначале выделяется из воспринимаемой реальности ПО,
определяются ее границы, происходит абстрагирование от несущественных частей для данного
конкретного применения базы данных. В результате этих действий определяются объекты, их
свойства и связи, которые будут существенны для будущих пользователей системы.
Рис 2.2. Этапы проектирования базы данных
После этого изучается предметная область, накапливаются знания о ней. Эти знания
представляются в какой-либо языковой системе, обычно это неформализованное описание с
использованием естественного языка, математических формул, диаграмм, связей и т.д.
Выполняется структуризация знаний о предметной области: выделяются и классифицируются
множества составляющих ПО, стандартизуется терминология.
Затем компонуется концептуальная инфологическая модель, основное значение при этом
имеют потребности пользователей. Описывается информация, требуемая каждому конкретному
пользователю, т.е. описываются запросы к БД. Каждый запрос соотносится с определенным
фрагментом предметной области. Формируются описания внешних инфологических моделей, их
взаимная увязка с концептуальной инфологической моделью. Полученные описания
инфологических моделей отражают составляющие (сущности) предметной области, связи
между ними, но эти описания не должны зависеть от методов представления данных в
конкретной СУБД. Концептуальная инфологическая модель призвана обеспечить прочную и
долговременную работу всей системы, выдерживать замену одной используемой СУБД на
другую.
26
Задача логического этапа проектирования – организация данных, выделенных на
предыдущем этапе проектирования в форму, принятую в выбранной конкретной СУБД. Иными
словами, требуется разработать схему концептуальной модели и схемы внешних моделей
данных о предметной области, пользуясь только теми типами моделей данных и их
особенностями, которые поддерживаются этой СУБД. На этом этапе проектирования обычно не
прорабатываются вопросы, связанные с организацией хранения и доступа к данным на
внутреннем уровне. Но целесообразно уже здесь получить вполне определенные рекомендации
по выбору методов доступа.
Задача физического этапа проектирования – выбор рациональной структуры хранения
данных и методов доступа к ним, исходя из арсенала методов и средств, который
предоставляется разработчику системой управления базами данных.
27
3. АРХИТЕКТУРЫ СУБД (ЛЕКЦИИ 3-4)
При реализации многопользовательских
архитектурные решения:
1) телеобработка;
2) файловый сервер;
3) технология «клиент/сервер».
СУБД
применяют
следующие
типовые
3.1. Телеобработка
Традиционной архитектурой многопользовательских систем раньше считалась схема,
получившая название «телеобработки», при которой один компьютер с единственным
процессором был соединен с несколькими терминалами так, как показано на рис. 1.6 [7]. При
этом вся обработка выполнялась в рамках единственного компьютера, а присоединенные к
нему пользовательские терминалы были типичными «неинтеллектуальными» устройствами, не
способными функционировать самостоятельно. С центральным процессором терминалы были
связаны с помощью кабелей, по которым они посылали сообщения пользовательским
приложениям (через подсистему управления обменом данными операционной системы). В
свою очередь, пользовательские приложения обращались к необходимым службам СУБД.
Таким же образом сообщения возвращались назад на пользовательский терминал. Недостатком
является то, что при такой архитектуре основная и чрезвычайно большая нагрузка возлагалась
на центральный компьютер, который должен был выполнять не только действия прикладных
программ и СУБД, но и значительную работу по обслуживанию терминалов (например,
форматирование данных, выводимых на экраны терминалов).
Рис. 1.6. Топология телеобработки
В последние годы был достигнут существенный прогресс в разработке
высокопроизводительных персональных компьютеров и составленных из них сетей. При этом
во всей индустрии наблюдается заметная тенденция к децентрализации (downsizing), т.е. замене
дорогих мейнфреймов более эффективными, с точки зрения эксплуатационных затрат, сетями
персональных компьютеров, позволяющими получить такие же результаты, если не лучше. Эта
тенденция привела к появлению следующих двух типов архитектуры СУБД: технологии
файлового сервера и технологии «клиент/сервер».
28
3.2. Файловый сервер
В среде файлового сервера обработка данных распределена в сети, обычно представляющей
собой локальную вычислительную сеть (ЛВС). Файловый сервер содержит файлы,
необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и
сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к
файловому серверу только по мере необходимости получения доступа к нужным им файлам –
как показано на рис. 1.7 [7].
Рис. 1.7. Архитектура .с использованием файлового сервера
Таким образом, файловый сервер функционирует просто как совместно используемый
жесткий диск. СУБД на каждой рабочей станции посылает запросы файловому серверу по всем
необходимым ей данным, которые хранятся на диске файл-сервера. Такой подход
характеризуется значительным сетевым трафиком, что может привести к снижению
производительности всей системы в целом.
Архитектура с использованием файлового сервера обладает следующими основными
недостатками.
1. Большой объем сетевого трафика.
2. На каждой рабочей станции должна находиться полная копия СУБД.
3. Управление параллельностью, восстановлением и целостностью усложняется, поскольку
доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.
3.3. Технология «клиент/сервер»
Технология «клиент/сервер» была разработана с целью устранения недостатков, имеющихся
в первых двух подходах. «Клиент/сервер» означает такой способ взаимодействия программных
компонентов, при котором они образуют единую систему. Как видно из самого названия,
существует некий клиентский процесс, требующий определенных ресурсов, а также серверный
процесс, который эти ресурсы предоставляет. При этом совсем необязательно, чтобы они
находились на одном и том же компьютере. На практике принято размещать сервер на одном
узле локальной сети, а клиенты – на других узлах. На рис. 1.8 показана архитектура типа
«клиент/сервер» [7].
В контексте базы данных клиент управляет пользовательским интерфейсом и логикой
приложения, действуя как сложная рабочая станция, на которой выполняются приложения баз
данных. Клиент принимает от пользователя запрос, проверяет синтаксис и генерирует запрос к
базе данных на языке SQL или другом языке базы данных, который соответствует логике
29
приложения. Затем он передает сообщение серверу, ожидает поступления ответа и форматирует
полученные данные для представления их пользователю. Сервер принимает и обрабатывает
запросы к базе данных, а затем передает полученные результаты обратно клиенту. Такая
обработка включает проверку полномочий клиента, обеспечение требований целостности,
поддержку системного каталога, а также выполнение запроса и обновление данных. Помимо
этого, поддерживается управление параллельностью и восстановлением.
Операции выполняемые клиентом:
1. Управляет пользовательским интерфейсом.
2. Принимает и проверяет синтаксис введенного пользователем запроса.
3. Выполняет приложение.
4. Генерирует запрос к базе данных и передает его серверу.
5. Отображает полученные данные пользователю.
Операции выполняемые сервером:
1. Принимает и обрабатывает запросы к базе данных со стороны клиентов.
2. Проверяет полномочия пользователей.
3. Гарантирует соблюдение ограничений целостности.
4. Выполняет запросы/обновления и возвращает результаты клиенту.
5. Поддерживает системный каталог.
6. Обеспечивает параллельный доступ к базе данных.
7. Обеспечивает управление восстановлением.
Рис. 1.8. Общая схема построения систем с архитектурой «клиент/сервер»
Этот тип архитектуры обладает следующими преимуществами:
1. Обеспечивается более широкий доступ к существующим базам данных.
2. Повышается общая производительность системы. Поскольку клиенты и сервер
находятся на разных компьютерах, их процессоры способны выполнять приложения
параллельно. При этом настройка производительности компьютера с сервером
упрощается, если на нем выполняется только работа с базой данных.
3. Стоимость аппаратного обеспечения снижается. Достаточно мощный компьютер с
большим устройством хранения нужен только серверу – для хранения и управления
базой данных,
4. Сокращаются коммуникационные расходы. Приложения выполняют часть операций на
клиентских компьютерах и посылают через сеть только запросы к базе данных, что
позволяет существенно сократить объем пересылаемых по сети данных.
5. Повышается уровень непротиворечивости данных. Сервер может самостоятельно
30
управлять проверкой целостности данных, поскольку все ограничения определяются и
проверяются только в одном месте. При этом каждому приложению не придется
выполнять собственную проверку.
6. Эта архитектура весьма естественно отображается на архитектуру открытых систем.
Некоторые разработчики баз данных использовали эту архитектуру для организации средств
работы с распределенными базами данных, т.е. с набором нескольких баз данных, логически
связанных и распределенных в компьютерной сети» Однако, несмотря на то, что архитектура
«клиент/сервер» вполне может быть использована для организации распределенной СУБД, сама
по себе она не образует распределенную СУБД. Более подробно распределенные СУБД
обсуждаются в главе 5.
3.4. Понятие независимости данных
Трехуровневая архитектура позволяет обеспечить независимость хранимых данных от
использующих их программ и пользователей [2, 5, 17], АБД может при необходимости
переписать хранимые данные на другие носители информации и (или) реорганизовать их
физическую структуру, изменив лишь физическую модель (внутреннюю схему) данных. АБД
может подключить к системе любое число новых пользователей (новых приложений),
дополнив, если надо, даталогическую модель (концептуальную схему). Указанные изменения
физической и даталогической моделей не будут замечены существующими пользователями
системы (окажутся «прозрачными» для них), так же как не будут замечены и новые
пользователи. Следовательно, независимость данных обеспечивает возможность развития
системы баз данных без разрушения существующих приложений.
Таким образом, различают два типа независимости данных – логическую и физическую.
Логическая независимость данных – полная защищенность внешних схем (инфологической
модели) от изменений, вносимых в концептуальную схему (даталогическую модель).
Физическая независимость данных – полная защищенность концептуальной схемы
(даталогической модели) от изменений, вносимых во внутреннюю схему (физическую модель).
Структура СУБД определяется используемой моделью данных. В этом смысле для СУБД
являются обязательными следующие функции [12]:
а) трансляция схемы, определяющей структуру хранимых данных, в некоторое внутреннее
представление, используемое СУБД при дальнейшей работе с данными (схема обычно
составляется администратором базы данных на основании требований предполагаемых
пользователей и записывается на языке определения данных, принятом в СУБД);
б) загрузка данных в базу данных (создание БД), сопровождаемая максимально возможной
проверкой их правильности;
в) реализация запросов пользователей (формулируемых на специальном языке, принятом в
данной СУБД) на отбор и извлечение некоторой части базы: данных по задаваемым ими
критериям отбора; этот процесс может сопровождаться некоторыми процедурами
редактирования и обработки отобранной информации;
г) обновление некоторых частей базы данных без изменения структуры данных; критерии
определения обновляемой части обычно аналогичны критериям отбора данных и задаются
пользователем.
31
4. ИНФОЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ БАЗЫ
ДАННЫХ (ЛЕКЦИИ 5-6)
Все этапы проектирования БД подразумевают создание моделей данных об интересующей
предметной области. Моделирование данных упрощает понимание смысла элементов данных,
способствует более плодотворному общению пользователей и разработчиков.
Исходя из важности адекватного отображения предметной области, к моделям данных
предъявляют ряд требований, и выдвигают комплекс критериев для оценки их эффективности
(оптимальности) (табл. 2.1).
Таблица 2.1
№ п/п
Критерий
Пояснение
1 Структурная достоверность Соответствие способу определения и организации информации в
данной предметной области
2 Простота
Легкость понимания модели разработчиками и пользователями
информационной системы
3 Выразительность
Способность представлять отличия между разными типами данных,
связи между данными и ограничения
4 Отсутствие избыточности
Исключение излишней информации, т.е. любая часть данных
должна быть представлена только в одном месте
5 Готовность к совместному Отсутствие принадлежности к какому-то особому приложению или
использованию
технологии
6 Расширяемость
Способность эволюционировать с целью включения новых
требований с минимальным влиянием на существующих
пользователей
7 Целостность
Согласованность по способам использования и управления
информацией
8 Представление в виде
Способность представления модели с помощью понятных
диаграмм
широкому кругу пользователей обозначений
Инфологическое (концептуальное) проектирование – процесс создания внешней
(инфологической) модели данных о предметной области, не зависящее от любых физических
аспектов ее представления.
На этом этапе используется информация, объединяющая требования пользователей.
Инфологическое проектирование базы данных не зависит от таких подробностей ее реализации,
как тип выбранной СУБД, набор создаваемых прикладных программ, используемые языки
программирования, тип вычислительной системы и т.п. При разработке инфологическая модель
постоянно подвергается критической оценке, проверке на соответствие требованиям
пользователей, и при необходимости модифицируется. От качества созданной инфологической
модели в определяющей степени зависит эффективность конечной базы данных.
4.1. Модель «сущность-связь»
Цель инфологического моделирования – обеспечение наиболее естественных для человека
способов сбора и представления той информации, которую предполагается хранить в
создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить на
доступном широкому кругу пользователей и разработчиков языке. Известны следующие
средства создания внешних моделей:
 семантические сети;
 язык инфологического моделирования;
 ER-диаграммы.
Наибольшую популярность из-за доступности, наглядности и компактности приобрел
подход моделирования «сущность-связь».
Модель «сущность-связь» (Entity-Relationship model) разработана Ченом в 1976 году с целью
32
упрощения концептуального проектирования баз данных.
Основными элементами этой модели являются:
 сущности;
 атрибуты;
 связи.
Сущность представляет собой различимое множество объектов {экземпляров сущности)
реального мира с одинаковым набором атрибутов.
Сущность идентифицируется именем и списком свойств (атрибутов). База данных о скольконибудь значительной предметной области содержит много (несколько) сущностей. Каждый
экземпляр сущности обладает уникальным набором значений атрибутов.
На ER-диаграммах сущность представляется прямоугольником с именем сущности внутри.
Атрибут – неотъемлемое свойство сущности или связи. Именно по значениям атрибутов
можно идентифицировать экземпляр сущности. Значения атрибутов представляют основную
часть сведений, хранящихся в БД.
На ER-диаграммах атрибут представляется овалом (эллипсом), соединенным с
соответствующей сущностью линией и с именем атрибута внутри.
С понятием атрибута тесно связано понятие домена. Домен – множество значений, которые
может принимать атрибут. Разработчика не должен удивлять тот факт, что домены могут быть
бесконечными (хотя и перечислимыми) множествами
Атрибуты делятся на:
 простые;
 составные;
 однозначные;
 многозначные;
 производные.
Простой атрибут состоит из одного компонента с независимым существованием.
Составной атрибут состоит из нескольких компонентов, каждый из которых
характеризуется независимым существованием.
Однозначный атрибут содержит одно значение для одного экземпляра сущности.
Многозначный атрибут может содержать несколько значений для одного экземпляра
сущности.
Производный атрибут представляет значение, производное (вычисляемое) от значения
связанного с ним атрибута или некоторого множества атрибутов, принадлежащих некоторой
сущности.
Вопрос однозначной идентификации экземпляров сущности связан с понятием ключа.
Ключ – минимальный набор атрибутов, по значениям которых можно идентифицировать
экземпляр сущности.
В наборе атрибутов сущности можно выделить несколько потенциальных ключей.
Потенциальный ключ, используемый реально для идентификации экземпляров сущности
называется первичным ключом.
На ER-диаграммах имена атрибутов, выбранных в качестве первичного ключа,
подчеркиваются.
Суперключом называется набор атрибутов, содержащий ключ.
Ассоциирование двух или более сущностей называется связью.
Связи, также как и сущности и атрибуты идентифицируют именем.
На ER-диаграммах связь изображается в виде ромба или шестиугольника, помеченного
соответствующим именем. Соединение с ассоциированными сущностями производится
линиями.
Пример ER-диаграммы с обозначениями сущностей, их атрибутов и связей представлен на
рис. 2.3.
Степень связи – количество сущностей, которые охвачены данной связью.
Если связь определена между двумя сущностями, то ее степень – 2, а называется такая связь
бинарной. Связь между тремя сущностями называется тернарной, четырьмя сущностями –
кватернарной и т.д. В общем случае связь между n сущностями называется n-арной. Примеры
33
различных связей представлены на рис. 2.4.
Рекурсивная связь – связь, в которой одни и те же сущности участвуют несколько раз в
разных ролях.
Рекурсивная связь часто называют унарной. Пример такой связи представлен на рис. 2.4, г. В
приведенном примере каждый студент из сущности СТУДЕНТ может исполнять обязанности
дежурного по отношению к другим студентам той же сущности.
При построении инфологической модели, на сущности – участницы некоторых связей могут
накладываться ограничения, отражающие семантику предметной области.
С этими ограничениями связано понятие показателя кардинальности связи.
Показатель кардинальности указывает количественное соотношение экземпляров
сущностей для каждой связи [5, 7].
Рис. 2.3. Пример ER-диаграммы
34
Рис. 2.4. Примеры связей:
а) – бинарной; б) – тернарной; в) – кватернарной; г) – унарной (рекурсивной)
Классическими признаны бинарные связи с показателями кардинальности «ОДИН-КОДНОМУ», «ОДИН-КО-МНОГИМ», «МНОГИЕ-КО-МНОГИМ».
Пусть в предметной области выделены сущности А и В.
1. Связь ОДИН-К-ОДНОМУ (1:1): в каждый момент времени каждому экземпляру
сущности А соответствует не более одного экземпляра сущности В (рис. 2.5).
Рис. 2.5. Связь ОДИН-К-ОДНОМУ
Декан осуществляет свою деятельность на одном факультете вуза.
2. Связь ОДИН-КО-МНОГИМ (1:М): каждому экземпляру сущности А соответствуют 0, 1
или несколько представителей сущности В (рис. 2.6).
35
Рис. 2.5. Связь ОДИН-КО-МНОГИМ
В квартире может проживать несколько жильцов.
3. Связь МНОГИЕ-КО-МНОГИМ (M:N): каждому экземпляру сущности А соответствуют
0, 1 или несколько представителей сущности В, каждому экземпляру сущности В
соответствуют 0, 1 или несколько представителей сущности А (рис. 2.7).
Рис. 2.7. Связь МНОГИЕ-КО-МНОГИМ
Процесс обучения осуществляется множеством преподавателей с множеством студентов.
Пример 2.1. Если связь между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ называется
БРАК, то существует четыре возможных представления такой связи (рис. 2.8) [5].
Характер связей между сущностями может оказаться более сложным (рис. 2.9) [5, 7].
В приведенных примерах для повышения иллюстративности рассматриваемых связей не
показаны атрибуты сущностей и ассоциаций во всех ЕR-диаграммах. Так, ввод лишь
нескольких основных атрибутов в описание значительно усложняет ER-диаграмму. В связи с
этим язык ER-диаграмм используется для построении небольших моделей и иллюстрации
отдельных фрагментов больших. Для представления полных инфологических моделей
предметной области применяется менее наглядный, но более содержательный язык
инфологического моделирования (ЯИМ) [5], в котором сущности и ассоциации представляются
предложениями вида:
где S – степень связи, а атрибуты, входящие в ключ, должны быть отмечены с помощью
подчеркивания.
36
Рис. 2.8. Примеры связи БРАК между сущностями МУЖЧИНЫ и ЖЕНЩИНЫ
Рис.2.9. Пример множества связей между сущностями ПРЕПОДАВАТЕЛЬ и СТУДЕНТ
Так, рассмотренный выше пример множества связей между сущностями, может быть описан
на ЯИМ следующим образом.
Для определения связей между сущностями необходимо, как минимум, выделить в
интересующей предметной области сами сущности. Но это непростая задача, так как в разных
предметных областях один и тот же объект может быть сущностью, атрибутом или связью.
4.2. Классификация сущностей, расширение ER-модели
Один из активных разработчиков реляционной модели К. Дейт [2] выделил три основные
класса сущностей: стержневые, ассоциативные и характеристические, а также подкласс
ассоциативных сущностей – обозначения.
Стержневая сущность (стержень) – это независимая сущность.
В рассмотренных ранее примерах стержни – это СТУДЕНТ, КВАРТИРА, МУЖЧИНА,
ПРЕПОДАВАТЕЛЬ, и другие, названия которых помещены в прямоугольники.
Ассоциативная сущность (ассоциация) – это связь вида МНОГИЕ-КО-МНОГИМ (-КОМНОГИМ и т.д.) между двумя или более сущностями или экземплярами сущности.
Ассоциации рассматриваются как полноправные сущности:
 могут участвовать в других ассоциациях и обозначениях точно так же, как стержневые
сущности;
 могут обладать свойствами, т.е. иметь не только набор ключевых атрибутов,
37
необходимых для указания связей, но и любое число других атрибутов, характеризующих
связь.
Характеристическая сущность (характеристика) – это связь вида МНОГИЕ-К-ОДНОМУ
или ОДИН-К-ОДНОМУ между двумя сущностями (частный случай ассоциации). Единственная
цель характеристики в рамках рассматриваемой предметной области состоит в описании или
уточнении некоторой другой сущности. Необходимость в них возникает в связи с тем, что
сущности реального мира имеют иногда многозначные свойства. Муж может иметь несколько
жен (пример 2.1), книга – несколько характеристик переиздания (исправленное, дополненное,
переработанное, ...) и т.д.
Существование характеристики полностью зависит от характеризуемой сущности: женщины
лишаются статуса жен, если умирает их муж.
Для описания характеристики используется новое предложение ЯИМ, имеющее в общем
случае вид:
Часто используют расширенный язык EER-диаграмм [5, 7] (Enhanced ER-диаграммы), в
котором для изображения характеристики используют трапецию (рис. 2.10).
Рис. 2.10. Элементы расширенного языка ER-диаграмм
Обозначающая сущность или обозначение – это связь вида МНОГИЕ-К-ОДНОМУ или
ОДИН-К-ОДНОМУ между двумя сущностями и отличается от характеристики тем, что не
зависит от обозначаемой сущности.
Обозначения используют для хранения повторяющихся значений больших текстовых
атрибутов: кодификаторов изучаемых студентами дисциплин, наименований организаций и их
отделов, перечней товаров и т.п.
Описание обозначения внешне отличается от описания характеристики только тем, что
обозначаемые сущности заключается не в фигурные скобки, а в квадратные:
Обозначения и характеристики не являются полностью независимыми сущностями,
поскольку они предполагают наличие некоторой другой сущности, которая будет
«обозначаться» или «характеризоваться». Однако они все же представляют собой частные
случаи сущности и могут, конечно, иметь свойства, могут участвовать в ассоциациях,
обозначениях и иметь свои собственные (более низкого уровня) характеристики. Все
экземпляры характеристики должны быть обязательно связаны с каким-либо экземпляром
характеризуемой сущности. Однако допускается, чтобы некоторые экземпляры
характеризуемой сущности не имели связей. Правда, если это касается браков, то сущность
«Мужья» должна быть заменена сущностью «Мужчины» (нет мужа без жены).
Теперь можно переопределить стержневую сущность как сущность, которая не является ни
ассоциацией, ни обозначением, ни характеристикой. Такие сущности имеют независимое
38
существование [5].
4.3. Проблемы ER-моделирования
В процессе создания инфологической модели на языке ER-диаграмм, могут возникать
нежелательные ситуации, которые в литературе называются ловушками соединения. Причины
этих проблем кроются в неправильной интерпретации семантики предметной области, в том
числе смысла некоторых связей между выделенными сущностями. Очень важно своевременно
выявлять в модели данных ловушки соединения, иначе они могут привести к неадекватному
описанию предметной области и необходимости перестройки всей концептуальной модели [7].
Наиболее распространенными являются два вида ловушек соединения:
 ловушки разветвления;
 ловушки разрыва.
Ловушка разветвления имеет место в том случае, если модель отображает связь между
сущностями, но путь между отдельными экземплярами этих сущностей однозначно не
определяется.
Ловушка разветвления возникает в случае, когда две или больше связей ОДИН-КОМНОГИМ разветвляются из одной сущности. Потенциальная ловушка разветвления показана
на рис. 2.11, где две связи типа 1:М выходят из одной и той же сущности ФАКУЛЬТЕТ.
Проанализировав модель, можно сделать вывод, что на одном факультете осуществляется
обучение по нескольким специальностям, и на факультете учится множество студентов.
Проблема может возникнуть при попытке выяснить, по какой специальности обучается каждый
из студентов факультета.
Рис. 2.11. Пример ловушки разветвления
Для обнаружения этой проблемы удобно пользоваться семантическими сетями – (рис. 2.12).
С помощью семантической сетевой модели на конкретном примере невозможно дать
однозначный ответ на вопрос: «По какой специальности обучается студент Гаврюхов?» - это
ловушка разветвления. Эта неприятность произошла из-за неправильной трактовки связей
между сущностями ФАКУЛЬТЕТ, СПЕЦИАЛЬНОСТЬ, СТУДЕНТ. Устранить такой дефект
можно только путем перестройки исходной модели.
39
Рис. 2.12. Семантическая сеть ER-модели с ловушкой разветвления
Результат адекватного преобразования модели представлен на рис. 2.13. В таком варианте
легко определяется, что студент Гаврюхов учится на экономическом факультете по
специальности «Налоговая работа и аудиторский контроль».
Рис. 2.13. Преобразованная ER-модель
Если проверить полученную структуру на уровне отдельных экземпляров сущностей (как
показано на рис. 2.14), можно убедиться, что по преобразованной модели легко дать
однозначный ответ на поставленный выше вопрос.
Ловушка разрыва появляется в том случае, если в модели предполагается наличие связи
между сущностями, но не существует пути между отдельными экземплярами этих сущностей.
Ловушка разрыва возникает при наличии связи, образующей часть пути между связанными
сущностями.
На рис. 2.15 потенциальная ловушка разрыва показана на примере связей между сущностями
ОБЩЕЖИТИЕ, СТУДЕНТ и КОМНАТА.
40
Рис. 2.14. Семантическая сеть преобразованной ER-модели
Рис. 2.15. Пример ловушки разрыва
С помощью семантической сети ER-модели с рис. 2.15 (представлена на рис. 2.16),
невозможно дать ответ на вопрос: «В каком общежитии находится комната под условным
номером 703?». Это причина проявления ловушки разрыва, возникающей из-за неправильной
интерпретации связей между сущностями ОБЩЕЖИТИЕ, СТУДЕНТ и КОМНАТА.
Устранить эту проблему можно только путем перестройки ER-модели для представления
правильного взаимоотношения между этими сущностями. Преобразованная ER-модель
показана на рис. 2.17. В модель добавлена связь Размещение между сущностями ОБЩЕЖИТИЕ
и КОМНАТА.
Рис. 2.17. Преобразованная ER-модель
41
Рис. 2.16. Семантическая сеть ER-модели с ловушкой разрыва
Если исследовать новую структуру на уровне отдельных сущностей (как показано на рис.
2.18), то можно дать ответ на поставленный вопрос: «Комната с условным номером 703
находится в общежитии №1».
Рис. 2.18. Семантическая сеть преобразованной ER-модели
42
5. ВЫБОР СУБД (ЛЕКЦИЯ 7)
Важным этапом жизненного цикла информационной системы и, в частности,
проектирования базы данных, является выбор целевой СУБД.
Предлагаемые в разделе методы пригодны и к оценке новых продуктов, поступающих на
рынок.
Основная цель при подборе СУБД – выбор системы, удовлетворяющей текущим и
прогнозируемым требованиям организации при оптимальном уровне затрат.
Затраты могут включать расходы на приобретение СУБД и дополнительного аппаратного и
программного обеспечения, а также расходы, связанные с переходом к новой системе и
необходимостью переобучения персонала.
Сложность и комплексность проблем, возникающих при проектировании сложных систем, в
том числе и информационных систем, основанных на базах данных, привели к тому, что
вопросы формирования критериев для анализа и синтеза систем перестали быть только
искусством, основанным на инженерной интуиции, а превратились в серьезное научное
направление, важность которого возрастает с каждым днем [3].
Если раньше выбор инструментальных средств (в том числе СУБД) производился исходя из
предпочтений разработчика вне зависимости от специфики предметной области и перспектив
использования базы данных, то на современном этапе развития программного обеспечения,
когда на рынке предлагается необозримое количество СУБД, выбор средства реализации БД
становится сложной задачей. Принятие строго оптимального решения в таких условиях
желательно, но затруднено.
В общем виде процесс выбора СУБД включает следующие этапы:
1) определение списка показателей, по которым будут оцениваться СУБД;
2) определение списка сравниваемых СУБД;
3) оценка продуктов по выбранным показателям;
4) принятие обоснованного решения, подготовка отчета.
Современные СУБД имеют множество основных и дополнительных функций,
предоставляющих разработчику мощный инструментарий для реализации, поддержки и
ведения баз данных. Какую из них выбрать в каждом конкретном случае?
Известны математические методы для решения задач оптимизации. В частности при выборе
СУБД по множеству показателей очевидно применение методов линейного или целочисленного
программирования. К числу сходных задач относится, например, задача о наименьшем
покрытии, а универсальный метод для решения таких задач – метод ветвей и границ. Но эти
задачи относятся к классу NP-полных, а значит, сложность их решения может сравниться (или
превзойти) сложную многоэтапную задачу проектирования информационной системы.
В таких условиях при выборе СУБД целесообразно использовать методы построения
обобщенных критериев.
Общая постановка задачи принятия решений выглядит следующим образом [3].
А. Имеется некоторое множество альтернатив (в рассматриваемом случае – СУБД) А, причем
каждая альтернатива а характеризуется определенной совокупностью свойств a1, a2, ..., аn.
Б. Имеется совокупность критериев q = (q1, q2, ..., qi, …, qn), отражающих количественно
множество свойств системы, т.е. каждая альтернатива характеризуется вектором q(a) = [q1(а),
q2(а), ..., qi(а), ..., qn(а)].
В. Необходимо принять решение о выборе одной из альтернатив (СУБД), причем решение
называется простым, если выбор производится по одному критерию, и сложным, если
выбранная альтернатива не является наилучшей по какому-то одному критерию, но может
оказаться наиболее приемлемой для всей их совокупности,
Г. Задача принятия решения по выбору альтернативы на множестве критериев формально
сводится к отысканию отображения φ, которое каждому вектору q ставит в соответствие
действительное число
43
определяющее степень предпочтительности данного решения.
Оператор φ называют интегральным (обобщенным) критерием. Интегральный критерий
присваивает каждому решению по выбору альтернативы соответствующее значение
эффективности Е. Это позволяет упорядочить множество решений по степени
предпочтительности.
В данном разделе предлагается использовать аддитивное преобразование при построений
обобщённого показателя эффективности, известное из теории полезности [3]:
Однако в этом случае значения коэффициентов bi, отражают полезность (ценность) критерия
qi при принятии сложного решения о выборе альтернативы. Определение их значений
производится в результате предварительного опроса группы из m экспертов (специалистов в
данной области). Один из возможных путей получения этих значений заключается в
следующем. Каждый j-й эксперт вначале определяет набор чисел Сij, отражающих его мнение
об относительной ценности i-го критерия, причем числа Сij записаны в произвольном масштабе.
Затем они масштабируются, в результате получают
Окончательные значения коэффициентов bi, вычисляются в результате осреднения значений
bij (j =1, 2, ..., т), получаемых от всех экспертов. Если компетентность экспертов в группе
считается одинаковой, то
m
Если же компетентность j-го эксперта оценивается числом g j ,  g j  1, то
j 1
Ниже рассматриваются основные методы формирования коэффициентов Сij, отражающих
мнение j-го эксперта о ценности i-го критерия. В дальнейшем предполагается, что вначале
каждый эксперт провел ранжировку всех критериев, т.е. упорядочил их в соответствии с
относительной ценностью так, что на первом месте находится самый главный критерий.
5.1. Метод ранжировки
В соответствии с данным методом производится нумерация всех критериев полученного
ряда, причем все неразличимые критерии, которые оказались на одном месте, нумеруются в
произвольном порядке [3]. В результате данной процедуры каждый критерий получает свой
номер. Ранг критерия определяется его номером, если на его месте в ряду отсутствуют какиелибо другие. Если на одном месте находится несколько неразличимых критериев, то ранг
каждого из них равен среднему арифметическому их новых номеров.
Пример 2.2 ([3]). Пусть имеется следующий ряд упорядоченных критериев q1, q2, ..., q8
для j-го эксперта:
44
Ранги критериев, вычисленные в соответствии с вышеуказанной процедурой, сведены в табл.
2.2.
Таблица 2.2
Переход от рангов к коэффициентам Сij производится на основе гипотезы о линейной
зависимости между рангом и относительной ценностью критерия. Чем ниже ранг, тем более
важным является соответствующий критерий. Определение коэффициентов Сij для
произвольного rij (1 ≤ rij ≤ n) производится в соответствии со следующей формулой:
Для рассмотренного примера коэффициенты Сij сведены в табл. 2.3.
Таблица 2.3
Следует отметить, что гипотеза о линейной зависимости между рангом и относительной
ценностью критерия делает оценки Сij весьма грубыми, но определяет их сравнительно
высокую достоверность.
5.2. Метод непосредственных оценок
В основу этого метода положена менее жесткая гипотеза об убывающей (но необязательно
линейной) зависимости между рангом и относительной ценностью критерия. Вначале каждый jй эксперт производит упорядочение всех критериев в соответствии с вышерассмотренной
процедурой. После этого он эвристическим путем дает численную оценку относительной
полезности каждого критерия по сравнению с самым главным, которому присваивается
значение, равное единице. Всем неразличимым критериям присваиваются одинаковые значения
Сij. В результате каждому критерию в упорядоченном ряду вместо рангов сразу присваиваются
числа Сij, совокупность которых должна образовать невозрастающую последовательность. При
использовании метода непосредственных оценок возникает возможность более
дифференцированно подходить к оценке важности отдельных критериев, но при этом
понижается достоверность полученной информации.
5.3. Метод последовательных предпочтений
Алгоритм последовательных предпочтений предназначен для повышения достоверности
информации, полученной от экспертов методом непосредственных оценок. Он позволяет
каждому эксперту провести самоконтроль суждений на основе сопоставления трех подходов:
ранжирования критериев, числовой оценки их ценности и сравнения п–2 пар специально
подобранных абстрактных объектов.
Последняя процедура, отражающая сущность метода последовательных предпочтений,
основана на следующей гипотезе. Если ценность i-го критерия объекта некоторого класса для jn
го эксперта есть Сij, то ценность объекта по всем критериям определяется
C .
i 1
ij
В процессе
коррекции оценок эксперт должен ответить на ряд вопросов: для i = 1, 2, …. (п–2) какой из двух
объектов лучше – обладающий только i-м критерием или совокупностью из (i+1, i±2, ..., n)
45
критериев? В зависимости от ответа на i-й вопрос составляется одно из трех соотношений:
В результате будут получены (n – 2) условия:
Далее производится последовательная проверка каждого из этих условий, начиная с
последнего, на соответствие ранее выбранным оценкам Сij и их ранжировке. При выявлении
противоречий в i-м условии эксперт должен либо изменить знак отношения R, либо
откорректировать значение величины Сij. В последнем случае он обязан убедиться в том, что не
оказалась нарушенной первоначальная ранжировка критериев. При нарушении ее необходимо
либо изменить порядок критериев, либо откорректировать значение Сij. После исправления
последней оценки Сij ее значение может отличаться от единицы. Следует отметить, что в этом
случае психологические ограничения не дают использовать метод последовательных
предпочтений, когда число рассматриваемых критериев превышает семь [3]. Рассмотрим
пример.
Пример 2.3. Пусть некоторый эксперт выставил следующий ряд коэффициентов Сi,
отражающих его мнение об относительной ценности шести частных критериев некоторого
объекта (табл. 2.4) [3].
Таблица 2.4
Для уточнения оценок коэффициентов Сi, эксперту предлагается сравнивать четыре пары
абстрактных объектов. Каждому объекту соответствует вектор х=(х1, х2, ..., xi, ..., х6), где хi = (0;
1): 1 – учитывается полезность i-го критерия, 0 – не учитывается; тогда:
1) (100000) хуже (011111);
2) (010000) лучше (001111);
3) (001000) хуже (000111);
4) (000100) лучше (000011).
Эксперт вынес систему решений. Соотношение х(1) лучше х(2) соответствует большей
предпочтительности для эксперта объекта х(1) по сравнению с объектом х(2).
Непротиворечивость принятых решений должна подтверждаться выполнением системы
неравенств:
Проверка неравенств начинается с последнего (четвертого). Третье и четвертое неравенства
выполняются, второе – нет; значит, необходимо скорректировать значения коэффициента С2.
Примем значение С2 = 2. Однако одновременно необходимо изменить значение C1 таким
образом, чтобы, во-первых, сохранился первоначальный порядок критериев, определенный
экспертом, т. е. C1 > C2, и, во-вторых, выполнялось первое неравенство. Принимаем, например,
значение C1 = 2,5. В результате применения метода последовательных предпочтений получили
непротиворечивый ряд оценок (табл. 2.5), которые в дальнейшем необходимо масштабировать.
Таблица 2.5
46
5.4. Оценка результатов экспертного анализа
При использовании всех рассмотренных выше методов возникает естественный вопрос:
насколько можно доверять результатам оценки коэффициентов Сij, полученным из
субъективных мнений экспертов? Достоверность результатов экспертного анализа чаще всего
характеризуется степенью согласованности данных ими оценок. Для количественной оценки
степени согласованности часто используется коэффициент конкордации [3]:
где
rij – место, которое заняло i-e свойство в ранжировке j-м экспертом.
Коэффициент W позволяет оценить, насколько согласованы между собой ряды
предпочтительности, построенные каждым экспертом. Его значение находится в пределах 0 ≤
W ≤ 1, причем W = 0 означает полную противоположность, a W = 1 – полное совпадение
ранжировок. Практически достоверность считается хорошей, если W = 0,7÷0,8.
На основе рассмотренных методов могут быть определены значения коэффициентов Cij (i =
1, 2, ..., т; t = 1, 2, ..., n), по которым будут вычислены коэффициенты bi, линейной формы
интегрального критерия. При использовании такого подхода к формированию интегрального
критерия в дальнейшем считается, что единица измерения каждого свойства системы,
отраженного в соответствующем частном критерии, выбрана по принципу «чем больше, тем
лучше». Отсюда следует, что качество решения по выбору альтернативы тем лучше, чем
больше значение показателя эффективности.
Так как критерии qi могут иметь различную размерность, то при использовании их в качестве
аргументов функции Е необходимо провести нормирование, т. е. привести их к общей
размерности, и в частности к безразмерному виду.
Для придания равномерности влияния каждого из критериев на значение интегрального
критерия необходимо выровнять диапазоны изменения значений критериев путем
масштабирования и сведения их к диапазону [0; 1].
Проведение преобразований типов нормирования и масштабирования требует, чтобы для
каждого из критериев были определены понятия «негодного» и «идеального» объектов, а это
означает, что должны быть заданы допустимые области изменений значений критериев qi, qiн <
qi ≤ qiв. В этом случае самым простым масштабирующим и нормирующим преобразованием
является линейное преобразование следующего вида:
где qiотн, qiн, qiв - относительное, нижнее и верхнее значения критерия qi соответственно.
В случае такого преобразования чувствительность шкалы изменения qi во всем диапазоне
изменений qi постоянна. Если же разработчика особенно интересуют альтернативы в
окрестности некоторой точки qi*, то можно повысить разрешающую способность частного
критерия в окрестности этой точки за счет использования соответствующих нелинейных
преобразований [3].
После проведения операций нормирования и масштабирования область годных альтернатив
47
окажется заданной в виде n-мерного единичного куба, причем
В результате проведенных преобразований для каждой рассматриваемой альтернативы будет
определен вектор qотн(a), причем аА, где А – множество возможных альтернатив. Оценка
интегрального показателя решения по выбору альтернативы производится в соответствии со
следующим соотношением:
Заканчивая рассмотрение вопросов, связанных с построением обобщенного критерия
эффективности сложных систем на основе метода экспертных оценок, следует еще раз обратить
внимание на то, что на многих этапах его построения приходится опираться на субъективные
мнения специалистов при выборе:
 наиболее существенных частных критериев;
 процедуры и единицы измерения для критериев;
 «идеального» значения критерия;
 значения, дающего наибольшую разрешающую способность критерия;
 нормирующего и масштабирующего преобразований;
 структуры функции обобщенного критерия;
 значений весовых коэффициентов.
Поэтому решения на каждом из перечисленных этапов должны приниматься на основе
усредненного мнения многих специалистов, что повышает объективное содержание критерия.
Однако это не исключает таких ситуаций, когда оценки некоторых реальных объектов,
полученные с помощью обобщенного критерия, противоречат мнению специалистов. В
подобных случаях следует не отказываться от дальнейшего использования данного подхода, а
тщательно проанализировать и выявить конкретные причины расхождения, после чего внести
соответствующие изменения в критерий.
Как указывалось выше, для оценки СУБД могут использоваться самые разнообразные
параметры, которые могут быть сгруппированы следующим образом:
 параметры определения данных;
 физические параметры;
 параметры доступности;
 параметры обработки транзакций;
 утилиты;
 средства разработки... и т.д.
Рекомендуемые параметры (показатели) для оценки СУБД приведены в табл. 2.6 [7].
Таблица 2.6
Наименование группы
Определение данных
Наименование параметра
Расширенная поддержка первичных ключей
Определение внешних ключей
Предусмотренные типы данных
Расширяемость типов данных
Определение доменов
Простота реструктуризации
Средства поддержки целостности данных
Реализация механизма представлений
Поддержка словаря данных
Независимость данных
Тип базовой модели организации данных
Поддержка эволюции схемы
48
Физические параметры
Доступность
Обработка транзакций
Утилиты
Средства разработки
Другие параметры
Предусмотренные файловые структуры
Поддержка определения файловых структур
Простота реорганизации
Средства индексирования
Поля/записи с переменной длиной
Сжатие данных
Возможности шифрования
Требования к памяти
Требования к устройствам хранения данных
Язык запросов: совместимость со стандартами SQL
Интерфейс для других систем
Интерфейс для языков третьего поколения
Многопользовательский доступ
Защита базы данных: управление доступом к данным, поддержка механизма
авторизации
Процедуры резервного копирования и восстановления
Поддержка контрольных точек
Средства ведения системного журнала
Поддерживаемый уровень детализации параллельности
Возможные стратегии разрешения тупиковых ситуаций
Поддержка усовершенствованных моделей управления транзакциями
Параллельная обработка запросов
Измерение производительности
Настройка производительности базы данных
Инструменты загрузки/выгрузки данных
Контроль активности пользователей
Поддержка процедур администрирования базы данных
Инструменты, использующие языки четвертого и пятого поколений
Case-инструменты
Инструменты для работы с оконным инструментом
Поддержка хранимых процедур, триггеров и правил
Способность к модернизации
Стабильность производителя СУБД
База пользователей
Обучение и поддержка пользователей
Взаимодействие с другими СУБД и прочими системами
Поддержка работы в Internet
Утилиты репликации
Возможности распределенной работы
Качество и полнота документации
Требуемая операционная система
Стоимость
Оперативная справочная система
Используемые стандарты
Управление версиями
Расширенная оптимизация запросов
Масштабируемость
Переносимость
Требуемое аппаратное обеспечение
Поддержка работы в сети
Объектно-ориентированные свойства
Поддержка двух- или трехуровневой архитектуры «клиент/сервер»
Производительность
Пропускная способность при обработке транзакций
Максимальное количество одновременно работающих пользователей
49
6. ДАТАЛОГИЧЕСКИЕ МОДЕЛИ ДАННЫХ
(ЛЕКЦИИ 8-9)
Модель данных – фиксированная система понятий и правил для представления структуры
данных, состояния и динамики проблемной области в базах данных [12]. Как правило, задается
языком определения данных и языком манипулирования данными. Примерами модели данных,
получившими широкое распространение, являются модели данных сетевая, иерархическая,
реляционная и др.
Модель данных состоит из трех компонент [11].
1. Структура данных для представления точки зрения пользователя на базу данных.
2. Допустимые операции, выполняемые на структуре данных. Они составляют основу языка
данных рассматриваемой модели данных. Одной лишь хорошей структуры данных
недостаточно. Необходимо иметь возможность работать с этой структурой при помощи
различных операций языка определения данных и языка манипулирования данными. Богатая
структура данных ничего не стоит, если нет возможности оперировать ее содержимым.
3. Ограничения для контроля целостности. Модель .данных должна быть обеспечена
средствами, позволя ющими сохранять ее целостность и защищать ее.
Схема – это средство, с помощью которого определяется модель данных приложения. В
действительности схема содержит не только модель данных: в ней присутствует также
некоторая семантическая информация, относящаяся к конкретному приложению. В модели
данных можно определить, например, что база данных будет хранить информацию об
организациях и служащих. Однако, тот факт, что данный служащий не может работать более
чем в одной организации, отражает семантику приложения. Это семантическое ограничение
должно выполняться для каждого отдельного экземпляра записи базы данных об этом
служащем. Поддержка ограничений заданной модели данных в базе данных также является
частью функций СУБД по обеспечению защиты и целостности.
Прежде, чем перейти к детальному и последовательному изучению реляционных систем БД,
целесообразно ознакомиться с ранними СУБД [8]. В этом есть смысл по трем причинам: вопервых, эти системы исторически предшествовали реляционным, и для правильного понимания
причин повсеместного перехода к реляционным системам нужно знать хотя бы что-нибудь про
их предшественников; во-вторых, внутренняя организация реляционных систем во многом
основана на использовании методов ранних систем; в-третьих, некоторое знание в области
ранних систем будет полезно для понимания путей развития постреляционных СУБД.
Подробный сравнительный анализ даталогических моделей приведен в прил. 3.
6.1. Иерархическая модель
Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из
упорядоченного набора нескольких экземпляров одного типа дерева.
Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или
более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в
целом представляет собой иерархически организованный набор типов записи [8].
Пример типа дерева (схемы иерархической БД) представлен на рис. 2.19.
Рис. 2.19. Пример схемы иерархической БД
50
На рис. 2.19 ОТДЕЛ является предком для НАЧАЛЬНИК и СОТРУДНИКИ, а НАЧАЛЬНИК
и СОТРУДНИКИ - потомки ОТДЕЛ. Между типами записи поддерживаются связи.
База данных с такой схемой могла бы выглядеть следующим образом (рис. 2.20, показан
один экземпляр дерева) [8].
Рис. 2.20. Реализация иерархической БД
Все экземпляры данного типа потомка с общим экземпляром типа предка называются
близнецами. Для БД определен полный порядок обхода - сверху-вниз, слева-направо.
Примерами типичных операторов манипулирования иерархически организованными
данными могут быть следующие [8].
 Найти указанное дерево БД (например, отдел 42).
 Перейти от одного дерева к другому.
 Перейти от одной записи к другой внутри дерева (например, от отдела – к первому
сотруднику).
 Перейти от одной записи к другой в порядке обхода иерархии.
 Вставить новую запись в указанную позицию.
 Удалить текущую запись.
Автоматически поддерживается целостность ссылок между предками и потомками.
Основное правило: никакой потомок не может существовать без своего родителя. Заметим,
что аналогичное поддержание целостности по ссылкам между записями, не входящими в одну
иерархию, не поддерживается.
В иерархических системах поддерживалась некоторая форма представлений БД на основе
ограничения иерархии. Примером представления приведенной выше БД может быть
следующая иерархия (рис. 2.21) [8].
Рис. 2.21. Пример схемы иерархической БД
Экземпляр дерева базы данных не обязательно должен содержать все свои сегменты. При
необходимости можно добавлять или удалять экземпляры типов записей в соответствии с
требованиями приложения.
Иерархическая структура реализует отношение ОДИН-КО-МНОГИМ между исходным и
порожденным типами записей. Это отображение полностью функционально, т.к. дерево не
может содержать порожденный узел без исходного узла (за исключением «корня»).
Следовательно,
отображения
ОДИН-К-ОДНОМУ
и
ОДИН-КО-МНОГИМ
могут
непосредственно представляться иерархическими структурами. Однако для представления
отображения МНОГИЕ-КО-МНОГИМ необходимо дублирование деревьев, а значит,
реализация сложных связей требует больших затрат памяти.
51
Другой проблемой иерархий является невозможность хранения в БД порожденного узла без
соответствующего исходного, т.е. в этом случае необходимо ввести пустой исходный узел.
Соответственно удаление данного исходного узла влечет удаление всех порожденных узлов
(поддеревьев), связанных в ним. Эти ограничения создают проблемы применения
иерархической модели для некоторых приложений.
6.2. Сетевая модель
Сетевой подход к организации данных является расширением иерархического. В
иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой
структуре данных потомок может иметь любое число предков. С точки зрения теории графов
сетевой модели соответствует произвольный граф (возможно имеющий циклы и петли). В узлах
графа помещаются типы записей, а ребра интерпретируются как связи между типами записей.
Сетевая БД состоит из набора записей и набора связей между этими записями, а если
говорить более точно, из набора экземпляров каждого типа из заданного в схеме БД набора
типов записи и набора экземпляров каждого типа из заданного набора типов связи [8].
Тип связи определяется для двух типов записи: предка и потомка. Экземпляр типа связи
состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа
записи потомка. Для данного типа связи L с типом записи предка Р и типом записи потомка С
должны выполняться следующие два условия:
 каждый экземпляр типа Р является предком только в одном экземпляре L;
 каждый экземпляр С является потомком не более, чем в одном экземпляре L.
На формирование типов связи не накладываются особые ограничения; возможны, например,
следующие ситуации [8].
А. Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом
типе связи L2 (как в иерархии).
B. Данный тип записи Р может быть типом записи предка в любом числе типов связи.
C. Дляный тип записи Р может быть типом записи потомка в любом числе типов связи.
D. Может существовать любое число типов связи с одним и тем же типом записи предка и
одним и тем же типом записи потомка; и если L1 и L2 - два типа связи с одним и тем же
типом записи предка Р и одним и тем же типом записи потомка С, то правила, по которым
образуется родство, в разных связях могут различаться.
E. Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком в другой.
F. Предок и потомок могут быть одного типа записи.
Простой пример сетевой схемы БД приведен на рис. 2.22.
Рис. 2.22. Пример схемы сетевой БД
Примерный набор операций при использовании сетевой модели может быть следующим [8].
 Найти конкретную запись в наборе однотипных записей (инженера Петрова).
 Перейти от предка к первому потомку по некою рой связи (к первому сотруднику отдела
42).
 Перейти к следующему потомку в некоторой связи (от Петрова к Иванову).
 Перейти от потомка к предку по некоторой связи (найти отдел Петрова).
52






Создать новую запись.
Уничтожить запись.
Модифицировать запись.
Включить в связь.
Исключить из связи.
Переставить в другую связь и т.д.
6.3. Реляционная модель
В конце 60-х годов появились работы, в которых обсуждались возможности применения
различных табличных даталогических моделей данных, т.е. возможности использования
привычных и естественных способов представления данных. Наиболее значительной из них
была статья сотрудника фирмы IBM д-ра Э. Кодда (Codd E.F., A Relational Model of Data for
Large Shared Data Banks. CACM 13: 6, June 1970), где, вероятно, впервые был применен термин
«реляционная модель данных».
Будучи математиком по образованию Э. Кодд предложил использовать для обработки
данных аппарат теории множеств (объединение, пересечение, разность, декартово
произведение). Он показал, что любое представление данных сводится к совокупности
двумерных таблиц особого вида, известного в математике как отношение – relation (англ.) [2,
5, 7, 10].
Наименьшая единица данных реляционной модели – это отдельное атомарное
(неразложимое) для данной модели значение данных. Так, в одной предметной области
фамилия, имя и отчество могут рассматриваться как единое значение, а в другой – как три
различных значения.
Доменом называется множество атомарных значений одного и того же типа. Так, на рис.
2.23 домен пунктов отправления (назначения) – множество названий населенных пунктов, а
домен номеров рейса – множество целых положительных чисел.
Смысл доменов состоит в следующем. Если значения двух атрибутов берутся из одного и
того же домена, то, вероятно, имеют смысл сравнения, использующие эти два атрибута
(например, для организации транзитного рейса можно дать запрос «Выдать рейсы, в которых
время вылета из Москвы в Сочи больше времени прибытия из Архангельска в Москву»). Если
же значения двух атрибутов берутся из различных доменов, то их сравнение, вероятно, лишено
смысла: стоит ли сравнивать номер рейса со стоимостью билета?
Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит
из заголовка и тела. На рис. 2.23 приведен пример отношения для расписания движения
самолетов.
Заголовок состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что
существует взаимно однозначное соответствие между этими атрибутами Аi и определяющими
их доменами Di (i = l, 2, ..., n).
Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит
в свою очередь из множества пар атрибут-значение (Ai:Vi), (i = 1, 2, ..., n), по одной такой паре
для каждого атрибута А. в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi
является значением из единственного домена Di, который связан с атрибутом Аi.
53
Рис. 2.23. Отношение в реляционной модели
Степень отношения – это число его атрибутов. Отношение степени один называют
унарным, степени два – бинарным, степени три – тернарным, ..., а степени п – n-арным.
Кардинальное число или мощность отношения – это число его кортежей. Кардинальное
число отношения изменяется во времени в отличие от его степени.
Изменение кардинального числа отношения связано с изменением состояния отношения.
Поскольку отношение – это множество, а множества по определению не содержат
совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг
друга в любой произвольно-заданный момент времени. Пусть R – отношение с атрибутами А1,
A2, ..., Ап. Говорят, что множество атрибутов К = (Аi, Аj, ..., Аk) отношения R является
возможным ключом R тогда и только тогда, когда удовлетворяются два независимых от
времени условия [5].
1. Уникальность: в произвольный заданный момент времени никакие два различных кортежа
R не имеют одного и того же значения для Аi, Аj, ..., Ak.
2. Минимальность: ни один из атрибутов Аi, Аj, ..., Ak не может быть исключен из К без
нарушения уникальности.
Каждое отношение обладает хотя бы одним возможным ключом, поскольку, по меньшей
мере, комбинация всех его атрибутов удовлетворяет условию уникальности. Один из
возможных ключей (выбранный произвольным образом) принимается за его первичный ключ.
Остальные возможные ключи, если они есть, называются альтернативными ключами.
Вышеупомянутые и некоторые другие математические понятия явились теоретической базой
для создания реляционных СУБД, разработки соответствующих языковых средств и
программных систем, обеспечивающих их высокую производительность, и создания основ
теории проектирования баз данных. Однако для массового пользователя реляционных СУБД
можно использовать неформальные эквиваленты этих понятий:
Отношение – Таблица (иногда Файл),
Кортеж – Строка (иногда Запись),
Атрибут - Столбец, Поле.
При этом принимается, что «запись» означает «экземпляр записи», а «поле» означает «имя и
тип поля».
Математическое определение реляционной модели приводится в [10, 17].
54
Отношение рассматривается как подмножество декартова произведения доменов.
Декартовым произведение доменов D1, D2, ..., Dk
где D1 ={d1.1, d1.2, …, d1.i1, …, d1.n1}, D2 = {d2.1, d2.2, …, d2.i2, …, d2.n2}, …, Dk = {dk.1, dk.2, ..., dk.ik,
..., dk.nk}, называется множество всех кортежей длины k, т.е. состоящих из k элементов – по
одному из каждого домена Di.
Пример 2.4. Если D1 = {A, 2}, D2 = {B, С}, D3 = {4, 5, D}, то k = 3 и соответственно
декартово произведение:
Декартово произведение позволяет получить все возможные комбинации элементов
исходных множеств – элементов рассматриваемых доменов.
Отношением R на множествах D1, D2, ..., Dk называется подмножество декартова
произведения D = = D1  D2  ...  Dk. Отношение R, определенное на множествах D1, D2, ..., Dk
(причем не обязательно, чтобы эти множества были различными), есть некоторое множество
кортежей арности k: (d1.i1, d2.i2, ..., di.ik), таких, что d1.i1 принадлежит D1, d2.i2 - D2 и т.д.:
Элементами отношения являются кортежи. Арность кортежа определяет арность отношения.
Поскольку отношение есть множество, то в нем не должны встречаться одинаковые кортежи и
порядок кортежей в отношении несуществен.
Отношение может использоваться двояко [17]:
1) для представления набора объектов;
2) для представления связей между наборами объектов.
Для представления набора объектов атрибуты интерпретируются столбцами отношения.
Множество допустимых значений атрибута интерпретируется соответствующим доменом.
Каждый кортеж отношения выполняет роль описания отдельного объекта из набора.
Отношение выполняет роль описания всего набора объектов.
Отношение также используется для представления связей между наборами объектов. В этом
случае кортеж в отношении R связь между объектами. Чтобы реализовать такую ситуацию,
каждому столбцу отношения ставится в соответствие ключевой атрибут соответствующего
набора объектов.
Список имен атрибутов отношения называется схемой отношения. Если отношение
называется R и его схема имеет атрибуты с именами А1, А2, ..., Ak, то схема отношения
Реляционная база данных – это набор экземпляров конечных отношений. Схему
реляционной БД можно представить в виде совокупности схем отношений
55
Другими словами – реляционная база данных – это совокупность отношений, содержащих
всю информацию, которая должна храниться в БД. Однако пользователи могут воспринимать
такую базу данных как совокупность таблиц. Так на рис. 2.24 показаны таблицы базы данных,
построенные по инфологической модели базы данных «Питание» (прил. 4) [5].
1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.
2. Строки имеют фиксированное число полей (столбцов) и значений (множественные поля и
повторяющиеся группы недопустимы). Иначе говоря, в каждой позиции таблицы на
пересечении строки и столбца всегда имеется в точности одно атомарное значение или
ничего.
3. Строки таблицы обязательно отличаются друг от друга хотя бы единственным значением,
что позволяет однозначно идентифицировать любую строку такой таблицы.
4. Столбцам таблицы однозначно присваиваются имена, и в каждом из них размещаются
однородные значения данных (даты, фамилии, целые числа или денежные суммы).
Рис. 2.24. База данных «Питание» (см. прил.4)
5. Полное информационное содержание базы данных представляется в виде явных значений
данных, и такой метод представления является единственным. В частности, не
существует каких-либо специальных «связей» или указателей, соединяющих одну
таблицу с другой. Так, связи между строкой с БЛ = 2 таблицы «Блюда» на рис. 2.24 и
строкой с ПР = 7 таблицы продукты (для приготовления Харчо нужен Рис),
представляется не с помощью указателей, а благодаря существованию в таблице
«Состав» строки, в которой номер блюда равен 2, а номер продукта – 7.
6. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом
порядке безотносительно к их информационному содержанию. Этому способствует
наличие имен таблиц и их столбцов, а также возможность выделения любой их строки
или любого набора строк с указанными признаками.
56
6.4. Достоинства и недостатки даталогических моделей
Сначала остановимся коротко на ранних (дореляционных) СУБД. Ограничимся
рассмотрением только общих особенностей ранних систем, а именно, систем, основанных на
иерархических и сетевых моделях [8].
1. Эти системы активно использовались в течение многих лет, дольше, чем используется
какая-либо из реляционных СУБД. На самом деле некоторые из ранних систем используются
даже в наше время, накоплены громадные базы данных, и одной из актуальных проблем
информационных систем является использование этих систем совместно с современными
системами.
2. Все ранние системы не основывались на каких-либо абстрактных моделях. Как
упоминалось, понятие модели данных фактически вошло в обиход специалистов в области БД
только вместе с реляционным подходом. Абстрактные представления ранних систем появились
позже на основе анализа и выявления общих признаков у различных конкретных систем.
3. В ранних системах доступ к БД производился на уровне записей. Пользователи этих
систем осуществляли явную навигацию в БД, используя языки программирования,
расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем
создания соответствующих прикладных программ с собственным интерфейсом.
4. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли
пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки
системы.
5. После появления реляционных систем большинство ранних систем было оснащено
«реляционными» интерфейсами. Однако в большинстве случаев это не сделало их понастоящему реляционными системами, поскольку оставалась возможность манипулировать
данными в естественном для них режиме (на низком физическом уровне).
Обобщая перечисленные особенности, можно сформулировать достоинства и недостатки
ранних систем.
Достоинства:
 развитые средства управления данными во внешней памяти на низком уровне;
 возможность построения вручную эффективных прикладных программ;
 возможность экономии памяти.
Недостатки:
 сложность практического использования;
 необходимость знания физической организации данных;
 жесткая зависимость прикладных систем от физической организации данных;
 логика перегружена деталями организации доступа к БД.
По сравнению с ранними моделями, реляционный подход обладает следующими
особенностями [2, 5, 8, 17].
Достоинства:
 наличие относительно небольшого набора абстракций;
 наличие простого, но мощного математического аппарата (в основе реляционного
подхода – теория множеств);
 возможность ненавигационного манипулирования данными без знания их конкретной
физической организации.
Недостатки:
 ограниченность использования в нетрадиционных предметных областях;
 относительно неполная адекватность отражения семантики предметной области.
В главе 4 рассматривается самая сильная сторона реляционного подхода – математический
аппарат для выполнения операций над отношениями реляционной модели.
Наличие простого, но мощного математического аппарата сыграло решающую роль в
повсеместном переходе разработчиков СУБД на реляционную модель.
57
7. ФИЗИЧЕСКАЯ ОРГАНИЗАЦИЯ ДАННЫХ В СУБД
(ЛЕКЦИИ 10-11)
7.1. Списковые структуры
В системах обработки данных в качестве данных выступают описания (представления)
фактов и понятий рассматриваемой предметной области на точном и формализованном
входном языке системы – языке описания данных [17]. С помощью входного языка при
описании фактов и понятий ПО между элементами данных конструируются логические
структурные отношения. В качестве логических структур (см. гл.2) используют либо таблицы,
представляющие собой двумерный или n-мерный массив данных, либо древовидные
иерархические структуры, либо сетевые структуры, представляющие собой сложную
многосвязную структуру с большим количеством взаимных соединений и т.п. Чтобы правильно
использовать вычислительную машину, необходимо хорошо представлять себе структурные
отношения между данными, знать способы представления таких структур в памяти машины и
методы работы с ними. Структура данных и представление этой структуры в памяти ЭВМ – два
важных, но различных между собой понятия [17]. Так, например, некоторая логическая
структура данных типа «дерево» может быть представлена в памяти ЭВМ несколькими
различными способами.
Таким образом, любое представление структуры данных в памяти ЭВМ должно включать в
себя как сами данные, так и задаваемые взаимосвязи, которые и определяют логическое
структурирование.
Форма представления структур данных в памяти ЭВМ зависит от предполагаемого
использования данных, поскольку для различных типов структур эффективность выполнения
тех или иных операций обработки данных различна. Основное различие форм представления
структур данных в памяти ЭВМ определяются в первую очередь тем, как адресуются элементы
структуры данных в памяти машины – по месту или по содержимому. В первом случае
указываются логические или физические адреса данных, определяющие местоположение
данных в памяти машины. Во втором случае размещение данных и их выборка осуществляются
по известному значению ключа, т.е. определяются содержимым самих данных [4].
Наиболее простой формой хранения данных в памяти ЭВМ является одномерный линейный
список.
Линейный список – это множество n≥0 объектов (узлов) Х[1], Х[2], ..., Х[п], структурные
свойства которого связаны только с линейным (одномерным) относительным расположением
узлов. Если n>0, то Х[1] является первым узлом; для 1<i<n узел X[i-1] предшествует узлу X[i], а
узел Х[i+1] следует за ним, Х[п] является последним узлом, т.е. линейный список реализует
структуру, которую можно определить как линейное упорядочение элементов данных [17].
Линейный список X рассматривают как последовательность Х[1], Х[2], ..., X[i], ..., Х[n],
компоненты которой идентифицированы порядковым номером, указывающим их
относительное расположение в X.
Одномерный линейный список, используемый для хранения данных в памяти машины,
называют еще вектором данных или физической структурой хранения данных. Использование
линейного списка в качестве физической структуры хранения данных определяется свойствами
памяти вычислительной машины. Так, оперативная память ЭВМ представляет вектор, в
котором байты упорядочены по возрастанию их адресов от 0 до наивысшего, т.е.
проидентифицированы адресом.
Проблема представления логических структур данных в памяти ЭВМ заключается в
нахождении эффективных методов отображения логической структуры данных на
физическую структуру хранения. Такое отображение называют адресной функцией.
При реализации адресной функции используют два основных метода [17]:
 последовательное распределение памяти;
 связанное распределение памяти.
58
7.1.1. Последовательное распределение памяти
Последовательное распределение – простой и естественный способ хранения линейного
списка. В этом случае узлы списка размещаются в последовательных элементах памяти
(рис.3.1) [17].
При последовательном распределении вектор данных логически отделен от описания
структуры хранимых данных. Например, если структура данных представляет собой линейный
список (файл записей фиксированной длины), то описание структуры хранится в отдельной
записи и содержит:
а) N – размер вектора данных, т.е. количество элементов списка записей;
б) т – размер элемента списка, т.е. размер записи, например, в байтах;
в) β – адрес базы, указывающий на начало вектора данных в памяти.
Рис. 3.1. Пример последовательного распределения памяти для представления линейного списка
В этом случае адрес каждой записи можно вычислить с помощью адресной функции,
отображающей логический индекс, идентифицирующий запись в структуре, в адрес физической
памяти
В случае линейного списка адресная функция состоит из операций смещения и
масштабирования. Любые отношения, которые можно выразить на языке целых чисел, можно
истолковать как отношения между элементами памяти, получая при этом всевозможные
варианты структур.
В качестве примера (из [17]) рассмотрим реализацию с помощью линейного списка при
последовательном распределении памяти для логической структуры типа регулярного
двоичного дерева (рис. 3.2). Идея способа заключается в том, что начиная с элемента памяти
α(1), делают его корнем дерева, размещают там данные, соответствующие узлу У1. В элементах
памяти α(2) и α(3) размещают непосредственных потомков узла У1 – узлы У2 и У3, и т.д. В
общем случае, непосредственные потомки узла Уk размещаются по адресам: α(2k) и α(2k+1).
Адресная функция имеет вид
где k – номер узла древовидной структуры; β – базовый адрес; т – размер элемента памяти,
который требуется для хранения данных узлов дерева (каждый узел представляет собой запись
фиксированной длины). По дереву, которое при этом получается, можно двигаться в обоих
направлениях, так как от узла Уk можно перейти к его потомкам, удвоив k (или удвоив k и
прибавив единицу). Можно двигаться к узлу, являющемуся исходным для узла Уk, разделив k
пополам и отбросив дробную часть. Адрес соответствующего узлу элемента памяти
определяется по адресной функции.
Рассмотрим еще один способ реализации, который применим только для двоичных деревьев.
59
Если для представления двоичного дерева используется вектор памяти от элемента i до
элемента j включительно, то корень дерева размещается в элементе памяти с адресом
где   – знак округления до ближайшего меньшего целого.
Рис. 3.2. Пример реализации структуры типа регулярного двоичного дерева с помощью линейного
списка
Корень дерева размещается в середину вектора. В элементах памяти от i-гo до (m-1)-гo
включительно размещается левое поддерево. В элементах памяти от (m+1)-го до j-го
включительно размещается правое поддерево. Аналогично процесс повторяется для
размещения каждого поддерева. Приведенный способ позволяет реализовать двоичное
сбалансированное дерево.
Существует ряд других способов представления древовидных структур [4, 13, 17]. С
помощью приемов, основанных на свойствах целых чисел, можно с помощью
последовательного распределения организовать в памяти некоторые сетевые структуры.
Однако для представления сложных сетевых структур требуются более гибкие методы
построения в памяти ЭВМ, которые невозможно получить с помощью последовательного
распределения памяти. В этом случае используется связанное распределение памяти.
7.1.2. Связанное распределение памяти
Связанное представление линейного списка называется связанным списком. При связанном
распределении памяти для построения структуры необходимо Задать отношения следования и
предшествования элементов с помощью указателей. Указателями служат адреса, хранимые в
записях данных. В отличие от последовательного распределения памяти, при котором с
помощью адресной функции вычисляется адрес следующего элемента, при связанном
распределении памяти значение адресной функции можно получить только путем просмотра
хранящихся указателей. Такой метод распределения памяти позволяет расширить либо
сократить структуру без перемещения самих данных в памяти ЭВМ, однако при этом требуется
больше памяти для хранения структуры по сравнению с последовательным распределением [16,
17].
Связанное распределение – более сложный, но и более гибкий способ хранения линейного
списка. Каждый узел содержит указатель на следующий узел списка, т.е. адрес следующего
узла списка (рис. 3.3). При связанном распределении не требуется, чтобы список хранился в
последовательных элементах памяти. Наличие адресов связи в данном способе хранения
позволяет размещать узлы списка произвольно в любом свободном участке памяти. При этом
60
линейная структура списка обеспечивается указателями.
Структура линейного списка, представленная с помощью связанного распределения,
называется также цепной структурой или цепью.
Для достижения большей гибкости при работе с линейными списками в каждый узел X[i]
вводятся два указателя. Один из указателей реализует связь рассматриваемого узла с узлом X[i1], а другой – с узлом XIi+1] (рис. 3.4).
Рис. 3.3. Примеры связанных линейных списков:
а) – однонаправленный список; б) - тот же список после удаления узла 4 и включения узлов 2а и 5
Связанные списки – удобная форма представления динамически изменяющихся линейных
структур. Любое произвольное изменение порядка записей, сокращение или расширение
вектора данных в какой-либо записи не требуют перемещения записей в памяти ЭВМ. Для
выполнения этих операций достаточно лишь изменить значения полей связи.
Однако доступ к конкретному узлу может оказаться намного длительнее, чем при
последовательном распределении памяти. Чтобы получить доступ к данным, хранящимся в узле
Х[i], необходимо сделать i итераций, используя указатели и поля связи в узлах X[k], где k = 1, 2,
..., i, т.е. последовательно просмотреть все предшествующие узлы списка. Этот недостаток
можно устранить различными способами.
Рис. 3.4. Пример двунаправленного линейного списка
Одним из способов является организация связанного линейного списка с пропусками (рис.
3.5, а). Для этого линейный список делится на группы узлов, связанные между собой
обратными указателями. Вначале осуществляется доступ по обратным указателям к группе, в
которой находится требуемый узел, а затем по прямым указателям перебираются узлы группы,
пока не будет найден требуемый узел. Вход в список при таком способе организации
осуществляется с конца.
Другой способ (рис. 3.5, б) заключается в построении специального дополнительного
61
линейного списка – индекса, например, с последовательным распределением памяти. Элементы
индекса – значения первых узлов каждой группы и указатели на них.
Оптимальный размер группы (количество узлов в группе) при равновероятном нахождении
узла в любой из групп nГ  n , где n – количество элементов списка.
Число групп
Рис. 3.5. Примеры реализации способов ускорения доступа к узлам линейного связанного списка:
а) – организация линейного связанного списка с пропусками; б) – организация линейного связанного
списка с индексом
При равновероятном нахождении узла в любой из групп при доступе к узлу необходимо
просмотреть в среднем l/2 групп, а в каждой группе nг/2 узлов. Следовательно, общее
количество просмотров
Для связанных линейных одно- или двунаправленных списков в ряде случаев целесообразно
создать специальный узел – голову списка – и хранить его в специальной фиксированной ячейке
памяти по адресу β. В этот узел помещается указатель на первый узел списка. В голове списка
можно хранить различную служебную информацию, необходимую при обработке списка
(идентификатор списка, количество узлов в списке и т.п.).
Важной разновидностью представления в памяти линейного списка является циклический
список. Циклически связанный линейный список обладает той особенностью, что связь от
последнего узла идет к первому узлу списка (рис. 3.6). Циклический список позволяет получить
доступ к любому узлу списка, отправляясь от любого заданного узла. Циклические списки
называются также кольцевыми структурами или кольцами.
Рис. 3.6. Пример однонаправленного циклического списка
62
Наряду с однонаправленными используются двунаправленные циклические списки. В ряде
случаев удобно использовать циклический список с указателями на голову списка из каждого
узла, за исключением последнего узла, поскольку используется прямой указатель на голову
списка [17].
Базируясь на использовании способов представления связанных линейных списков, можно
реализовать в памяти ЭВМ сложные нелинейные структуры, например древовидные или
сетевые. Такие представления структур называются многосвязанными списками. Для
построения многосвязанного списка требуется иметь в узлах достаточное количество
указателей. Наличие большого числа указателей в многосвязанной структуре в ряде случаев
повышает эффективность обработки.
Таким образом, основой построения связанных списковых структур являются указатели.
При практической реализации на ЭВМ можно использовать три типа указателей (адресов
записей):
 машинный (действительный);
 относительный;
 символический (идентификатор).
Первый тип указателей – действительный адрес – используется тогда, когда необходимо
получить наибольшую скорость обработки данных, организованных в связанные списковые
структуры. Этот тип указателей имеет серьезный недостаток – жесткую привязку записей к
конкретному месту расположения в памяти. Если возникнет необходимость переместить список
на новое место в памяти ЭВМ, то потребуется выполнить работу изменению указателей во всех
записях.
Второй тип указателей – относительный адрес – позволяет размещать записи в любом
месте памяти и на различных внешних устройствах без изменения значений указателей, при
этом относительное расположение в памяти узлов списка между собой должно оставаться
постоянным. При перемещении списка указатели в записях не изменяются, а изменяется
базовый адрес при вычислении действительных машинных адресов. Относительные адреса в
качестве указателей применяются при страничной организации памяти. Скорость доступа к
узлам при использовании относительных адресов несколько замедляется по сравнению со
случаем машинных адресов, однако появляется возможность размещать список в любом
свободном месте памяти подходящего размера.
Третий тип указателей – символический адрес (идентификатор) – позволяет перемещать
отдельные записи относительно друг друга, включать или удалять записи в список без
изменения указателей во всех остальных записях списка. Однако при работе с символическими
указателями скорость доступа меньше, чем при работе с машинными или относительными
адресами. Идентификаторы в качестве указателей удобно использовать для интенсивно
изменяющихся файлов. Преобразование идентификатора в машинный адрес при выполнении
операций обращения к узлам списка выполняется с помощью специального алгоритма в
соответствии с выбранным методом адресации.
С точки зрения организации структуры данных различают два типа указателей [17]:
 встроенные указатели;
 справочник указателей.
Если указатели образуют часть записи, то они называются встроенными. Если указатели
хранятся отдельно от записей, то они образуют справочник.
Указатели имеют следующие возможные пути использования [17]:
1) определяют направление доступа (можно двигаться только в тех направлениях, которые
заданы указателями);
2) соединяют вместе связанные по смыслу данные;
3) отображают ориентированные ребра в древовидных или сетевых структурах;
4) связывают память на дисках и организуют цепочки дисковых страниц и т.п.
Применение многосвязанных списков – это основной механизм, позволяющий
разработчикам СУБД реализовать сложные нелинейные структуры. Однако следует избегать
слишком большого количества указателей, поскольку на них тратится память и время на
63
переходы по указателям. Кроме того, при большом количестве указателей основная структура,
представляемая в памяти ЭВМ, теряет четкость, и могут возникнуть связи, которые в
отображаемой структуре отсутствуют.
7.2. Модель внешней памяти
Данные хранятся во внешней памяти на магнитных дисках, магнитных лентах и т.д., а их
обработка выполняется в оперативной памяти ЭВМ. Поэтому при обработке некоторые порции
данных пересылаются из внешней памяти в оперативную либо наоборот [17].
При больших объемах данных в БД может потребоваться несколько томов внешней памяти.
Однако обмен между внешней и оперативной памятью выполняется небольшими порциями
данных – обычно объемом не более нескольких сотен байт. С этой целью внешняя память
разбивается на части, называемые блоками или страницами. Данные пересылаются блоками.
Операцию пересылки еще называют обменом данными между внешней и оперативной
памятью. Такой обмен называется чтением блока, а в обратном направлении – записью блока.
При чтении блока, последний помещается в оперативной памяти в специально отведенный
(буферный) участок памяти. Может отводиться участок под несколько буферов (буферный
пул). Чем больше буферный пул, тем эффективнее обработка данных. При считывании другого
блока из внешней памяти в тот же самый буфер предыдущее содержимое буфера теряется. При
внесении изменений в блок вначале блок считывается в буфер, затем выполняются изменения и
далее блок записываются во внешнюю память.
Для организации каждого файла в зависимости от его размера во внешней памяти ему
выделяется от одного до п блоков, где размещаются записи файла. Предположим, что в одном
блоке размещаются записи только одного файла. В зависимости от соотношения объемов
записей и блоков может оказаться, что в одном блоке размещается либо одна, либо несколько
записей файла, либо одна запись размещается в нескольких блоках. Обычно запись занимает
несколько десятков байт.
Каждый байт в блоке пронумерован: О, 1, 2, ..., х. Номер байта блока, с которого начинается
запись, определяет относительный адрес записи файла в блоке.
В качестве адресов записей файла во внешней памяти используют: машинный адрес,
относительный адрес, ключ записи [17].
В качестве относительного адреса записи файла используют ее номер по порядку
(внутрисистемный номер) в файле либо комбинацию таких составляющих адреса, как номер
блока и относительный адрес в блоке, либо номер блока и значение ключа. В последнем случае,
после считывания блока в буфер оперативной памяти, доступ к записи в буфере осуществляется
в помощью какого-либо метода поиска записей в файле по значению ключа.
При чтении записи из блока, который уже находится в буфере, обмен с внешней памятью не
выполняется. Во многих системах при вводе записи ей присваивается уникальный системный
идентификатор – ключ базы данных.
Запись обычно состоит из:
1) служебных полей, в которых хранятся указатели, реализующие связи с другими записями,
и другая информация, необходимая для организации управления файлом,
2) полей хранимых данных.
Записи могут быть фиксированной и переменной длины. Записи размещаются в блоках
плотно, без промежутков, последовательно одна за другой. В блоке часть памяти отводится
также для служебной информации о блоке: относительные адреса свободных участков памяти,
указатели на следующий блок и т.д.
Если файл базы данных состоит из записей фиксированной длины, то в одном блоке может
разместиться k записей:
где   – обозначает целую часть числа; Vбл. и Vз. – соответственно объем блока и записи в
байтах.
64
Однако обычно блоки заполняются не полностью, например, наполовину. Оставшаяся
область блока остается некоторое время при работе системы незаполненной
(зарезервированной). В дальнейшем эта область заполняется при расширении (увеличении)
записей, хранящихся в блоке, или при поступлении в систему новых записей, которые в
соответствии со значениями их ключей или по другим условиям необходимо поместить в одном
блоке с уже хранящимися записями. По истечении некоторого времени блок заполняют
полностью.
Для хранения поступающих данных, которые должны были бы попасть в этот блок,
выделяется дополнительный блок памяти в области переполнения. Записи, которые должны
были размещаться в одном блоке, связываются специальными указателями в одну цепь.
Процесс выделения дополнительных блоков в области переполнения можно было бы не
ограничивать, если бы при этом не снижалась эффективность (по временному критерию)
обработки хранимых данных. Снижение эффективности обработки данных связано с тем, что
система непроизводительно затрачивает время на поиск записей в области переполнения, что
сказывается на увеличении общего времени поиска требуемых записей (по сравнению со
случаем, когда область переполнения еще не была использована и все записи были размещены
в основной области).
Поэтому периодически файл реорганизуется: при необходимости файлу добавляется
требуемой количество блоков в основной области памяти и выполняется требуемая
перекомпоновка записей. При этом исходят из расчета, чтобы можно было освободить область
переполнения, а все записи разместить в блоках основной области, причем, в каждом блоке
разместить записи последовательно и в таком количестве, чтобы r-я часть блока осталась
незаполненной. В этом случае требуемое количество блоков
где r < 1 – незаполненная часть блока; Nз. – количество записей в файле.
Считается, что все блоки каждого файла пронумерованы: 1, 2, ..., β, ..., N и система
определяет требуемый блок по имени файла и номеру блока. Если файл состоит из записей
фиксированной длины, записи организованы последовательно и имеют внутри файла
системный номер, то по этому номеру вычисляют номер блока, в котором находится запись:
Среднее время выполнения операций обмена зависит от типа устройства внешней памяти (от
его характеристик) и от размера блока:
где to – среднее время выполнения операции обмена; tp – время считывания, приведенное к
одному байту (т.е. время считывания одного байта); tподг. – время подготовки устройства к
выполнению операции обмена.
Время поиска данных в файле
где tп – время выполнения операции поиска; tс – среднее время выполнения в процессоре одной
операции сравнения; Хо – количество операций обмена; Хс – количество операций сравнения.
Если tc << to, то время поиска в основном определяется временем, затрачиваемым на обмен с
внешней памятью. Поэтому при составлении алгоритмов поиска данных в файле стремятся к
сокращению количества операций обмена.
На скорость поиска данных в файле наибольшее влияние оказывают следующие
65
характеристики файла и технических устройств внешней памяти, использованных для его
организации [17]:
 объем блока;
 объем байта;
 количество записей в блоке файла пз.бл.;
 количество записей в блоке индекса;
 количество блоков в файле данных nбл.ф.;
 доля резервируемой части блока r (при начальной организации данных в файле);
 длина поля, отведенного для указателя;
 количество записей в файле пз.ф.;
 число полей в записи nп.з.;
 размер записи Vз.;
 длина ключевого поля в записи;
 число записей файла, удовлетворяющих условию поиска Q;
 среднее число блоков переполнения на один блок файла;
 среднее время обмена to.
На рис. 3.7 изображен файл со следующими характеристиками: nз.ф. = 10; nз.бл. = 4; r = 0,5.
Записи файла описываются схемой: F(А1, А2, А3, А4), т.е. nп.з. = 4. При начальной загрузке при
таких характеристиках для организации файла требуется 5 блоков.
7.3. Методы поиска и индексирования данных
При рассмотрении последующего учебного материала используются модели, приведенные в
разд.3.1, 3.2.
7.3.1. Последовательный поиск
Последовательный поиск заключается в последовательной проверке всех записей файла на
их соответствие условию поиска Q [17]. Записи, значения полей которых удовлетворяют
условию Q, выдаются в качестве результата поиска.
Рис. 3.7. Пример организации файла при начальной загрузке
Поиск по равенству К = а, где К – значение ключевого поля. Алгоритм поиска заключается в
последовательном просмотре записей файла и проверке условия К = а. Если запись найдена, то
66
алгоритм заканчивает свою работу (удачный поиск). В противном случае поиск заканчивается
просмотром последней записи файла (неудачный поиск).
Если ключ К с равной вероятностью может принимать любое из заданных значений, то в
среднем для выполнения поиска требуется время
Поиск по интервалу значений ключа а ≤ К ≤ b. Алгоритм поиска заключается в
последовательном просмотре всех записей файла, так как зарание неизвестно, какие записи
удовлетворяют условию Q, а какие не удовлетворяют.
Требуемое время на поиск
Поиск по множеству значений K = ai, i = 1, 2, ..., п, где ai принимает значения из множества
{а1, а2, ..., аi, ..., ап}. Алгоритм поиска заключается в последовательном просмотре всех записей
файла, при чем для каждой записи осуществляется п проверок по равенству: К = аi, где i = 1, 2,
..., п.
Основным достоинством последовательного поиска данных при последовательной
организации файла является простота его реализации.
7.3.2. Бинарный поиск
Записи в файле можно упорядочить, например, по возрастанию или убыванию значения
первичного ключа соответственно:
В этом случае можно построить более эффективные алгоритмы поиска, поскольку после
сравнения значения а (условие поиска Q: К = а) со значением ключа i-й записи файла ясно, в
какой части файла продолжать поиск [17].
Методы поиска записей в упорядоченном файле различаются друг от друга стратегией
выбора очередной записи из фала для выполнения операции сравнения ключа в соответствии с
заданным условием Q. Метод бинарного поиска основан на делении интервала поиска пополам.
Поиск по равенству К = а. Алгоритм поиска заключается в следующем. Файл считают
упорядоченным по возрастанию ключа. Сравнивают значения ключа средней записи Ki, где i =
nз.ф./2 со значением а. Если К = а то поиск удачный и алгоритм заканчивает свою работу. Если
Кi < а, то для продолжения поиска выбирается средняя запись правой половины файла: зi, ..., зj,
..., зпз., где
Если Кi > а, то для продолжения поиска выбирается средняя запись левой половины файла:
з1, з2, ..., зj, ..., зi, где
Процесс деления интервала пополам продолжается до тех пор, пока не будет найдена
искомая запись (Кi = а), либо пока в интервале не останется всего одна запись. Если значение ее
ключа не удовлетворяет условию поиска, то поиск неудачный и искомой записи в файле нет.
Бинарный поиск можно выполнять, работая с блоками файла, а не с записями. При
считывании блока в оперативную память поиск записи в блоке может быть последовательным.
В этом случае в качестве характеристик блока используются граничные значения ключей
записей, находящихся в блоке.
Поиск по интервалу значений а ≤ К ≤ b. Алгоритм поиска следующий. Вначале выполняется
бинарный поиск записи, значение ключа которой удовлетворяет условию Кi = а, либо, если
такой записи нет в файле, то значение ключа которой является наиболее близким к а по
67
условию а ≤ Кi. Далее последовательно читаются записи в блоках файла до тех пор, пока не
будет нарушено условие: Кi ≤ b.
7.3.3. Индекс - «бинарное дерево»
Любой бинарный алгоритм поиска в упорядоченном файле БД можно представить с
помощью соответствующего бинарного дерева [17]. Это бинарное дерево можно реализовать в
виде самостоятельного файла (или индекса). При этом операции поиска будут освобождены от
необходимости каждый раз вычислять адреса записей (они будут сформированы один раз при
начальной загрузке файла БД и при последующих добавлениях в файл новых записей).
На рис. 3.8 представлено бинарное дерево, построенное для файла из 15 записей [17]. Запись
бинарного дерева состоит из поля ключа записи и двух полей указателей. Один указатель для
левого поддерева, другой – для правого поддерева. Листовые записи бинарного дерева
содержат указатели на блоки файла основных записей (файла данных). Для уменьшения
количества операций обмена с внешней памятью при выполнении поиска соседние записи в
бинарном дереве объединяются в блоки. На слайде объединяемые в один блок записи
бинарного дерева очерчены штриховой линией.
Записи бинарного дерева обычно меньше по объему памяти записей основного файла Vз.б.д. <
Vз., так как содержат только одно поле данных (поле ключа) и два служебных поля для
хранения индексов, то при одинаковых размерах блоков количество записей в блоке бинарного
дерева больше, чем в блоке основного файла. Это позволяет еще больше сократить количество
обращений к внешней памяти.
Рис. 3.8. Пример бинарного дерева
Реализация бинарного дерева позволяет сократить время поиска данных по сравнению с
бинарным поиском, однако возрастает требуемый объем внешней памяти [17].
7.3.4. Неплотный индекс
Пусть основной файл F упорядочен по полю ключа К. Построим дополнительный файл FD
(рис. 3.9) по правилу [17]:
1) записи файла FD имеют формат FD(K, Р), где К – поле, принимающее значение ключа
первой записи блока основного файла F; Р – указатель на этот блок;
68
2) записи файла FD упорядочены по полю К.
Рис. 3.9. Пример неплотного индекса
Полученный файл FD называется неплотным индексом. Количество записей файла FD равно
количеству блоков основного файла F. Для организации файла FD требуется дополнительная
внешняя память.
Рис. 3.10. Пример структуры типа В-дерево
Поиск вначале выполняется в индексе для нахождения адреса блока основного файла, а за
тем этот блок считывает в оперативную память и в нем, например, с помощью
последовательного поиска, определяется требуемая запись.
В-дерево. Так как неплотный индекс упорядочен по ключевому полю, то над ним можно
построить еще один неплотный индекс (неплотный индекс неплотного индекса) и т.д., пока на
самом последнем, верхнем уровне не останется всего один блок (рис. 3.10).
69
Полученная структура называется В-деревом порядка т, где т – количество записей в блоке
индекса. Такое дерево должно иметь в каждом узле не менее т / 2 зависимых узлов и все листья
должны располагаться на одном уровне.
Для осуществления последовательного поиска блоки первого уровня могут быть связаны в
цепь по возрастанию значения ключа. Поиск в В-дереве выполняется так же, как и в неплотном
индексе. Удачный и неудачный поиск записи в В-дереве требует h обменов, где h – число
уровней В-дерева.
При поиске по интервалу значений а ≤ К ≤ b вначале выполняется поиск по К = а в В-дереве,
а затем – последовательный поиск по условию К ≤ b в блоках 1-го уровня В-дерева.
7.3.5. Плотный индекс
Пусть по каким-либо причинам невозможно упорядочить основной файл F по ключу К.
Построим дополнительный файл FD по правилу [17]:
1) записи файла FD имеют формат FD(K, Р), где К – поле, принимающее значение ключа
записи основного файла F; Р – указатель на эту запись;
2) записи файла FD упорядочены по полю К.
Полученный файл называется плотным индексом. Он строится почти так же, как и
неплотный индекс. Различие заключается в том, что для каждого значения ключа К в файле FD
имеется отдельная запись, а в неполном индексе - только для значения ключа первой записи
блока.
Пример плотного индекса представлен на рис. 3.11. Над плотным индексом можно также
построить В-дерево.
Рис. 3.11. Пример плотного индекса
3.3.6. Инвертированный файл
В рассмотренных выше способах индексирования данных расчет делался на поиск по
значению ключевого поля. Но часто требуется осуществить выборку данных по значениям
неключевых полей. В этом случае неключевые поля также должны быть проиндексированы
(т.е. для каждого из них строится особый индекс). Индексы, построенные для неключевых
полей используются при организации многоаспектного поиска. Широко распространены на
практике методы многоаспектного поиска по инвертированным файлам. Пусть имеется
70
основной файл F, упорядоченный либо неупорядоченный по значениям вторичного ключа Кi.
Строится дополнительный файл FDi по правилу [17]:
1) записи файла FDi имеют формат FDi(Ki, P) где Ki – поле, принимающее значение
вторичного ключа Кi записи основного файла; Р – указатели на записи основного файла F,
имеющие данное значение вторичного ключа Кi;
2) записи файла FDi упорядочены по полю Ki.
Построенный дополнительный файл FD. Называется инвертированным. В этом случае об
основном файле F говорят, что он инвертирован по полю Кi. Количество записей в
инвертированном файле FDi определяется количеством значений вторичного ключа Кi в
записях основного файла F. Пример инвертированного файла по полю К2 для основного файла
F приведен на рис. 3.12. Рассмотренный способ организации инвертированного файла
предполагает использование записей переменной длины. Инвертированный файл можно
организовать и с помощью записей фиксированной длины, если в каждой записи
инвертированного файла выделять фиксированное число полей для указателей Р. Если
фиксированного числа поле для некоторых записей окажется недостаточно, то организуется
еще дополнительный служебный файл для хранения неуместившихся цепочек указателей.
Рис. 3.12. Пример инвертированного файла
Поскольку записи инвертированного файла упорядочены по значению ключа Ki, то для
поиска записей можно использовать любой из рассмотренных выше методов поиска в
упорядоченном файле (например, бинарный поиск или В-дерево). Чтобы выполнить
многоаспектный поиск по n ключам, необходимо построить п инвертированных файлов [17].
71
8. ВНУТРЕННИЙ ЯЗЫК СУБД (ЛЕКЦИИ 12-13)
Для работы с данными в СУБД предусмотрен внутренний язык, состоящий из двух частей:
языка определения данных (Data Definition Language – DDL) и языка манипулирования данными
(Data Manipulation Language – DML).
Эти языки еще называются подъязыками данных, т.к. в них отсутствуют конструкции для
выполнения всех вычислительных операций, обычно используемых в языках
программирования высокого уровня. Во многих СУБД предусмотрена возможность внедрения
операторов подъязыка данных в программы на языках высокого уровня. В этом случае язык
высокого уровня принято называть базовым или включающим языком.
Язык определения данных (ЯОД, DDL) - формальный закон, используемый в некоторой
модели данных для определения структуры, баз данных [12].
Результат компиляции операторов ЯОД – набор таблиц» хранимых в особых файлах,
называемых словарями данных или системными каталогами.
Посредством ЯОД обычно определяются подразделения данных, типовые структуры и
правила их композиции, присваиваются имена данным, определяются типы элементов данных
посредством задания присущих им свойств, учреждаются ключи базы данных, а также
определяются отношения между данными, упорядоченность данных внутри их совокупностей,
правила проверки достоверности данных и замки защиты от неправомочного использования их.
Обычно в ЯОД не определяются техника запоминания или поиска данных на физических
носителях и другие особенности их физической организации, что обусловлено одной из
основных концепций базы данных – независимостью логической структуры данных от
физических особенностей их хранения.
ЯОД обычно полностью независим от языка манипулирования данными. Следовательно,
определение данных в базах данных независимо от программ обработки, что является второй
важной концепцией использования баз данных.
Язык манипулирования данными (ЯМД, DML) – совокупность языковых средств для
организации доступа к данным в некоторой модели данных и в соответствующих ей СУБД [12].
Может выступать в роли языка запросов, прямо обеспечивающего информационное
обслуживание пользователей баз данных, или быть расширением некоторого языка
программирования, называемого базовым (включающим) языком, с конструкциями и
понятиями которого ЯМД должен быть согласован. Операторы ЯМД позволяют извлекать
данные из баз данных, создавать или модифицировать последние.
К основным операциям манипулирования данными относятся:
 вставка в БД новых сведений;
 модификация сведений, хранимых в БД;
 извлечение сведений, содержащихся в БД;
 удаление сведений на БД.
ЯМД отличаются базовыми конструкциями манипулирования данными. Отличают два их
типа:
а) процедурные ЯМД;
б) непроцедурные (декларативные) ЯМД.
С помощью, процедурного языка пользователь (программист) указывает на то, кол; можно
получить необходимые данные из определенного набора данных. Т.е. пользователь должен
определить все операции доступа К данным, чтобы получить результат. При этом
предполагается знание пользователем деталей внутренней , организации структур данных в БД.
С помощью непроцедурных языков пользователь указывает какие данные ему нужны, без
определения способа их получения. Данный подход освобождает пользователя от
необходимости знать подробности внутренней организации БД. Работа пользователя обретает
некоторую независимость от данных.
В общем случае язык запросов – часть ЯМД, высокоуровневый узкоспециализированный
язык, предназначенный для удовлетворения различных требований по выборке данных из БД.
72
8.1. Теоретические языки запросов
Для получения информации из отношений необходим язык манипулирования данными,
способный выполнять соответствующие операции над отношениями. Наиболее важной частью
ЯМД является его раздел для формулировки запросов. Поскольку запросы в общем случае
представляют собой произвольные функции над отношениями, необходимо решить вопрос о
требуемой выразительности языка запросов. Для исследования этого вопроса были разработаны
три типа теоретических языков [2, 17]:
1) реляционная алгебра;
2) реляционное исчисление с переменными-кортежами;
3) реляционное исчисление с переменными-доменами.
Языки запросов первого типа – алгебраические языки – позволяют выражать запросы
средствами специализированных операторов, применяемых к отношениям.
Языки запросов второго и третьего типов – языки исчисления – позволяют выражать запросы
путем спецификации предиката, которому должны удовлетворять требуемые кортежи или
домены.
Теоретические языки служат эталоном для оценки существующих реальных языков запросов
[17]. Они были предложены Коддом для представления минимальных возможностей любого
разумного языка запросов для реляционной модели данных. По своей выразительности все три
языка оказались эквивалентными между собой.
8.1.1. Реляционная алгебра
В этом разделе на ряде примеров рассматриваются операции реляционной алгебры [11]. Для
представления каждой операции будем использовать терминологию как алгебры, так и
исчисления. Последняя базируется на системе понятий, использованной Коддом. Пять
операций являются основными:
 проекция;
 объединение;
 разность;
 декартово произведение;
 селекция.
Другие часто используемые операции пересечения, соединения и деления можно выразить
через пять основных операций. Ниже представлены отношения, используемые в примерах [11].
Описание каждого отношения состоит из имени отношения, за которым в круглых скобках
следует список атрибутов (это описание называется интенсивналом или схемой отношения).
Под описанием приведено некоторое заполнение кортежей отношения (экстенсионал
отношения). В последующих примерах буквы R и S используются для обозначения отношений,
а буквы А и В – для обозначения списка атрибутов (для простоты можно считать, что список
состоит из единственного атрибута).
73
Операция проекции представляет собой выборку из каждого кортежа отношения значений
атрибутов, входящих в А, и удаление из полученного отношения повторяющихся строк. В
исчислении t обозначает «кортежную» переменную, значениями которой являются кортежи
исходного отношения R, a t[A] – часть кортежа R с атрибутами из А. В соответствии с
определением отношения неявно предполагается удаление дубликатов кортежей
результирующего отношения.
Пример
Объединение
Для того чтобы объединение было возможным, отношения-операнды (R и S) должны быть
совместимы по объединению, т.е. их атрибуты должны быть определены над совместимыми
доменами.
Пример
Пример
Декартово произведение
74
Из обозначений видно, что операция декартова произведения осуществляется между
кортежами отношений-аргументов, а результатом является конкатенация (обозначаемая ||)
соответствующих кортежей. При этом
Отсюда следует, что результирующее отношение может иметь очень большие размеры. (На
практике используется ограниченный вариант этой операции, называемый соединением.) Пусть
Тогда
Степень результирующего отношения равна 4 (22), а мощность – 8 (24).
Селекция (Ограничение)
В приведенном определении υ обозначает константу, а В – атрибут отношения R, отличный
от А. Символ 6 используется для обозначения одной из операций сравнения (<, ≤, =, ≠, ≥, >).
Примеры
P[D1>D2]= (пустое множество) поскольку в отношении отсутствуют кортежи, где D1 > D2.
Пересечение
75
Пересечение RS=R-(R-S), что соответствует области, отмеченной звездочкой на диаграмме
Венна для операции разности.
Пример
Соединение
Алгебра
R[AθB]S
Исчисление
{(r||s)| rRsS(r[А]θs[В])}
Как видно из определения, операция соединения имеет сходство с декартовым
произведением. Однако здесь добавлено условие, согласно которому вместо полного
произведения всех строк в результирующее отношение включаются только строки,
удовлетворяющие определенному соотношению между атрибутами соединения (А, В)
соответствующих отношений. Имеется несколько вариантов операции соединения:
a) тета- и эквисоединение. При этой операции А и В являются совместимыми атрибутами
соединения, а степень результирующего отношения равна сумме степеней отношенийоперандов. Такое соединение называется θ-соединением (тета-соединением). В случае
сравнения на равенство соединение называется экви-соединением;
б) естественное соединение. В этом случае атрибуты соединения имеют общие
(одинаковые) домены, и после соединения один из атрибутов отбрасывается. Степень
результирующего отношения на единицу меньше суммы степеней отношений-операндов;
в) композиция. Это соединение отличается от естественного тем, что из результирующего
отношения удаляются оба атрибута соединения. Поэтому степень результирующего отношения
на две единицы меньше суммы степеней отношений-операндов.
Примеры
Тета-соединение R[Q > A]S
При выполнении соединения необходимо для каждого кортежа из R взять значение атрибута
Q и сравнить его со значением атрибута A из каждого кортежа S. В результате получим
Следует отметить, что кортеж < ω 50 1 b > отношения R не вошел в результирующее
отношение.
Естественное соединение P[D3 = D4]Q
76
Деление
Атрибуты А и В являются совместимыми и/или общими атрибутами деления. Для упрощения
объяснения можно считать R бинарным отношением, состоящим из А и дополнения А, которое
обозначается A и содержит атрибуты, отличные от А. Для каждого раздела из R[ A ], т.е. для
каждого уникального кортежа r[ A ], необходимо выполнить следующее:
 выбрать допустимые строки кортежей r[ A ] из R[ A ], обозначив полученное множество
кортежей через T = gR(r[ A ]). Множество Т называется также множеством-образом;
 в результирующее отношение входят кортежи r, для которых выполняется S[B]HgR(r[ A ]).
Примеры
P[D3÷D4]Q= (пустое множество), так как
Следовательно, подходящие р[ D 3 ] отсутствуют.
8.1.2. Реляционное исчисление кортежей
В выражениях реляционной алгебры всегда явно задается некий порядок выполнения
запроса. В реляционном же исчислении указывается что необходимо извлечь, а не как.
Реляционное исчисление никак не связано с дифференциальным и интегральным
исчислениями в математике, а его название произошло от части символьной логики, которая
называется логикой предикатов.
В логике первого порядка или теории исчисления предикатов под предикатом
подразумевается истинностная функция с аргументами. При подстановке вместо аргументов
значений, функция становится выражением, называемым суждением, которое может быть
истинным или ложным. Например, предложения «студент Шепелявцев учится на третьем курсе
вуза» и «средний балл успеваемости студента Шепелявцева выше, чем у студента Мамаева»
являются суждениями, поскольку можно определить их истинность или ложность. В первом
77
случае функция «учится на третьем курсе вуза» имеет один аргумент («студент Шепелявцев»),
а во втором случае функция «средний балл выше» имеет два аргумента («студент Шепелявцев»
и «студент Мамаев»).
Если предикат содержит переменную, например в виде «ж учится на третьем курсе вуза», то
у этой переменной должна быть область определения. При подстановке вместо переменной х
одних значений из ее области определения данное суждение может оказаться истинным, а при
подстановке других – ложным.
Если Р – предикат, то множество всех значений переменной х, при которых суждение Р
становится истинным, можно символически записать следующим образом:
Предикаты могут соединяться с помощью логических операторов , , , с образованием
составных предикатов.
В реляционном исчислении кортежей задача состоит в нахождении таких кортежей, для
которых предикат является истинным.
Выражение реляционного исчисления с переменными-кортежами записывается в виде [17]
где t – свободная переменная-кортеж, обозначающая кортеж фиксированной длины (если
необходимо указать арность кортежа, то используют запись t(i); i – арность кортежа t); φ –
некоторая формула, построенная по специальным правилам.
Например, выражение {t R1(t)R2(t)}, где в качестве формулы выступает конструкция
R1(t)R2(t), означает, что необходимо получить множество всех кортежей t, причем таких
кортежей, которые принадлежат отношениям R1 или R2. Формула (R1(t)R2(t)) имеет смысл
только тогда, когда отношения R1 и R2 имеют одинаковую арность, поскольку переменнаякортеж t задана как переменная фиксированной длины. Выражение {t R1(t)R2(t)}
эквивалентно операции объединения (R1  RJ реляционной алгебры.
Формулы в реляционном исчислении строятся из атомов и совокупности арифметических и
логических операторов.
Атомы формул могут быть трех типов [17]:
1) R(t), где R - имя отношения. Этот атом означает, что t – это кортеж в отношении R;
2) s[i]θu[j], где s и и - переменные-кортежи; θ - арифметический оператор (<, >, =, ≤, ≥, ≠); i, j
- номера или имена необходимых компонентов (столбцов) в соответствующих кортежах;
s[i] – i-тый компонент в кортеже-переменной s; u[j] – j-тый компонент в кортежепеременной и. Например, атом (s[3]≥u[5]) означает, что третий компонент переменной s
больше или равен пятому компоненту переменной и;
3) s[i]θa или aθs[i], где а – константа. Например, атом (s[4]=70), означает, что четвертая
компонента переменной-кортежа s равна 70.
При записи формул используется понятие свободных и связанных переменных-кортежей,
что определяется характером использования в формуле кванторов;  – квантор всеобщности
(общности), читается – все, всякий, каков бы ни был и т.п.;  – квантор существования, читается
– некоторые, хотя бы один существует и т.п.
Вхождение переменной t в формулу φ связано, если в φ оно находится в подформуле,
начинающейся квантором  или , за которым непосредственно следует переменная t и о
котором говорят, что он связывает переменную t. В остальных случаях вхождения переменной t
в формулу φ свободны. Например, в формуле
все вхождения переменной х связаны, первое и последнее вхождения у свободны, остальные
вхождения переменной у связаны, все вхождения переменной z свободны, единственное
вхождение переменной r связано.
78
Кванторы в реляционном исчислении играют ту же роль, что декларации в языке
программирования. Понятие свободной переменной аналогично понятию глобальной
переменной, описанной вне текущей процедуры. Понятие связанной переменной аналогично
понятию локальной переменной, описанной в текущей процедуре.
Аналогично тому, как не все возможные комбинации букв алфавита образуют правильные
слова, так и в реляционном исчислении не каждая последовательность формул является
допустимой. Допустимыми формулами могут быть только недвусмысленные и
небессмысленные последовательности.
Правильно построенные формулы определяются рекурсивно следующим образом [11, 17].
1. Каждый атом – это формула. Все вхождения переменных-кортежей, упомянутые в атоме,
являются свободными.
2. Если φ1 и φ2 – формулы, то выражения φ1φ2 (утверждает, что φ1 и φ2 истинны), φ1φ2
(утверждает, что φ1 или φ2, или обе истинны), φ1 (утверждает, что φ1 не истинна), также
являются формулами.
Экземпляры переменных-кортежей – свободные или связанные в формулах (φ1φ2), (φ1φ2) и
(φ1) так же, как и в φ1 и φ2. Таким образом, свободными (связанными) являются те и только те
вхождения переменных, которые происходят от свободных (связанных) вхождений переменных
φ1 и φ2. Некоторое вхождение переменной может быть связанным в φ1, например, в то время как
другое – свободным в φ2 и т.п.
3. Если φ – формула, то (s)(φ) – также формула. Свободные вхождения переменной s в
формуле φ становятся связанными квантором (s) в формуле (s)(φ). Формула (s)(φ)
утверждает, что при подстановке любого кортежа подходящей арности вместо свободных
вхождений s формула становится истинной.
4. Если φ – формула, то (s)(φ) – также формула. Свободные вхождения переменной s в
формуле φ также становятся связанными квантором (s) в формуле (s)(φ). Формула (s)(φ)
утверждает, что существует значение s, при подстановке которого вместо всех свободных
вхождений s в формулу φ эта формула становится истинной.
Например, формула (s)(R(s)) означает, что отношение не пусто, т.е. существует некоторый
кортеж s, принадлежащий R.
5. Формулы могут при необходимости заключаться в скобки. Используется следующий
порядок старшинства:
 арифметические операторы сравнения;
 кванторы  и ;
 , , .
6. Ничто иное не является формулой.
В качестве примера можно записать выражение реляционного исчисления на переменныхкортежах, соответствующее операции проекции в реляционной алгебре:
Введем ограничения на конечность реальных отношений в БД, чтобы исключить
возможность формирования выражений типа {t-R(t)}, не имеющих смысла. Это выражение
обозначает все возможные, не принадлежащие R кортежи, арность которых согласуется с t.
С этой целью в реляционном исчислении рассматривают только безопасные выражения {t
φ(t)}, для которых выполняется условие, что каждый компонент (элемент столбца) любого
кортежа t, удовлетворяющего φ(t) является элементом некоторого множества элементов D(φ).
Множество D(φ) определяется как функция фактических отношений, которые указываются в
φ(t), и констант, присутствующих в формуле φ(t) и элементов кортежей тех отношений,
которые указаны в φ(t). Так как все отношения в БД предполагаются конечными, то и
множество D(φ) – конечно:
79
где a1.φ, а2.φ, ..., ап.φ – константы, встретившиеся в формуле φ(t); π1(R1), …, πk(Rn) – проекции
кортежей фактических отношений R1, ..., Rn, встретившихся в формуле φ(t) (в данном случае –
компоненты кортежей).
При таком определении множества D(φ) справедливо следующее:
Например, если задано выражение {tcR(t)}, где R – бинарное отношение, то
Реляционное исчисление является безопасным, если выполнятся следующие условия:
1) из истинности φ(t) следует, что каждый компонент кортежа t принадлежит D(φ);
2) для любой подформулы вида (u)(φ1(u)), входящей в состав ф, из истинности φ1(и) следует,
что и принадлежит D(φ1);
3) для любой подформулы вида (u)(φ1(u)), входящей в состав φ, из истинности φ1(u) следует,
что и не принадлежит D(φ1), или же, что то же самое, из истинности φ1(u) следует, что и
принадлежит D(φ1).
При выполнении этих условий выражение {t|φ(t)} является безопасным. Выражению
(u)(φ1(u)) эквивалентно выражение (u)(φ1(u)).
На основании вышеизложенного можно утверждать, что если формула φ(t) такова, что любая
ее подформула вида (u)(φ1(t)) или (u)(φj(t)) безопасна, то безопасно каждое выражение вида
{tR(t)φ(t)}. Действительно, любой кортеж, удовлетворяющий формуле (R(t)φ(t)),
принадлежит в соответствии с этой формулой отношению R, Следовательно, каждый из его
компонентов будет принадлежать также и множеству элементов D(R(t)φ(t)). Тогда в силу
выполнения условия 1 (выполнение условий 2 и 3 задано как исходная предпосылка)
выражение {t|R(t)φ(t)} – безопасное. Если в φ(t) найдется хотя бы одна из подформул вида
(u)(φi(t)) или (u)(φj(t)), которая окажется не безопасной, то тогда и выражение {t|R(t)φ(t)} не
будет безопасным. Если в формуле φ(t) вообще отсутствуют подформулы вида (u)(φi(t)) или
(u)(φj(t)) – или соответствующие им эквивалентные -(u)(φi(t)) или (u)(φj(t)), – то
выражение (t|R(t)φ(t)} всегда является безопасным.
Например, если φ(t) = R2(t), то получим безопасное выражение {tR1(t)R2(t)},
соответствующее операции разности отношений в реляционной алгебре (R1 – R2).
Безопасным является также выражение {t|R(t)}, соответствующее выражению R (точнее –
переменной R, обозначающей отношение).
В реляционном исчислении на переменных-кортежах доказана теорема, устанавливающая
эквивалентность безопасных выражений в исчислении операциям реляционной алгебры.
Теорема 4.1. Если Е – выражение реляционной алгебры, то существует эквивалентное
ему безопасное выражение в реляционном исчислении с переменными-кортежами [17].
Для основных операций реляционной алгебры укажем следующие соответствующие
выражения реляционного исчисления на переменных-кортежах.
1. Операции объединения (R1  R2) соответствует выражение
2. Операции разности (R1 – R2) соответствует выражение
80
Рассматривается все множество кортежей t, таких, что t принадлежит R1 и не принадлежит
R2.
3. Операции декартова произведения (R1  R2) соответствует выражение
Рассматривается все множество кортежей t арности (k+m), таких, что существует кортеж и,
принадлежащий R1, и существует кортеж υ, принадлежащий R2, причем k первых компонентов
кортежа t образуют компоненты кортежа и, а следующие т компонентов кортежа t образуют
компоненты кортежа υ.
4. Операции проекции соответствует выражение
5. Операции селекции соответствует выражение {tR(t)F'}, где F' – это выражение F, в
котором каждый операнд, обозначающий компонент i, заменен на t[i].
Несмотря на то, что реляционное исчисление является достаточно сложным с точки зрения
освоения и использования, тем не менее, его непроцедурная природа считается весьма
перспективной и это стимулирует поиск других, более простых в употреблении непроцедурных
методов. Подобные исследования привели к появлению двух категорий реальных реляционных
языков:
 языков на основе преобразований;
 графических языков.
Языки на основе преобразований являются классом непроцедурных языков, которые
используют отношения для преобразования исходных данных к требуемому виду. Эти языки
предоставляют простые в употреблении структуры для получения результата. Примером
реального языка на основе преобразований, реализующего реляционное исчисление с
переменными-кортежами, является язык запросов SQL.
8.1.3. Реляционное исчисление доменов
В реляционном исчислении с переменными на доменах используются те же операторы, что и
в реляционном исчислении с переменными-кортежами.
Атомы формул могут быть двух типов [11, 17].
1. R(x1x2...xk), где R – k-арное отношение; хi - константа или переменная на некотором домене.
Атом R(x1x2...xk) указывает, что значения тех xi, которые являются переменными, должны
быть выбраны так, чтобы (x1x2...xk) было кортежем отношения R.
2. xθy, где х и у – константы или переменные на некотором домене, θ – оператор сравнения.
Атом хθу указывает, что х и у представляют собой значения, при которых истинно xθy.
Формулы в реляционном исчислении с переменными на доменах также используют
логические связки , ,  и кванторы (x), (х), где х – переменная на домене. Аналогично
используются понятия свободных и связанных переменных.
Реляционное исчисление с переменными на доменах имеет вид
где φ – формула, обладающая тем свойством, что только ее свободные переменные на доменах
являются различными переменными x1, x2, ..., xk. Например, выражение
имеет место для бинарных отношений R1 и R2 и означает множество кортежей в R1, таких, что
81
ни один из их компонентов не является первым компонентом какого-либо кортежа отношения
R2.
С целью учета ограничения – конечности реальных отношений – аналогично вводятся
безопасные выражения.
Реляционное исчисление с переменными на доменах называется безопасным, если
выполняются следующие условия:
1) из истинности φ(х1, х2, ..., xk) следует, что xi принадлежит D(φ);
2) если (u)(φ1(u)) является подформулой φ, то из истинности φ1(u), следует, что и
принадлежит D(φ);
3) если (u)(φ1(u)) является подформулой φ, то из истинности φ1(u), следует, что и не
принадлежит D(φ).
Выражение исчисления с переменными на доменах, эквивалентное заданному выражению
исчисления с переменными-кортежами {t |φ(t)}, строится следующим образом:
1) если t является кортежем арности k, то вводится k новых переменных на доменах t1, t2, ..., tk;
2) атомы R(t) заменяются атомами R(t1, t2, ..., tk);
3) каждое свободное вхождение t[i] заменяется на ti;
4) для каждого квантора (u) или (u) вводится т новых переменных на доменах u1, и2, ..., ит,
где т – арность кортежа и. В области действия этой кванти-фикации выполняются замены:
5) выполняется построение выражения
где φ’ – это φ, в которой выполнены соответствующие замены.
Например, {t R1(t)R2(t)} перепишется так:
В реляционном исчислении с переменными на доменах существуют следующие две теоремы.
Теорема 4.2. Для каждого безопасного выражения реляционного исчисления с
переменными-кортежами
существует
эквивалентное
безопасное
выражение
реляционного исчисления с переменными на доменах [17].
Теорема 4.3. Для каждого безопасного выражения реляционного исчисления с
переменными на доменах существует эквивалентное ему выражение реляционной
алгебры [17].
Примером реального языка запросов, реализующего реляционное исчисление с
переменными на доменах, является QBE. Это графический язык, предоставляющий
пользователю графическое отображение структуры отношения. Пользователь создает некий
образец желаемого результата, а система возвращает затребованные данные в указанном
формате.
8.1.4. Сравнение теоретических языков
Рассмотренные выше три абстрактных языка запросов служат основой реальных языков
манипулирования данными реляционных систем.
Каждый из трех рассмотренных языков эквивалентен по своей выразительности двум
82
другим. Однако языки исчисления – это непроцедурные языки, поскольку их средствами можно
выразить все, что необходимо и не обязательно указывать, как это получить (выражение в
исчислении описывает лишь свойства желаемого результата, фактически не указывая, как его
получить). Выражение реляционной алгебры, напротив, специфицируют конкретный порядок
выполнения операций.
В первом случае определение наиболее эффективного порядка вычисления для реализации
запроса пользователя выполняется транслятором или интерпретатором. Во втором случае
пользователь обычно сам должен выполнить оптимизацию своего запроса при его
формулировке. Однако, например, в соответствии с теоремой 1 транслятор на первом шаге
трансляции запроса может выполнить преобразование алгебраического выражения в
эквивалентное выражение исчисления и далее определить эффективный порядок вычислений
[7, 17].
В общем случае языки манипулирования данными выходят за рамки теоретических языков,
поскольку для обработки данных требуются операции, выходящие за рамки возможностей
реляционного исчисления. Это прежде всего следующие команды: включить данные;
модифицировать данные; удалить данные. Кроме этих операций обычно представляются
следующие дополнительные возможности:
 арифметические вычисления и сравнения могут включаться в формулы селекции
реляционных алгебраических выражений или в атомы в выражениях реляционного
исчисления;
 команды печати;
 агрегатные функции – функции, применяемые к столбцам отношений, в результате
выполнения которых вычисляется одна-единственная величина, например максимальное
или минимальное значение, сумма, среднее.
Так как реальные языки могут реализовывать функции, не имеющие аналогов ни в
реляционной алгебре, ни в реляционном исчислении, то в действительности они являются более
чем полными. Причем, полным считается язык, в котором реализуются все возможности
реляционного исчисления или реляционной алгебры.
Перспективной категорией языков запросов являются языки четвертого поколения (4generation languages – 4GL), которые позволяют создавать полностью готовое и
соответствующее требованиям заказчика прикладное приложение с помощью ограниченного
набора команд и в то же время предоставляют дружественную по отношению к пользователю
среду разработки, чаще всего построенную на использовании команд меню. В некоторых
системах даже используются некоторые разновидности естественного языка, т.е. ограниченной
версии обычного английского языка, который иногда называется языком пятого поколения
(5GL) [7].
8.2. Определение реляционной полноты
Пусть реляционная база данных содержит множество отношений R{R1, R2, ..., Rn}, а
множество C(R) представляет собой множество отношений, полученных из R с помощью
операций реляционной алгебры. Множество C(R) отражает все связи, имеющиеся в базе
данных. Говорят, что язык обладает реляционной полнотой, если он может охватить все связи,
представленные C(R). Это означает, что язык имеет такую же выразительную мощность, как
реляционная алгебра и реляционное исчисление [11].
Для обеспечения реляционной полноты при реализации языка необходимы две следующие
операции [11]:
1) операция присваивания, т.е. возможность создавать новые отношения для хранения
результатов операций реляционной алгебры, являющихся также отношениями. R1R2*R3
означает, что результат соединения отношений R2 и R3 помещается во вновь созданное
отношение R1;
2) операция транзитивного замыкания, допускающая рекурсию или вложенность операций
реляционной алгебры для построения выражений произвольной сложности. Например,
выражение
83
содержит вложенные выражения и присваивание, необходимые для получения результата.
8.3. Введение в язык SQL
8.3.1. Краткая история языка SQL
Язык SQL, предназначенный для взаимодействия с базами данных, появился в середине
70-х гг. (первые публикации датируются 1974 г.) и был разработан в компании IBM в рамках
проекта экспериментальной реляционной СУБД System R. Исходное название языка SEQUEL
(Structured English Query Language) только частично отражало суть этого языка. Конечно, язык
был ориентирован главным образом на удобную и понятную пользователям формулировку
запросов к реляционным БД. Но, в действительности, он почти с самого начала являлся полным
языком БД, обеспечивающим помимо средств формулирования запросов и манипулирования
БД следующие возможности:
• средства определения и манипулирования схемой БД;
• средства определения ограничений целостности и триггеров;
• средства определения представлений БД;
• средства определения структур физического уровня, поддерживающих эффективное
выполнение запросов;
• средства авторизации доступа к отношениям и их полям;
• средства определения точек сохранения транзакции и выполнения фиксации и откатов
транзакций.
В языке отсутствовали средства явной синхронизации доступа к объектам БД со стороны
параллельно выполняемых транзакций: с самого начала предполагалось, что необходимую
синхронизацию неявно выполняет СУБД.
В настоящее время язык SQL реализован во всех коммерческих реляционных СУБД и
почти во всех СУБД, которые изначально основывались не на реляционном подходе. Все
компании-производители провозглашают соответствие своей реализации стандарту SQL, и на
самом деле реализованные диалекты SQL очень близки. Этого удалось добиться не сразу.
Наиболее близки к System R были две системы компании IBM – SQL/DS и DB2.
Разработчики обеих систем использовали опыт проекта System R, а СУБД SQL/DS напрямую
основывалась на программном коде System R. Отсюда предельная близость диалектов SQL,
реализованных в этих системах, к SQL System R. Из SQL System R были удалены только те
части, которые были недостаточно проработаны (например, точки сохранения) или реализация
которых вызывала слишком большие технические трудности (например, ограничения
целостности и триггеры). Можно назвать этот путь к коммерческой реализации SQL движением
сверху вниз.
Другой подход применялся в таких системах, как Oracle, Informix и Sybase. Несмотря на
различие в способах разработки систем, реализация SQL везде происходила «снизу вверх». В
первых выпущенных на рынок версиях этих систем использовалось ограниченное
подмножество SQL System R. В частности, в первой известной нам реализации SQL в СУБД
Oracle в операторах выборки не допускалось использование вложенных подзапросов и
отсутствовала возможность формулировки запросов с соединениями нескольких отношений.
Тем не менее, несмотря на эти ограничения и на очень слабую, на первых порах,
эффективность СУБД, ориентация компаний на поддержку разных аппаратных платформ и
заинтересованность пользователей в переходе к реляционным системам позволили компаниям
добиться коммерческого успеха и приступить к совершенствованию своих реализаций. В
текущих версиях Oracle, Informix, Sybase и Microsoft SQL Server поддерживаются достаточно
мощные диалекты SQL, хотя реализация иногда вызывает сомнения.
Особенностью большинства современных коммерческих СУБД, затрудняющей
сравнение существующих диалектов SQL, является отсутствие единообразного описания языка.
84
Обычно описание разбросано по разным руководствам и перемешано с описанием
специфических для данной системы языковых средств, не имеющих прямого отношения к SQL.
Тем не менее, можно сказать, что базовый набор операторов SQL, включающий операторы
определения схемы БД, выборки и манипулирования данными, авторизации доступа к данным,
поддержки встраивания SQL в языки программирования и операторы динамического SQL, в
коммерческих реализациях устоялся и более или менее соответствует стандарт
Деятельность по стандартизации языка SQL началась практически одновременно с
появлением его первых коммерческих реализаций. В 1982 г. комитету по базам данных
Американского национального института стандартов (ANSI) было поручено разработать
спецификацию стандартного языка реляционных баз данных. Первый документ из числа
имеющихся у автора проектов стандарта датирован октябрем 1985 г. и является уже не первым
проектом стандарта ANSI. Стандарт был принят ANSI в 1986 г., а в 1987 г. одобрен
Международной организацией по стандартизации (ISO). Этот стандарт принято называть
SQL/86.
Понятно, что в качестве основы стандарта нельзя было использовать SQL System R. Вопервых, этот вариант языка не был должным образом технически проработан. Во-вторых, его
слишком сложно было бы реализовать (кто знает, как бы сложилась судьба SQL, если бы все
идеи проекта System R были реализованы полностью). Поэтому за основу был взят диалект
языка SQL, сложившийся в IBM к началу 1980-х гг. В сущности, этот диалект представлял
собой технически проработанное подмножество SQL System R.
К 1989 г. стандарт SQL/86 был несколько расширен, и был подготовлен и принят
следующий стандарт, получивший название ANSI/ISO SQL/89. Анализ доступных документов
показывает, что процесс стандартизации SQL происходил очень сложно с использованием не
только научных доводов. В результате SQL/89 во многих частях имеет чрезвычайно общий
характер и допускает очень широкое толкование. В этом стандарте полностью отсутствуют
такие важные разделы, как манипулирование схемой БД и динамический SQL. Многие важные
аспекты языка в соответствии со стандартом определяются в реализации.
Возможно, наиболее важными достижениями стандарта SQL/89 являются четкая
стандартизация синтаксиса и семантики операторов выборки данных и манипулирования
данными и фиксация средств ограничения целостности БД. Были специфицированы средства
определения первичного и внешних ключей отношений и так называемых проверочных
ограничений целостности, которые представляют собой подмножество немедленно
проверяемых ограничений целостности SQL System R. Средства определения внешних ключей
позволяют легко формулировать требования так называемой ссылочной целостности БД. Это
распространенное в реляционных БД требование можно было сформулировать и на основе
общего механизма ограничений целостности SQL System R, но формулировка на основе
понятия внешнего ключа более проста и понятна.
Осознавая неполноту стандарта SQL, на фоне завершения разработки этого стандарта
специалисты различных компаний начали работу над стандартом SQL2. Эта работа также
длилась несколько лет, было выпушено множество проектов стандарта, пока наконец в марте
1992 г. не был принят окончательный проект стандарта (SQL/92). Этот стандарт существенно
полнее стандарта SQL/89 и охватывает практически все аспекты, необходимые для реализации
приложений: манипулирование схемой БД, управление транзакциями (появились точки
сохранения) и сессиями (сессия – это последовательность транзакций, в пределах которой
сохраняются временные отношения), подключения к БД, динамический SQL. Наконец, были
стандартизованы отношения-каталоги БД, что вообще-то не связано непосредственно с языком,
но очень сильно влияет на реализацию.
В 1995 г. стандарт был дополнен спецификацией интерфейса уровня вызова (Call-Level
Interface – SQL/CLI). SQL/CLI представляет собой набор спецификаций интерфейсов процедур,
вызовы которых позволяют выполнять динамически задаваемые операторы SQL. По сути дела,
SQL/CLI представляет собой альтернативу динамическому SQL. Интерфейсы процедур
определены для всех основных языков программирования: С, Ada, Pascal, PL/1 и т. д. Следует
заметить, что стандарт SQL/CLI послужил основой для создания повсеместно
85
распространенных сегодня интерфейсов ODBC (Open Database Connectivity) и JDBC (Java
Database Connectivity).
В 1996 г. к стандарту SQL/92 был добавлен еще один компонент — SQL/PSM (Persistent
Stored Modules). Основная цель этой спецификации состоит в том, чтобы стандартизировать
способы определения и использования хранимых процедур, т. е. специальным образом
оформленных программ, включающих операторы SQL, которые сохраняются в базе данных,
могут вызываться приложениями и выполняются внутри СУБД.
Незадолго до завершения работ по определению стандарта SQL2 была начата разработка
стандарта SQL3. Первоначально планировалось завершить проект в 1995 г. и включить в язык
некоторые объектные возможности: определяемые пользователями типы данных, поддержку
триггеров, поддержку темпоральных свойств данных и т. д. Реально работу над новым стандартом удалось частично завершить только в 1999 г., и по этой причине (а также в связи с
проблемой 2000 года) стандарт получил название SQL: 1999.
Приведем краткую характеристику текущего состояния стандарта SQL: 1999 и
перспектив его развития. Прежде всего, заметим, что каждый новый вариант стандарта языка
SQL был существенно объемнее предыдущих версий. Так, если стандарт SQL/89 занимал около
600 страниц, то объем SQL/92 составлял на 300 с лишним страниц больше. Самые первые
проекты SQL3 занимали около 1500 страниц. Это вполне естественно, потому что язык
усложняется, а его спецификации становятся более детальными и точными. Но разработчики
SQL3 пришли к выводу, что при таких объемах стандарта вероятность его принятия и
последующей успешной поддержки заметно уменьшается. Поэтому было принято решение разбить стандарт на относительно независимые части, которые можно было бы разрабатывать и
поддерживать по отдельности.
В 1999 г. были приняты пять первых частей стандарта SQL: 1999. Первая часть
(SQL/Framework) посвящена описанию концептуальной структуры стандарта. В этой части
приводится развернутая аннотация следующих четырех частей и формулируются требования к
реализациям, претендующим на соответствие стандарту.
Вторая часть SQL: 1999 (SQL/Foundation) образует базис стандарта. Вводится система
типов языка, формулируются правила определения функциональных зависимостей и
возможных ключей, определяются синтаксис и семантика основных операторов SQL:
• операторов определения и манипулирования схемой базы данных;
• операторов манипулирования данными;
• операторов управления транзакциями;
• операторов управления подключениями к базе данных и т. д.
Третью часть занимает уточненная по сравнению с SQL/92 спецификация SQL/CLL В
четвертой части специфицируется SQL/PSM — синтаксис и семантика языка определения
хранимых процедур. Наконец, в пятой части - SQL/Bindings - определяются правила связывания
SQL для стандартных версий языков программирования FORTRAN, COBOL, PL/1, Pascal, Ada,
С и MUMPS.
В стандарт SQL: 1999 должны были войти еще несколько частей. Среди них
спецификации следующих средств:
• управление распределенными транзакциями (SQL/Transaction);
• поддержка темпоральных свойств данных (SQL/Temporal);
• управление внешними данными (SQL/MED);
• связывание с объектно-ориентированными языками программирования (SQL/OLB);
• поддержка оперативной аналитической обработки (SQL/OLAP).
В конце 2003 г. был принят и опубликован новый вариант международного стандарта
SQL:2003. Многие специалисты считали, что в варианте стандарта, следующем за SQL: 1999,
будут всего лишь исправлены неточности SQL: 1999- Но на самом деле, в SQL:2003
специфицирован ряд новых и важных свойств, часть из которых мы затронем в этом курсе.
Претерпела некоторые изменения общая организация стандарта. Стандарт SQL:2003 состоит из
следующих частей:
• 9075-1, SQL/Framework;
• 9075-2, SQL/Foundation;
86
•
•
•
•
•
•
•
9075-3, SQL/CLI;
9075-4, SQL/PSM;
9075-9, SQL/MED;
9075-10, SQL/OLB;
9075-11, SQL/Schemata;
9075-13, SQL/JRT;
9075-14, SQL/XML.
Части 1-4 и 9-10 с необходимыми изменениями остались такими же, как и в SQL: 1999
(разд. 7.4). Часть 5 (SQL/Bindings) перестала существовать; соответствующие спецификации
включены в часть 2. Раздел части 2 SQL: 1999, посвященный информационной схеме, выделен
в отдельную часть 11. Появились две новые части — 13 и 14. Часть 13 полностью называется
«SQL Routines and Types Using the Java Programming Language» («Использование подпрограмм
и типов SQL в языке программирования Java»). Появление такой части стандарта оправдано
повышенным вниманием к языку Java со стороны ведущих производителей SQLориентированных СУБД. Наконец, последняя часть SQL.2003 посвящена спецификациям
языковых средств, позволяющих работать с XML-документами в среде SQL.
На мой взгляд, текущее состояние процесса стандартизации языка SQL отражает
текущее состояние технологии SQL-ориентированных баз данных. Ведущие поставщики
соответствующих СУБД (сегодня это компании IBM, Oracle и Microsoft) стараются
максимально быстро реагировать на потребности и конъюнктуру рынка и расширяют свои
продукты все новыми и новыми возможностями. Очевидна потребность в стандартизации
соответствующих языковых средств, но процесс стандартизации явно не поспевает за
происходящими изменениями.
8.3.2. Структура языка SQL
Язык SQL, соответствующий последним стандартам SQL:2003, SQL: 1999 (и даже
SQL/92), – это очень богатый и сложный язык, все возможности которого трудно сразу осознать
и тем более понять. Поэтому приходится разбивать язык на уровни, или слои, такие, что
каждый уровень языка включает все конструкции, входящие в более низкие уровни. В
стандарте определяется несколько способов разбиения языка на уровни. В одной из
классификаций язык разбивается на «базовый» (entry), «промежуточный» (intermediate) и
«полный» (full) уровни.
Эта классификация ориентирована, прежде всего, на производителей СУБД, в которых
поддерживается SQL. Реализация базового уровня языка является обязательным условием хотя
бы какого-то соответствия стандарту. Реализация промежуточного уровня желательна, и
обычно именно такой уровень языка поддерживается ведущими компаниями-производителями
SQL-ориентированных СУБД. Наконец, полный уровень языка является целью, к достижению
которой следует стремиться. В данной классификации критерием отнесения той или иной
возможности языка к некоторому уровню является оцениваемая создателями стандарта SQL
(большая часть которых является сотрудниками ведущих компаний, производящих SQLориентированные СУБД) техническая сложность реализации этой возможности. Конечно, такая
классификация важна и для программистов приложений баз данных, но только для того, чтобы
оценить реальные возможности конкретной СУБД. Для понимания языка SQL это разбиение на
уровни несущественно.
Другая классификация показана на рис. 11.1. Среди всех конструкций языка SQL можно
выделить такие конструкции, которые можно использовать при «прямом» (direct)
взаимодействии конечного пользователя с СУБД (например, в интерактивном режиме). В
некотором смысле этот уровень также является базовым, поскольку соответствующие средства
языка в наибольшей степени отражают его ориентированность на работу с мультимножествами.
На следующем уровне, уровне «встраиваемого» (embedded) SQL, язык расширяется
конструкциями, позволяющими использовать возможности прямого SQL в программах,
написанных на традиционных языках программирования.
87
Наконец, на уровне «динамического» (dynamic) SQL во встраиваемый SQL добавляются
конструкции, позволяющие приложениям обращаться к СУБД с конструкциями прямого SQL,
которые динамически образуются во время выполнения программы.
Нам кажется, что вторая классификация является более полезной для читателя,
постигающего основы языка SQL. По нашему мнению, дополнительные возможности,
присутствующие во встраиваемом и в динамическом SQL, не слишком сильно влияют на
модельное представление языка. Конечно, возможности встраиваемого и динамического SQL
необходимо хорошо знать разработчикам приложений SQL-ориентированных баз данных. Но
поскольку задачей этого курса не является обучение использованию языка SQL при
программировании приложений баз данных, мы не будем затрагивать эти темы. Обратимся к
прямому SQL, причем не в полном объеме стандартов SQL:2003 и SQL: 1999 (этого не позволяет сделать объем курса). Обсудим только наиболее важные аспекты.
8.3.3. Типы данных SQL
Данные, хранящиеся в столбцах таблиц SQL-ориентированной базы данных, являются
типизированными, т.е. представляют собой значения одного из типов данных,
предопределенных в языке SQL или определяемых пользователями путем применения
соответствующих средств языка. Для этого при определении таблицы каждому ее столбцу
назначается некоторый тип данных (или домен), и в дальнейшем СУБД должна следить, чтобы
в каждом столбце каждой строки каждой таблицы присутствовали только допустимые
значения. В этом разделе мы обсудим систему типов языка SQL.
Все допустимые в SQL типы данных, которые можно использовать при определении
столбцов, разбиваются на следующие категории:
• точные числовые типы (exact numerics);
• приближенные числовые типы (approximate numerics);
• типы символьных строк (character strings);
• типы битовых строк (bit strings)*;
• типы даты и времени (datetimes);
• типы временных интервалов (intervals);
• булевский тип (Booleans);
• типы коллекций (collection types);
• анонимные строчные типы (anonymous row types);
• типы, определяемые пользователем (user-defined types);
• ссылочные типы (reference types).
В столбцах таблиц, определенных на любых типах данных, наряду со значениями этих
типов, допускается сохранение неопределенного значения, которое обозначается ключевым
словом NULL. В языке определено, что результатом выражений вида х а_ор NULL, NULL a_op
88
x, NULL а_ор NULL является NULL для всех арифметических операций а_ор (+, - и т. д.),
допустимых для типа данных выражения х (выражение NULL a_op NULL является допустимым
для любой арифметической операции а_ор). Также по определению полагается, что значением
выражений х comp_op NULL, NULL comp__op x,NULL comp_op NULL для всех операций
сравнения (-, ^, >, < и т. д.), определенных для типа выражения х, является третье логическое
значение unknown (выражение NULL comp_op NULL является допустимым для любой операции
сравнения сопр_ор).
89
9. РАСПРЕДЕЛЕННЫЕ БАЗЫ ДАННЫХ И СУБД
(ЛЕКЦИЯ 14)
Технология распределенных баз данных, получившая в настоящее время широкое
распространение, способствует обратному переходу от централизованной обработки данных к
децентрализованной. Создание технологии систем управления распределенными базами
данных является одним самых больших достижений в области баз данных.
9.1. Основные определения, классификация распределенных систем
Основной причиной разработки систем, использующих базы данных, является стремление
интегрировать все обрабатываемые в организации данные в единое целое и обеспечить к ним
контролируемый доступ. Хотя интеграция и предоставление контролируемого доступа могут
способствовать централизации, последняя не является самоцелью. На практике создание
компьютерных сетей приводит к децентрализации обработки данных. Децентрализованный
подход отражает организационную структуру компании, логически состоящую из отдельных
подразделений, отделов, проектных групп и тому подобного, которые физически распределены
по разным офисам, отделениям, предприятиям или филиалам, причем каждая отдельная
единица имеет дело с собственным набором обрабатываемых данных [7, 9].
Разработка распределенных баз данных позволяет сделать данные, поддерживаемые каждым
из существующих подразделений организации, общедоступными, обеспечив при этом их
сохранение именно в тех местах, где они чаще всего используются. Подобный подход
расширяет возможности совместного использования информации, одновременно повышая
эффективность доступа к ней.
Распределенные системы призваны разрешить проблему островов информации. Базы
данных иногда рассматривают как некие электронные острова, представляющие собой
отдельные и, в общем случае, труднодоступные места, подобные удаленным друг от друга
островам. Данное положение может являться следствием географической разобщенности,
несовместимости используемой компьютерной архитектуры, несовместимости используемых
коммутационных протоколов и т.д. Интеграция отдельных баз данных в одно логическое целое
способна изменить подобное положение дел.
Распределенная база данных – набор логически связанных между собой разделяемых
данных (и их описаний), которые физически распределены в некоторой компьютерной сети.
Распределенная СУБД – программный комплекс, предназначенный для управления
распределенными базами данных и позволяющий сделать распределен-ность информации
прозрачной для конечного пользователя.
Система управления распределенными базами данных (СУРБД) состоит из единой
логической базы данных, разделенной на некоторое количество фрагментов. Каждый фрагмент
базы данных сохраняется на одном или нескольких компьютерах, которые соединены между
собой линиями связи и каждый из которых работает под управлением отдельной СУБД. Любой
из сайтов способен независимо обрабатывать запросы пользователей, требующие доступа к
локально сохраняемым данным (что создает определенную степень локальной автономии), а
также способен обрабатывать данные, сохраняемые на других компьютерах сети.
Пользователи взаимодействуют с распределенной базой данных через приложения.
Приложения могут быть классифицированы как те, которые не требуют доступа к данным на
других сайтах (локальные приложения), и те, которые требуют подобного доступа (глобальные
приложения). В распределенной СУБД должно существовать хотя бы одно глобальное
приложение, поэтому любая СУРБД должна иметь следующие особенности [7].
 Набор логически связанных разделяемых данных.
 Сохраняемые данные разбиты на некоторое количество фрагментов.
 Между фрагментами может быть организована репликация данных.
 Фрагменты и их реплики распределены по различным сайтам.
 Сайты связаны между собой сетевыми соединениями.
90


Работа с данными на каждом сайте управляется СУБД.
СУБД на каждом сайте способна поддерживать автономную работу локальных
приложений.
 СУБД каждого сайта поддерживает хотя бы одно глобальное приложение.
Нет необходимости в том, чтобы на каждом из сайтов системы существовала своя
собственная локальная база данных, что и показано на примере топологии СУРБД,
представленной на рис. 5.1.
Рис. 5.1. Топология системы управления распределенной базой данных
Из определения СУРБД следует, что для конечного пользователя распределенность системы
должна быть совершенно прозрачна (невидима). Другими словами, от пользователей должен
быть полностью скрыт тот факт, что распределенная база данных состоит из нескольких
фрагментов, которые могут размещаться на различных компьютерах и для которых, возможно,
организована служба репликации данных.
Назначение обеспечения прозрачности состоит в том, чтобы распределенная система внешне
вела себя точно так, как и централизованная. В некоторых случаях это требование называют
основным принципом построения распределенных СУБД [7]. Данный принцип требует
предоставления конечному пользователю существенного диапазона функциональных
возможностей, но, к сожалению, одновременно ставит перед программным обеспечением
СУРБД множество дополнительных задач.
Очень важно понимать различия, существующие между распределенными СУБД и
распределенной обработкой данных.
Распределенная обработка – обработка с использованием централизованной базы данных,
доступ к которой может осуществляться с различных компьютеров сети.
Ключевым моментом в определении распределенной базы данных является утверждение, что
система работает с данными, физически распределенными в сети. Если данные хранятся
централизованно, то даже в том случае, когда доступ к ним обеспечивается для любого
пользователя в сети, данная система просто поддерживает распределенную обработку, но не
может рассматриваться как распределенная СУБД.
Кроме того, следует четко понимать различия, существующие между распределенными и
параллельными СУБД.
Параллельная СУБД – система управления базой данных, функционирующая с
использованием нескольких процессоров и устройств жестких дисков, что позволяет ей (если
это возможно) распараллеливать выполнение некоторых операций с целью повышения общей
производительности обработки.
Появление параллельных СУБД было вызвано тем фактом, что системы с одним
процессором оказались неспособны удовлетворять растущие требования к масштабируемости,
надежности и производительности обработки данных. Эффективной и экономически
обоснованной альтернативой однопроцессорным СУБД стали параллельные СУБД,
функционирующие одновременно на нескольких процессорах. Применение параллельных
СУБД позволяет объединить несколько маломощных машин для получения того же самого
91
уровня производительности, что и в случае одной, но более мощной машины, с
дополнительным выигрышем в масштабируемости и надежности системы, по сравнению с
однопроцессорными СУБД.
Для предоставления нескольким процессорам совместного доступа к одной и той же базе
данных параллельная СУБД должна обеспечивать управление совместным доступом к
ресурсам. Какие именно ресурсы разделяются и как это разделение реализовано на практике,
непосредственно влияет на показатели производительности и масштабируемости создаваемой
системы, что, в свою очередь, определяет пригодность конкретной СУБД к условиям заданной
вычислительной среды и требованиям приложений. Три основных типа архитектуры
параллельных СУБД представлены на рис. 5.2. К ним относятся:
 системы с разделением памяти;
 системы с разделением дисков;
 системы без разделения.
Хотя схему без разделения в некоторых случаях относят к распределенным СУБД, в
параллельных системах размещение данных диктуется исключительно соображениями
производительности. Более того, узлы (сайты) распределенной СУБД обычно разделены
географически, независимо администрируются и соединены между собой относительно
медленными сетевыми соединениями, тогда как узлы параллельной СУБД чаще всего
располагаются на одном и том же компьютере или в пределах одного и того же сайта [7].
Рис. 5.2. Архитектура систем с параллельной обработкой: а) с разделением памяти; б) с разделением
дисков; в) без разделения
Системы с разделением памяти состоят из тесно связанных между собой компонентов, в
число которых входит несколько процессоров, разделяющих общую системную память. Иначе
называемая симметричной многопроцессорной обработкой (СМП), эта архитектура в настоящее
время приобрела большую популярность и применяется для самых разных вычислительных
платформ, начиная от персональных рабочих станций, содержащих несколько параллельно
работающих микропроцессоров, больших RISC-систем и вплоть до крупнейших мейнфреймов.
Данная архитектура обеспечивает быстрый доступ к данным для ограниченного числа
процессоров, количество которых обычно не превосходит 64. В противном случае сетевые
взаимодействия превращаются в узкое место, ограничивающее производительность всей
системы.
Системы без разделения (эту архитектуру иначе называют массовой параллельной
обработкой – ММП) используют схему, в которой каждый процессор, являющийся частью
92
системы, имеет свою собственную оперативную и дисковую память. База данных распределена
между всеми дисковыми устройствами, подключенным к отдельным, связанным с этой базой
данных вычислительным подсистемам, в результате чего все данные прозрачно доступны
пользователям каждой из этих подсистем. Данная архитектура обеспечивает более высокий
уровень масштабируемости, чем системы с СМП, и позволяет легко организовать поддержку
работы большого количества процессоров. Однако оптимальной производительности удается
достичь только в том случае, если требуемые данные хранятся локально.
Системы с разделением дисков строятся из менее тесно связанных между собой
компонентов. Они являются оптимальным вариантом для приложений, которые унаследовали
высокую централизацию обработки и должны обеспечивать самые высокие показатели
доступности и производительности. Каждый из процессоров имеет непосредственный доступ
ко всем совместно используемым дисковым устройствам, но обладает собственной оперативной
памятью. Как и в случае архитектуры без разделения, архитектура с разделением дисков
исключает узкие места, связанные с совместно используемой памятью. Однако, в отличие от
архитектуры без разделения, данная архитектура исключает упомянутые узкие места без
внесения дополнительной нагрузки, связанной с физическим распределением данных по
отдельным устройствам. Разделяемые дисковые системы в некоторых случаях называют
кластерами.
Параллельные технологии обычно используются в случае исключительно больших баз
данных, размеры которых могут достигать нескольких терабайт (1012 байт), или в системах,
которые должны поддерживать выполнение тысяч транзакций в секунду. Подобные системы
нуждаются в доступе к большому объему данных и должны обеспечивать приемлемое время
реакции на запрос. Параллельные СУБД могут использовать различные вспомогательные
технологии, позволяющие повысить производительность обработки сложных запросов за счет
применения методов распараллеливания операций сканирования, соединения и сортировки, что
позволяет нескольким процессорным узлам автоматически распределять между собой текущую
нагрузку [7].
Распределенные СУБД можно классифицировать как гомогенные и гетерогенные [7].
В гомогенных системах все сайты используют один и тот же тип СУБД.
В гетерогенных системах на сайтах могут функционировать различные типы СУБД,
использующие разные модели данных, т.е. гетерогенная система может включать сайты с
реляционными, сетевыми, иерархическими или объектно-ориентированными СУБД.
Гомогенные системы значительно проще проектировать и сопровождать. Кроме того,
подобный подход позволяет поэтапно наращивать размеры системы, последовательно добавляя
новые сайты к уже существующей распределенной системе. Дополнительно появляется
возможность повышать производительность системы за счет организации на различных сайтах
параллельной обработки информации.
Гетерогенные системы обычно возникают в тех случаях, когда независимые сайты, уже
эксплуатирующие свои собственные системы с базами данных, интегрируются во вновь
создаваемую распределенную систему. В гетерогенных системах для организации
взаимодействия между различными типами СУБД потребуется организовать трансляцию
передаваемых сообщений. Для обеспечения прозрачности в отношении типа используемой
СУБД пользователи каждого из сайтов должны иметь возможность вводить интересующие их
запросы на языке той СУБД, которая используется на данном сайте. Система должна взять на
себя локализацию требуемых данных и выполнение трансляции передаваемых сообщений. В
общем случае данные могут быть затребованы с другого сайта, который характеризуется
такими особенностями, как:
 иной тип используемого оборудования;
 иной тип используемой СУБД;
 иной тип применяемых оборудования и СУБД,
Если используется иной тип оборудования, однако на сайте установлен тот же самый тип
СУБД, методы выполнения трансляции вполне очевидны и включают замену кодов и
изменение длины слова. Если типы используемых на сайтах СУБД различны, процедура
трансляции усложняется тем, что необходимо отображать структуры данных одной модели в
93
соответствующие структуры данных другой модели. Например, отношения в реляционной
модели данных должны быть преобразованы в записи и наборы, типичные для сетевой модели
данных. Кроме того, потребуется транслировать текст запросов с одного используемого языка
на другой (например, запросы с SQL-оператором SELECT потребуется преобразовать в запросы
с операторами FIND и GET языка манипулирования данными сетевой СУБД). Если отличаются
и тип используемого оборудования, и тип программного обеспечения, потребуется выполнять
оба вида трансляции. Все изложенное выше чрезвычайно усложняет обработку данных в
гетерогенных СУБД.
Дополнительные сложности возникают при попытках выработки единой концептуальной
схемы, создаваемой путем интеграции независимых локальных концептуальных схем.
Типичное решение, применяемое в некоторых реляционных системах, состоит в том, что
отдельные части гетерогенных распределенных систем должны использовать шлюзы,
предназначенные для преобразования языка и модели данных каждого из используемых типов
СУБД в язык и модель данных реляционной системы. Однако подходу с использованием
шлюзов свойственны некоторые серьезные ограничения.
Во-первых, шлюзы не позволяют организовать систему управления транзакциями даже для
отдельных пар систем. Другими словами, шлюз между двумя системами представляет собой не
более чем транслятор запросов. Например, шлюзы не позволяют системе координировать
управление параллельностью и процедурами восстановления транзакций, включающих
обновление данных в обеих базах.
Во-вторых, использование шлюзов призвано лишь решить задачу трансляции запросов с
языка одной СУБД на язык другой СУБД. Поэтому они не позволяют справиться с проблемами,
вызванными неоднородностью структур и представлением данных в различных схемах.
В настоящее время организована рабочая группа (Specification Working Group – SWG) для
подготовки спецификаций, регламентирующих инфраструктуру среды базы данных,
включающую следующие элементы [7].
1. Унифицированный и достаточно мощный интерфейс языка SQL (SQL API), позволяющий
создавать клиентские приложения таким образом, чтобы они не были привязаны к
конкретному типу используемой СУБД.
2. Унифицированный протокол доступа к базе данных, позволяющий СУБД одного типа
непосредственно взаимодействовать с СУБД другого типа, без необходимости
использования какого-либо шлюза.
3. Унифицированный сетевой протокол, позволяющий осуществлять взаимодействие СУБД
различного типа.
Самой важной задачей этой группы следует считать отыскание способа, позволяющего в
одной транзакции выполнять обработку данных, содержащихся в нескольких базах,
управляемых СУБД различных типов, причем без необходимости использования каких-либо
шлюзов.
Одной из разновидностей распределенных СУБД, являются мультибазовые системы.
Мультибазовая система – распределенная система управления базами данных, в которой
управление каждым из сайтов осуществляется совершенно автономно.
В последние годы заметно возрос интерес к мультибазовым СУБД, в которых
предпринимается попытка интеграции таких распределенных систем баз данных, в которых
весь контроль над отдельными локальными системами целиком и полностью осуществляется
их операторами. Одним из следствий полной автономии сайтов является отсутствие
необходимости внесения каких-либо изменений в локальные СУБД. Следовательно,
мультибазовые СУБД требуют создания поверх существующих локальных систем
дополнительного уровня программного обеспечения, предназначенного для предоставления
необходимой функциональности.
Мультибазовые системы позволяют конечным пользователям разных сайтов получать доступ
и совместно использовать данные без необходимости физической интеграции существующих
баз данных. Они обеспечивают пользователям возможность управлять базами данных их
собственных сайтов без какого-либо централизованного контроля, который обязательно
присутствует в обычных типах СУРБД. Администратор локальной базы данных может
94
разрешить доступ к определенной части своей базы данных посредством создания схемы
экспорта, определяющей, к каким элементам локальной базы данных смогут получать доступ
внешние пользователи. Различают нефедеральные (не имеющие локальных пользователей) и
федеральные мультибазовые системы. Федеральная система представляет собой некоторый
гибрид распределенной и централизованной систем, поскольку она выглядят как
распределенная система для удаленных пользователей и как централизованная система – для
локальных.
Говоря простыми словами, мультибазовая СУБД является такой СУБД, которая прозрачным
образом располагается поверх существующих баз данных и файловых систем, предоставляя их
своим пользователям как некоторую единую базу данных. Мультибазовая СУБД поддерживает
глобальную схему, на основании которой пользователи могут строить запросы и
модифицировать данные. Мультибазовая СУБД работает только с глобальной схемой, тогда как
локальные СУБД собственными силами обеспечивают поддержку данных всех их
пользователей. Глобальная схема создается посредством интеграции схем локальных баз
данных. Программное обеспечение мультибазовой СУБД предварительно транслирует
глобальные запросы и превращает их в запросы и операторы модификации данных
соответствующих локальных СУБД. Затем полученные после выполнения локальных запросов
результаты сливаются в единый глобальный результат, предоставляемый пользователю. Кроме
того, мультибазовая СУБД осуществляет контроль за выполнением фиксации или отката
отдельных операций глобальных транзакций локальных СУБД, а также обеспечивает
сохранение целостности данных в каждой из локальных баз данных. Программы мультибазовой
СУБД управляют различными шлюзами, с помощью которых они контролируют работу
локальных СУБД.
9.2. Преимущества и недостатки распределенных СУБД
Системы с распределенными базами данных имеют дополнительные преимущества перед
традиционными централизованными системами баз данных [7]. Но эта технология не лишена и
некоторых недостатков (табл. 5.1).
Таблица 5.1
Преимущества
Отражение структуры организации
Разделяемость и локальная автономность
Повышение доступности данных
Повышение надежности
Повышение производительности
Экономические выгоды
Модульность системы
Недостатки
Повышение сложности
Увеличение стоимости
Проблемы защиты
Усложнение контроля за целостностью данных
Отсутствие стандартов
Недостаток опыта
Усложнение процедуры разработки базы данных
Комплексный учет всех предоставляемых выигрышей и проигрышей является сложной
задачей, методология решения которой в настоящее время не определена. Ответственность за
принятие решения по разработке и внедрению распределенной системы может взять на себя
группа смелых специалистов.
Преимущества
Отражение структуры организации
Крупные организации, как правило, имеют множество отделений, которые могут находиться
в разных концах страны и даже за ее пределами. Вполне логично будет предположить, что
используемые этими организациями базы данных должны быть распределены между
отдельными офисами. В каждом отделении может поддерживаться своя база данных. В
подобной базе данных персонал отделения сможет выполнять необходимые ему локальные
запросы. Руководству компании может потребоваться выполнять глобальные запросы,
95
предусматривающие получение доступа к данным, сохраняемым во всех существующих
отделениях компании.
Разделяемостъ и локальная автономность
Географическая распределенность организации может быть отражена в распределении ее
данных, причем пользователи одного сайта смогут получать доступ к данным, сохраняемым на
других сайтах. Данные могут быть помещены на тот сайт, на котором зарегистрированы
пользователи, которые их чаще всего используют. В результате заинтересованные пользователи
получают локальный контроль над требуемыми им данными и могут устанавливать или
регулировать локальные ограничения на их использование. Администратор глобальной базы
данных (АБД) отвечает за систему в целом. Как правило, часть этой ответственности
делегируется на локальный уровень, благодаря чему АБД локального уровня получает
возможность управлять локальной СУБД.
Повышение доступности данных
В централизованных СУБД отказ центрального компьютера вызывает прекращение
функционирования всей СУБД. Однако отказ одного из сайтов СУРБД или линии связи между
сайтами сделает недоступным лишь некоторые сайты, тогда как вся система в целом сохранит
свою работоспособность. Распределенные СУБД проектируются таким образом, чтобы
обеспечивать продолжение функционирования системы, несмотря на подобные отказы. Если
выходит из строя один из узлов, система сможет перенаправить запросы к отказавшему узлу в
адрес другого сайта.
Повышение надежности
Если организована репликация данных, в результате чего данные и их копии будут
размещены на более чем одном сайте, отказ отдельного узла или соединительной связи между
узлами не приведет к недоступности данных в системе.
Повышение производительности
Если данные размещены на самом нагруженном сайте, который унаследовал от системпредшественников высокий уровень параллельности обработки, то развертывание
распределенной СУБД может способствовать повышению скорости доступа к базе данных (по
сравнению с доступом к удаленной централизованной СУБД). Более того, поскольку каждый
сайт работает только с частью базы данных, уровень использования центрального процессора и
служб ввода/ вывода может оказаться ниже, чем в случае централизованной СУБД.
Экономические выгоды
В шестидесятые годы мощность вычислительной установки возрастала пропорционально
квадрату стоимости ее оборудования, поэтому система, стоимость которой была втрое выше
стоимости данной, превосходила ее по мощности в девять раз. Эта зависимость получила
название закона Гроша [7]. Однако в настоящее время считается общепринятым положение,
согласно которому намного дешевле собрать из небольших компьютеров систему, мощность
которой будет эквивалентна мощности одного большого компьютера. Оказывается, что
намного выгоднее устанавливать в подразделениях организации собственные маломощные
компьютеры, кроме того, гораздо дешевле добавить в сеть новые рабочие станции, чем
модернизировать систему с мейнфреймом.
Второй потенциальный источник экономии имеет место в том случае, когда базы данных
географически удалены друг от друга и приложения требуют осуществления доступа к
распределенным данным. В этом случае из-за относительно высокой стоимости передаваемых
96
по сети данных (по сравнению со стоимостью их локальной обработки) может оказаться
экономически выгодным разделить приложение на соответствующие части и выполнять
необходимую обработку на каждом из сайтов локально.
Модульность системы.
В распределенной среде расширение существующей системы осуществляется намного
проще. Добавление в сеть нового сайта не оказывает влияния на функционирование уже
существующих. Подобная гибкость позволяет организации легко расширяться. Перегрузки изза увеличения размера базы данных обычно устраняются путем добавления в сеть новых
вычислительных мощностей и устройств дисковой памяти. В централизованных СУБД рост
размера базы данных может потребовать замены и оборудования (более мощной системой), и
используемого программного обеспечения (более мощной или более гибкой СУБД).
Недостатки
Повышение сложности
Распределенные СУБД, способные скрыть от конечных пользователей распределенную
природу используемых ими данных и обеспечить необходимый уровень производительности,
надежности и доступности, безусловно, являются более сложными программными
комплексами, чем централизованные СУБД. Тот факт, что данные могут подвергаться
репликации, также добавляет дополнительный уровень сложности в программное обеспечение
СУРБД. Если репликация данных не будет поддерживаться на требуемом уровне, система будет
иметь более низкий уровень доступности данных, надежности и производительности, чем
централизованные системы, а все изложенные выше преимущества превратятся в недостатки.
Увеличение стоимости
Увеличение сложности означает и увеличение затрат на приобретение и сопровождение
СУРБД (по сравнению с обычными централизованными СУБД). Разворачивание
распределенной СУБД потребует дополнительного оборудования, необходимого для установки
сетевых соединений между сайтами. Следует ожидать и роста расходов на оплату каналов
связи, вызванных возрастанием сетевого трафика. Кроме того, возрастают затраты на оплату
труда персонала, который потребуется для обслуживания локальных СУБД и сетевых
соединений.
Проблемы защиты
В централизованных системах доступ к данным легко контролируется. Однако в
распределенных системах потребуется организовать контроль доступа не только к данным,
реплицируемым на несколько различных сайтов, но и защиту сетевых соединений самих по
себе. Раньше сети рассматривались как совершенно незащищенные каналы связи. Хотя это
отчасти справедливо и для настоящего времени, тем не менее, в отношении защиты сетевых
соединений достигнут весьма существенный прогресс.
Усложнение контроля за целостностью данных
Целостность базы данных означает корректность и согласованность сохраняемых в ней
данных. Требования обеспечения целостности обычно формулируются в виде некоторых
ограничений, выполнение которых будет гарантировать защиту информации в базе данных от
разрушения. Реализация ограничений поддержки целостности обычно требует доступа к
большому количеству данных, используемых при выполнении проверок, но не требует
выполнения операций обновления. В распределенных СУБД повышенная стоимость передачи и
97
обработки данных может препятствовать организации эффективной защиты от нарушений
целостности данных.
Отсутствие стандартов
Хотя функционирование распределенных СУБД зависит от эффективности используемых
каналов связи, только в последнее время стали вырисовываться контуры стандарта на каналы
связи и протоколы доступа к данным. Отсутствие стандартов существенно ограничивает
потенциальные возможности распределенных СУБД. Кроме того, не существует
инструментальных средств и методологий, способных помочь пользователям в преобразовании
централизованных систем в распределенные.
Недостаток опыта
В настоящее время в эксплуатации находится уже несколько систем-прототипов и
распределенных СУБД специального назначения, что позволило уточнить требования к
используемым протоколам и установить круг основных проблем. Однако на текущий момент
распределенные системы общего назначения еще не получили широкого распространения.
Соответственно, еще не накоплен необходимый опыт промышленной эксплуатации
распределенных систем, сравнимый с опытом эксплуатации централизованных систем. Такое
положение дел является серьезным сдерживающим фактором для многих потенциальных
сторонников данной технологии.
Усложнение процедуры разработки базы данных
Разработка распределенных баз данных, помимо обычных трудностей, связанных с
процессом проектирования централизованных баз данных, требует принятия решения о
фрагментации данных, распределении фрагментов по отдельным сайтам и организации
процедур репликации данных.
9.3. Функции распределенных СУБД
Очевидно, что типичная СУРБД должна обеспечивать, по крайней мере, тот же набор
функциональных возможностей, который был определен для централизованных СУБД в главе
1.
Кроме того, СУРБД должна предоставлять следующий набор функциональных
возможностей [7].
 Расширенные службы установки соединений должны обеспечивать доступ к удаленным
сайтам и позволять передавать запросы и данные между сайтами, входящими в сеть.
 Расширенные средства ведения каталога, позволяющие сохранять сведения о
распределении данных в сети.
 Средства обработки распределенных запросов, включая механизмы оптимизации
запросов и организации удаленного доступа.
 Расширенные функции управления параллельностью, позволяющие поддерживать
целостность реплицируемых данных.
 Расширенные функции восстановления, учитывающие возможность отказов в работе
отдельных сайтов и отказов линий связи.
9.4. Архитектура распределенных СУБД
Трехуровневая архитектура ANSI-SPARC для СУБД, обсуждавшаяся в разделе 1.3,
представляет собой типовое решение для централизованных СУБД. Однако распределенные
СУБД имеют множество отличий, которые сложно отразить в некотором эквивалентном
архитектурном решении, приемлемом для большинства случаев.
98
Один из примеров рекомендуемой архитектуры СУРБД представлен на рис. 5.3. Он включает
следующие элементы [7]:
 набор глобальных внешних схем;
 глобальную концептуальную схему;
 схему фрагментации и схему распределения;
 набор схем для каждой локальной СУБД, отвечающих требованиям трехуровневой
архитектуры ANSI-SPARC.
Рис. 5.3. Рекомендуемая архитектура СУРБД
Соединительные линии на схеме представляют преобразования, выполняемые при переходе
между схемами различных типов. В зависимости от поддерживаемого уровня прозрачности
некоторые из уровней рекомендуемой архитектуры могут быть опущены.
Глобальная концептуальная схема
Глобальная концептуальная схема представляет собой логическое описание всей базы
данных, представляющее ее так, как будто она не является распределенной. Этот уровень
СУРБД соответствует концептуальному уровню архитектуры ANSI-SPARC и содержит
определения сущностей, связей, требований защиты и ограничений поддержки целостности
информации. Он обеспечивает физическую независимость данных от распределенной среды.
Логическую независимость данных обеспечивают глобальные внешние схемы.
Схемы фрагментации и распределения
Схема фрагментации содержит описание того, как данные должны логически распределяться
по разделам. Схема распределения является описанием того, где расположены имеющиеся
данные. Схема распределения учитывает все организованные в системе процессы репликации.
Локальные схемы
Каждая локальная СУБД имеет свой собственный набор схем. Локальная концептуальная и
99
локальная внутренняя схемы полностью соответствуют эквивалентным уровням архитектуры
ANSI-SPARC. Локальная схема отображения используется для отображения фрагментов в
схеме распределения во внутренние объекты локальной базы данных. Эти элементы являются
зависимыми от типа используемой СУБД и служат основой для построения гетерогенных
СУРБД.
Независимо от рекомендованной общей архитектуры СУРБД компонентная архитектура
СУРБД должна включать четыре следующих важнейших компонента (рис. 5.4) [7]:
1) локальную СУБД;
2) компонент передачи данных;
3) глобальный системный каталог;
4) распределенную СУБД (СУРБД).
Рис. 5.4. Компонентная архитектура распределенной СУБД
Локальная СУБД
Компонент локальной СУБД представляет собой стандартную СУБД, предназначенную для
управления локальными данными на каждом из сайтов, входящих в состав распределенной
базы данных. Локальная СУБД имеет свой собственный системный каталог, в котором
содержится информация о данных, сохраняемых на этом сайте. В гомогенных системах на
каждом из сайтов в качестве локальной СУБД используется один и тот же программный
продукт. В гетерогенных системах существуют, по крайней мере, два сайта, использующих
различные типы СУБД и/или различные типы вычислительных платформ.
Компонент передачи данных
Компонент передачи данных представляет собой программное обеспечение, позволяющее
всем сайтам взаимодействовать между собой. Он содержит сведения о существующих сайтах и
линиях связи между ними.
Глобальный системный каталог
Глобальный системный каталог имеет то же самое функциональное назначение, что и
системный каталог в централизованных базах данных. Глобальный каталог содержит
информацию, специфическую для распределенной природы системы, например схемы
фрагментации и распределения. Этот каталог сам по себе может являться распределенной базой
данных и поэтому подвергаться фрагментации и распределению, быть полностью
реплицируемым или централизованным, как и любое другое отношение.
Что касается отношений, созданных на некотором сайте (сайте создания), то
100
ответственность за фиксацию описания каждого его фрагмента, каждой реплики, каждого
фрагмента, а также хранение сведений о расположении этих фрагментов, возлагается на
локальный каталог данного сайта. В случае если фрагмент или реплика перемещается в другое
место, сведения в локальном каталоге сайта создания соответствующего отношения
необходимым образом обновляются. Следовательно, для определения расположения фрагмента
или реплики отношения необходимо получить доступ к каталогу его сайта создания. Сведения
о сайте создания каждого глобального отношения должны фиксироваться в каждом локальном
экземпляре глобального системного каталога.
Распределенная СУБД
Компонент распределенной СУБД является управляющим по отношению ко всей системе
элементом. В предыдущем разделе описаны основные функциональные возможностями,
которыми должен обладать этот компонент.
9.5. Разработка распределенных реляционных баз данных
В главе 2 была приведена методология концептуального и логического проектирования
централизованных реляционных баз данных. В данном разделе рассматриваются следующие
дополнительные факторы, которые должны приниматься во внимание при разработке
распределенных реляционных баз данных [7].
 Фрагментация. Любое отношение может быть разделено на некоторое количество
частей, называемых фрагментами, которые затем распределяются по различным сайгам.
Существуют два основных типа фрагментов: горизонтальные и вертикальные.
Горизонтальные фрагменты представляют собой подмножества кортежей, а вертикальные
– подмножества атрибутов.
 Распределение. Каждый фрагмент сохраняется на сайте, выбранном с учетом
«оптимальной» схемы их размещения.
 Репликация. СУРБД может поддерживать актуальную копию некоторого фрагмента на
нескольких различных сайтах.
Определение и размещение фрагментов должно проводиться с учетом особенностей
использования базы данных. Это подразумевает выполнение анализа приложений. Как правило,
провести анализ всех приложений не представляется возможным, поэтому следует
сосредоточить усилия на самых важных из них.
Проектирование должно выполняться на основе как количественных, так и качественных
показателей. Количественная информация используется в качестве основы для распределения,
тогда как качественная служит базой при создании схемы фрагментации. Количественная
информация включает такие показатели:
 частота запуска приложения на выполнение;
 сайт, на котором запускается приложение;
 требования к производительности транзакций и приложений.
Качественная информация может включать перечень выполняемых в приложении
транзакций, используемые отношения, атрибуты и кортежи, к которым осуществляется доступ,
тип доступа (чтение или запись), предикаты, используемые в операциях чтения.
Определение и размещение фрагментов по сайтам выполняется для достижения следующих
стратегических целей.
• Локальность ссылок. Везде, где только это возможно, данные должны храниться как можно
ближе к местам их использования. Если фрагмент используется на нескольких сайтах, может
оказаться целесообразным разместить на этих сайтах его копии.
• Повышение надежности и доступности. Надежность и доступность данных повышаются
за счет использования механизма репликации. В случае отказа одного из сайтов всегда будет
существовать копия фрагмента, сохраняемая на другом сайте.
• Приемлемый уровень производительности. Неверное распределение данных будет иметь
следствием возникновение в системе узких мест. В этом случае некоторый сайт оказывается
101
просто завален запросами со стороны других сайтов, что может вызвать существенное
снижение производительности всей системы. В то же время неправильное распределение может
иметь следствием неэффективное использование ресурсов системы.
• Баланс между емкостью и стоимостью внешней памяти. Обязательно следует учитывать
доступность и стоимость устройств хранения данных, имеющихся на каждом из сайтов
системы. Везде, где только это, возможно, рекомендуется использовать более дешевые
устройства массовой памяти. Это требование должно быть сбалансировано с требованием
поддержки локальности ссылок.
• Минимизация расходов на передачу данных. Следует тщательно учитывать стоимость
выполнения в системе удаленных запросов. Затраты на выборку будут минимальны при
обеспечении максимальной локальности ссылок, т.е. когда каждый сайт будет иметь
собственную копию данных. Однако при обновлении реплицируемых данных внесенные
изменения потребуется распространить на все сайты, имеющие копию обновленного
отношения, что вызовет увеличение затрат на передачу данных.
9.5.1. Распределение данных
Существуют четыре альтернативные стратегии размещения данных в системе [7]:
1) централизованное;
2) раздельное (фрагментированное);
3) размещение с полной репликацией;
4) размещение с выборочной репликацией.
Централизованное размещение
Данная стратегия предусматривает создание на одном из сайтов единственной базы данных
под управлением СУБД, доступ к которой будут иметь все пользователи сети («распределенная
обработка»). В этом случае локальность ссылок минимальна для всех сайтов, за исключением
центрального, поскольку для получения любого доступа к данным требуется установка
сетевого соединения. Соответственно уровень затрат на передачу данных будет высок. Уровень
надежности и доступности в системе низок, поскольку отказ на центральном сайте вызовет
паралич работы всей системы.
Раздельное (фрагментированное) размещение
В этом случае база данных разбивается на непересекающиеся фрагменты, каждый из
которых размещается на одном из сайтов системы. Если элемент данных будет размещен на
том сайте, на котором он чаще всего используется, полученный уровень локальности ссылок
будет высок. При отсутствии репликации стоимость хранения данных будет минимальна, но
при этом будет невысок также уровень надежности и доступности данных в системе. Однако он
будет выше, чем в предыдущем варианте, поскольку отказ на любом из сайтов вызовет утрату
доступа только к той части данных, которая на нем хранилась. При правильно выбранном
способе распределения данных уровень производительности в системе будет относительно
высоким, а уровень затрат на передачу данных – низким.
Размещение с полной репликацией
Эта стратегия предусматривает размещение полной копии всей базы данных на каждом из
сайтов системы. Следовательно, локальность ссылок, надежность и доступность данных, а
также уровень производительности системы будут максимальны. Однако стоимость устройств
хранения данных и уровень затрат на передачу данных в этом случае также будут самыми
высокими. Для преодоления части этих проблем в некоторых случаях используется технология
моментальных снимков. Моментальный снимок представляет собой копию базы данных в
определенный момент времени. Эти копии обновляются через некоторый установленный
102
интервал времени – например, один раз в час или в неделю, – а потому они не всегда будут
актуальными в текущий момент. Иногда в распределенных системах моментальные снимки
используются для реализации представлений, что позволяет улучшить время выполнения в базе
данных операций с представлениями.
Размещение с выборочной репликацией
Данная стратегия представляет собой комбинацию методов фрагментации, репликации и
централизации. Одни массивы данных разделяются на фрагменты, что позволяет добиться для
них высокой локальности ссылок, тогда как другие, используемые на многих сайтах, но не
подверженные частым обновлениям, подвергаются репликации. Все остальные данные
хранятся централизованно. Целью применения данной стратегии является объединение всех
преимуществ, существующих в остальных, моделях, с одновременным исключением
свойственных им недостатков. Благодаря своей гибкости именно эта стратегия используется
чаще всего.
Сводные характеристики всех рассмотренных выше стратегий приведены в табл. 5.2.
Таблица 5.2
Локальность
ссылок
Стоимость
устройств
хранения
данных
Централизован Самая низкая Самая низкая
Неудовлетворител Самая низкая
ное
ь-ная
Высокая
Низкая для отдельных Удовлетворительн Самая низкая
Фрагментирова
элементов; высокая для ая
иное
системы в целом
Самая высокая
Самая
Самая высокая
Хорошая для
Полная
высокая
операций чтения
репликация
высокая
Выборочная
репликация
Надежность и
доступность
Производительно
сть
Низкая для отдельных
Средняя
элементов, высокая для Удовлетворительн
системы
ая
Затраты на
передачу
Самая высокая
Низкая
Высокая для
операций
обновления, низкая
для операций
чтения
Низкая
9.5.2. Фрагментация
Необходимость фрагментации вызывают следующие причины [7].
 Условия использования. Чаще всего приложения работают с некоторыми
представлениями, а не с полными базовыми отношениями. Следовательно, с точки зрения
распределения данных, целесообразнее организовать работу приложений с
определенными фрагментами отношений, выступающими как распределяемые элементы.
 Эффективность. Данные хранятся в тех местах, в которых они чаще всего используются.
Кроме того, исключается хранение данных, которые не используются локальными
приложениями.
 Параллельность. Поскольку фрагменты являются распределяемыми элементами,
транзакции могут быть разделены на несколько подзапросов, обращающихся к
различным фрагментам. Такой подход дает возможность повысить уровень
параллельности обработки в системе, т.е. позволяет транзакциям, которые допускают это,
безопасно выполняться в параллельном режиме.
 Защищенность. Данные, не используемые локальными приложениями, не хранятся на
сайтах, а значит, неавторизированные пользователи не смогут получить к ним доступ.
Механизму фрагментации свойственны два основных недостатка.
 Производительность. Производительность приложений, требующих доступа к данным
из нескольких фрагментов, расположенных на различных сайтах, может оказаться
недостаточной.
103

Целостность данных. Поддержка целостности данных может существенно осложняться,
поскольку функционально зависимые данные могут оказаться фрагментированными и
размещаться на различных сайтах.
При проведении фрагментации следует обязательно придерживаться трех следующих правил
[7].
1. Полнота. Если экземпляр отношения R разбивается на фрагменты, например R1, R2, ..., Rn,
то каждый элемент данных, присутствующий в отношении R, должен присутствовать, по
крайней мере, в одном из созданных фрагментов. Выполнение этого правила гарантирует, что
какие-либо данные не будут утрачены в результате выполнения фрагментации.
2. Восстановитостъ. Должна существовать операция реляционной алгебры, позволяющая
восстановить отношение R из его фрагментов. Это правило гарантирует сохранение
функциональных зависимостей.
3. Непересекаемость. Если элемент данных di присутствует во фрагменте Ri, то он не должен
одновременно присутствовать в каком-либо ином фрагменте. Исключением из этого правила
является операция вертикальной фрагментации, поскольку в этом случае в каждом фрагменте
должны присутствовать атрибуты первичного ключа, необходимые для восстановления
исходного отношения. Данное правило гарантирует минимальную избыточность данных во
фрагментах.
В случае горизонтальной фрагментации элементом данных является кортеж, а в случае
вертикальной фрагментации – атрибут.
Существуют два основных типа фрагментации (рис. 5.5, а, б):
 горизонтальная,
 вертикальная.
Горизонтальные фрагменты представляют собой подмножества кортежей отношения, а
вертикальные подмножества атрибутов отношения.
Кроме того, различают смешанную (рис. 5.5, в, г) и производную (вариант горизонтальной)
фрагментации.
Горизонтальный фрагмент – выделенный по горизонтали фрагмент отношения, состоящий
из некоторого подмножества кортежей этого отношения.
Горизонтальный фрагмент создается посредством определения предиката, с помощью
которого выполняется отбор кортежей из исходного отношения. Данный тип фрагмента
определяется с помощью операции выборки (селекции) реляционной алгебры (см. гл. 4).
Операция выборки позволяет выделить группу кортежей, обладающих некоторым общим для
них свойством, – например, все кортежи, используемые одним из приложений, или все
кортежи, применяемые на одном из сайтов.
Рис. 5.5. Типы фрагментации:
а) горизонтальная; 6) вертикальная; в) горизонтально разделенные вертикальные фрагменты; г)
вертикально разделенные горизонтальные фрагменты
В одних случаях целесообразность использования горизонтальной фрагментации вполне
104
очевидна. Однако в других случаях потребуется выполнение детального анализа приложений.
Этот анализ должен включать проверку предикатов (или условий) поиска, используемых в
транзакциях или запросах, выполняемых в приложении. Предикаты могут быть простыми,
включающими только по одному атрибуту, или сложными, включающими несколько
атрибутов. Для каждого из используемых атрибутов предикат может содержать единственное
значение или несколько значений. В последнем случае значения могут быть дискретными или
задавать диапазон значений.
Стратегия определения типа фрагментации предполагает поиск набора минимальных (т.е.
полных и релевантных) предикатов, которые можно будет использовать как основу для
построения схемы фрагментации [7].
Набор предикатов является полным тогда и только тогда, когда вероятность обращения к
любым двум кортежам одного и того же фрагмента со стороны любого приложения будет
одинакова.
Предикат является релевантным, если существует, по крайней мере, одно приложение,
которое по-разному обращается к выделенным с помощью этого предиката фрагментам.
Вертикальный фрагмент – выделенный по вертикали фрагмент отношения, состоящий из
подмножества атрибутов этого отношения.
При вертикальной фрагментации в различные фрагменты объединяются атрибуты,
используемые отдельными приложениями. Определение фрагментов в этом случае выполняется
с помощью операции проекции реляционной алгебры (см. гл.4).
Вертикальные фрагменты определяются путем установки родственности одного атрибута
по отношению к другому. Один из способов решить эту задачу состоит в создании матрицы,
содержащей количество обращений с выборкой каждой из пар атрибутов. Например,
транзакция, которая осуществляет доступ к атрибутам A1, A2 и А4 отношения R, состоящего из
набора атрибутов (А1, А2, А3, А4), может быть представлена следующей матрицей.
Эта матрица является треугольной, поскольку диагональ ее не заполняется, а нижняя часть
является зеркальным отражением верхней части. Единицы в матрице означают наличие доступа
с обращением к соответствующей паре атрибутов и, в конечном счете, должны быть заменены
числами, отражающими частоту выполнения транзакции. Подобная матрица составляется для
каждой транзакции, после чего строится общая матрица, содержащая суммы всех показателей
доступа к каждой из пар атрибутов. Пары атрибутов с высоким показателем родственности
должны присутствовать в одном и том же вертикальном фрагменте. Пары с невысоким
показателем родственности могут быть разнесены в разные вертикальные фрагменты.
Очевидно, что обработка сведений об отдельных атрибутах для всех важнейших транзакций
может потребовать немало времени и вычислений. Следовательно, если заранее известно о
родственности определенных атрибутов, может оказаться целесообразным обработать сведения
сразу о группах атрибутов.
Подобный подход носит название расщепления (splitting) и впервые был предложен группой
разработчиков в 1984 году [7]. Он позволяет выделить набор неперекрывающихся фрагментов,
которые гарантированно будут отвечать определенному выше правилу непересекаемости.
Фактически требование непересекаемости касается только атрибутов, не входящих в
первичный ключ отношения. Атрибуты первичного ключа должны присутствовать в каждом из
выделенных вертикальных фрагментов, а потому могут быть исключены из анализа.
В некоторых случаях применения только лишь горизонтальной и вертикальной
фрагментации элементов схемы базы данных оказывается недостаточно для адекватного
распределения данных между приложениями. В этом случае приходится прибегать к
смешанной (или гибридной) фрагментации.
105
Смешанный фрагмент образуется либо посредством дополнительной вертикальной
фрагментации созданных ранее горизонтальных фрагментов, либо за счет вторичной
горизонтальной фрагментации предварительно определенных вертикальных фрагментов.
Смешанная фрагментация определяется с помощью операций выборки и проекции
реляционной алгебры.
Некоторые приложения включают операции соединения двух или больше отношений. Если
отношения сохраняются в различных местах, то выполнение их соединения создаст очень
большую дополнительную нагрузку на систему. В подобных случаях более приемлемым
решением будет размещение соединяемых отношений или их фрагментов в одном и том же
месте. Данная цель может быть достигнута за счет применения производной горизонтальной
фрагментации.
Производный фрагмент – горизонтальный фрагмент отношения, созданный на основе
горизонтального фрагмента родительского отношения.
Термин «дочернее» используется для ссылок на отношение, содержащее внешний ключ, а
термин «родительское» – для ссылок на отношение с соответствующим первичным ключом.
Определение производных фрагментов осуществляется с помощью операции полусоединения
реляционной алгебры (см. гл. 4).
Если отношение включает больше одного внешнего ключа, то может потребоваться выбрать
в качестве родительского только одно из связанных отношений. Выбор может быть сделан в
соответствии с чаще всего используемым типом фрагментации или с целью достижения
оптимальных характеристик соединения – например, соединения, которое включает более
мелкие фрагменты или соединения, выполняемого с большей степенью распараллеливания.
Последний вариант возможной стратегии при разработке распределенных БД состоит в
отказе от фрагментации отношения [7].
9.5.3. Репликация
Репликацию можно определить как процесс генерации и воспроизведения нескольких копий
данных, размещаемых на одном или нескольких сайтах.
Механизм репликации очень важен, поскольку позволяет организации обеспечивать доступ
пользователям к актуальным данным там и тогда, когда они в этом нуждаются. Использование
репликации позволяет достичь многих преимуществ, включая повышение производительности
(в тех случаях, когда централизованный ресурс оказывается перегруженным), надежности
хранения и доступности данных, наличие «горячей» резервной копии на случай
восстановления, а также возможность поддержки мобильных пользователей и хранилищ
данных.
9.5.3.1. Виды репликации
Протоколы обновления реплицируемых данных, построены на допущении, что обновления
всех копий данных выполняются как часть самой транзакции обновления. Другими словами,
все копии реплицируемых данных обновляются одновременно с изменением исходной копии и,
как правило, с помощью протокола двухфазной фиксации транзакций [7]. Такой вариант
репликации называется синхронной репликацией.
Хотя этот механизм может быть просто необходим для некоторого класса систем, в которых
все копии данных требуется поддерживать в абсолютно синхронном состоянии (например, в
случае финансовых операций), ему свойственны определенные недостатки. В частности,
транзакция не сможет быть завершена, если один из сайтов с копией реплицируемых данных
окажется недоступным. Кроме того, множество сообщений, необходимых для координации
процесса синхронизации данных, создают существенную дополнительную нагрузку на
корпоративную сеть.
Многие коммерческие распределенные СУБД предоставляют другой механизм репликации,
получивший название асинхронного. Он предусматривает обновление целевых баз данных
после выполнения обновления исходной базы данных. Задержка в восстановлении
106
согласованности данных может варьироваться от нескольких секунд до нескольких часов или
даже дней. Однако рано или поздно данные во всех копиях будут приведены в синхронное
состояние. Хотя такой подход нарушает принцип независимости распределенных данных, он
вполне может пониматься как приемлемый компромисс между целостностью данных и их
доступностью, причем последнее может быть важнее для организаций, чья деятельность
допускает работу с копией данных, необязательно точно синхронизованной на текущий
момент.
9.5.3.2. Функции службы репликации
В качестве базового уровня служба репликации распределенных данных должна быть
способна копировать данные из одной базы данных в другую синхронно или асинхронно.
Кроме того, существует множество других функций, которые должны поддерживаться,
включая следующие [7].
 Масштабируемость. Служба репликации должна эффективно обрабатывать как малые,
так и большие объемы данных.
 Отображение и трансформация. Служба репликации должна поддерживать репликацию
данных в гетерогенных системах, использующих несколько платформ. Это может быть
связано с необходимостью отображения и преобразования данных из одной модели
данных в другую или же для преобразования некоторого типа данных в соответствующий
тип данных, но для среды другой СУБД.
 Репликация объектов. Должна существовать возможность реплицировать объекты,
отличные от обычных данных. Например, в некоторых системах допускается репликация
индексов и хранимых процедур (или триггеров).
 Средства определения схемы репликации. Система должна предоставлять механизм,
позволяющий привилегированным пользователям задавать данные и объекты,
подлежащие репликации.
 Механизм
подписки.
Система
должна
включать
механизм,
позволяющий
привилегированным пользователям оформлять подписку на данные и другие подлежащие
репликации объекты.
 Механизм инициализации. Система должна включать средства, обеспечивающие
инициализацию вновь создаваемой реплики.
9.5.3.3. Схемы владения данными
Владение данными определяет, какому из сайтов будет предоставлена привилегия
обновления данных _ Основными типами схем владения являются [7]:
 « ведущий/ведомый »;
 «рабочий поток»;
 «повсеместное обновление».
Последний вариант иногда называют одноранговой, или симметричной репликацией.
При организации владения данными по схеме «ведущий/ведомый» асинхронно
реплицируемые данные принадлежат одному из сайтов, называемому ведущим, или первичным,
и могут обновляться только на нем. Здесь можно провести аналогию между издателем и
подписчиками. Издатель (ведущий сайт) публикует свои данные. Все остальные сайты только
лишь подписываются на данные, принадлежащие ведущему сайту, т.е. имеют собственные
локальные копии, доступные им только для чтения. Потенциально каждый из сайтов может
играть роль ведущего для различных, не перекрывающихся наборов данных. Однако в системе
может существовать только один сайт, на котором располагается ведущая обновляемая копия
каждого конкретного набора данных, а это означает, что конфликты обновления данных в
системе полностью исключены. Ниже приводится несколько примеров возможных вариантов
использования этой схемы репликации.
 Системы, поддержки принятия решений (ППР). Данные из одной или более
распределенных баз данных могут выгружаться в отдельную, локальную систему ППР,
где они будут только считываться при выполнении различных видов анализа.
107

Централизованное распределение или распространение информации. Распространение
данных имеет место в тех случаях, когда данные обновляются только в центральном
звене системы, после чего реплицируются их копии, доступные только для чтения. Этот
вариант репликации данных показан на рис.5.6,а.
 Консолидация удаленной информации. Консолидация данных имеет место в тех случаях,
когда обновление данных выполняется локально, поле чего их копии, доступные только
для чтения, отсылаются в общее хранилище. В этой схеме каждый из сайтов автономно
владеет некоторой частью данных. Этот вариант репликации данных показан на рис. 5.6,
б.
 Поддержка мобильных пользователей. Поддержка работы мобильных пользователей
получила в последние годы очень широкое распространение. Сотрудники многих
организаций вынуждены постоянно перемещаться с места на место и работать за
пределами офисов. Разработано несколько методов предоставления необходимых данных
мобильным пользователям. Одним из них и является репликация. В этом случае по
требованию пользователя данные загружаются с локального сервера его рабочей группы.
Обновления, выполненные клиентом для данных рабочей группы или центрального
сайта, обрабатываются сходным образом.
Ведущий сайт может владеть данными всей таблицы, и в этом случае все остальные сайты
являются лишь подписчиками на копии этой таблицы, доступные только для чтения. В
альтернативном варианте многие сайты владеют отдельными фрагментами таблицы, а
остальные сайты могут выступать как подписчики копий каждого из этих фрагментов,
доступных им только для чтения. Этот тип репликации называют асимметричной репликацией.
Как и в случае схемы «ведущий/ведомый», в модели «рабочий поток» удается избежать
появления конфликтов обновления, хотя данной модели свойствен больший динамизм. Схема
владения «рабочий поток» позволяет передавать право обновления реплицируемых данных от
одного сайта другому. Однако в каждый конкретный момент времени существует только один
сайт, имеющий право обновлять некоторый конкретный набор данных. Типичным примером
использования схемы рабочего потока является система обработки заказов, в которой работа с
каждым заказом выполняется в несколько этапов, например оформление заказа, контроль
кредитоспособности, выписка счета, доставка и т.д.
Рис. 5.6. Владение данными по схеме «ведущий/ведомый»:
а) распределение данных; б) консолидация данных
Централизованные системы позволяют приложениям, выполняющим отдельные этапы
обработки, получать доступ и обновлять данные в одной интегрированной базе данных. Каждое
108
приложение обновляет данные о заказе по очереди тогда и только тогда, когда состояние заказа
указывает, что предыдущий этап обработки уже завершен. В модели владения «рабочий поток»
приложения могут быть распределены по различным сайтам, и когда данные реплицируются и
пересылаются на следующий сайт в цепочке, вместе с ними передается и право на их
обновление, как показано на рис. 5.7.
У двух предыдущих моделей есть одно общее свойство: в любой заданный момент времени
только один сайт имеет право обновлять данные. Всем остальным сайтам доступ к репликам
данным будет разрешен только для чтения. В некоторых случаях это ограничение оказывается
слишком жестким.
Схема владения с повсеместным обновлением создает равноправную среду, в которой
множество сайтов имеют одинаковые права на обновление реплицируемых данных. В
результате локальные сайты получают возможность работать автономно, даже в тех случаях,
когда другие сайты недоступны.
Рис. 5.7. Схема владения «рабочий поток»
Разделение права владения может вызвать возникновение в системе конфликтов, поэтому
служба репликации в этой схеме должна использовать тот или иной метод выявления и
разрешения конфликтов.
9.5.3.4. Сохранение целостности транзакций
Первые попытки реализации механизма репликации по самой своей сути не
предусматривали сохранения целостности транзакций [7]. Данные копировались без
сохранения свойства атомарности транзакций, что потенциально могло привести к утрате
целостности распределенных данных. Этот подход проиллюстрирован на рис. 5.8, а.
В данном случае транзакция, состоящая на исходном сайте из нескольких операций
обновления данных в различных таблицах, в процессе репликации преобразовывалась в серию
отдельных транзакций, каждая из которых обновляла данные в одной из таблиц. Если часть
этих транзакций на целевом сайте завершалась успешно, а остальная часть – нет, то
согласованность информации между двумя базами данных утрачивалась.
109
Рис. 5.8. Репликация транзакций:
а) без соблюдения свойства атомарности; б) с соблюдением атомарности транзакций
В противоположность этому, на рис. 5.8, б показан пример репликации с сохранением
структуры транзакции в исходной базе данных.
9.5.3.5. Моментальные снимки таблиц
Метод моментальных снимков таблиц позволяет асинхронно распространять результаты
изменений, выполненных в отдельных таблицах, группах таблиц, представлениях или
фрагментах таблиц в соответствии с заранее установленным графиком [7].
Общий подход к созданию моментальных снимков состоит в использовании файла журнала
восстановления базы данных, который позволяет минимизировать уровень дополнительной
нагрузки на систему. Основная идея состоит в том, что файл журнала является лучшим
источником для получения сведений об изменениях в исходных данных. Достаточно иметь
механизм, который будет обращаться к файлу журнала для выявления изменений в исходных
данных, после чего распространять обнаруженные изменения на целевые базы данных, не
оказывая никакого влияния на нормальное функционирование исходной системы. Различные
СУБД реализуют подобный механизм по-разному: в некоторых случаях данный процесс
является частью самого сервера СУБД, тогда как в других случаях он реализуется как
независимый внешний сервер.
Для отправки сведений об изменениях на другие сайты целесообразно применять метод
организации очередей. Если произойдет отказ сетевого соединения или целевого сайта,
сведения об изменениях могут сохраняться в очередях до тех пор, пока соединение не будет
восстановлено. Для гарантии сохранения согласованности данных порядок доставки сведений
на целевые сайты должен сохранять исходную очередность внесения изменений.
9.5.3.6. Триггеры базы данных
Альтернативный подход заключается в предоставлении пользователям возможности
создавать собственные приложения, выполняющие репликацию данных с использованием
механизма триггеров базы данных.
В этом случае на пользователей возлагается ответственность за написание тех триггерных
процедур, которые будут вызываться при возникновении соответствующих событий, например
при создании новых записей или обновлении уже существующих. Хотя подобный подход
предоставляет большую гибкость, чем механизм создания моментального снимка, ему также
110
присущи определенные недостатки.
 Отслеживание запуска и выполнение триггерных процедур создает дополнительную
нагрузку на систему.
 Триггеры выполняются при каждом изменении строки в ведущей таблице. Если ведущая
таблица подвержена частым обновлениям, вызов триггерных процедур может создать
существенную дополнительную нагрузку на приложения и сетевые соединения. В
противоположность этому, при использовании моментальных снимков все выполненные
изменения пересылаются за одну операцию.
 Триггеры не могут выполняться в соответствии с некоторым графиком. Они
выполняются в тот момент, когда происходит обновление данных в ведущей таблице.
Моментальные снимки могут создаваться в соответствии с установленным графиком или
даже вручную. В любом случае это позволяет исключить дополнительную нагрузку от
репликации данных в периоды пиковой нагрузки на систему.
 Если реплицируется несколько связанных таблиц, синхронизация их репликации может
быть достигнута за счет использования механизма групповых обновлений. Решить эту
задачу с помощью триггеров существенно сложнее.
 Аннулирование результатов выполнения триггер-ной процедуры в случае отмены или
отката транзакции – достаточно сложная задача.
9.5.3.7. Выявление и разрешение конфликтов
Когда несколько сайтов могут независимо вносить изменения в реплицируемые данные,
необходимо использовать некоторый механизм, позволяющий выявлять конфликтующие
обновления данных и восстанавливать согласованность информации в базе. Простейший
механизм обнаружения конфликтов в отдельной таблице состоит в рассылке исходным сайтом
как новых, так и исходных значений измененных данных для каждой строки, которая была
обновлена с момента последней синхронизации копий. На целевом сайте сервер репликации
должен сравнить с полученными значениями каждую строку в целевой базе данных, которая
была локально изменена за данный период. Однако этот метод требует установки
дополнительных соглашений для обнаружения других типов конфликтов, например нарушения
ссылочной целостности между двумя таблицами.
Было предложено несколько различных механизмов разрешения конфликтов, однако чаще
всего применяются следующие [7].
 Самая ранняя или самая поздняя временная отметка. Изменяются соответственно
данные с самой ранней или самой поздней временной отметкой.
 Приоритеты сайтов. Применяется обновление, поступившее с сайта с наибольшим
приоритетом.
 Дополняющие и усредненные обновления. Введенные изменения обобщаются. Этот
вариант разрешения конфликтов может использоваться в тех случаях, когда обновление
атрибута выполняется операциями, записанными в форме отклонений.
 Минимальное или максимальное значение. Применяются обновления, соответствующие
столбцу с минимальным или максимальным значением.
 По решению пользователя. АБД создает собственную процедуру разрешения конфликта.
Для устранения различных типов конфликтов могут быть подготовлены различные
процедуры.
 Сохранение информации для принятия решения вручную. Сведения о конфликте
записываются в журнал ошибок для последующего анализа и устранения
администратором базы данных вручную.
9.6. Обеспечение прозрачности
В определении РСУБД, приведенном в разд.5.1, утверждается, что система должна
обеспечить прозрачность распределенного хранения данных для конечного пользователя. Под
прозрачностью понимается сокрытие от пользователей деталей реализации системы. Например,
111
в централизованной СУБД обеспечение независимости программ от данных также можно
рассматривать как одну из форм прозрачности – в данном случае от пользователя скрываются
изменения, происходящие в определении и организации хранения данных.
Распределенные СУБД могут обеспечивать различные уровни прозрачности. Однако в
любом случае преследуется одна и та же цель: сделать работу с распределенной базой данных
совершенно аналогичной работе с обычной централизованной СУБД. Выделяют четыре
основных типа прозрачности, которые могут иметь место в системе с распределенной базой
данных [7].
 Прозрачность распределейности.
 Прозрачность транзакций.
 Прозрачность выполнения.
 Прозрачность использования.
Следует отметить, что полная прозрачность не всегда принимается как одна из целевых
установок. В [7] указывается, что приложения, написанные с учетом полной прозрачности
доступа в географически распределенной базе данных, обычно характеризуются
недостаточными управляемостью, модульностью и производительностью обработки
сообщений.
9.6.1. Прозрачность распределенности
Прозрачность распределенности базы данных позволяет конечным пользователям
воспринимать базу данных как единое логическое целое. Если СУРБД обеспечивает
прозрачность распределенности, то пользователю не требуется каких-либо знаний о
фрагментации данных (прозрачность фрагментации) или их размещении (прозрачность
расположения).
Если пользователю необходимо иметь сведения о фрагментации данных и расположении
фрагментов, то этот тип прозрачности называют прозрачностью локального отображения.
Прозрачность фрагментации является самым высоким уровнем прозрачности
распределейности. Если СУРБД обеспечивает прозрачность фрагментации, то пользователю не
требуется знать, как именно фрагментированы данные. В этом случае доступ к данным
осуществляется на основе глобальной схемы и пользователю нет необходимости указывать
имена фрагментов или расположение данных.
Пользователь применяет те же самые SQL-операторы, которые потребовалось бы ввести для
получения необходимых результатов в централизованной системе.
Прозрачность расположения представляет собой средний уровень прозрачности
распределейности. В этом случае пользователь должен иметь сведения о способах
фрагментации данных в системе, но не нуждается в сведениях о расположении данных. При
наличии в системе прозрачности расположения в запросах следует указывать имена
используемых фрагментов.
Кроме того, дополнительно необходимо воспользоваться операциями соединения (или
подзапросами), поскольку некоторые атрибуты могут находиться в разных фрагментах.
Основное преимущество прозрачности расположения состоит в том, что база данных может
быть подвергнута физической реорганизации и это не окажет никакого влияния на программы
приложений, осуществляющих к ней доступ.
С прозрачностью расположения очень тесно связан еще один тип прозрачности –
прозрачность репликации. Он означает, что пользователю не требуется иметь сведения о
существующей репликации фрагментов. Под прозрачностью репликации подразумевается
прозрачность расположения реплик. Однако могут существовать системы, которые не
обеспечивают прозрачности расположения, но поддерживают прозрачность репликации.
Прозрачность локального отображения – самый низкий уровень прозрачности
распределенности. При наличии в системе прозрачности локального отображения пользователю
необходимо указывать как имена используемых фрагментов, так и расположение
соответствующих элементов данных.
Очевидно, что в данном случае запрос имеет более сложный вид и на его подготовку
112
потребуется больше времени, чем в двух предыдущих случаях. Маловероятно, чтобы система,
предоставляющая только такой уровень прозрачности распределенности, была приемлема для
конечного пользователя.
Прямым следствием обсуждавшихся выше вариантов прозрачности распределенности
является требование наличия прозрачности именования. Как и в случае централизованной базы
данных, каждый элемент распределенной базы данных должен иметь уникальное имя.
Следовательно, СУРБД должна гарантировать, что никакие два сайта системы не смогут
создать некоторый объект базы данных, имеющий одно и то же имя.
Одним из вариантов решения этой проблемы является создание центрального сервера имен,
который будет нести ответственность за полную уникальность всех существующих в системе
имен. Однако подобному подходу свойственны такие недостатки, как:
 утрата определенной части локальной автономии;
 появление проблем с производительностью (поскольку центральный сайт превращается в
узкое место всей системы);
 снижение доступности – если центральный сайт по какой-либо причине станет
недоступным, все остальные сайты системы не смогут создавать никаких новых объектов
базы данных [7].
Альтернативное решение состоит в использовании префиксов, помещаемых в имена
объектов в качестве идентификатора сайта, создавшего этот объект [7]. Аналогичным образом,
необходимо иметь возможность идентифицировать каждый фрагмент и каждую его копию.
Однако подобный подход приводит к утрате прозрачности распределенности.
Подход, который позволяет преодолеть недостатки, свойственные обоим упомянутым
методам, состоит в использовании алиасов, создаваемых для каждого из объектов базы данных
[7]. Задача преобразования алиаса в истинное имя соответствующего объекта базы данных
возлагается на СУРБД.
9.6.2. Прозрачность транзакций
Прозрачность транзакций в среде распределенных СУБД означает, что при выполнении
любых распределенных транзакций гарантируется сохранение целостности и согласованности
распределенной базы данных.
Распределенная транзакция осуществляет доступ к данным, сохраняемым более чем в одном
местоположении. Каждая из транзакций разделяется на несколько субтранзакций – по одной
для каждого сайта, к данным которого осуществляется доступ. На удаленных сайтах
субтранзакции представляются агентами.
Неделимость остается фундаментальной концепцией понятия транзакции и в случае
распределенных транзакций, однако дополнительно СУРБД должна гарантировать неделимость
и каждой из ее субтранзакций [7]. Следовательно, СУРБД должна гарантировать не только
синхронизацию субтранзакций с другими локальными транзакциями, выполняющимися
параллельно с ними на одном сайте, но и обеспечить синхронизацию субтранзакций с
глобальными транзакциями, выполняющимися одновременно с ними на этом и других сайтах
системы. Прозрачность транзакций в распределенных СУБД дополнительно усложняется за
счет наличия фрагментации, распределения данных и использования репликации. Существуют
два дополнительных аспекта прозрачности транзакций, таких как прозрачность
параллельности и прозрачность отказов.
Прозрачность параллельности обеспечивается СУБРД в том случае, если результаты всех
параллельно выполняемых транзакций (как распределенных, так и нераспределенных)
генерируются независимо и являются логически согласующимися с результатами, которые
были бы получены в том случае, если бы все эти транзакции выполнялись последовательно в
некотором произвольном порядке, по одной в каждый момент времени. В случае
распределенных СУБД имеют место дополнительные усложнения, связанные с
необходимостью гарантировать, что как глобальные, так и локальные транзакции не могут
оказывать влияния друг на друга. Кроме того, СУРБД должны гарантировать согласованность
всех субтранзакций каждой глобальной транзакции.
113
Наличие в системе репликации еще более усложняет проблему организации параллельной
обработки в системе. Если одна из копий реплицируемых данных подвергается обновлению,
сведения об этом в конечном счете должны быть представлены в каждой из существующих
копий. В данном случае наиболее очевидная стратегия – сделать распространение сведений об
изменении частью исходной транзакции, оформив его как еще одну атомарную операцию.
Однако, если один из содержащих копию измененных данных сайтов окажется в момент
внесения изменения недоступным из-за отказа на самом сайте или в канале связи, то
выполнение транзакции будет отложено до тех пор, пока этот сайт вновь не станет доступным.
Если существует большое количество копий данных, то вероятность успешного завершения
транзакции уменьшается в экспоненциальной зависимости от их числа. Альтернативной
стратегией является ограничение распространения сведений об изменении только теми
сайтами, которые в данный момент доступны. На остальные сайты сведения об изменении
поступят, как только они вновь станут доступными.
Дополнительной стратегией могла бы быть выдача разрешения обновлять копии асинхронно,
через некоторое время после внесения исходного обновления. Задержка в восстановлении
целостности может варьироваться от нескольких секунд до нескольких часов [7].
Любая централизованная СУБД должна включать механизм восстановления, который в
подверженной различным сбоям и отказам среде будет гарантировать атомарность выполнения
транзакций – либо все операции транзакции будут завершены, либо ни одна из них. Если
транзакция выполнена, внесенные ею изменения приобретают длительный характер. Среди
отказов централизованных СУБД выделяют: сбои системы, отказ носителей, ошибки в
программах, небрежность персонала, стихийные бедствия и действия злоумышленников. В
распределенных СУБД необходимо дополнительно учитывать следующее:
 возможность потери сообщения;
 возможность отказа линии связи;
 аварийный останов одного из сайтов;
 расчленение сетевых соединений.
СУРБД должна гарантировать атомарность глобальных транзакций, т.е. должна
синхронизировать выполнение глобальной транзакции так, чтобы все ее субтранзакции были
успешно завершены до финальной операции фиксации результатов глобальной транзакции.
9.6.3. Прозрачность выполнения
Прозрачность выполнения требует, чтобы работа в среде СУРБД выполнялась аналогично
работе в централизованной СУБД. В распределенной среде не должно быть видно снижение
производительности из-за наличия медленных сетевых соединений и т.д. Прозрачность
выполнения требует также, чтобы СУРБД могла находить наиболее эффективные стратегии
выполнения запросов.
В централизованной СУБД обработчик запросов оценивает каждый запрос на доступ к
данным и находит оптимальную стратегию его выполнения в виде упорядоченной
последовательности операций с базой данных. В распределенной среде обработчик запросов
отображает запрос на доступ к данным в упорядоченную последовательность операций с
локальными базами данных. При этом дополнительная сложность возникает из-за
необходимости учитывать наличие фрагментации, репликации и определенной схемы
размещения данных.
Обработчик распределенных запросов должен знать:
 к какому фрагменту следует обратиться;
 какую копию фрагмента использовать, если его данные реплицируются;
 какое из местоположений должно использоваться [7].
Обработчик распределенных запросов вырабатывает стратегию выполнения, которая
является оптимальной с точки зрения некоторой стоимостной функции. Обычно используются
следующие показатели:
 время доступа, включающее физический доступ к данным на диске;
 время работы центрального процессора, затрачиваемое на обработку данных в первичной
114
памяти;
 время, необходимое для передачи данных по сетевым соединениям.
Первые два фактора аналогичны тем, которые учитываются в централизованных системах
для оптимизации выполнения запросов. Но в СУРБД доминирующую роль играет время
передачи данных по сетевым соединениям, что особенно актуально для глобальных сетей.
Скорость передачи в таких каналах может составлять лишь несколько Кбайт в секунду. В
подобных ситуациях при оптимизации можно игнорировать затраты на ввод/вывод и
использование ЦП. Однако некоторые сетевые соединения имеют скорость передачи данных,
сравнимую со скоростью доступа к дискам (в локальных сетях). В этом случае целесообразно
учитывать все три указанных показателя.
9.6.4. Прозрачность использования
Прозрачность использования СУБД позволяет скрыть от пользователя тот факт, что на
разных сайтах могут функционировать различные локальные СУБД. Данный тип прозрачности
является самым сложным, и применим только для гетерогенных распределенных систем.
Таким образом, концепция прозрачности не может быть отнесена к типу «все или ничего»,
так как может быть организована на нескольких различных уровнях. Каждый из уровней
подразумевает определенный набор соглашений между сайтами системы. Так, при полной
прозрачности сайты должны следовать общему соглашению по вопросам модели данных,
интерпретации схем, представления данных и т.п. В непрозрачных системах единственным
соглашением является формат обмена данными и набор функциональных возможностей,
предоставляемых каждым сайтом в системе.
С точки зрения конечного пользователя полная прозрачность желательна. Но с точки зрения
АБД локальной базы полностью прозрачный доступ связан с трудностями осуществления
контроля. Традиционный способ работы с представлениями, используемый для построения
защитного механизма, в такой ситуации может оказаться неэффективным. Например, механизм
работы с представлениями языка SQL позволяет ограничивать доступ к базовым таблицам или
подмножеству данных базовой таблицы и разрешать его только конкретным пользователям.
Однако он не позволяет также легко ограничивать доступ к данным на основе набора
критериев, отличных от имени пользователя,
Проще обеспечить подобный тип функциональности с помощью процедур, которые будут
запускаться удаленным пользователем. В этом случае локальные пользователи смогут работать
с данными так же, как они работали прежде, при использовании стандартного механизма
защиты СУБД. Однако удаленные пользователи смогут получать только такой тип доступа к
данным, который реализован в предоставленном им наборе процедур, подобно тому, как это
делается в объектно-ориентированных системах. Подобный тип федеральной архитектуры
реализовать проще, чем обеспечить полную прозрачность системы, к тому же он предоставляет
более высокий уровень локальной автономности.
115
10. ЗАЩИТА И СЕКРЕТНОСТЬ ДАННЫХ.
(ЛЕКЦИИ 15-16)
10.1. Понятие информационной безопасности. Основные составляющие
10.1.1. Понятие информационной безопасности
Под информационной безопасностью мы будем понимать защищенность информации и
поддерживающей инфраструктуры от случайных или преднамеренных воздействий
естественного или искусственного характера, которые могут нанести неприемлемый ущерб
субъектам информационных отношений, в том числе владельцам и пользователям информации
и поддерживающей инфраструктуры.
Защита информации — это комплекс мероприятий, направленных на обеспечение
информационной безопасности.
Таким образом, правильный с методологической точки зрения подход к проблемам
информационной безопасности начинается с выявления субъектов информационных
отношений и интересов этих субъектов, связанных с использованием информационных систем
(ИС). Угрозы информационной безопасности — это оборотная сторона использования
информационных технологий.
Из этого положения можно вывести два важных следствия:
1. Трактовка проблем, связанных с информационной безопасностью, для разных категорий
субъектов может существенно различаться. Для иллюстрации достаточно сопоставить
режимные государственные организации и учебные институты. В первом случае "пусть
лучше все сломается, чем враг узнает хоть один секретный бит", во втором — "да нет у
нас никаких секретов, лишь бы все работало".
2. Информационная безопасность не сводится исключительно к защите от
несанкционированного доступа к информации, это принципиально более широкое
понятие. Субъект информационных отношений может пострадать (понести убытки и/или
получить моральный ущерб) не только от несанкционированного доступа, но и от
поломки системы, вызвавшей перерыв в работе. Более того, для многих открытых
организаций (например, учебных) собственно защита от несанкционированного доступа к
информации стоит по важности отнюдь не на первом месте.
Возвращаясь к вопросам терминологии, отметим, что термин "компьютерная безопасность"
(как эквивалент или заменитель ИБ) представляется нам слишком узким. Компьютеры —
только одна из составляющих информационных систем, и хотя наше внимание будет
сосредоточено в первую очередь на информации, которая хранится, обрабатывается и
передается с помощью компьютеров, ее безопасность определяется всей совокупностью
составляющих и, в первую очередь, самым слабым звеном, которым в подавляющем
большинстве случаев оказывается человек (записавший, например, свой пароль на
"горчичнике", прилепленном к монитору).
Согласно определению информационной безопасности, она зависит не только от
компьютеров, но и от поддерживающей инфраструктуры, к которой можно отнести системы
электро-, водо- и теплоснабжения, кондиционеры, средства коммуникаций и, конечно,
обслуживающий персонал. Эта инфраструктура имеет самостоятельную ценность, но нас будет
интересовать лишь то, как она влияет на выполнение информационной системой предписанных
ей функций.
Обратим внимание, что в определении ИБ перед существительным "ущерб" стоит
прилагательное "неприемлемый". Очевидно, застраховаться от всех видов ущерба невозможно,
тем более невозможно сделать это экономически целесообразным способом, когда стоимость
защитных средств и мероприятий не превышает размер ожидаемого ущерба. Значит, с чем-то
приходится мириться и защищаться следует только от того, с чем смириться никак нельзя.
Иногда таким недопустимым ущербом является нанесение вреда здоровью людей или
состоянию окружающей среды, но чаще порог неприемлемости имеет материальное (денежное)
116
выражение, а целью защиты информации становится уменьшение размеров ущерба до
допустимых значений.
10.1.2. Основные составляющие информационной безопасности
Информационная безопасность — многогранная, область деятельности, в которой успех
может принести только систематический, комплексный подход.
Спектр интересов субъектов, связанных с использованием информационных систем, можно
разделить на следующие категории: обеспечение доступности, целостности и
конфиденциальности информационных ресурсов и поддерживающей инфраструктуры.
Доступность — это возможность за приемлемое время получить требуемую
информационную услугу.
Под целостностью подразумевается актуальность и непротиворечивость информации, ее
защищенность от разрушения и несанкционированного изменения.
Наконец, конфиденциальность — это защита от несанкционированного доступа к
информации.
Информационные системы создаются для получения определенных информационных услуг.
Если по тем или иным причинам предоставить эти услуги пользователям становится
невозможно, это, очевидно, наносит ущерб всем субъектам информационных отношений.
Поэтому, не противопоставляя доступность остальным аспектам, мы выделяем ее как
важнейший элемент информационной безопасности.
Особенно ярко ведущая роль доступности проявляется в разного рода системах управления
— производством, транспортом и т.п. Внешне менее драматичные, но также весьма неприятные
последствия — и материальные, и моральные — может иметь длительная недоступность
информационных услуг, которыми пользуется большое количество людей (продажа
железнодорожных и авиабилетов, банковские услуги и т.п.).
Целостность можно подразделить на статическую (понимаемую как неизменность
информационных объектов) и динамическую (относящуюся к корректному выполнению
сложных действий (транзакций)). Средства контроля динамической целостности применяются,
в частности, при анализе потока финансовых сообщений с целью выявления кражи,
переупорядочения или дублирования отдельных сообщений.
Целостность оказывается важнейшим аспектом ИБ в тех случаях, когда информация служит
"руководством к действию". Рецептура лекарств, предписанные медицинские процедуры, набор
и характеристики комплектующих изделий, ход технологического процесса — все это примеры
информации, нарушение целостности которой может оказаться в буквальном смысле
смертельным. Неприятно и искажение официальной информации, будь то текст закона или
страница Web-сервера какой-либо правительственной организации.
Конфиденциальность — самый проработанный у нас в стране аспект информационной
безопасности.
К
сожалению,
практическая
реализация
мер
по
обеспечению
конфиденциальности современных информационных систем наталкивается в России на
серьезные трудности. Во-первых, сведения о технических каналах утечки информации
являются закрытыми, так что большинство пользователей лишено возможности составить
представление о потенциальных рисках. Во-вторых, на пути пользовательской криптографии
как основного средства обеспечения конфиденциальности стоят многочисленные
законодательные преграды и технические проблемы.
Если вернуться к анализу интересов различных категорий субъектов информационных
отношений, то почти для всех, кто реально использует ИС, на первом месте стоит доступность.
Практически не уступает ей по важности целостность — какой смысл в информационной
услуге, если она содержит искаженные сведения?
Наконец, конфиденциальные моменты есть также у многих организаций (даже в
упоминавшихся выше учебных институтах стараются не разглашать сведения о зарплате
сотрудников) и отдельных пользователей (например, пароли).
117
10.2. Распространение объектно-ориентированного подхода на
информационную безопасность
10.2.1. Основные понятия объектно-ориентированного подхода
Объектно-ориентированный подход использует объектную декомпозицию, то есть поведение
системы описывается в терминах взаимодействия объектов.
Прежде всего, введем понятие класса. Класс — это абстракция множества сущностей
реального мира, объединенных общностью структуры и поведения.
Объект — это элемент класса, то есть абстракция определенной сущности.
Подчеркнем, что объекты активны, у них есть не только внутренняя структура, но и
поведение, которое описывается так называемыми методами объекта. Например, может быть
определен класс "пользователь", характеризующий "пользователя вообще", то есть
ассоциированные с пользователями данные и их поведение (методы). После этого может быть
создан объект "пользователь Иванов" с соответствующей конкретизацией данных и, возможно,
методов.
Следующую группу важнейших понятий объектного подхода составляют инкапсуляция,
наследование и полиморфизм.
Основным инструментом борьбы со сложностью в объектно-ориентированном подходе
является инкапсуляция — сокрытие реализации объектов (их внутренней структуры и деталей
реализации методов) с предоставлением вовне только строго определенных интерфейсов.
Понятие "полиморфизм" может трактоваться как способность объекта принадлежать более
чем одному классу. Введение этого понятия отражает необходимость смотреть на объекты под
разными углами зрения, выделять при построении абстракций разные аспекты сущностей
моделируемой предметной области, не нарушая при этом целостности объекта.
Наследование означает построение новых классов на основе существующих с возможностью
добавления или переопределения данных и методов. Наследование является важным
инструментом борьбы с размножением сущностей без необходимости. Общая информация не
дублируется, указывается только то, что меняется. При этом класс-потомок помнит о своих
"корнях".
Очень важно и то, что наследование и полиморфизм в совокупности наделяют объектноориентированную систему способностью к относительно безболезненной эволюции. Средства
информационной безопасности приходится постоянно модифицировать и обновлять, и если
нельзя сделать так, чтобы это было экономически выгодно, ИБ из инструмента защиты
превращается в обузу.
Пополним рассмотренный выше классический набор понятий объектно-ориентированного
подхода еще двумя понятиями: грани объекта и уровня детализации.
Объекты реального мира обладают, как правило, несколькими относительно независимыми
характеристиками. Применительно к объектной модели будем называть такие характеристики
гранями. Мы уже сталкивались с тремя основными гранями ИБ — доступностью, целостностью
и конфиденциальностью.
Понятие уровня детализации важно не только для визуализации объектов, но и для
систематического рассмотрения сложных систем, представленных в иерархическом виде. Само
по себе оно очень простое: если очередной уровень иерархии рассматривается с уровнем
детализации п > 0, то следующий — с уровнем (п — 1). Объект с уровнем детализации 0
считается атомарным.
Понятие уровня детализации показа позволяет рассматривать иерархии с потенциально
бесконечной высотой, варьировать детализацию как объектов в целом, так и их граней.
10.2.2. Применение объектно-ориентированного подхода к рассмотрению
защищаемых систем
Попытаемся применить объектно-ориентированный подход к вопросам информационной
безопасности.
118
Проблема обеспечения информационной безопасности — комплексная, защищать
приходится сложные системы, и сами защитные средства тоже сложны, поэтому нам
понадобятся все введенные понятия. Начнем с понятия грани.
Фактически три грани уже были введены: это доступность, целостность и
конфиденциальность. Их можно рассматривать относительно независимо, и считается, что если
все они обеспечены, то обеспечена и ИБ в целом (то есть субъектам информационных
отношений не будет нанесен неприемлемый ущерб).
Таким образом, мы структурировали нашу цель. Теперь нужно структурировать средства ее
достижения. Введем следующие грани:
законодательные меры обеспечения информационной безопасности;
административные меры (приказы и другие действия руководства организаций, связанных с
защищаемыми информационными системами);
процедурные меры (меры безопасности, ориентированные на людей);
программно-технические меры.
В принципе, их можно рассматривать и как результат варьирования уровня детализации (по
этой причине мы будем употреблять словосочетания "законодательный уровень",
"процедурный уровень" и т.п.). Законы и нормативные акты ориентированы на всех субъектов
информационных отношений независимо от их организационной принадлежности (это могут
быть как юридические, так и физические лица) в пределах страны (международные конвенции
имеют даже более широкую область действия), административные меры — на всех субъектов в
пределах организации, процедурные - на отдельных людей (или небольшие категории
субъектов), программно-технические — на оборудование и программное обеспечение. При
такой трактовке в переходе с уровня на уровень можно усмотреть применение наследования
(каждый следующий уровень не отменяет, а дополняет предыдущий), а также полиморфизма
(субъекты выступают сразу в нескольких ипостасях — например, как инициаторы
административных мер и как обычные пользователи, обязанные этим мерам подчиняться).
Очевидно, для всех выделенных, относительно независимых граней действует принцип
инкапсуляции (это и значит, что грани "относительно независимы"). Более того, эти две
совокупности граней можно назвать ортогональными, поскольку для фиксированной грани в
одной совокупности (например, доступности) грани в другой совокупности должны пробегать
все множество возможных значений (нужно рассмотреть законодательные, административные,
процедурные и программно-технические меры). Ортогональных совокупностей не должно быть
много; думается, двух совокупностей с числом элементов, соответственно, 3 и 4 уже
достаточно, так как они дают 12 комбинаций.
Продемонстрируем теперь, как можно рассматривать защищаемую ИС, варьируя уровень
детализации.
Пусть интересы субъектов информационных отношений концентрируются вокруг ИС некой
организации, располагающей двумя территориально разнесенными производственными
площадками, на каждой из которых есть серверы, обслуживающие своих и внешних
пользователей, а также пользователи, нуждающиеся во внутренних и внешних сервисах. Одна
из площадок оборудована внешним подключением (то есть имеет выход в Internet).
При взгляде с нулевым уровнем детализации мы увидим лишь то, что у организации есть
информационная система (см. рис. 2.0).
Подобная точка зрения может показаться несостоятельной, но это не так. Уже здесь
необходимо учесть законы, применимые к организациям, располагающим информационными
системами. Возможно, какую-либо информацию нельзя хранить и обрабатывать на
компьютерах, если ИС не была аттестована на соответствие определенным требованиям. На
административном уровне могут быть декларированы цели, ради которых создавалась ИС,
119
общие правила закупок, внедрения новых компонентов, эксплуатации и т.п. На процедурном
уровне нужно определить требования к физической безопасности ИС и пути их выполнения,
правила противопожарной безопасности и т.п. На программно-техническом уровне могут быть
определены предпочтительные аппаратно-программные платформы и т.п.
По каким критериям проводить декомпозицию ИС — в значительной степени дело вкуса.
Будем считать, что на первом уровне детализации делаются видимыми сервисы и пользователи,
точнее, разделение на клиентскую и серверную часть (рис. 2.1).
На этом уровне следует сформулировать требования к сервисам (к самому их наличию, к
доступности, целостности и конфиденциальности предоставляемых информационных услуг),
изложить способы выполнения этих требований, определить общие правила поведения
пользователей, необходимый уровень их предварительной подготовки, методы контроля их
поведения, порядок поощрения и наказания и т.п. Могут быть сформулированы требования и
предпочтения по отношению к серверным и клиентским платформам.
На втором уровне детализации мы увидим следующее (см. рис. 2.2).
На этом уровне нас все еще не интересует внутренняя структура ИС организации, равно как
и детали Internet. Констатируется только существование связи между этими сетями, наличие в
них пользователей, а также предоставляемых и внутренних сервисов. Что это за сервисы, пока
неважно.
Находясь на уровне детализации 2, мы должны учитывать законы, применимые к
организациям, ИС которых снабжены внешними подключениями. Речь идет о допустимости
такого подключения, о его защите, об ответственности пользователей, обращающихся к
внешним сервисам, и об ответственности организаций, открывающих свои сервисы для
120
внешнего доступа. Конкретизация аналогичной направленности, с учетом наличия внешнего
подключения, должна быть выполнена на административном, процедурном и программнотехническом уровнях.
Увеличивая уровень детализации, можно разглядеть две разнесенные производственные
площадки и каналы связи между ними, распределение сервисов и пользователей по этим
площадкам и средства обеспечения безопасности внутренних коммуникаций, специфику
отдельных сервисов, разные категории пользователей и т.п.
10.3. НАИБОЛЕЕ РАСПРОСТРАНЕННЫЕ УГРОЗЫ
10.3.1. Основные определения и критерии классификации угроз
Угроза — это потенциальная возможность определенным образом нарушить
информационную безопасность.
Попытка реализации угрозы называется атакой, а тот, кто предпринимает такую попытку, —
злоумышленником. Потенциальные злоумышленники называются источниками угрозы.
Чаще всего угроза является следствием наличия уязвимых мест в защите информационных
систем (таких, например, как возможность доступа посторонних лиц к критически важному
оборудованию или ошибки в программном обеспечении).
Промежуток времени от момента, когда появляется возможность использовать слабое место,
и до момента, когда пробел ликвидируется, называется окном опасности, ассоциированным с
данным уязвимым местом. Пока существует окно опасности, возможны успешные атаки на ИС.
Если речь идет об ошибках в ПО, то окно опасности "открывается" с появлением средств
использования ошибки и ликвидируется при наложении заплат, ее исправляющих.
Для большинства уязвимых мест окно опасности существует сравнительно долго (несколько
дней, иногда — недель), поскольку за это время должны произойти следующие события:
1) должно стать известно о средствах использования пробела в защите;
2) должны быть выпущены соответствующие заплаты;
3) заплаты должны быть установлены в защищаемой ИС.
Новые уязвимые места и средства их использования появляются постоянно; это значит, вопервых, что почти всегда существуют окна опасности и, во-вторых, что отслеживание таких
окон должно производиться постоянно, а выпуск и наложение заплат — как можно более
оперативно.
Отметим, что некоторые угрозы нельзя считать следствием каких-то ошибок или просчетов;
они существуют в силу самой природы современных ИС. Например, угроза отключения
электричества или выхода его параметров за допустимые границы существует в силу
зависимости аппаратного обеспечения ИС от качественного электропитания.
Рассмотрим наиболее распространенные угрозы, которым подвержены современные
информационные системы. Иметь представление о возможных угрозах, а также об уязвимых
местах, которые эти угрозы обычно эксплуатируют, необходимо для того, чтобы выбирать
наиболее экономичные средства обеспечения безопасности. Слишком много мифов существует
в сфере информационных технологий (вспомним все ту же "Проблему 2000"), поэтому
незнание в данном случае ведет к перерасходу средств и, что еще хуже, к концентрации
ресурсов там, где они не особенно нужны, за счет ослабления действительно уязвимых
направлений.
Подчеркнем, что само понятие "угроза" в разных ситуациях зачастую трактуется по-разному.
Например, для подчеркнуто открытой организации угроз конфиденциальности может просто не
существовать — вся информация считается общедоступной; однако в большинстве случаев
нелегальный доступ представляется серьезной опасностью. Иными словами, угрозы, как и все в
ИБ, зависят от интересов субъектов информационных отношений (и от того, какой ущерб
является для них неприемлемым). Впрочем, многие угрозы (например, пожар) опасны для всех.
Угрозы можно классифицировать по нескольким критериям:
1) по
аспекту
информационной
безопасности
(доступность,
целостность,
121
конфиденциальность), против которого угрозы направлены в первую очередь;
2) по компонентам информационных систем, на которые угрозы нацелены (данные,
программы, аппаратура, поддерживающая инфраструктура);
3) по
способу
осуществления
(случайные/преднамеренные
действия
природного/техногенного характера);
4) по расположению источника угроз (внутри/вне рассматриваемой ИС).
В качестве основного критерия мы будем использовать первый (по аспекту ИБ), привлекая
при необходимости остальные.
10.3.2. Наиболее распространенные угрозы доступности
Самыми частыми и самыми опасными (с точки зрения размера ущерба) являются
непреднамеренные ошибки штатных пользователей, операторов, системных администраторов и
других лиц, обслуживающих информационные системы.
Иногда такие ошибки и являются собственно угрозами (неправильно введенные данные или
ошибка в программе, вызвавшая крах системы), иногда они создают уязвимые места, которыми
могут воспользоваться злоумышленники (таковы обычно ошибки администрирования). По
некоторым данным, до 65% потерь — следствие непреднамеренных ошибок.
Пожары и наводнения не приносят столько бед, сколько безграмотность и небрежность в
работе.
Очевидно, самый радикальный способ борьбы с непреднамеренными ошибками —
максимальная автоматизация и строгий контроль.
Другие угрозы доступности классифицируем по компонентам ИС, на которые нацелены
угрозы:
1) отказ пользователей;
2) внутренний отказ информационной системы;
3) отказ поддерживающей инфраструктуры.
Обычно применительно к пользователям рассматриваются следующие угрозы:
1) нежелание работать с информационной системой (чаще всего проявляется при
необходимости осваивать новые возможности и при расхождении между запросами
пользователей и фактическими возможностями и техническими характеристиками);
2) невозможность работать с системой в силу отсутствия соответствующей подготовки
(недостаток общей компьютерной грамотности, неумение интерпретировать диагностические
сообщения, неумение работать с документацией и т.п.);
3) невозможность работать с системой в силу отсутствия технической поддержки (неполнота
документации, недостаток справочной информации и т.п.).
Основными источниками внутренних отказов являются:
1) отступление (случайное или умышленное) от установленных правил эксплуатации;
2) выход системы из штатного режима эксплуатации в силу случайных или преднамеренных
действий пользователей или обслуживающего персонала (превышение расчетного числа
запросов, чрезмерный объем обрабатываемой информации и т.п.);
3) ошибки при (пере)конфигурировании системы;
4) отказы программного и аппаратного обеспечения;
5) разрушение данных;
6) разрушение или повреждение аппаратуры.
По отношению к поддерживающей инфраструктуре рекомендуется рассматривать
следующие угрозы:
1) нарушение работы (случайное или умышленное) систем связи, электропитания, водои/или теплоснабжения, кондиционирования;
2) разрушение или повреждение помещений;
3) невозможность или нежелание обслуживающего персонала и/или пользователей
выполнять свои обязанности (гражданские беспорядки, аварии на транспорте,
террористический акт или его угроза, забастовка и т.п.).
Весьма опасны так называемые "обиженные" сотрудники — нынешние и бывшие. Как
122
правило, они стремятся нанести вред организации - "обидчику", например:
1) испортить оборудование;
2) встроить логическую бомбу, которая со временем разрушит программы и/или данные;
3) удалить данные.
Обиженные сотрудники, даже бывшие, знакомы с порядками в организации и способны
нанести немалый ущерб. Необходимо следить за тем, чтобы при увольнении сотрудника его
права доступа (логического и физического) к информационным ресурсам аннулировались.
Опасны, разумеется, стихийные бедствия и события, воспринимаемые как стихийные
бедствия,— пожары, наводнения, землетрясения, ураганы. По статистике, на долю огня, воды и
тому подобных "злоумышленников" (среди которых самый опасный — перебой
электропитания) приходится 13% потерь, нанесенных информационным системам.
10.3.3. Некоторые примеры угроз доступности
Угрозы доступности могут выглядеть грубо — как повреждение или даже разрушение
оборудования (в том числе носителей данных). Такое повреждение может вызываться
естественными причинами (чаще всего — грозами). К сожалению, находящиеся в массовом
использовании источники бесперебойного питания не защищают от мощных кратковременных
импульсов, и случаи выгорания оборудования — не редкость.
В принципе, мощный кратковременный импульс, способный разрушить данные на
магнитных носителях, можно сгенерировать и искусственным образом - с помощью так
называемых высокоэнергетических радиочастотных пушек. Но, наверное, в наших условиях
подобную угрозу следует все же признать надуманной.
Действительно опасны протечки водопровода и отопительной системы. Часто организации,
чтобы сэкономить на арендной плате, снимают помещения в домах старой постройки, делают
косметический ремонт, но не меняют ветхие трубы.
Летом, в сильную жару, норовят сломаться кондиционеры, установленные в серверных
залах, набитых дорогостоящим оборудованием. В результате значительный ущерб наносится и
репутации, и кошельку организации.
Общеизвестно, что периодически необходимо производить резервное копирование данных.
Однако даже если это предложение выполняется, резервные носители зачастую хранят
небрежно, не обеспечивая их защиту от вредного воздействия окружающей среды. И когда
требуется восстановить данные, оказывается, что эти самые носители никак не желают
читаться.
Перейдем теперь к угрозам доступности, которые будут похитрее засоров канализации. Речь
пойдет о программных атаках на доступность.
В качестве средства вывода системы из штатного режима эксплуатации может
использоваться агрессивное потребление ресурсов (обычно — полосы пропускания сетей,
вычислительных возможностей процессоров или оперативной памяти). По расположению
источника угрозы такое потребление подразделяется на локальное и удаленное. При просчетах
в конфигурации системы локальная программа способна практически монополизировать
процессор и/или физическую память, сведя скорость выполнения других программ к нулю.
Простейший пример удаленного потребления ресурсов — атака, получившая наименование
"SYN-наводнение". Она представляет собой попытку переполнить таблицу "полуоткрытых"
TCP-соединений сервера (установление соединений начинается, но не заканчивается). Такая
атака по меньшей мере затрудняет установление новых соединений со стороны легальных
пользователей, то есть сервер выглядит как недоступный.
По отношению к атаке "Papa Smurf' уязвимы сети, воспринимающие ping-пакеты с
широковещательными адресами. Ответы на такие пакеты "съедают" полосу пропускания.
Удаленное потребление ресурсов в последнее время проявляется в особенно опасной форме как скоординированные распределенные атаки, когда на сервер с множества разных адресов с
максимальной скоростью направляются вполне легальные запросы на соединение и/или
обслуживание.
123
10.3.4. Основные угрозы целостности
На втором месте по размерам ущерба (после непреднамеренных ошибок и упущений) стоят
кражи и подлоги. По данным газеты USA Today, еще в 1992 году в результате подобных
противоправных действий с использованием персональных компьютеров американским
организациям был нанесен общий ущерб в размере 882 миллионов долларов. Можно
предположить, что реальный ущерб был намного больше, поскольку многие организации по
понятным причинам скрывают такие инциденты; не вызывает сомнений, что в наши дни ущерб
от такого рода действий вырос многократно.
В большинстве случаев виновниками оказывались штатные сотрудники организаций,
отлично знакомые с режимом работы и мерами защиты. Это еще раз подтверждает опасность
внутренних угроз, хотя говорят и пишут о них значительно меньше, чем о внешних.
Ранее мы проводили различие между статической и динамической целостностью. С целью
нарушения статической целостности злоумышленник (как правило, штатный сотрудник) может:
1) ввести неверные данные;
2) изменить данные.
Иногда изменяются содержательные данные, иногда — служебная информация. Угрозой
целостности является не только фальсификация или изменение данных, но и отказ от
совершенных действий. Если нет средств обеспечить "неотказуемость", компьютерные данные
не могут рассматриваться в качестве доказательства.
Потенциально уязвимы с точки зрения нарушения целостности не только данные, но и
программы.
Угрозами динамической целостности являются нарушение атомарности транзакций,
переупорядочение, кража, дублирование данных или внесение дополнительных сообщений
(сетевых пакетов и т.п.). Соответствующие действия в сетевой среде называются активным
прослушиванием.
10.3.5. Основные угрозы конфиденциальности
Конфиденциальную информацию можно разделить на предметную и служебную. Служебная
информация (например, пароли пользователей) не относится к определенной предметной
области, в информационной системе она играет техническую роль, но ее раскрытие особенно
опасно, поскольку оно чревато получением несанкционированного доступа ко всей
информации, в том числе предметной.
Даже если информация хранится в компьютере или предназначена для компьютерного
использования, угрозы ее конфиденциальности могут носить некомпьютерный и вообще
нетехнический характер.
Многим людям приходится выступать в качестве пользователей не одной, а целого ряда
систем (информационных сервисов). Если для доступа к таким системам используются
многоразовые пароли или иная конфиденциальная информация, то наверняка эти данные будут
храниться не только в голове, но и в записной книжке или на листках бумаги, которые
пользователь часто оставляет на рабочем столе, а то и попросту теряет. И дело здесь не в
неорганизованности людей, а в изначальной непригодности парольной схемы. Невозможно
помнить много разных паролей; рекомендации по их регулярной (по возможности — частой)
смене только усугубляют положение, заставляя применять несложные схемы чередования или
вообще стараться свести дело к двум-трем легко запоминаемым (и столь же легко
угадываемым) паролям.
Описанный класс уязвимых мест можно назвать размещением конфиденциальных данных в
среде, где им не обеспечена (зачастую — и не может быть обеспечена) необходимая защита.
Угроза же состоит в том, что кто-то не откажется узнать секреты, которые сами просятся в
руки. Помимо паролей, хранящихся в записных книжках пользователей, в этот класс попадает
передача конфиденциальных данных в открытом виде (в разговоре, в письме, по сети), которая
делает возможным перехват данных. Для атаки могут использоваться разные технические
средства (подслушивание или прослушивание разговоров, пассивное прослушивание сети и
124
т.п.), но идея одна — осуществить доступ к данным в тот момент, когда они наименее
защищены.
Угрозу перехвата данных следует принимать во внимание не только при начальном
конфигурировании ИС, но и, что очень важно, при всех изменениях. Весьма опасной угрозой
являются выставки, на которые многие организации, недолго думая, отправляют оборудование
из производственной сети, со всеми хранящимися на них данными. Остаются прежними
пароли, при удаленном доступе они продолжают передаваться в открытом виде. Это плохо
даже в пределах защищенной сети организации; в объединенной сети выставки — это слишком
суровое испытание честности всех участников.
Еще один пример изменения, о котором часто забывают, — хранение данных на резервных
носителях. Для защиты данных на основных носителях применяются развитые системы
управления доступом; копии же нередко просто лежат в шкафах и получить доступ к ним могут
многие.
Кражи оборудования являются угрозой не только для резервных носителей, но и для
компьютеров, особенно портативных. Часто ноутбуки оставляют без присмотра на работе или в
автомобиле, иногда просто теряют.
Опасной нетехнической угрозой конфиденциальности являются методы моральнопсихологического воздействия, такие как маскарад — выполнение действий под видом лица,
обладающего полномочиями для доступа к данным.
К неприятным угрозам, от которых трудно защищаться, можно отнести злоупотребление
полномочиями. На многих типах систем привилегированный пользователь (например
системный администратор) способен прочитать любой (незашифрованный) файл, получить
доступ к почте любого пользователя и т.д. Другой пример - нанесение ущерба при сервисном
обслуживании. Обычно сервисный инженер получает неограниченный доступ к оборудованию
и имеет возможность действовать в обход программных защитных механизмов.
10.4. Административный уровень информационной безопасности
10.4.1. Основные понятия
К административному уровню информационной безопасности относятся действия общего
характера, предпринимаемые руководством организации.
Главная цель мер административного уровня — сформировать программу работ в области
информационной безопасности и обеспечить ее выполнение, выделяя необходимые ресурсы и
контролируя состояние дел.
Основой программы является политика безопасности, отражающая подход организации к
защите своих информационных активов. Руководство каждой организации должно осознать
необходимость поддержания режима безопасности и выделения на эти цели значительных
ресурсов.
Политика безопасности строится на основе анализа рисков, которые признаются реальными
для информационной системы организации. Когда риски проанализированы и стратегия
защиты определена, составляется программа обеспечения информационной безопасности. Под
эту программу выделяются ресурсы, назначаются ответственные, определяется порядок
контроля выполнения программы и т.п.
Термин "политика безопасности" является не совсем точным переводом английского
словосочетания "security policy", однако в данном случае калька лучше отражает смысл этого
понятия, чем лингвистически более верные "правила безопасности". Мы будем иметь в виду не
отдельные правила или их наборы (такого рода решения выносятся на процедурный уровень,
речь о котором впереди), а стратегию организации в области информационной безопасности.
Для выработки стратегии и проведения ее в жизнь нужны, несомненно, политические решения,
принимаемые на самом высоком уровне.
Под политикой безопасности мы будем понимать совокупность документированных
решений, принимаемых руководством организации и направленных на защиту информации и
125
ассоциированных с ней ресурсов.
ИС организации и связанные с ней интересы субъектов — это сложная система, для
рассмотрения которой необходимо применять объектно-ориентированный подход и понятие
уровня детализации.
Чтобы рассматривать ИС предметно, с использованием актуальных данных, следует
составить карту информационной системы. Эта карта, разумеется, должна быть изготовлена в
объектно-ориентированном стиле, с возможностью варьировать не только уровень детализации,
но и видимые грани объектов. Техническим средством составления, сопровождения и
визуализации подобных карт может служить свободно распространяемый каркас какой-либо
системы управления.
10.4.2. Политика безопасности
С практической точки зрения политику безопасности целесообразно рассматривать на трех
уровнях детализации. К верхнему уровню можно отнести решения, затрагивающие
организацию в целом. Они носят весьма общий характер и, как правило, исходят от руководства
организации. Примерный список подобных решений может включать в себя следующие
элементы:
 решение сформировать или пересмотреть комплексную программу обеспечения
информационной безопасности, назначение ответственных за продвижение
программы;
 формулировка целей, которые преследует организация в области информационной
безопасности, определение общих направлений в достижении этих целей;
 обеспечение базы для соблюдения законов и правил;
 формулировка административных решений по тем вопросам реализации программы
безопасности, которые должны рассматриваться на уровне организации в целом.
Для политики верхнего уровня цели организации в области информационной безопасности
формулируются в терминах целостности, доступности и конфиденциальности. Если
организация отвечает за поддержание критически важных баз данных, на первом плане может
стоять уменьшение числа потерь, повреждений или искажений данных. Для организации,
занимающейся продажей компьютерной техники, вероятно, важна актуальность информации о
предоставляемых услугах и ценах и ее доступность максимальному числу потенциальных
покупателей. Руководство режимного предприятия в первую очередь заботится о защите от
несанкционированного доступа, то есть о конфиденциальности.
Политика верхнего уровня имеет дело с тремя аспектами законопослушности и
исполнительской дисциплины. Во-первых, организация должна соблюдать существующие
законы. Во-вторых, следует контролировать действия лиц, ответственных за выработку
программы безопасности. Наконец, необходимо обеспечить определенную степень
исполнительности персонала, а для этого нужно выработать систему поощрений и наказаний.
К среднему уровню можно отнести вопросы, касающиеся отдельных аспектов
информационной безопасности, но важные для различных эксплуатируемых организацией
систем. Примеры таких вопросов — отношение к передовым (но, возможно, недостаточно
проверенным) технологиям, доступ в Internet (как совместить свободу доступа к информации с
защитой от внешних угроз?), использование домашних компьютеров, применение
пользователями неофициального программного обеспечения и т.д.
Политика среднего уровня должна для каждого аспекта освещать следующие темы:
Описание аспекта. Например, если рассмотреть применение пользователями
неофициального программного обеспечения, последнее можно определить как ПО, которое не
было одобрено и/или закуплено на уровне организации.
Область применения. Следует определить, где, когда, как, по отношению к кому и чему
применяется данная политика безопасности. Например, касается ли политика, связанная с
использованием неофициального программного обеспечения, организаций-субподрядчиков?
Затрагивает ли она сотрудников, пользующихся портативными и домашними компьютерами и
вынужденных переносить информацию на производственные машины?
126
Позиция организации по данному аспекту. Продолжая пример с неофициальным
программным обеспечением, можно представить себе позиции полного запрета, выработки
процедуры приемки подобного ПО и т.п. Позиция может быть сформулирована и в гораздо
более общем виде, как набор целей, которые преследует организация в данном аспекте. Вообще
стиль документов, определяющих политику безопасности (как и их перечень), в разных
организациях может сильно отличаться.
Роли и обязанности. В "политический" документ необходимо включить информацию о
должностных лицах, ответственных за реализацию политики безопасности. Например, если для
использования неофициального программного обеспечения сотрудникам требуется разрешение
руководства, должно быть известно, у кого и как его можно получить. Если неофициальное
программное обеспечение использовать нельзя, следует знать, кто следит за выполнением
данного правила.
Законопослушность. Политика должна содержать общее описание запрещенных действий и
наказаний за них.
Точки контакта. Должно быть известно, куда следует обращаться за разъяснениями,
помощью и дополнительной информацией. Обычно "точкой контакта" служит определенное
должностное лицо, а не конкретный человек, занимающий в данный момент данный пост.
Политика безопасности нижнего уровня относится к конкретным информационным
сервисам. Она включает в себя два аспекта — цели и правила их достижения, поэтому ее порой
трудно отделить от вопросов реализации. В отличие от двух верхних уровней, рассматриваемая
политика должна быть определена более подробно. Есть много вещей, специфичных для
отдельных видов услуг, которые нельзя единым образом регламентировать в рамках всей
организации. В то же время, эти вещи настолько важны для обеспечения режима безопасности,
что относящиеся к ним решения должны приниматься на управленческом, а не техническом
уровне. Приведем несколько примеров вопросов, на которые следует дать ответ в политике
безопасности нижнего уровня:
 кто имеет право доступа к объектам, поддерживаемым сервисом?
 при каких условиях можно читать и модифицировать данные?
 как организован удаленный доступ к сервису?
При формулировке целей политики нижнего уровня можно исходить из соображений
целостности, доступности и конфиденциальности, но нельзя на этом останавливаться. Ее цели
должны быть более конкретными. Например, если речь идет о системе расчета заработной
платы, можно поставить цель, чтобы только сотрудникам отдела кадров и бухгалтерии
позволялось вводить и модифицировать информацию. В более общем случае цели должны
связывать между собой объекты сервиса и действия с ними.
10.4.3. Программа безопасности
После того, как сформулирована политика безопасности, можно приступать к составлению
программы ее реализации и собственно к реализации.
Чтобы понять и реализовать какую-либо программу, ее нужно структурировать по уровням,
обычно в соответствии со структурой организации. В простейшем и самом распространенном
случае достаточно двух уровней — верхнего, или центрального, который охватывает всю
организацию, и нижнего, или служебного, который относится к отдельным услугам или
группам однородных сервисов.
Программу верхнего уровня возглавляет лицо, отвечающее за информационную
безопасность организации. У этой программы следующие главные цели:
 управление рисками (оценка рисков, выбор эффективных средств защиты);
 координация деятельности в области информационной безопасности, пополнение и
распределение ресурсов;
 стратегическое планирование;
 контроль деятельности в области информационной безопасности.
В рамках программы верхнего уровня принимаются стратегические решения по
обеспечению безопасности, оцениваются технологические новинки. Информационные
127
технологии развиваются очень быстро, и необходимо иметь четкую политику отслеживания и
внедрения новых средств.
Следует подчеркнуть, что программа верхнего уровня должна занимать строго определенное
место в деятельности организации, она должна официально приниматься и поддерживаться
руководством, а также иметь определенный штат и бюджет.
Цель программы нижнего уровня — обеспечить надежную и экономичную защиту
конкретного сервиса или группы однородных сервисов. На этом уровне решается, какие
следует использовать механизмы защиты; закупаются и устанавливаются технические средства;
выполняется повседневное администрирование; отслеживается состояние слабых мест и т.п.
Обычно за программу нижнего уровня отвечают администраторы сервисов.
10.5. Управление рисками
10.5.1. Основные понятия
Управление рисками рассматривается нами на административном уровне ИБ, поскольку
только руководство организации способно выделить необходимые ресурсы, инициировать и
контролировать выполнение соответствующих программ.
Вообще говоря, управление рисками, равно как и выработка собственной политики
безопасности, актуально только для тех организаций, информационные системы которых и/или
обрабатываемые данные можно считать нестандартными. Обычную организацию вполне
устроит типовой набор защитных мер, выбранный на основе представления о типичных рисках
или вообще без всякого анализа рисков.
Использование информационных систем связано с определенной совокупностью рисков.
Когда возможный ущерб неприемлемо велик, необходимо принять экономически оправданные
меры защиты. Периодическая (пере)оценка рисков необходима для контроля эффективности
деятельности в области безопасности и для учета изменений обстановки.
С количественной точки зрения уровень риска является функцией вероятности реализации
определенной угрозы (использующей некоторые уязвимые места), а также величины
возможного ущерба.
Таким образом, суть мероприятий по управлению рисками состоит в том, чтобы оценить их
размер, выработать эффективные и экономичные меры снижения рисков, а затем убедиться, что
риски заключены в приемлемые рамки (и остаются таковыми). Следовательно, управление
рисками включает в себя два вида деятельности, которые чередуются циклически:
1) (пере)оценка (измерение) рисков;
2) выбор эффективных и экономичных защитных средств (нейтрализация рисков).
По отношению к выявленным рискам возможны следующие действия:
 ликвидация риска (например, за счет устранения причины);
 уменьшение риска (например, за счет использования дополнительных защитных
средств);
 принятие риска (и выработка плана действия в соответствующих условиях);
 переадресация риска (например, путем заключения страхового соглашения).
Процесс управления рисками можно разделить на следующие этапы:
1. Выбор анализируемых объектов и уровня детализации их рассмотрения.
2. Выбор методологии оценки рисков.
3. Идентификация активов.
4. Анализ угроз и их последствий, выявление уязвимых мест в защите.
5. Оценка рисков.
6. Выбор защитных мер.
7. Реализация и проверка выбранных мер.
8. Оценка остаточного риска.
Этапы 6 и 7 относятся к выбору защитных средств (нейтрализации рисков), остальные — к
оценке рисков.
128
Уже перечисление этапов показывает, что управление рисками — процесс циклический. По
существу, последний этап — это оператор конца цикла, предписывающий вернуться к началу.
Риски нужно контролировать постоянно, периодически проводя их переоценку. Отметим, что
добросовестно выполненная и тщательно документированная первая оценка может
существенно упростить последующую деятельность.
10.5.2. Подготовительные этапы управления рисками
Выбор анализируемых объектов и уровня детализации их рассмотрения - первый шаг в
оценке рисков. Для небольшой организации допустимо рассматривать всю информационную
инфраструктуру; однако если организация крупная, всеобъемлющая оценка может потребовать
неприемлемых затрат времени и сил. В таком случае следует сосредоточиться на наиболее
важных сервисах, заранее соглашаясь с приближенностью итоговой оценки. Если важных
сервисов все еще много, выбираются те из них, риски для которых заведомо велики или
неизвестны.
Вообще говоря, уязвимым является каждый компонент информационной системы — от
сетевого кабеля, который могут прогрызть мыши, до базы данных, которая может быть
разрушена из-за неумелых действий администратора. Как правило, в сферу анализа невозможно
включить каждый винтик и каждый байт. Приходится останавливаться на некотором уровне
детализации, опять-таки отдавая себе отчет в приближенности оценки. Для новых систем
предпочтителен детальный анализ; старая система, подвергшаяся небольшим модификациям,
может быть проанализирована более поверхностно.
Очень важно выбрать разумную методологию оценки рисков. Целью оценки является
получение ответа на два вопроса: приемлемы ли существующие риски, и если нет, то какие
защитные средства стоит использовать. Значит, оценка должна быть количественной,
допускающей сопоставление с заранее выбранными границами допустимости и расходами на
реализацию новых регуляторов безопасности. Можно, конечно, попытаться получить для всех
анализируемых величин денежное выражение, высчитать все с точностью до копейки, но
большого смысла в этом нет. Практичнее пользоваться условными единицами. В простейшем и
вполне допустимом случае можно пользоваться трехбалльной шкалой.
Информационной основой сколько-нибудь крупной организации является сеть, поэтому в
число аппаратных активов следует включить компьютеры (серверы, рабочие станции, ПК),
периферийные устройства, внешние интерфейсы, кабельное хозяйство, активное сетевое
оборудование (мосты, маршрутизаторы и т.п.). К программным активам, вероятно, будут
отнесены операционные системы (сетевая, серверные и клиентские), прикладное программное
обеспечение, инструментальные средства, средства управления сетью и отдельными системами.
Важно зафиксировать, где (в каких узлах сети) хранится программное обеспечение, и из каких
узлов оно используется. Третьим видом информационных активов являются данные, которые
хранятся, обрабатываются и передаются по сети. Следует классифицировать данные по типам и
степени конфиденциальности, выявить места их хранения и обработки, способы доступа к ним.
Все это важно для оценки последствий нарушений информационной безопасности.
10.5.3. Основные этапы управления рисками
Этапы, предшествующие анализу угроз, можно считать подготовительными, поскольку,
строго говоря, они напрямую с рисками не связаны. Риск появляется там, где есть угрозы.
Краткий перечень наиболее распространенных угроз был рассмотрен нами ранее. К
сожалению, на практике угроз гораздо больше, причем далеко не все из них носят
компьютерный характер. Так, вполне реальной угрозой является наличие мышей и тараканов в
занимаемых организацией помещениях. Первые могут повредить кабели, вторые вызвать
короткое замыкание. Как правило, наличие той или иной угрозы является следствием пробелов
в защите информационной системы, которые, в свою очередь, объясняются отсутствием
некоторых сервисов безопасности или недостатками в реализующих их защитных механизмах.
Опасность прогрызания кабелей возникает не просто там, где есть мыши, она связана с
129
отсутствием или недостаточной прочностью защитной оболочки.
Первый шаг в анализе угроз — их идентификация. Рассматриваемые виды угроз следует
выбирать исходя из соображений здравого смысла (исключив, например, землетрясения, однако
не забывая о возможности захвата организации террористами), но в пределах выбранных видов
провести максимально подробный анализ.
Целесообразно выявлять не только сами угрозы, но и источники их возникновения — это
поможет в выборе дополнительных средств защиты. Например, нелегальный вход в систему
может стать следствием воспроизведения начального диалога, подбора пароля или
подключения к сети неавторизованного оборудования. Очевидно, для противодействия
каждому из перечисленных способов нелегального входа нужны свои механизмы безопасности.
После идентификации угрозы необходимо оценить вероятность ее осуществления.
Допустимо использовать при этом трехбалльную шкалу (низкая (1), средняя (2) и высокая (3)
вероятность).
Кроме вероятности осуществления, важен размер потенциального ущерба. Например,
пожары бывают нечасто, но ущерб от каждого из них, как правило, велик. Тяжесть ущерба
также можно оценить по трехбалльной шкале.
Оценивая размер ущерба, необходимо иметь в виду не только непосредственные расходы на
замену оборудования или восстановление информации, но и более отдаленные, такие как
подрыв репутации, ослабление позиций на рынке и т.п. Пусть, например, в результате дефектов
в управлении доступом к бухгалтерской информации сотрудники получили возможность
корректировать данные о собственной заработной плате. Следствием такого состояния дел
может стать не только перерасход бюджетных или корпоративных средств, но и полное
разложение коллектива, грозящее развалом организации.
Уязвимые места обладают свойством притягивать к себе не только злоумышленников, но и
сравнительно честных людей. Не всякий устоит перед искушением немного увеличить свою
зарплату, если есть уверенность, что это сойдет в рук. Поэтому, оценивая вероятность
осуществления угроз, целесообразно исходить не только из среднестатистических данных, но
учитывать также специфику конкретных информационных систем. Если в подвале дома,
занимаемого организацией, располагается сауна, а сам дом имеет деревянные перекрытия, то
вероятность пожара, к сожалению, оказывается существенно выше средней.
После того, как накоплены исходные данные и оценена степень неопределенности, можно
переходить к обработке информации, то есть собственно к оценке рисков. Вполне допустимо
применить такой простой метод, как умножение вероятности осуществления угрозы на
предполагаемый ущерб. Если для вероятности и ущерба использовать трехбалльную шкалу, то
возможных произведений будет шесть: 1, 2, 3, 4, 6 и 9. Первые два результата можно отнести к
низкому риску, третий и четвертый — к среднему, два последних — к высокому, после чего
появляется возможность снова привести их к трехбалльной шкале. По этой шкале и следует
оценивать приемлемость рисков. Правда, граничные случаи, когда вычисленная величина
совпала с приемлемой, целесообразно рассматривать более тщательно из-за приближенного
характера результата.
Если какие-либо риски оказались недопустимо высокими, необходимо их нейтрализовать,
реализовав дополнительные меры защиты. Как правило, для ликвидации или нейтрализации
уязвимого места, сделавшего угрозу реальной, существует несколько механизмов безопасности,
различных по эффективности и стоимости. Например, если велика вероятность нелегального
входа в систему, можно потребовать, чтобы пользователи выбирали длинные пароли (скажем,
не менее восьми символов), задействовать программу генерации паролей или закупить
интегрированную систему аутентификации на основе интеллектуальных карт. Если есть
вероятность умышленного повреждения сервера баз данных, что может иметь серьезные
последствия, можно врезать замок в дверь серверной комнаты или поставить около каждого
сервера по охраннику.
Оценивая стоимость мер защиты, приходится, разумеется, учитывать не только прямые
расходы на закупку оборудования и/или программ, но и расходы на внедрение новинки и, в
частности, обучение и переподготовку персонала. Эту стоимость также можно оценить по
трехбалльной шкале и затем сопоставить ее с разностью между вычисленным и допустимым
130
риском. Если по этому показателю новое средство оказывается экономически выгодным, его
можно взять на заметку (подходящих средств, вероятно, будет несколько). Однако если
средство окажется дорогим, его не следует сразу отбрасывать, памятуя о приближенности
расчетов.
Можно представить себе ситуацию, когда для нейтрализации риска не существует
эффективных и приемлемых по цене мер. Например, компания, базирующаяся в сейсмически
опасной зоне, не всегда может позволить себе строительство защищенной штаб-квартиры. В
таком случае приходится поднимать планку приемлемого риска и переносить центр тяжести на
смягчение последствий и выработку планов восстановления после аварий, стихийных бедствий
и иных происшествий. Продолжая пример с сейсмоопасностью, можно рекомендовать
регулярное тиражирование данных в другой город и овладение средствами восстановления
первичной базы данных.
10.6. Процедурный уровень информационной безопасности
10.6.1.Основные классы мер процедурного уровня
Мы приступаем к рассмотрению мер безопасности, которые ориентированы на людей, а не
на технические средства. Именно люди формируют режим информационной безопасности, и
они же оказываются главной угрозой, поэтому "человеческий фактор" заслуживает особого
внимания.
На процедурном уровне можно выделить следующие классы мер:
 управление персоналом;
 физическая защита;
 поддержание работоспособности;
 реагирование на нарушения режима безопасности;
 планирование восстановительных работ.
10.6.2. Управление персоналом
Управление персоналом начинается с приема нового сотрудника на работу и даже раньше —
с составления описания должности. Уже на данном этапе желательно подключить к работе
специалиста по информационной безопасности для определения компьютерных привилегий,
ассоциируемых с должностью.
Предварительное составление описания должности позволяет оценить ее критичность и
спланировать процедуру проверки и отбора кандидатов. Чем ответственнее должность, тем
тщательнее нужно проверять кандидатов: навести о них справки, быть может, побеседовать с
бывшими сослуживцами и т.д. Подобная процедура может быть длительной и дорогой, поэтому
нет смысла дополнительно усложнять ее. В то же время, неразумно и совсем отказываться от
предварительной проверки, чтобы случайно не принять на работу человека с уголовным
прошлым или психическим заболеванием.
Когда кандидат определен, он, вероятно, должен пройти обучение; по крайней мере, его
следует подробно ознакомить со служебными обязанностями, а также с нормами и
процедурами информационной безопасности. Желательно, чтобы меры безопасности были им
усвоены до вступления в должность и до заведения его системного счета с входным именем,
паролем и привилегиями. С момента заведения системного счета начинается его
администрирование, а также протоколирование и анализ действий пользователя.
Ликвидация системного счета пользователя, особенно в случае конфликта между
сотрудником и организацией, должна производиться максимально оперативно (в идеале —
одновременно с извещением о наказании или увольнении). Возможно и физическое
ограничение доступа к рабочему месту. Разумеется, если сотрудник увольняется, у него нужно
принять все его компьютерное хозяйство и, в частности, криптографические ключи, если
использовались средства шифрования.
131
10.6.3. Физическая защита
Безопасность информационной системы зависит от окружения, в котором она
функционирует. Необходимо принять меры для защиты зданий и прилегающей территории,
поддерживающей инфраструктуры, вычислительной техники, носителей данных.
Основной принцип физической защиты, соблюдение которого следует постоянно
контролировать, формулируется как "непрерывность защиты в пространстве и времени". Ранее
мы рассматривали понятие окна опасности. Для физической защиты таких окон быть не
должно.
Мы кратко рассмотрим следующие направления физической защиты:
 физическое управление доступом;
 противопожарные меры;
 защита поддерживающей инфраструктуры;
 защита от перехвата данных;
 защита мобильных систем.
Меры физического управления доступом позволяют контролировать и при необходимости
ограничивать вход и выход сотрудников и посетителей. Контролироваться может все здание
организации, а также отдельные помещения, например, те, где расположены серверы,
коммуникационная аппаратура и т.п.
Средства физического управления доступом известны давно. Это охрана, двери с замками,
перегородки, телекамеры, датчики движения и многое другое. Для выбора оптимального (по
критерию стоимость/эффективность) средства целесообразно провести анализ рисков (к этому
мы еще вернемся). Кроме того, есть смысл периодически отслеживать появление технических
новинок в данной области, стараясь максимально автоматизировать физическую защиту.
Профессия пожарника - одна из древнейших, но пожары по-прежнему случаются и наносят
большой ущерб. Мы не собираемся цитировать параграфы противопожарных инструкций или
изобретать новые методы борьбы с огнем - на это есть профессионалы. Отметим лишь
необходимость установки противопожарной сигнализации и автоматических средств
пожаротушения. Обратим также внимание на то, что защитные меры могут создавать новые
слабые места. Если на работу взят новый охранник, это, вероятно, улучшает физическое
управление доступом. Если же он по ночам курит и пьет, то ввиду повышенной
пожароопасности подобная мера защиты может только навредить.
К поддерживающей инфраструктуре можно отнести системы электро-, водо- и
теплоснабжения, кондиционеры и средства коммуникаций. В принципе, к ним применимы те
же требования целостности и доступности, что и к информационным системам. Для
обеспечения целостности нужно защищать оборудование от краж и повреждений. Для
поддержания доступности следует выбирать оборудование с максимальным временем
наработки на отказ, дублировать ответственные узлы и всегда иметь под рукой запчасти.
Отдельную проблему составляют аварии водопровода. Они происходят нечасто, но могут
нанести огромный ущерб. При размещении компьютеров необходимо принять во внимание
расположение водопроводных и канализационных труб и постараться держаться от них
подальше. Сотрудники должны знать, куда следует обращаться при обнаружении протечек.
Перехват данных может осуществляться самыми разными способами. Злоумышленник
может подсматривать за экраном монитора, читать пакеты, передаваемые по сети, производить
анализ побочных электромагнитных излучений и наводок (ПЭМИН) и т.д. Остается уповать на
повсеместное
использование
криптографии,
стараться
максимально
расширить
контролируемую территорию, разместившись в тихом особнячке, поодаль от других домов,
пытаться держать под контролем линии связи (например, заключать их в надувную оболочку с
обнаружением прокалывания), но самое разумное, вероятно, — постараться осознать, что для
коммерческих систем обеспечение конфиденциальности является все-таки не главной задачей.
Мобильные и портативные компьютеры — заманчивый объект кражи. Их часто оставляют
без присмотра, в автомобиле или на работе, и похитить такой компьютер совсем несложно. То и
дело средства массовой информации сообщают о том, что какой-нибудь офицер английской
132
разведки или американский военный лишился таким образом движимого имущества. Мы
настоятельно рекомендуем шифровать данные на жестких дисках таких компьютеров.
10.6.4. Поддержание работоспособности
Далее рассмотрим ряд рутинных мероприятий, направленных на поддержание
работоспособности информационных систем. Именно здесь таится наибольшая опасность.
Нечаянные ошибки системных администраторов и пользователей грозят повреждением
аппаратуры, разрушением программ и данных; в лучшем случае они создают бреши в защите,
которые делают возможной реализацию угроз.
Недооценка факторов безопасности в повседневной работе — ахиллесова пята многих
организаций. Дорогие средства безопасности теряют смысл, если они плохо документированы,
конфликтуют с другим программным обеспечением, а пароль системного администратора не
менялся с момента установки.
Можно выделить следующие направления повседневной деятельности:
 поддержка пользователей;
 поддержка программного обеспечения;
 конфигурационное управление;
 резервное копирование;
 управление носителями;
 документирование;
 регламентные работы.
Поддержка пользователей подразумевает прежде всего консультирование и оказание
помощи при решении разного рода проблем. Иногда в организациях создают для этой цели
специальный "справочный стол", но чаще от пользователей отбивается системный
администратор. Очень важно в потоке вопросов уметь выявлять проблемы, связанные с
информационной безопасностью. Так, многие трудности пользователей, работающих на
персональных компьютерах, могут быть следствием заражения вирусами. Целесообразно
фиксировать вопросы пользователей, чтобы выявлять их типичные ошибки и выпускать
памятки с рекомендациями для распространенных ситуаций.
Поддержка программного обеспечения — одно из важнейших средств обеспечения
целостности информации. Прежде всего, необходимо следить за тем, какое программное
обеспечение установлено на компьютерах. Второй аспект поддержки программного
обеспечения — контроль за отсутствием неавторизованного изменения программ и прав
доступа к ним.
Конфигурационное управление позволяет контролировать и фиксировать изменения,
вносимые в программную конфигурацию. Прежде всего, необходимо застраховаться от
случайных или непродуманных модификаций, уметь как минимум возвращаться к прошлой,
работающей, версии. Фиксация изменений позволит легко восстановить текущую версию после
аварии.
Резервное копирование необходимо для восстановления программ и данных после аварий. И
здесь целесообразно автоматизировать работу, как минимум, сформировав компьютерное
расписание создания полных и инкрементальных копий, а как максимум — воспользовавшись
соответствующими программными продуктами. Нужно также наладить размещение копий в
безопасном месте, защищенном от несанкционированного доступа, пожаров, протечек, то есть
от всего, что может привести к краже или повреждению носителей. Целесообразно иметь
несколько экземпляров резервных копий и часть из них хранить вне территории организации,
защищаясь таким образом от крупных аварий и аналогичных инцидентов. Время от времени в
тестовых целях следует проверять возможность восстановления информации с копий.
Управлять носителями необходимо для обеспечения физической защиты и учета дискет,
лент, печатных выдач и т.п. Управление носителями должно обеспечивать
конфиденциальность, целостность и доступность информации, хранящейся вне компьютерных
систем. Под физической защитой здесь понимается не только отражение попыток
несанкционированного доступа, но и предохранение от вредных влияний окружающей среды
133
(жары, холода, влаги, магнетизма). Управление носителями должно охватывать весь жизненный
цикл — от закупки до выведения из эксплуатации.
Документирование — неотъемлемая часть информационной безопасности. В виде
документов оформляется почти все — от политики безопасности до журнала учета носителей.
Важно, чтобы документация была актуальной, отражала именно текущее состояние дел, причем
в непротиворечивом виде.
Регламентные работы — очень серьезная угроза безопасности. Сотрудник, осуществляющий
регламентные работы, получает исключительный доступ к системе, и на практике очень трудно
проконтролировать, какие именно действия он совершает. Здесь на первый план выходит
степень доверия к тем, кто выполняет работу.
10.6.5. Реагирование на нарушения режима безопасности
Программа безопасности, принятая организацией, должна предусматривать набор
оперативных мероприятий, направленных на обнаружение и нейтрализацию нарушений режима
информационной безопасности. Важно, чтобы в подобных случаях последовательность
действий была спланирована заранее, поскольку меры нужно принимать срочные и
скоординированные.
Реакция на нарушения режима безопасности преследует три главные цели:
 локализация инцидента и уменьшение наносимого вреда;
 выявление нарушителя;
 предупреждение повторных нарушений.
В организации должен быть человек, доступный 24 часа в сутки (лично, по телефону,
пейджеру или электронной почте), который отвечает за реакцию на нарушения. Все должны
знать координаты этого человека и обращаться к нему при первых признаках опасности. В
общем, как при пожаре, нужно знать, куда звонить, и что делать до приезда пожарной команды.
10.6.6. Планирование восстановительных работ
Ни одна организация не застрахована от серьезных аварий, вызванных естественными
причинами, действиями злоумышленника, халатностью или некомпетентностью. В то же время,
у каждой организации есть функции, которые руководство считает критически важными, они
должны выполняться несмотря ни на что. Планирование восстановительных работ позволяет
подготовиться к авариям, уменьшить ущерб от них и сохранить способность к
функционированию хотя бы в минимальном объеме.
Отметим, что меры информационной безопасности можно разделить на три группы, в
зависимости от того, направлены ли они на предупреждение, обнаружение или ликвидацию
последствий атак. Большинство мер носит предупредительный характер. Оперативный анализ
регистрационной информации и некоторые аспекты реагирования на нарушения (так
называемый активный аудит) служат для обнаружения и отражения атак. Планирование
восстановительных работ, очевидно, можно отнести к последней из трех перечисленных групп.
Процесс планирования восстановительных работ можно разделить на следующие этапы:
 выявление критически важных функций организации, установление приоритетов;
 идентификация ресурсов, необходимых для выполнения критически важных
функций;
 определение перечня возможных аварий;
 разработка стратегии восстановительных работ;
 подготовка к реализации выбранной стратегии;
 проверка стратегии.
Планируя восстановительные работы, следует отдавать себе отчет в том, что полностью
сохранить функционирование организации не всегда возможно. Необходимо выявить
критически важные функции, без которых организация теряет свое лицо, и даже среди
критичных функций расставить приоритеты, чтобы как можно быстрее и с минимальными
затратами возобновить работу после аварии.
134
Информационная инфраструктура включает в себя следующие элементы:
 компьютеры;
 программы и данные;
 информационные сервисы внешних организаций;
 документацию.
Нужно подготовиться к тому, что на "запасном аэродроме", куда организация будет
эвакуирована после аварии, аппаратная платформа может отличаться от исходной.
Соответственно, следует продумать меры поддержания совместимости по программам и
данным.
Документация важна хотя бы потому, что не вся информация, с которой работает
организация, представлена в электронном виде. Скорее всего, план восстановительных работ
напечатан на бумаге.
10.7. Основные программно-технические меры
10.7.1. Основные понятия программно-технического уровня информационной
безопасности
Программно-технические меры, то есть меры, направленные на контроль компьютерных
сущностей — оборудования, программ и/или данных, образуют последний и самый важный
рубеж информационной безопасности. Напомним, что ущерб наносят в основном действия
легальных пользователей, по отношению к которым процедурные регуляторы малоэффективны.
Главные враги — некомпетентность и неаккуратность при выполнении служебных
обязанностей, и только программно-технические меры способны им противостоять.
Компьютеры помогли автоматизировать многие области человеческой деятельности. Вполне
естественным представляется желание возложить на них и обеспечение собственной
безопасности. Даже физическую защиту все чаще поручают не охранникам, а интегрированным
компьютерным системам, что позволяет одновременно отслеживать перемещения сотрудников
и по организации, и по информационному пространству.
Следует, однако, учитывать, что быстрое развитие информационных технологий не только
предоставляет обороняющимся новые возможности, но и объективно затрудняет обеспечение
надежной защиты, если опираться исключительно на меры программно-технического уровня.
Причин тому несколько:
 повышение быстродействия микросхем, развитие архитектур с высокой степенью
параллелизма позволяет методом грубой силы преодолевать барьеры (прежде всего
криптографические), ранее казавшиеся неприступными;
 развитие сетей и сетевых технологий, увеличение числа связей между
информационными системами, рост пропускной способности каналов расширяют
круг злоумышленников, имеющих техническую возможность организовывать атаки;
 появление новых информационных сервисов ведет и к образованию новых уязвимых
мест как "внутри" сервисов, так и на их стыках;
 конкуренция среди производителей программного обеспечения заставляет сокращать
сроки разработки, что приводит к снижению качества тестирования и выпуску
продуктов с дефектами защиты;
 навязываемая потребителям парадигма постоянного наращивания мощности
аппаратного и программного обеспечения не позволяет долго оставаться в рамках
надежных, апробированных конфигураций и, кроме того, вступает в конфликт с
бюджетными ограничениями, из-за чего снижается доля ассигнований на
безопасность.
Перечисленные соображения лишний раз подчеркивают важность комплексного подхода к
информационной безопасности, а также необходимость гибкой позиции при выборе и
сопровождении программно-технических регуляторов.
Центральным для программно-технического уровня является понятие сервиса безопасности.
135
Следуя объектно-ориентированному подходу, при рассмотрении информационной системы с
единичным уровнем детализации мы увидим совокупность предоставляемых ею
информационных сервисов. Назовем их основными. Чтобы они могли функционировать и
обладали требуемыми свойствами, необходимо несколько уровней дополнительных
(вспомогательных) сервисов — от СУБД и мониторов транзакций до ядра операционной
системы и оборудования.
К вспомогательным относятся сервисы безопасности (мы уже сталкивались с ними при
рассмотрении стандартов и спецификаций в области ИБ); среди них нас в первую очередь будут
интересовать универсальные, высокоуровневые, допускающие использование различными
основными и вспомогательными сервисами. Далее мы рассмотрим следующие сервисы:
 идентификация и аутентификация;
 управление доступом;
 протоколирование и аудит;
 шифрование;
 контроль целостности;
 экранирование;
 анализ защищенности;
 обеспечение отказоустойчивости;
 обеспечение безопасного восстановления;
 туннелирование;
 управление.
Для проведения классификации сервисов безопасности и определения их места в общей
архитектуре меры безопасности можно разделить на следующие виды:
 превентивные, препятствующие нарушениям ИБ;
 меры обнаружения нарушений;
 локализующие, сужающие зону воздействия нарушений;
 меры по выявлению нарушителя;
 меры восстановления режима безопасности.
Большинство сервисов безопасности попадает в число превентивных, и это, безусловно,
правильно. Аудит и контроль целостности способны помочь в обнаружении нарушений;
активный аудит, кроме того, позволяет запрограммировать реакцию на нарушение с целью
локализации и/или прослеживания. Направленность сервисов отказоустойчивости и
безопасного восстановления очевидна. Наконец, управление играет инфраструктурную роль,
обслуживая все аспекты ИС.
10.7.2. Особенности современных информационных систем, существенные с точки
зрения безопасности
Информационная система типичной современной организации является весьма сложным
образованием, построенным в многоуровневой архитектуре клиент/сервер, которое пользуется
многочисленными внешними сервисами и, в свою очередь, предоставляет собственные сервисы
вовне. Даже сравнительно небольшие магазины, обеспечивающие расчет с покупателями по
пластиковым картам (и, конечно, имеющие внешний Web-сервер), зависят от своих
информационных систем и, в частности, от защищенности всех компонентов систем и
коммуникаций между ними.
С точки зрения безопасности наиболее существенными представляются следующие аспекты
современных ИС:
 корпоративная сеть имеет несколько территориально разнесенных частей (поскольку
организация располагается на нескольких производственных площадках), связи
между которыми находятся в ведении внешнего поставщика сетевых услуг, выходя за
пределы зоны, контролируемой организацией;
 корпоративная сеть имеет одно или несколько подключений к Internet;
 на каждой из производственных площадок могут находиться критически важные
136







серверы, в доступе к которым нуждаются сотрудники, работающие на других
площадках, мобильные пользователи и, возможно, сотрудники других организаций;
для доступа пользователей могут применяться не только компьютеры, но и
потребительские устройства, использующие, в частности, беспроводную связь;
в течение одного сеанса работы пользователю приходится обращаться к нескольким
информационным сервисам, опирающимся на разные аппаратно-программные
платформы;
к доступности информационных сервисов предъявляются жесткие требования,
которые обычно выражаются в необходимости круглосуточного функционирования с
максимальным временем простоя порядка нескольких минут;
информационная система представляет собой сеть с активными агентами, то есть в
процессе работы программные компоненты, такие как апплеты или сервлеты,
передаются с одной машины на другую и выполняются в целевой среде, поддерживая
связь с удаленными компонентами;
не все пользовательские системы контролируются сетевыми и/или системными
администраторами организации;
программное обеспечение, особенно полученное по сети, не может считаться
надежным, в нем могут быть ошибки, создающие проблемы в защите;
конфигурация информационной системы постоянно изменяется на уровнях
административных данных, программ и аппаратуры (меняется состав пользователей,
их привилегии и версии программ, появляются новые сервисы, новая аппаратура и
т.п.).
10.7.3. Архитектурная безопасность
Сервисы безопасности, какими бы мощными они ни были, сами по себе не могут
гарантировать надежность программно-технического уровня защиты. Только проверенная
архитектура способна сделать эффективным объединение сервисов, обеспечить управляемость
информационной системы, ее способность развиваться и противостоять новым угрозам при
сохранении таких свойств, как высокая производительность, простота и удобство
использования.
С практической точки зрения наиболее важными являются следующие принципы
архитектурной безопасности:
 непрерывность защиты в пространстве и времени, невозможность миновать защитные
средства;
 следование признанным стандартам, использование апробированных решений;
 иерархическая организация ИС с небольшим числом сущностей на каждом уровне;
 усиление самого слабого звена;
 невозможность перехода в небезопасное состояние;
 минимизация привилегий;
 разделение обязанностей;
 эшелонированность обороны;
 разнообразие защитных средств;
 простота и управляемость информационной системы.
137