Глава 2 Модели данных

Федеральное агентство по образованию
Кемеровский институт (филиал)
Государственного образовательного учреждения высшего профессионального
образования
«Российский государственный
торгово-экономический университет»
Т.Ф. Лебедева
БАЗЫ ДАННЫХ
Учебное пособие
Кемерово
2012 г.
Содержание
Содержание .................................................................................................................................................4
Глава 1 Концепция баз данных ...............................................................................................................6
1.1 Данные и ЭВМ ...................................................................................................................................6
1.2 Поколения СУБД и направления исследований в области БД .....................................................8
1.3 Терминология в СУБД ....................................................................................................................10
1.4 Вопросы для самоконтроля к главе 1 ............................................................................................11
Глава 2 Модели данных .........................................................................................................................11
2.1. Классификация моделей данных...................................................................................................11
2.2 Основные особенности систем, основанных на инвертированных списках .............................14
2.2.1 Структуры данных ....................................................................................................................14
2.2.2 Манипулирование данными ....................................................................................................14
2.2.3 Ограничения целостности........................................................................................................15
2.3 Иерархические модели ...................................................................................................................15
2.3.1. Иерархические структуры данных .........................................................................................15
2.4 Сетевые модели................................................................................................................................16
2.4.1 Сетевые структуры данных .....................................................................................................16
2.4.2 Манипулирование данными ....................................................................................................17
2.4.3 Ограничения целостности........................................................................................................17
2.5 Физические модели организации баз данных ...............................................................................17
2.5.1 Файловые структуры, используемые для хранения данных в БД ..................................19
2.5.2 Модели страничной организации данных в современных БД ........................................21
2.5.3 Этапы доступа к БД .............................................................................................................22
2.6 Вопросы и упражнения для самоконтроля к главе 2 ...............................................................24
Глава 3 Реляционная модель данных ..................................................................................................24
3.1 Базовые понятия реляционных баз данных ..............................................................................24
3.1.1. Тип данных ...............................................................................................................................25
3.1.2. Домен ........................................................................................................................................25
3.1.3 Схема отношения, схема базы данных ...................................................................................25
3.1.4 Кортеж, отношение, ключи .....................................................................................................25
3.1.5 Связи в реляционных базах данных........................................................................................27
3.2 Фундаментальные свойства отношений ........................................................................................27
3.2.1 Отсутствие кортежей-дубликатов ...........................................................................................27
3.2.2 Отсутствие упорядоченности кортежей .................................................................................27
3.2.3 Отсутствие упорядоченности атрибутов ................................................................................28
3.2.4 Атомарность значений атрибутов ...........................................................................................28
3.3. Характеристика реляционной модели данных ............................................................................28
3.4 Трехзначная логика (3VL) ..............................................................................................................29
3.5 Реляционная алгебра .......................................................................................................................30
3.6 Особенности операций реляционной алгебры..............................................................................39
3.7 Реляционное исчисление ............................................................................................................40
3.7 Вопросы и упражнения для самоконтроля к главе 3 ...............................................................42
Глава 4 Элементы языка SQL..............................................................................................................42
4.1 История языка SQL..........................................................................................................................42
4.2 Структура языка SQL ......................................................................................................................44
4.3 Создание запроса с помощью оператора SELECT .......................................................................46
4.3.1 Создание простых запросов .....................................................................................................46
4.3.2. Агрегирование данных в запросах .........................................................................................48
4.3.3 Формирование запросов на основе соединения таблиц .......................................................50
4.3.4 Формирование структур вложенных запросов .....................................................................52
4.3.5 Объединение нескольких запросов в один ............................................................................54
4.3.6 Синтаксис оператора SELECT ................................................................................................55
4
4.4 Операторы манипулирования данных ...........................................................................................56
4.4.1 Оператор удаления данных DELETE .....................................................................................56
4.4.2 Оператор вставки данных INSERT .........................................................................................56
4.4.3 Оператор обновления данных UPDATE ................................................................................57
4.5 Операторы определения объектов базы данных ......................................................................57
4.5.1 Операторы определения таблицы ...........................................................................................57
4.5.2 Оператор определения представлений CREATE VIEW .......................................................59
4.6 Операторы контроля данных, защиты и управления данными ..............................................60
4.6.1 Операторы управления привилегиями ..................................................................................60
4.6.2 Операторы управления транзакциями ....................................................................................62
4.6.3 Проблемы параллельной работы транзакций ........................................................................64
4.7 Вопросы и упражнения для самоконтроля к главе 4 ...............................................................65
Глава 5 Проектирование баз данных..................................................................................................66
5.1 Проектирование реляционных БД с использованием принципов нормализации .....................67
5.2 Проектирование реляционных БД с использованием семантических моделей ...................72
5.2.1 Применение семантических моделей при проектировании .................................................72
5.2.2. Основные понятия модели Entity-Relationship .....................................................................74
5.2.3 Пример разработки простой ER-модели ................................................................................76
5.3 Практические рекомендации по проектированию БД ............................................................80
5.4 Вопросы и упражнения для самоконтроля к главе 5 ...............................................................81
Глава 6 Функции СУБД и системы обработки транзакций ...........................................................81
6.1 Основные функции СУБД ..............................................................................................................81
6.2 Системы обработки транзакций ................................................................................................84
6.2.1 OLTP-системы...........................................................................................................................84
6.2.2 OLAP -системы .........................................................................................................................85
6.2.3 Мониторы транзакций ..............................................................................................................86
6.3 Архитектура СУБД .....................................................................................................................88
6.4 Администрация и пользователи БД ...............................................................................................89
6.4 Вопросы и упражнения для самоконтроля по главе 6 .................................................................89
Глава 7 Технологии, модели и архитектура систем обработки данных .....................................90
7.1 Технологии и модели архитектуры «клиент-сервер» ..................................................................90
7.2 Распределенная обработка данных ................................................................................................93
7.2.1 Аспекты сетевого взаимодействия ....................................................................................94
7.2.2 Технология распределенной БД (технология STAR) .......................................................97
7.2.3 Технология тиражирования данных ..................................................................................98
7.3 Концепция активного сервера в модели DBS ..............................................................................99
7.4 Вопросы и упражнения для самоконтроля к главе 7 ..................................................................102
Литература ..............................................................................................................................................102
5
Глава 1 Концепция баз данных
1.1 Данные и ЭВМ
Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и
взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда,
когда не могли их понять). Такое описание называют данными.
Традиционно фиксация данных осуществляется с помощью конкретного средства общения,
например, с помощью естественного языка на конкретном носителе (например, бумаге). Обычно
данные (факты, явления, события, идеи или предметы) и их интерпретация (семантика)
фиксируются совместно, так как естественный язык достаточно гибок для представления того и
другого. Примером может служить утверждение «Стоимость авиабилета 128». Здесь «128» –
данное, а «Стоимость авиабилета» – его семантика.
Нередко данные и интерпретация разделены. Например, «Расписание движения самолетов»
может быть представлено в виде таблицы (таблица 1.1), в верхней части которой (отдельно от
данных) приводится их интерпретация. Такое разделение затрудняет работу с данными
(попробуйте быстро получить сведения из нижней части таблицы).
Таблица 1.1 – Расписание движения самолетов
Интерпретация
Номер
рейса
Дни
Пункт
недели отправления
Время
вылета
Пункт
назначения
Время
прибытия
Тип
Стоимость
самолета билета
Данные
138
2_4_7
Баку
21.12
Москва
0.52
ИЛ-86
115.00
57
3_6
Ереван
7.20
Киев
9.25
ТУ-154
92.00
1234
2_6
Казань
22.40
Баку
23.50
ТУ-134
73.50
242
1 по 7
Киев
14.10
Москва
16.15
ТУ-154
57.00
86
2_3_5
Минск
10.50
Сочи
13.06
ИЛ-86
78.50
137
1_3_6
Москва
15.17
Баку
18.44
ИЛ-86
115.00
241
1 по 7
Москва
9.05
Киев
11.05
ТУ-154
57.00
577
1_3_5
Рига
21.53
Таллин
22.57
АН-24
21.50
78
3_6
Сочи
18.25
Баку
20.12
ТУ-134
44.00
578
2_4_6
Таллин
6.30
Рига
7.37
АН-24
21.50
Применение ЭВМ для ведения (ведение данных – термин, объединяющий действия по
добавлению, удалению или изменению хранимых данных) и обработки данных обычно приводит к
еще большему разделению данных и интерпретации. ЭВМ имеет дело главным образом с
данными как таковыми. Большая часть интерпретирующей информации вообще не фиксируется в
явной форме (ЭВМ не «знает», является ли «21.50» стоимостью авиабилета или временем вылета).
Существуют по крайней мере две исторические причины, по которым применение ЭВМ
привело к отделению данных от интерпретации:
1.
ЭВМ не обладали достаточными возможностями для обработки текстов на естественном
языке – основном языке интерпретации данных;
2.
стоимость памяти ЭВМ была первоначально весьма велика.
Память использовалась для хранения самих данных, а интерпретация традиционно
возлагалась на пользователя. Пользователь закладывал интерпретацию данных в свою программу,
которая «знала», например, что шестое вводимое значение связано со временем прибытия
самолета, а четвертое – со временем его вылета. Это существенно повышало роль программы, так
как вне интерпретации данные представляют собой не более чем совокупность битов на
запоминающем устройстве.
6
Жесткая зависимость между данными и использующими их программами создает серьезные
проблемы в ведении данных и делает использования их менее гибкими. Нередки случаи, когда
пользователи одной и той же ЭВМ создают и используют в своих программах разные наборы
данных, содержащие сходную информацию.
Разработчики прикладных программ (написанных, например, на Бейсике, Паскале или С)
размещают нужные им данные в файлах, организуя их наиболее удобным для себя образом. При
этом одни и те же данные могут иметь в разных приложениях совершенно разную организацию
(разную последовательность размещения в записи, разные форматы одних и тех же полей и т.п.).
Обобществить такие данные чрезвычайно трудно: например, любое изменение структуры записи
файла, производимое одним из разработчиков, приводит к необходимости изменения другими
разработчиками тех программ, которые используют записи этого файла.
В книге У. Девиса (Операционные системы, М., Мир, 1980) приведен пример:
«Несколько лет назад почтовое ведомство (из лучших побуждений) пришло к решению, что все
адреса должны обязательно включать почтовый индекс. Во многих вычислительных центрах это,
казалось бы, незначительное изменение привело к ужасным последствиям. Добавление к адресу
нового поля, содержащего шесть символов, означало необходимость внесения изменений в
каждую программу, использующую данные этой задачи в соответствии с изменившейся
суммарной длиной полей. Тот факт, что какой-то программе для выполнения ее функций не
требуется знания почтового индекса, во внимание не принимался: если в некоторой программе
содержалось обращение к новой, более длинной записи, то в такую программу вносились
изменения, обеспечивающие дополнительное место в памяти».
Активная деятельность по отысканию приемлемых способов обобществления непрерывно
растущего объема информации привела к созданию в начале 60-х годов специальных
программных комплексов, называемых «Системы управления базами данных» (СУБД). Основная
особенность СУБД – это наличие процедур для ввода и хранения не только самих данных, но и
описаний их структуры. Файлы, снабженные описанием хранимых в них данных и находящиеся
под управлением СУБД, стали называть банками данных, а затем базами данных (БД).
Пусть, например, требуется хранить расписание движения самолетов (таблица. 1.1) и ряд других
данных, связанных с организацией работы аэропорта (БД «Аэропорт»). Представив, что мы
используем для этого «русифицированную» СУБД, можно подготовить следующее описание
расписания:
СОЗДАТЬ ТАБЛИЦУ Расписание
(Номер_рейса
Целое
Дни_недели
Текст (8)
Пункт_отправления Текст (24)
Время_вылета
Время
Пункт_назначения Текст (24)
Время_прибытия Время
Тип_самолета
Текст (8)
Стоимость_билета Валюта);
и ввести его вместе с данными в БД «Аэропорт».
Язык запросов СУБД позволяет обращаться за выборкой данных как из программ, так и с
терминалов). Сформировав запрос
ВЫБРАТЬ Номер_рейса, Дни_недели, Время_вылета
ИЗ ТАБЛИЦЫ Расписание
ГДЕ Пункт_отправления = 'Москва'
И Пункт_назначения = 'Киев'
И Время_вылета > 17;
получим расписание «Москва-Киев» на вечернее время, а по запросу
ВЫБРАТЬ КОЛИЧЕСТВО(Номер_рейса)
ИЗ ТАБЛИЦЫ Расписание
ГДЕ Пункт_отправления = 'Москва'
И Пункт_назначения = 'Минск';
7
получим количество рейсов «Москва-Минск».
Эти запросы не потеряют актуальности и при расширении таблицы:
ДОБАВИТЬ В ТАБЛИЦУ Расписание
Длительность_полета Целое;
как это было с программами обработки почтовых адресов при введении почтового индекса.
Однако за все надо расплачиваться: на обмен данными через СУБД требуется большее время,
чем на обмен аналогичными данными прямо из файлов, специально созданных для того или иного
приложения.
1.2 Поколения СУБД и направления исследований в области БД
Принято выделять три поколения СУБД:
I. Поколение. Сетевые и иерархические системы БД, широко распространенные в 70-е годы,
получили название - системы БД первого поколения. Это были первые системы, предлагавшие
развитую функциональность СУБД в рамках единой системы, с языками определения и
манипулирования данными для набора записей. Назовем некоторые наиболее общие
характеристики ранних систем:
a. Эти системы активно использовались в течение многих лет, дольше, чем используется
какая-либо из реляционных СУБД.
b. Все ранние системы не основывались на каких-либо абстрактных моделях. Понятие модели
данных фактически вошло в обиход специалистов в области БД только вместе с
реляционным подходом. Абстрактные представления ранних систем появились позже на
основе анализа и выявления общих признаков у различных конкретных систем.
c. В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем
осуществляли явную навигацию в БД, используя языки программирования, расширенные
функциями СУБД.
d. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли
пользователя самого производить всю оптимизацию доступа к БД, без какой-либо
поддержки системы.
e. После появления реляционных систем большинство ранних систем было оснащено
«реляционными» интерфейсами. Однако в большинстве случаев это не сделало их понастоящему реляционными системами, поскольку оставалась возможность манипулировать
данными в естественном для них режиме.
II. Поколение. В 80-е годы системы первого поколения были существенно потеснены
современным семейством реляционных СУБД, называемых системами БД второго поколения.
Типичные представители многопользовательских профессиональных систем второго поколения –
DB2, INGRES, ORACLE, Informix и др.
В нашей стране представление о реляционных СУБД у большинства программистов
сложилось на основе опыта использования систем на платформе персональных компьютеров,
таких как dBASE, FoxBASE, FoxPro, Paradox, Clipper, Clarion, а позже Access. Причины такой
популярности можно видеть как в широком распространении персональных компьютеров, так и в
относительной простоте и легкости изучения и освоения самих персональных СУБД. Очень часто
персональные СУБД использовались (да и сейчас кое-где используются) для автоматизации таких
задач, например, в финансовой сфере, которые требуют
многопользовательских
профессиональных систем.
Реляционные СУБД и сейчас являются наиболее популярными в сфере разработки бизнесприложений. Однако существует широкий класс приложений,
для которых технология
реляционных систем БД не является вполне удовлетворительной:); технология программирования;
системы, основанные на знаниях, и мультимедийные системы; системы автоматизации
проектирования (САПР); геоинформационные системы (ГИС); издательские системы; системы
дистанционного обучения; системы электронной коммерции и др. Это прежде всего связано с
примитивностью структур данных, лежащих в основе реляционной модели данных. Плоские
нормализованные отношения универсальны и теоретически достаточны для представления
данных любой предметной области. Однако в нетрадиционных приложениях в базе данных
появляются сотни, если не тысячи таблиц, над которыми постоянно выполняются дорогостоящие
8
операции соединения, необходимые для воссоздания сложных структур данных, присущих
предметной области.
Другим серьезным ограничением реляционных систем являются их относительно слабые
возможности по части представления семантики приложения.
Осознавая эти ограничения и недостатки реляционных систем, исследователи в области баз
данных выполняют многочисленные проекты, основанные на идеях, выходящих за пределы
реляционной модели данных
III. Поколение. Термин «системы следующего (или третьего) поколения» вошел в жизнь после
опубликования группой известных специалистов в области БД «Манифеста систем баз данных
третьего поколения». В целом можно сказать, что СУБД следующего поколения - это прямые
наследники реляционных систем. В число требований к СУБД третьего поколения входят полнота
системы типов, поддерживаемых в СУБД; поддержка иерархии и наследования типов;
возможность управления сложными объектами и т.д.
Основными направлениями систем третьего поколения, обладающими некоторыми разными
характеристиками, являются:
- Ориентация на расширенную реляционную модель. Основные характеристики:
максимальное следование (насколько это возможно с учетом новых требований) известным
принципам организации СУБД; абстрактные типы данных; поддержка исторической информации
и темпоральных запросов; отказ от требований нормализации. Одной из наиболее известных
СУБД этого направления является система Postgres. В Postgres реализованы многие интересные
средства: поддерживается темпоральная модель хранения и доступа к данным; допускается
хранение в полях отношений данных абстрактных, определяемых пользователями типов.
- Генерация систем баз данных, ориентированных на приложения. Основная
характеристика: создание собственно не системы, а генератора систем, наиболее полно
соответствующих потребностям приложений. Решение достигается путем создания наборов
модулей со стандартизованными интерфейсами. Существуют два экспериментальных прототипа
«генерационных» систем - Genesis и Exodus. Обе эти системы основаны прежде всего на
принципах модульности и точного соблюдения установленных интерфейсов. По сути дела,
системы состоят из минимального ядра (развитой файловой системы в случае Exodus) и
технологического механизма программирования дополнительных модулей. В проекте Exodus этот
механизм основывается на системе программирования E, которая является простым расширением
С++, поддерживающим стабильное хранение данных во внешней памяти. Вместо готовой СУБД
предоставляется набор "полуфабрикатов" с согласованными интерфейсами, из которых можно
сгенерировать систему, максимально отвечающую потребностям приложения
- Системы баз данных, основанные на правилах. К этому направлению относятся
дедуктивные БД. Основная характеристика: достижение расширяемости системы и ее адаптации к
нуждам конкретных приложений путем использования стандартного механизма управления
правилами. По сути дела, система представляет собой некоторый интерпретатор системы правил и
набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять
наборы правил (существует специальный язык задания правил) или изменять действия, подставляя
другие модули с тем же интерфейсом. По определению, дедуктивная БД состоит из двух частей:
экстенциональной, содержащей факты, и интенциональной, содержащей правила для логического
вывода новых фактов на основе экстенциональной части и запроса пользователя. Отметим лишь,
что обычно языки запросов и определения интенциональной части БД являются логическими
(поэтому дедуктивные БД часто называют логическими). Имеется прямая связь дедуктивных БД с
базами знаний
- Объектно-ориентированные СУБД. Направление объектно-ориентированных баз данных
(ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х. Однако
наиболее активно это направление развивается в последние годы. В настоящее время ведется
очень много экспериментальных и производственных работ в области объектно-ориентированных
СУБД. На рынке представлено свыше 25 систем ООБД. Среди них — система GemStone компании
Servio, ONTOS компании Ontos, ObjectStore компании Object Design, O2, ORION, Iris. Кроме того,
системы управления реляционными базами данных, разработанные компаниями Oracle, Microsoft,
9
Borland, Informix, включали объектно-ориентированные средства. Многие из этих продуктов
появились еще во второй половине 80-х годов, и сегодня, по прошествии почти полутора
десятилетий разработки они все еще не вступили в пору зрелости; в этом — одна из причин того,
что по сей день мировой рынок реальных приложений не торопится принимать системы ООБД.
Широкое использование Интернет в различных сферах деятельности ставит перед
разработчиками СУБД следующие проблемы:
1.
Интеграция текста, данных, кода и потоков. В области СУБД основное внимание
всегда уделялось организации, хранению, анализу и выборке структурированных данных.
Развитие Web-приложений продемонстрировало важность более сложных типов данных: текстов,
изображений, темпоральных, аудио- и видеоданных.
2.
Интеграция информации. Типичным подходом к интеграции информации в
масштабах предприятия является построение хранилищ (DataWarehouse) витрин (data mart)
данных на основе извлечения операционных данных, их трансформации к единой схеме и загрузке
данных в хранилище (процедура ETL - extraction, transfotamation, loading). Этот подход пригоден
для использования на предприятии с несколькими десятками операционных баз данных,
находящихся под единым контролем. В Интернет требуется производить интеграцию информации
между несколькими предприятиями. Как правило, организации не позволят в массовом порядке
извлекать данные из своих операционных баз данных, к ним можно будет адресовать лишь
одиночные запросы. В результате потребуется интеграция, возможно, миллионов
информационных источников «на лету». В связи с этим существует множество нерешенных
проблем: семантическая неоднородность; неполнота и неточность данных; ограниченность
доступа к конфиденциальным данным и т.д.
3.
Мультимедийные запросы. Очевидно, что объем мультимедийных данных
(изображения, аудио, видео и т.д.) значительно возрастает. Проблемой сообщества баз данных
является создание простых способов анализа, обобщения, поиска и обозрения электронных
подборок мультимедийной информации, относящейся к некоторому объекту.
1.3 Терминология в СУБД
В общеотраслевых руководящих материалах по созданию банков данных Государственного
комитета по науке и технике, изданных в 1982 г., приводятся следующие определения основных
понятий:
База данных (БД) - именованная совокупность данных, отражающая состояние объектов и их
отношений в рассматриваемой предметной области (ПО).
Предметная область (ПО) – часть реального мира, подлежащая автоматизации с целью
организации управления. Она представлена множеством фрагментов, каждый из которых
характеризуется объектами, процессами и множеством пользователей.
Банк данных (БнД) – это система специальным образом организованных данных – баз данных,
программных, технических, языковых, организационно-методических средств, предназначенных
для обеспечения централизованного накопления и коллективного многоцелевого использования
данных.
Системы управления базами данных (СУБД) – совокупность языковых и программных средств,
предназначенных для создания, ведения и совместного использования БД многими
пользователями.
Программы, с помощью которых пользователи работают с БД, называются приложениями.
СУБД должна обеспечивать:
 возможность представления внутренней структуры данных;
 физическую и логическую независимость данных;
 минимальную избыточность данных;
 возможность быстрого поиска;
 эффективные языки запросов к данным;
 требования безопасности, надежности, конфиденциальности, целостности:
- данные должны быть защищены от искажения, хищения, разрушения;
10
данные должны быть восстанавливаемыми;
данные должны быть контролируемыми;
должна быть установлена процедура идентификации пользователей;
должна быть организована система санкционированного доступа;
должен быть установлен контроль за действиями пользователя с целью обнаружения
ошибочных операций;
СУБД должна предоставлять доступ к данным любым пользователям, включая и тех,
которые практически не имеют и (или) не хотят иметь представления о:
 физическом размещении в памяти данных и их описаний;
 механизмах поиска запрашиваемых данных;
 проблемах, возникающих при одновременном запросе одних и тех же данных многими
пользователями (прикладными программами);
 способах обеспечения защиты данных от некорректных обновлений и (или)
несанкционированного доступа;
 поддержании БД в актуальном состоянии и множестве других функций СУБД.
1.4 Вопросы для самоконтроля к главе 1
1. Что понимается под ведением данных?
2. Можно ли использовать термины «база данных» и «банк данных» как эквивалентные?
3. Какие функции по отношению к пользователю выполняет СУБД?
4. Что включают требования надежности и безопасности БД?
5. Чем характеризуются БД первого поколения?
-
Глава 2 Модели данных
2.1. Классификация моделей данных
Модель данных - это совокупность структур данных, взаимосвязей и операций их обработки.
При выполнении основных функций СУБД должна использовать различные описания
данных. Естественно, что проект базы данных надо начинать с анализа предметной области и
выявления требований к ней отдельных пользователей (сотрудников организации, для которых
создается база данных). Подробнее этот процесс будет рассмотрен ниже, а здесь отметим, что
проектирование обычно поручается человеку (группе лиц) – администратору базы данных (АБД).
Им может быть как специально выделенный сотрудник организации, так и будущий пользователь
БД, достаточно хорошо знакомый с машинной обработкой данных.
Объединяя частные представления о содержимом БД, полученные в результате опроса
пользователей, и свои представления о данных, которые могут потребоваться в будущих
приложениях, АБД сначала создает обобщенное неформальное описание создаваемой базы
данных. Это описание, выполненное с использованием естественного языка, математических
формул, таблиц, графиков и других средств, понятных всем людям, работающих над
проектированием базы данных, называют инфологической моделью данных (рис. 2.1).
Такая человеко-ориентированная модель полностью независима от физических параметров
среды хранения данных. Поэтому инфологическая модель не должна изменяться до тех пор, пока
какие-то изменения в реальном мире не потребуют изменения в ней некоторого определения,
чтобы эта модель продолжала отражать предметную область. Остальные модели, показанные на
рис. 1.1, являются компьютеро-ориентированными. С их помощью СУБД дает возможность
программам и пользователям осуществлять доступ к хранимым данным лишь по их именам, не
заботясь о физическом расположении этих данных. Нужные данные отыскиваются СУБД на
внешних запоминающих устройствах по физической модели данных.
Так как указанный доступ осуществляется с помощью конкретной СУБД, то модели должны быть
описаны на языке описания данных этой СУБД. Такое описание, создаваемое АБД по
инфологической модели данных, называют даталогической или концептуальной моделью данных.
Трехуровневая архитектура (инфологический, даталогический и физический уровни)
позволяет обеспечить независимость хранимых данных от использующих их программ. АБД
может при необходимости переписать хранимые данные на другие носители информации и (или)
11
реорганизовать их физическую структуру, изменив лишь физическую модель данных. АБД может
подключить к системе любое число новых пользователей (новых приложений), дополнив, если
надо, даталогическую модель. Указанные изменения физической и даталогической моделей не
будут замечены существующими пользователями системы (окажутся «прозрачными» для них), так
же как не будут замечены и новые пользователи. Следовательно, независимость данных
обеспечивает возможность развития системы баз данных без разрушения существующих
приложений.
Рисунок. 2.1. Уровни моделей данных
На рис.2.2 представлена классификация моделей данных в соответствии с рассмотренной
выше трехуровневой архитектурой.
Инфологическая модель отображает реальный мир в некоторые понятные человеку
концепции, полностью независимые от параметров среды хранения данных. Инфологическая
модель отражает ПО в виде совокупности информационных объектов и их структурных связей.
Существует множество подходов к построению таких моделей. Наиболее популярной из них
оказалась модель «сущность-связь» (ER - Entity Relationship), которая будет рассмотрена в п.5.2.
Инфологическая модель должна быть отображена в компьютеро-ориентированную
даталогическую модель, «понятную» СУБД. В процессе развития теории и практического
использования баз данных, а также средств вычислительной техники создавались СУБД,
поддерживающие различные даталогические модели – документальные и фактографические.
Документальные модели соответствуют представлению о слабо структурированной информации,
ориентированной на свободные форматы текста на естественном языке.
Модели, ориентированные на формат документа, связаны прежде всего со стандартным общим
языком разметки - SGML, чаще используются HTML и XML
Тезаурусные модели основаны на принципе организации словарей и содержит определенные
языковые конструкции и принципы их взаимодействия в заданной грамматике. Эти модели
используются в системах - переводчиках, особенно в многоязыковых переводчиках.
Дескрипторные модели – самые простые из документальных моделей и широко использовались
на ранних стадиях использования документальных баз данных. В этих моделях каждому
12
документу соответствует дескриптор (описатель), имеющий жесткую структуру. Дескриптор
описывал документ в соответствии с теми характеристиками, которые требуются для работы с
документами в разрабатываемой БД. Например, для БД с описаниями патентов дескриптор
содержал название области, к которой относился патент, номер, дату выдачи патента и еще ряд
ключевых характеристик. Обработка информации в таких БД велась исключительно по
дескрипторам, а не по самому текстовому описанию патента.
Модели данных
Инфологические
Даталогические
модель
документальные
сущность-связь (ER)
ориентиро- дескрипванные
торные
на формат
документа
тезаурусные
Физические
фактографические
теоретикографовые
иерархические сетевые
основанные
основанные
на файловых на страничноструктурах
сегментной
организации
теоретикомножественные
реляционные
объектноориентированные
основанные на
инвертированных файлах
Рисунок. 2.2. Классификация моделей данных
Физическая модель данных оперирует категориями, касающимися организации внешней памяти и
структур хранения, используемых в данной операционной среде. Физическая организация данных
оказывает основное влияние на эксплуатационные характеристики БД.
Фактографические модели. Сначала стали использовать иерархические даталогические модели.
Простота организации, наличие заранее заданных связей между сущностями, сходство с
физическими моделями данных позволяли добиваться приемлемой производительности
иерархических СУБД на медленных ЭВМ с весьма ограниченными объемами памяти. Но, если
данные не имели древовидной структуры, то возникало много сложностей при построении
иерархической модели.
Сетевые модели также создавались для мало ресурсных ЭВМ. Это достаточно сложные
структуры, состоящие из «наборов» – поименованных двухуровневых деревьев. «Наборы»
соединяются с помощью «записей-связок», образуя цепочки и т.д. При разработке сетевых
моделей было выдумано множество «маленьких хитростей», позволяющих увеличить
производительность СУБД, но существенно усложнивших последние. Прикладной программист
должен изучить несколько внутренних языков СУБД, детально представлять логическую
структуру базы данных для осуществления навигации среди различных экземпляров, наборов,
записей и т.п.
Сложность практического использования иерархических и сетевых СУБД заставляла искать иные
способы представления данных. В конце 60-х годов появились СУБД на основе инвертированных
файлов, отличающиеся простотой организации и наличием весьма удобных языков
манипулирования данными. Однако такие СУБД обладают рядом ограничений на количество
файлов для хранения данных, количество связей между ними, длину записи и количество ее
полей.
Сегодня наиболее распространены реляционные модели, которые будут подробно рассмотрены в
главе 3.
Любая логическая модель данных должна содержать три компонента:
1. структура данных;
2. набор допустимых операций, выполняемых на структуре данных. Модель данных
предполагает наличие языка определения данных, описывающего структуру их хранения, и
13
языка манипулирования данными, включающего операции извлечения и модификации
данных;
3. ограничение целостности: механизм поддержания соответствия данных ПО на основе
формально описанных правил.
Прежде, чем перейти к детальному и последовательному изучению реляционных систем БД,
остановимся коротко на логических моделях ранних (дореляционных) СУБД.
Для обозначения типов структур данных широко используется терминология, предложенная
CODASYL (The Conference on Data Systems Languages): элемент данных, агрегат данных, запись,
база данных.
Элемент данных (ЭД) - наименьшая поименованная единица данных, к которой СУБД
может адресоваться непосредственно, и с помощью которой выполняется построение всех
остальных структур. ЭД имеет имя и значение.
Агрегат данных (АД) - поименованная совокупность ЭД внутри записи, которую можно
рассматривать как единое целое. АД может быть простым или составным.
Запись - поименованная совокупность ЭД и агрегатов. Запись это АД, не входящий в состав
другого АД. Запись может иметь сложную иерархическую структуру, так как допускается
многократное применение агрегации.
База данных - поименованная совокупность экземпляров записей различного типа,
содержащая ссылки между записями, представленные экземплярами наборов. Описание
структуры БД задается ее схемой.
2.2 Основные особенности систем, основанных на инвертированных списках
К числу наиболее известных и типичных представителей таких систем относятся Datacom/DB
компании Applied Data Research, Inc. (ADR), ориентированная на компьютеры фирмы IBM, и
Adabas компании Software AG.
Организация доступа к данным на основе инвертированных списков используется практически во
всех современных реляционных СУБД, но в этих системах пользователи не имеют
непосредственного доступа к инвертированным спискам (индексам).
2.2.1 Структуры данных
База данных, организованная с помощью инвертированных списков, похожа на реляционную БД,
но с тем отличием, что хранимые таблицы и пути доступа к ним видны пользователям. При этом:
- строки таблиц упорядочены системой в некоторой физической последовательности;
- физическая упорядоченность строк всех таблиц может определяться и для всей БД (так
делается, например, в Datacom/DB).
- для каждой таблицы можно определить произвольное число ключей поиска, для которых
строятся индексы. Эти индексы автоматически поддерживаются системой, но явно видны
пользователям.
2.2.2 Манипулирование данными
Поддерживаются два класса операторов:
1. Операторы, устанавливающие адрес записи, среди которых:
 прямые поисковые операторы (например, найти первую запись таблицы по некоторому
пути доступа);
 операторы, находящие запись в терминах относительной позиции от предыдущей записи по
некоторому пути доступа.
2. Операторы над адресуемыми записями
Примеры операторов:
 LOCATE FIRST - найти первую запись таблицы T в физическом порядке; возвращает адрес
записи;
 LOCATE FIRST WITH SEARCH KEY EQUAL - найти первую запись таблицы T с
заданным значением ключа поиска K; возвращает адрес записи;
 LOCATE NEXT - найти первую запись, следующую за записью с заданным адресом в
заданном пути доступа; возвращает адрес записи;
 RETRIVE - выбрать запись с указанным адресом;
14
UPDATE - обновить запись с указанным адресом;
DELETE - удалить запись с указанным адресом;
STORE - включить запись в указанную таблицу; операция генерирует адрес записи.
2.2.3 Ограничения целостности
Общие правила определения целостности БД отсутствуют. В некоторых системах
поддерживаются ограничения уникальности значений некоторых полей, но в основном все
возлагается на прикладную программу.
2.3 Иерархические модели
Типичным представителем (наиболее известным и распространенным) является Information
Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г.
2.3.1. Иерархические структуры данных
Иерархическая модель данных (ИМД) свойственна многим реальным древовидным
структурам (классификаторы, структуры управления и т. п.). Существуют графовая и табличная
формы представления данных ИМД. Иерархическая БД состоит из упорядоченного набора
деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.
Дерево - связный неориентированный граф, который не содержит циклов.
Иерархическая древовидная структура, ориентированная от корня (выделенная вершина
или узел) определяется условиями:
 иерархия начинается с корневого узла, который находится на первом уровне иерархии;
 на нижних уровнях находятся порожденные (зависимые) узлы;
 каждый порожденный узел, находящийся на і-том уровне, связан непосредственно с
одним исходным (родительским) узлом, находящимся на (і-1) уровне иерархии;
 каждый исходный узел может иметь один или несколько непосредственно порожденных
узлов;
 доступ к порожденному узлу осуществляется через его исходный узел;
 существует единственный иерархический путь доступа к узлу, начиная от корня дерева
(рис. 2. 3).
Иерархический путь включает в себя все связанные между собой узлы.
В ИМД используется ориентация древовидной структуры от корня к листьям дерева.
Пример схемы иерархической БД представлен на рис 2. 4.



1 ур.
À
B
C
F
E
I
G
K
M
D
2 ур.
H
3 ур.
L
4 ур.
N
O
Рисунок 2.3 Пример иерархической структуры.
Для БД определен полный порядок обхода – «сверху-вниз», «слева-направо».
15
5 ур.
ФАКУЛЬТЕТ
ШИФР-ФАКУЛЬТЕТА,
НАЗВАНИЕ
КУРС
НОМЕР-КУРСА, ДАТАНАЧАЛА-СЕССИИ, ДАТАОКОНЧАНИЯ-СЕССИИ
КАФЕДРА
ГРУППА
ИНДЕКС-ГРУППЫ, ФАМИЛИЯ-ИМЯ-ОТЧЕСТ-ВОСТАРОСТЫ-ГРУППЫ
ДИСЦИПЛИНА
ШИФР-КАФЕДРЫ,
НАЗВАНИЕ-КАФЕДРЫ
ШИФР-ДИСЦИПЛИНЫ,
НАЗВАНИЕ-ДИСЦИПЛИНЫ
СТУДЕНТ
№-ЗАЧЕТНОЙ-КНИЖ-КИ, №
П/П, ФАМИЛИЯ-ИМЯОТЧЕСТВО
Рисунок 2.4 Иерархическая БД
2.3.2 Манипулирование данными
Примерами типичных операторов манипулирования иерархически организованными данными
могут быть следующие операторы:
 найти указанное дерево БД;
 перейти от одного дерева к другому;
 перейти от одной записи к другой внутри дерева (например, от группы - к первому
студенту);
 перейти от одной записи к другой в порядке обхода иерархии;
 вставить новую запись в указанную позицию;
 удалить текущую запись.
2.3.3 Ограничения целостности
Автоматически поддерживается целостность ссылок между предками и потомками. Основное
правило: никакой потомок не может существовать без своего родителя.
2.4 Сетевые модели
Типичным представителем является Integrated Database Management System (IDMS) компании
Cullinet Software, Inc. Архитектура системы основана на предложениях Data Base Task Group
(DBTG) Комитета по языкам программирования (Conference on Data Systems Languages CODASYL). Отчет DBTG был опубликован в 1971 г., а в 70-х годах появилось несколько систем,
среди которых IDMS.
2.4.1 Сетевые структуры данных
Сетевой подход к организации данных является расширением иерархического. В иерархических
структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных
потомок может иметь любое число предков.
Сетевая БД состоит из набора записей, соответствующих каждому экземпляру объекта
предметной области, и набора связей между этими записями.
Простой пример сетевой схемы БД приведен на рис.2.5. Для сетевых моделей допускается
пересечения, циклы. В некоторых случаях один элемент данных может быть связан с целой
совокупностью других элементов данных. Например, одно изделие может поставляться
несколькими поставщиками, каждый из которых установил свою цену. Элемент данных ЦЕНА не
может быть ассоциирован только с записью ИЗДЕЛИЕ или только с записью ПОСТАВЩИК, а
должен быть связан с двумя этими записями. Данные, ассоциированные с совокупностью записей,
называют данными пересечения.
Циклом называется ситуация, в которой исходный узел является в то же время порожденным
узлом.
16
Любую сетевую модель можно представить в виде иерархической путем введения избыточности.
Сеть преобразуется в дерево указанием некоторых узлов дважды.
Рисунок 2.5 Пример сетевой схемы БД
2.4.2 Манипулирование данными
Примерный набор операций может быть следующим:
 найти конкретную запись в наборе однотипных записей (инженера Сидорова);
 перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела
310);
 перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);
 перейти от потомка к предку по некоторой связи (найти отдел Сидорова);
 создать новую запись;
 уничтожить запись;
 модифицировать запись;
 включить в связь;
 исключить из связи;
 переставить в другую связь и т.д.
2.4.3 Ограничения целостности
В принципе их поддержание не требуется, но иногда требуют целостности по ссылкам (как в
иерархической модели).
Достоинства ранних СУБД:
 развитые средства управления данными во внешней памяти на низком уровне;
 возможность построения вручную эффективных прикладных систем;
 возможность экономии памяти за счет разделения подобъектов (в сетевых системах).
Недостатки дореляционных СУБД:
 слишком сложно пользоваться;
 фактически необходимы знания о физической организации данных;
 прикладные программы зависят от физической организации;
 логика прикладных программ перегружена деталями организации доступа к БД.
2.5 Физические модели организации баз данных
Физические модели определяет способ размещения данных в среде хранения и способы доступа к
этим данным, которые поддерживаются на физическом уровне. Среди самых важных
характеристик любой базы данных следует назвать производительность, надежность и простоту
администрирования. Знание того, как большинство СУБД физически хранят данные во внешней
памяти, представление о параметрах этого хранения и соответствующих методах доступа может
очень помочь при проектировании баз данных, обладающих заданной производительностью.
Любая логическая структура данных представляется на физическом уровне в виде
последовательности битов.
Можно выделить следующие аспекты проблемы физического представления данных:
I. Как найти нужную запись? Необходимо установить соответствие между логической записью
и адресом физической записи. Под физической записью будем понимать последовательность
битов, которые можно прочесть с помощью одной машинной инструкции. Логические записи
17
находят по ключу или совокупности ключей.
II. Каким образом организовать данные, чтобы их поиск был эффективным, а выборку можно
было осуществить по совокупности ключей?
III. Как можно добавить новую запись к данным, уничтожить старые записи и при этом не
нарушить системы адресации и поиска, а также сами структуры данных.
Укажем основные факторы, влияющие на физическую организацию данных для конкретных БД:
1. произвольная или последовательная обработка данных. Для определения вида обработки
используют коэффициент активности файла (k)
k=z1/z ,
где z1 – число записей, считанных за 1 прогон; z - число записей, просмотренных за 1 прогон.
Если k высок, то используют последовательную обработку, например при расчете заработной
платы;
2. частота обращения к определенным записям;
3. время ответа (важно для систем реального времени);
4. способность к расширению (особенно, если добавляется записей больше, чем
уничтожается);
5. возможность организации поиска по нескольким ключам.
Можно выделить следующие способы адресации (поиска нужной записи):
1. Последовательное сканирование файла с проверкой ключа каждой записи. Такой метод
используется, если выбран последовательный метод обработки данных или используется
файл последовательного доступа. Требует много времени.
2. Блочный поиск. Если записи упорядочены по ключу, то при сканировании не требуется
чтение каждой записи. Считывается первая запись блока и ее ключ сравнивается с ключом
искомой записи. А далее или просматриваются все записи данного блока или выбирается
первая запись следующего блока.
3. Преобразование ключа в адрес - самая быстрая организация поиска. Сейчас применяется
технология хэширования – технология быстрого доступа к хранимой записи на основе
вычисления специальной функции от заданного значения некоторого поля. Это значение и
является адресом для записи.
4. Поиск по индексу. Первичный индекс – индекс, использующий в качестве входной
информации первичный ключ. В индексном файле запись состоит из индекса и указателя.
Сначала проводится поиск в индексе, а потом по указателю обращаемся к основному файлу
с записями. Эффективно, быстро, но требуется память для хранения индекса.
5. Бинарный (двоичный) поиск для записей, упорядоченных по индексу.
6. Поиск по В-дереву для записей, упорядоченных по индексу.
Исторически первыми системами хранения и доступа были файловые структуры и системы
управления файлами, которые фактически являлись частью операционных систем. СУБД
создавала над этими файлами свою надстройку, которая позволяла организовать всю совокупность
файлов таким образом, чтобы она работала как единое целое и получала централизованное
управление от СУБД. При этом непосредственный доступ осуществлялся на уровне файловых
команд, которые СУБД использовала при манипулировании файлами.
Однако механизмы буферизации и управления файловыми структурами не приспособлены для
решения задач собственно СУБД, так как создавались для традиционной обработки файлов, и с
ростом объемов хранимых данных они стали неэффективными для использования СУБД. Тогда
постепенно произошел переход от базовых файловых структур к непосредственному управлению
размещением данных на внешних носителях самой СУБД. При этом механизмы, применяемые в
файловых системах, перешли во многом и в новые системы организации данных во внешней
памяти, называемые чаще страничными системами хранения информации. Любое упорядоченное
расположение данных на диске, называется структурой хранения. На рис. 2.6 приведена
классификация структур хранения информации в БД.
18
Структуры хранения информации в БД
Файловые
прямого
доступа
Бесфайловые
последовательного
доступа
индексные инвертированные взаимосвязанные строки
списки
файлы
страницы
чанки
экстенты
индексно-прямые
индексно- В-деревья
с однонаправ- с двухнаправпоследовательные
ленными
ленными
цепочками цепочками
Рисунок. 2.6. Классификация структур хранения информации в БД
2.5.1 Файловые структуры, используемые для хранения данных в БД
На устройствах последовательного доступа (магнитофоны, стримеры) могут быть организованы
файлы только последовательного доступа. Файлы с переменной длиной записи также всегда
являются файлами последовательного доступа и могут быть организованы двумя способами:
 конец записи отмечается специальным маркером;
 в начале каждой записи записывается ее длина.
Файлы с постоянной длиной записи, расположенные на устройствах прямого доступа (магнитные,
оптические диски), являются файлами прямого доступа. В этих файлах физический адрес
расположения нужной записи может быть вычислен по номеру записи (NZ).
Для файлов с постоянной длиной записи адрес размещения записи с номером NZ может быть
вычислен по формуле:
BA+( NZ -1)*LZ+1,
где BA – базовый адрес, LZ – длина записи.
Файлы прямого доступа обеспечивают наиболее быстрый доступ к произвольным записям, и их
использование является наиболее перспективным в системах БД.
Однако чаще всего в БД необходим поиск по ключам, а не по номеру записи, и номер записи,
необходимый для прямого доступа, в этом случае неизвестен.
При организации файлов прямого доступа в некоторых случаях возможно построение функции,
которая по значению ключа К однозначно вычисляет номер записи (номер записи файла)
NZ=F(K).
Часто не удается построить взаимно-однозначное соответствие между значениями ключа и
номерами записей, поэтому применяют различные методы хэширования; создают специальные
хэш-функции.
Общей идеей методов хэширования является применение к значению ключа некоторой функции
свертки (хэш-функции), вырабатывающей значение меньшего размера. Свертка значения ключа
затем используется для доступа к записи.
В самом простом, классическом случае, свертка ключа используется как адрес в таблице,
содержащей ключи и записи. Основным требованием к хэш-функции является равномерное
распределение значений свертки. При возникновении коллизий (одна и та же свертка для
нескольких значений ключа) образуются цепочки переполнения. Новая запись заносится в область
переполнения на первое свободное место, а в записи-синониме (с тем же значением хэшфункции), которая находится в основной области, делается ссылка на адрес вновь размещенной
записи в области переполнения. Главным ограничением этого метода является фиксированный
размер таблицы. Если таблица заполнена слишком сильно или переполнена, но возникнет
слишком много цепочек переполнения, и главное преимущество хэширования - доступ к записи
почти всегда за одно обращение к таблице - будет утрачено. Расширение таблицы требует ее
полной переделки на основе новой хэш-функции (со значением свертки большего размера).
В случае баз данных такие действия являются абсолютно неприемлемыми. Поэтому обычно
вводят промежуточные таблицы-справочники, содержащие значения ключей и адреса записей, а
19
сами записи хранятся отдельно. Тогда при переполнении справочника требуется только его
переделка, что значительно проще.
Несмотря на высокую эффективность хэш-адресации, в файловых структурах не всегда удается
найти соответствующую функцию, поэтому при организации доступа по первичному ключу
широко используются индексные файлы. Индексные файлы можно представить как таблицы
указателей к основному файлу с записями, причем для одного основного файла можно построить
несколько индексных по различным ключам.
Различают два типа индексных файлов: с плотным индексом (индексно-прямые) и с неплотным
индексом (индексно-последовательные) .
Структура файлов с плотным индексом имеет вид:
Значение ключа
Номер записи в основном файле
Записи в основном файле расположены в произвольном порядке. Такие файлы строятся для
первичных ключей и в них не может быть двух записей, имеющих одинаковые значения
первичного ключа. Все записи в индексном файле упорядочены по значению ключа, поэтому для
поиска в индексном файле можно применить бинарный или двоичный поиск.
Файлы с неплотным индексом строятся для основных файлов, в которых записи упорядочены по
ключу и структура индексных файлов имеет вид:
Значение ключа первой записи блока
Номер блока с этой записью в основном файле
В индексном файле ищется нужный блок по заданному значению первичного ключа. Так как все
записи упорядочены, то значение первой записи блока позволяет быстро определить, в каком
блоке находится искомая запись. Все остальные действия по поиску проходят в основном файле.
Наиболее популярным подходом к организации индексов в базах данных является использование
техники B-деревьев. С точки зрения внешнего логического представления B-дерево - это
сбалансированное дерево во внешней памяти. Сбалансированность означает, что длина пути от
корня дерева к любому его листу одна и та же. Построение В-деревьев связано с простой идеей
построения индекса над уже построенным индексом. Если построить файл с неплотным индексом,
то, рассматривая его как основной файл, над которым надо снова построить файл с неплотным
индексом, а потом снова над новым индексом строим следующий и так до того момента, пока не
останется всего один индексный блок.
Если индексные файлы используются для ускорения доступа по первичному ключу, то для
ускорения доступа по вторичному ключу используются структуры, называемые
инвертированными списками. Вторичными ключами является атрибут или набор атрибутов,
которому соответствует несколько искомых записей. Например, для таблицы «Книги» вторичным
ключом может служить место издания, год издания. Множество книг могут быть изданы в одном
месте, и множество книг могут быть изданы в одном году.
Инвертированный список в общем случае – это трехуровневая индексная структура. На первом
уровне находится файл или часть файла, в которой упорядоченно расположены значения
вторичных ключей. Каждая запись с вторичным ключом имеет ссылку на номер первого блока в
цепочке блоков, содержащих номера записей с данным значением вторичного ключа. На втором
уровне находится цепочка блоков, содержащих номера записей с одним и тем же значением
вторичного ключа. При этом блоки второго уровня упорядочены по значениям вторичного ключа.
На третьем уровне находится основной файл с записями. Представим механизм доступа к записям
по вторичному ключу:
Шаг_1. В области первого уровня ищется заданное значение вторичного ключа;
Шаг_2.По ссылке считываются блоки второго уровня, содержащие номера записей с заданным
значением вторичного ключа;
Шаг_3. В рабочую область пользователя прямым доступом загружается содержимое всех записей
с заданным значением вторичного ключа.
Для одного основного файла может быть создано несколько инвертированных списков по разным
вторичным ключам. Однако при модификации основного файла требуется внести изменения во
все инвертированные списки. Поэтому можно утверждать, что построение инвертированных
списков ускоряет процесс доступа только в том случае, если БД стабильна и ее содержимое не
20
изменяется.
Для моделирования связей на файловых структурах используется принцип организации цепочек
записей внутри файла и ссылки на номера записей для нескольких взаимосвязанных файлов.
Цепочка – это совокупность записей, расположенных в разных местах и связанных
последовательностью указателей. Структура файла с цепочкой может быть условно представлена
в виде:
Ключ
Запись
Ссылка-указатель на следующую запись
Для моделирования отношения один-ко-многим связываются два файла, например F1 и F2, причем
предполагается, что одна запись в файле F1 может быть связана с несколькими записями в файле
F2. Структура файла F1 может быть условно представлена:
Ключ
Запись
Ссылка-указатель на первую запись в файле F2, с которой начинается
цепочка записей файла, связанных с данной записью файла F1
Структура записи файла F2 имеет вид:
Указатель на следующую запись в цепочке
Содержимое записи
2.5.2 Модели страничной организации данных в современных БД
Реляционные СУБД хранят следующие разновидности объектов во внешней памяти БД:
 строки таблиц - основная часть БД;
 управляющие структуры - индексы, создаваемые по инициативе пользователя
(администратора) из соображений повышения эффективности выполнения запросов;
 журнальная информация, поддерживаемая для удовлетворения потребности в надежном
хранении данных;
 служебная информация, поддерживаемая для удовлетворения внутренних потребностей
нижнего уровня системы (например, информация о свободной памяти).
Хранение данных во внешней памяти в известных СУБД (Oracle, IBM DB2, Microsoft SQL Server,
Sybase и Informix и др.) организовано очень похожим образом. Основными единицами
физического хранения являются блок данных, экстент, чанк. Логический уровень представления
информации включает пространства (либо табличные пространства). Блок данных (block) или
страница (page) является единицей обмена с внешней памятью. Размер страницы фиксирован для
базы данных (Oracle) или устанавливается при создании БД.
Размер блока оказывает большое влияние на производительность базы данных — при больших
размерах скорость операций чтения/записи растет (особенно это характерно для полных
просмотров таблиц и операций интенсивной загрузки данных), однако возрастают накладные
расходы на хранение (база увеличивается) и снижается эффективность индексных просмотров.
Меньший размер блока позволяет более экономно расходовать память, но вместе с тем
относительно дорог. Длинные блоки (16, 32 или 64 Кбайт) лучше использовать для больших
объектов данных: полнотекстовые фрагменты, мультимедиа-объекты, длинные строки и т.п.
Короткие блоки (2 или 4 Кбайт) лучше подходят для значений числовых типов, недлинных строк,
значений даты и времени. Следует также учитывать размер блока ОС, он должен быть кратен
размеру блока базы данных.
Пространством внешней памяти, отведенным администратором, СУБД управляет с помощью
экстентов (extent), т.е. непрерывных последовательностей блоков (страниц). Экстенты
представляют собой единицу выделения памяти для таблиц и индексов. Информация о наличии
экстентов для объекта схемы данных находится в специальных управляющих структурах,
реализация которых зависит от СУБД. На управление экстентами (выделение пространства,
освобождение, слияние) тратятся определенные ресурсы, поэтому для достижения эффективности
нужно правильно определять их параметры. СУБД от Oracle, IBM, Informix позволяют определять
параметры этих структур, а в Sybase экстенты имеет постоянный размер, равный 8 страницам.
Уменьшение размера экстента будет способствовать более эффективному использованию памяти,
однако при этом возрастают накладные расходы на управление большим количеством экстентов,
что может замедлить операции вставки большого количества строк в таблицу. В Informix
существует еще одна единица физического хранения, промежуточная между файлом (или
21
разделом диска) и экстентом, — это «чанк» (от английского chunk, что дословно переводится как
«емкость»). Чанк позволяет более гибко управлять очень большими массивами внешней памяти. В
одном разделе диска или файле администратор может создать несколько чанков.
Основной единицей осуществления обмена данных является страница данных. Все данные
хранятся постранично. При табличном хранении данные на одной странице являются
однородными, т. е. страница может содержать только данные или только индексы.
Например, для СУБД MS SQL Server 2000 размер страниц – 8 Kb, заголовок страницы – 96 байт.
Страницы содержат строки данных, которые размещаются последовательно и начинаются сразу
после заголовка. Все страницы данных имеют одинаковую структуру, представленную на рис. 2.7.
Заголовок страницы
строки данных 1
строки данных 2
строки данных 3
Свободное место
Смещения
строк
3
2
1
Рисунок 2.7 Структура страницы данных MS SQL Server 2000
Заголовок страницы содержит системную информацию: идентификатор объекта данных, которому
принадлежит страница; логический номер страницы; логические номера следующей и
предыдущей страниц в цепочке; номер следующей свободной строки на странице. В конце
страницы располагается таблица смещения строк. В БД каждая строка имеет уникальный
идентификатор в рамках всей базы данных, часто называемый RID – номер строки, он имеет
размер 4 байта и состоит из номера страницы и номера строки на странице. При упорядочении
строк на страницах не происходит физического перемещения строк, все манипуляции происходят
со смещениями. При переполнении страниц создается специальный вид страниц, называемых
страницами остатка. Строки, не уместившиеся на основной странице, связываются со своим
продолжением на страницах остатка с помощью ссылок-указателей, которые содержат номер
страницы и номер смещения на странице.
2.5.3
Этапы доступа к БД
Опишем последовательность действий при доступе к БД (см. рис. 2.8):
1. Сначала в СУБД определяется искомая запись, а затем для ее извлечения запрашивается
диспетчер файлов (ДФ).
2. Диспетчер файлов одним из рассмотренных способов адресации определяет страницу, на
которой находится искомая запись, а затем для ее извлечения запрашивается диспетчер
дисков (ДД).
3. Диспетчер дисков определяет физическое положение искомой страницы на диске и
посылает запрос на ввод – вывод данных (страница уже может находиться в ОЗУ).
С точки зрения СУБД база данных выглядит как набор записей, которые могут просматриваться с
помощью ДФ. С точки зрения
ДФ БД выглядит как набор страниц, которые могут
просматриваться с помощью ДД.
ДД часто бывает компонентом ОС, с помощью которого выполняются все операции ввода/вывода,
используя физические адреса записей. Однако ДФ не обязательно знать физические адреса
записей, достаточно рассматривать диск как набор страниц фиксированного размера с
уникальным идентификатором набора страниц.
22
запрос хранимых записей
запрос хранимых страниц
СУБД
возврат
Возврат хранимых записей
записей
возврат хранимых страниц
ДФ
ДД
дисковые операции ввода/
вывода
БД
Рисунок 2.8 Схема доступа к БД
Страница внутри набора обладает уникальным идентификационным номером страницы.
Соответствие физических адресов на диске и номера станиц достигается с помощью ДД.
Преимущества страничной организации - все компоненты высокого уровня не зависят от
конкретного диска.
Диск – это набор хранимых файлов. Файл – хранимый набор однотипных записей. В общем случае
хранимый файл может храниться в памяти различными способами:

на одном томе памяти (диске);

на нескольких томах;

физически упорядоченным в соответствии со значением некоторого хранимого поля;

упорядоченным с помощью одного или нескольких индексов;

упорядоченным с помощью цепочек указателей;

к нему может быть обеспечен доступ методом хэш-адресации;

хранимые записи могут быть объединены в блоки (несколько логических записей в одной
физической записи).
Набор страниц может содержать несколько хранимых файлов. Каждый хранимый файл имеет имя
или идентификационный номер (file ID), уникальный в данном наборе страниц. А каждая
хранимая (логическая) запись обладает идентификационным номером (record ID).
ДФ выполняет следующие операции с файлами:
1. извлечь хранимую запись r из хранимого файла f;
2. заменить хранимую запись r в хранимом файле f;
3. удалить хранимую запись r из хранимого файла f;
4. добавить новую хранимую запись r в хранимый файл f;
5. создать новый хранимый файл f;
6. удалить хранимый файл f.
В одних СУБД ДФ – компонент ОС, а в других – СУБД.
Все страницы диска делятся на несвязанные наборы. Один из наборов, набор пустых страниц, свободное пространство на диске.
Операции, выполняемые ДД с наборами страниц:
1. извлечь страницу P из набора S;
2. заменить страницу P из набора S;
3. добавить новую страницу в набор S (извлечь ее из набора пустых страниц и добавить в
набор S);
4. удалить страницу P из набора S (поместить ее в набор пустых страниц).
Пример 2.1 Рассмотрим БД «Заказы деталей», которая содержит таблицы ПОСТАВЩИКИ (Р1,
23
Р2, Р3, Р4, Р5); ДЕТАЛИ (Д1, Д2, Д3, Д4, Д5, Д6); ПОСТАВКИ (РД1, РД2, РД3, РД4, РД5, РД6).
Для размещения БД будет создан набор страниц:
0
1
2
3
4
5
Р1
Р2
Р3
Р4
Р5
6
7
8
9
10
11
Д1
Д2
Д3
Д4
Д5
Д6
12
13
14
15
16
17
РД1
РД2
РД3
РД4
РД5
РД6
19
пустые
станицы
на
диске
18
На странице с номером 0 хранится информация о структуре БД: количестве записей в таблице; их
распределении по страницам; о номерах и количестве пустых страниц. Выполним действия по
модификации БД.
Добавить запись о поставщике Р6. Для этого ДФ вставляет новую хранимую запись, а ДД ищет
первую пустую страницу (18), а затем добавляет ее к набору страниц поставщиков.
Удалить запись о поставщике Р2. ДФ удаляет запись, а ДД возвращает страницу 2 в набор
пустых страниц.
Добавить новую запись о детали Д7. Для этого ДФ вставляет новую хранимую запись, а ДД ищет
первую пустую страницу (2), а затем добавляет ее к набору страниц о деталях.
После выполнения действий по модификации нельзя гарантировать, что логически близкие записи
будут физически располагаться рядом. Поэтому логическую последовательность страниц в данном
наборе следует задавать с помощью указателей.
Для некоторого хранимого файла всегда можно осуществить последовательный доступ ко всем
хранимым записям обычно в порядке возрастания RID (под термином «последовательный»
понимаем доступ согласно последовательности записей внутри страницы и последовательности
страниц внутри набора страниц). Такая последовательность называется физической, хотя она не
всегда соответствует физическому расположению данных на диске. Это наиболее простой способ
доступа к данным - последовательное сканирование.
Для ускорения поиска используются технологии хеширования, индексирования, поиска с
использованием В-деревьев.
2.6 Вопросы и упражнения для самоконтроля к главе 2
1. Чем даталогические документальные модели отличаются от фактографических?
2. Приведите примеры даталогических документальных моделей.
3. Какие компоненты входят в структуру логической (даталогической) модели?
4. Назовите структуры данных иерархических моделей.
5. Что включает в себя физическая модель данных?
6. Чем характеризуется последовательный доступ к данным?
7. Чем характеризуется прямой (произвольный) доступ к данным?
8. Какие методы адресации используются для ускорения доступа к данным?
9. Дайте характеристику методу хеширования.
10. Опишите алгоритм адресации с использованием индексно-последовательного файла?
11. Что такое страница данных? Опишите ее структуру.
12. Укажите последовательность действий доступа к данным.
13. Как связаны страницы данных в наборе?
14. Укажите последовательность действий по добавлению записи о поставках РД7 (пример
2.1).
15. Укажите последовательность действий по удалению записи о детали Д1 (пример 2.1).
Глава 3 Реляционная модель данных
3.1 Базовые понятия реляционных баз данных
Реляционные (от английского слова relation – отношение) модели были разработаны Э.
Коддом в начале 70-х годов. Основными понятиями реляционных баз данных являются тип
24
данных, домен, атрибут, кортеж, ключи, отношение, схема отношения.
Атрибут – это наименьшая поименованная единица данных, к которой СУБД может
адресоваться непосредственно, и с помощью которой выполняется построение всех остальных
структур. Атрибут имеет имя и значение.
Для начала покажем смысл этих понятий на примере отношения СОТРУДНИКИ, содержащего
информацию о сотрудниках некоторой организации (рис. 3.1).
3.1.1. Тип данных
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в
языках программирования. Обычно в современных реляционных БД допускается хранение данных
следующих типов: символьных, числовых, битовых, специализированных числовых данных
(таких как «деньги», «темпоральных» данных (дата, время, временной интервал). Достаточно
активно развивается подход к расширению возможностей реляционных систем абстрактными
типами данных (соответствующими возможностями обладают, например, системы семейства
Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые
числа и «деньги».
3.1.2. Домен
Домен – допустимое потенциальное множество значений простого типа данных Понятие домена
более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых
языках программирования. В самом общем виде домен определяется заданием некоторого
базового типа данных, к которому относятся элементы домена, и произвольного логического
выражения, применяемого к элементу типа данных. Если вычисление этого логического
выражения дает результат «истина», то элемент данных является элементом домена.
Например, домен «Имена» в нашем примере определен на базовом типе строк символов, но в
число его значений могут входить только те строки, которые могут представлять имя (в частности,
такие строки не могут начинаться с мягкого знака).
Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми
только в том случае, когда они относятся к одному домену. В нашем примере значения доменов
«Номера пропусков» и «Номера отделов» относятся к типу целых чисел, но не являются
сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется,
хотя в Oracle V.7 оно уже поддерживается.
3.1.3 Схема отношения, схема базы данных
Схема отношения - это именованное множество пар {имя атрибута – имя домена (или типа, если
понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого
множества. Степень отношения СОТРУДНИКИ равна четырем, то есть оно является 4-арным.
Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать
для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это
является всего лишь удобным способом именования и не устраняет различия между понятиями
домена и атрибута).
Схема БД (в структурном смысле) - это набор именованных схем отношений
3.1.4 Кортеж, отношение, ключи
Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме
отношения. "Значение" является допустимым значением домена данного атрибута (или типа
данных, если понятие домена не поддерживается). Степень или «арность» кортежа, т.е. число
элементов в кортеже, совпадает с «арностью» соответствующей схемы отношения. Кортеж - это
набор именованных значений заданного типа.
Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда,
чтобы не путаться, говорят «отношение-схема» и «отношение-экземпляр», иногда схему
отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения.
На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в
языках программирования. Было бы вполне логично разрешать отдельно определять схему
отношения, а затем одно или несколько отношений с данной схемой.
Однако в реляционных базах данных это не принято. Имя схемы отношения в таких базах данных
25
всегда совпадает с именем соответствующего отношения-экземпляра. В классических
реляционных базах данных после определения схемы базы данных изменяются только отношенияэкземпляры. В них могут появляться новые и удаляться или модифицироваться существующие
кортежи. Однако во многих реализациях СУБД допускается и изменение схемы базы данных:
определение новых и изменение существующих схем отношения. Это принято называть
эволюцией схемы базы данных.
Обычным представлением отношения является таблица, заголовком которой является схема
отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют
Рисунок 3.1 Пример отношения СОТРУДНИКИ
столбцы этой таблицы. Поэтому иногда говорят «столбец таблицы» имея в виду «атрибут
отношения». Когда мы перейдем к рассмотрению практических вопросов организации
реляционных БД и средств управления, мы будем использовать эту житейскую терминологию.
Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД.
Термины, которыми оперирует реляционная модель данных, имеют соответствующие
«табличные» синонимы, представленные в таблице 3.1
Таблица 3.1 – Соответствие терминов
Реляционный термин
Соответствующий «табличный» термин
База данных
Набор таблиц
Схема базы данных
Набор заголовков таблиц
Отношение
Таблица
26
Заголовок отношения
Заголовок таблицы
Тело отношения
Тело таблицы
Атрибут отношения
Столбец (колонка) таблицы
Кортеж отношения
Строка таблицы
Степень (-арность) отношения Количество столбцов таблицы
Мощность отношения
Количество строк таблицы
Домены и типы данных
Типы данных в ячейках таблицы
Реляционная база данных - это набор отношений, имена которых совпадают с именами схем
отношений в схеме БД.
Ключ – набор атрибутов, значение которых однозначно идентифицирует кортежи. Отношение
может иметь несколько ключей, но всегда один из ключей объявляется первичным и его значения
не могут обновляться. Все остальные ключи называются возможными ключами. Атрибуты,
представляющие собой копии ключей других отношений называются внешними ключами.
3.1.5 Связи в реляционных базах данных
В реляционных БД связи позволяют избежать избыточности данных. Связь работает путем
сопоставления данных ключевых столбцов. В большинстве случаев связь сопоставляет первичный
ключ одной таблицы с внешним ключом другой таблицы. Связи между таблицами могут быть трех
видов:
1. Один-к-одному. Одной записи таблицы А соответствует одна запись таблицы Б, и наоборот. Этот тип
связи применяется достаточно редко. Единственный случай, когда применение этого типа связи
оправданно – разбиение таблицы, содержащей очень большое количество полей, на несколько частей.
2. Один-ко-многим. Одной записи таблицы А (главной) соответствует несколько записей таблицы Б (или
ни одной). В свою очередь каждой записи таблицы Б (подчиненной) может соответствовать только одна
запись таблицы А. Наиболее употребительный вид связи.
3. Многие-ко-многим. При этом типе связи многим записям из таблицы А может соответствовать много
записей из таблицы Б (и наоборот). Такую связь в реляционных БД можно организовать только при
помощи третьей вспомогательной таблицы. По сути связь «многие-ко-многим» представляет собой две
связи типа «один-ко-многим». При этом таблицы А и Б расположены со стороны «один», а
вспомогательная таблица со стороны – «многие».
Как видно, основные структурные понятия реляционной модели данных (если не считать понятия
домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все
они определяются абсолютно формально и точно.
3.2 Фундаментальные свойства отношений
Остановимся теперь на четырех важных свойствах отношений, которые следуют из
приведенных ранее определений.
3.2.1 Отсутствие кортежей-дубликатов
То свойство, что отношения не содержат кортежей-дубликатов, следует из определения
отношения как множества кортежей. В классической теории множеств по определению каждое
множество состоит из различных элементов.
Из этого свойства вытекает наличие у каждого отношения так называемого первичного
ключа - набора атрибутов, значения которых однозначно определяют кортеж отношения. Для
каждого отношения по крайней мере полный набор его атрибутов обладает этим свойством.
Однако при формальном определении первичного ключа требуется обеспечение его
«минимальности», т.е. в набор атрибутов первичного ключа не должны входить такие атрибуты,
которые можно отбросить без ущерба для основного свойства, - однозначно определять кортеж.
Понятие первичного ключа является исключительно важным в связи с понятием целостности баз
данных.
3.2.2 Отсутствие упорядоченности кортежей
Свойство отсутствия упорядоченности кортежей отношения также является следствием
определения отношения-экземпляра как множества кортежей. Отсутствие требования к
27
поддержанию порядка на множестве кортежей отношения дает дополнительную гибкость СУБД
при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не
противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно
потребовать сортировки результирующей таблицы в соответствии со значениями некоторых
столбцов. Такой результат, вообще говоря, не отношение, а некоторый упорядоченный список
кортежей.
3.2.3 Отсутствие упорядоченности атрибутов
Атрибуты отношений не упорядочены, поскольку по определению схема отношения есть
множество пар {имя атрибута – имя домена}. Для ссылки на значение атрибута в кортеже
отношения всегда используется имя атрибута. Это свойство теоретически позволяет, например,
модифицировать схемы существующих отношений не только путем добавления новых атрибутов,
но и путем удаления существующих атрибутов. Однако в большинстве существующих систем
такая возможность не допускается, и хотя упорядоченность набора атрибутов отношения явно не
требуется, часто в качестве неявного порядка атрибутов используется их порядок в линейной
форме определения схемы отношения.
3.2.4 Атомарность значений атрибутов
Значения всех атрибутов являются атомарными. Это следует из определения домена как
потенциального множества значений простого типа данных, т.е. среди значений домена не могут
содержаться множества значений (отношения). Принято говорить, что в реляционных базах
данных допускаются только нормализованные отношения или отношения, представленные в
первой нормальной форме. Нормализованные отношения составляют основу классического
реляционного подхода к организации баз данных. Они обладают некоторыми ограничениями (не
любую информацию удобно представлять в виде плоских таблиц), но существенно упрощают
манипулирование данными.
3.3. Характеристика реляционной модели данных
Наиболее распространенная трактовка реляционной модели данных, по-видимому,
принадлежит Дейту К., который воспроизводит ее (с различными уточнениями) практически во
всех своих книгах. Согласно Дейту реляционная модель состоит из трех частей, описывающих
разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной
части.
В структурной части реляционной модели данных фиксируется, что единственной
структурой данных, используемой в реляционных БД, является нормализованное n-арное
отношение. По сути дела, в предыдущих двух параграфах мы рассматривали именно понятия и
свойства структурной составляющей реляционной модели.
В манипуляционной части реляционной модели данных утверждаются два фундаментальных
механизма манипулирования реляционными БД - реляционная алгебра и реляционное исчисление.
Первый механизм базируется в основном на классической теории множеств (с некоторыми
уточнениями), а второй - на классическом логическом аппарате исчисления предикатов первого
порядка.
В целостной части реляционной модели данных фиксируются два базовых требования
целостности, которые должны поддерживаться в любой реляционной СУБД.
Первое требование называется требованием целостности сущностей. Объектам или
сущностям реального мира в реляционных БД соответствуют кортежи отношений. Конкретно
требование состоит в том, что любой кортеж любого отношения отличим от любого другого
кортежа этого отношения, т.е. другими словами, любое отношение должно обладать первичным
ключом. Как видно из предыдущего раздела, это требование автоматически удовлетворяется, если
в системе не нарушаются базовые свойства отношений.
Второе требование называется требованием целостности по ссылкам и является более
сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности
реального мира представляются в реляционной БД в виде нескольких кортежей нескольких
отношений. Например, представим, что нам требуется представить в реляционной БД сущность
ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и
ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР
28
(номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника).
При правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ (
ОТД_НОМЕР, ОТД_КОЛ ) первичный ключ - ОТД_НОМЕР и СОТРУДНИКИ ( СОТР_НОМЕР,
СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ ) первичный ключ - СОТР_НОМЕР.
Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому,
что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь
возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута
СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать
значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода
называется внешним ключом, поскольку его значения однозначно характеризуют сущности,
представленные кортежами некоторого другого отношения (т.е. задают значения их первичного
ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на
соответствующее отношение, в котором такой же атрибут является первичным ключом.
Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что
для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении,
на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа,
либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать). Для
нашего примера это означает, что если для сотрудника указан номер отдела, то этот отдел должен
существовать.
Ограничения целостности сущности и по ссылкам должны поддерживаться СУБД. Для
соблюдения целостности сущности достаточно гарантировать отсутствие в любом отношении
кортежей с одним и тем же значением первичного ключа. С целостностью по ссылкам дела
обстоят несколько более сложно.
Понятно, что при обновлении ссылающегося отношения (вставке новых кортежей или
модификации значения внешнего ключа в существующих кортежах) достаточно следить за тем,
чтобы не появлялись некорректные значения внешнего ключа. Но как быть при удалении кортежа
из отношения, на которое ведет ссылка?
Существуют три подхода, каждый из которых поддерживает целостность по ссылкам:
1. запрещается производить удаление кортежа, на который существуют ссылки (т.е. сначала
нужно либо удалить ссылающиеся кортежи, либо соответствующим образом изменить значения
их внешнего ключа);
2. при удалении кортежа, на который имеются ссылки, во всех ссылающихся кортежах значение
внешнего ключа автоматически становится неопределенным;
3. каскадное удаление, состоящее в том, что при удалении кортежа из отношения, на которое ведет
ссылка, из ссылающегося отношения автоматически удаляются все ссылающиеся кортежи.
В развитых реляционных СУБД обычно можно выбрать способ поддержания целостности по
ссылкам для каждой отдельной ситуации определения внешнего ключа. Конечно, для принятия
такого решения необходимо анализировать требования конкретной прикладной области.
3.4 Трехзначная логика (3VL)
В подходе 2 (п.3.3) использовано понятие «неопределенного» значения ключа. В реальном
мире часто встречается ситуация, когда данные неизвестны или неполны. Для того чтобы обойти
проблему неполных или неизвестных данных, в базах данных могут использоваться так
называемые null-значения. Null-значение - это, собственно, не значение, а некий маркер,
показывающий, что значение неизвестно.
Таким образом, в ситуации, когда возможно появление неопределенных, неизвестных или
неполных данных, разработчик имеет на выбор два варианта.
Первый вариант состоит в том, чтобы не использовать null-значения, а вместо неизвестных
данных вводить либо нулевые значения, либо значения специального вида - например,
договориться, что строка "КЛЮЧ НЕИЗВЕСТЕН" и есть те данные, которые нужно вводить
вместо неизвестного ключа. В любом случае пользователь (или разработчик) ответственен за
правильную трактовку таких данных.
Второй вариант состоит в использовании null-значений вместо неизвестных данных. За
кажущейся естественностью такого подхода скрываются менее очевидные и более глубокие
29
проблемы. Наиболее бросающейся в глаза проблемой является необходимость использования
трехзначной логики при оперировании с данными, которые могут содержать null-значения. В этом
случае при неаккуратном формулировании запросов, даже самые естественные запросы могут
давать неправильные ответы. Практически все реализации современных реляционных СУБД
позволяют использовать null-значения, несмотря на их недостаточную теоретическую
обоснованность.
Приведем здесь описание трехзначной логики, необходимой для работы с null-значениями.
Т.к. null-значение обозначает на самом деле тот факт, что значение неизвестно, то любые
алгебраические операции (сложение, умножение, конкатенация строк и т.д.) должны давать также
неизвестное значение, т.е. null. Действительно, если, например, вес детали неизвестен, то
неизвестно также, сколько весят 10 таких деталей.
При сравнении выражений, содержащих null-значения, результат также может быть неизвестен,
например, значение истинности для выражения
есть null, если один или оба аргумента есть
null. Таким образом, определение истинности логических выражений базируется на трехзначной
логике (three-valued logic, 3VL), в которой кроме значений T - ИСТИНА и F - ЛОЖЬ, введено
значение U - НЕИЗВЕСТНО. Логическое значение U - это то же самое, что и null-значение.
Трехзначная логика базируется на следующих таблицах истинности:
AND F T U
F
F F
F
T
F T
U
U
F U
U
OR
F T U
F
F T U
T
T T T
U
U T U
NOT
F
T
T
F
U
U
Рисунок 3.2 Таблицы истинности логических операций AND, OR, NOT
Имеется несколько парадоксальных следствий применения трехзначной логики.
Парадокс 1. Null-значение не равно самому себе. Действительно, выражение null = null дает
значение не ИСТИНА, а НЕИЗВЕСТНО. Значит выражение
не обязательно ИСТИНА!
Парадокс 2. Неверно также, что null-значение не равно самому себе! Действительно, выражение
null null также принимает значение не ИСТИНА, а НЕИЗВЕСТНО! Значит также, что и
выражение
тоже не обязательно ЛОЖЬ!
Парадокс 3.
не обязательно ИСТИНА. Значит, в трехзначной логике не работает
принцип исключенного третьего (любое высказывание либо истинно, либо ложно).
Таких парадоксов можно построить сколько угодно. Конечно, это на самом деле не парадоксы, а
просто следствия из аксиом трехзначной логики.
3.5 Реляционная алгебра
Вторая часть реляционной модели, манипуляционная часть, утверждает, что доступ к
реляционным данным осуществляется при помощи реляционной алгебры или эквивалентного ему
реляционного исчисления.
30
В реализациях конкретных реляционных СУБД сейчас не используется в чистом виде ни
реляционная алгебра, ни реляционное исчисление. Фактическим стандартом доступа к
реляционным данным стал язык SQL (Structured Query Language). Язык SQL представляет собой
смесь операторов реляционной алгебры и выражений реляционного исчисления, использующий
синтаксис, близкий к фразам английского языка и расширенный дополнительными
возможностями, отсутствующими в реляционной алгебре и реляционном исчислении. Вообще,
язык доступа к данным называется реляционно полным, если он по выразительной силе не
уступает реляционной алгебре (или, что то же самое, реляционному исчислению), т.е. любой
оператор реляционной алгебры может быть выражен средствами этого языка. Именно таким и
является язык SQL.
В данной главе будут рассмотрены основы реляционной алгебры.
Реляционная алгебра представляет собой набор операторов, использующих отношения в
качестве аргументов, и возвращающие отношения в качестве результата. Таким образом,
реляционный оператор
выглядит как функция с отношениями в качестве аргументов:
Реляционная алгебра является замкнутой, т.к. в качестве аргументов в реляционные
операторы можно подставлять другие реляционные операторы, подходящие по типу:
Таким образом, в реляционных выражениях можно использовать вложенные выражения сколь
угодно сложной структуры.
Каждое отношение обязано иметь уникальное имя в пределах базы данных. Имя отношения,
полученного в результате выполнения реляционной операции, определяется в левой части
равенства. Однако можно не требовать наличия имен от отношений, полученных в результате
реляционных выражений, если эти отношения подставляются в качестве аргументов в другие
реляционные выражения. Такие отношения будем называть неименованными отношениями.
Неименованные отношения реально не существуют в базе данных, а только вычисляются в
момент определения значения реляционного оператора.
Традиционно, вслед за Э. Коддом, определяют восемь реляционных операций реляционной
алгебры, объединенных в две группы.
Теоретико-множественные операции:
 объединение;
 пересечение;
 вычитание;
 декартово произведение.
Специальные реляционные операции:
 выборка (селекция, ограничение) ;
 проекция;
 соединение;
 деление.
Не все они являются независимыми, т.е. некоторые из этих операций могут быть выражены через
другие реляционные операции. Каждая операция реляционной алгебры использует одну или
несколько таблиц (отношений) в качестве своих операндов и продуцирует в результате новую
таблицу, т.е. позволяет «разрезать» или «склеивать» таблицы (рис. 3.3)
31
Рисунок. 3.3. Графическая интерпретация некоторых операций реляционной алгебры
Кроме того, в состав алгебры включается операция присваивания, позволяющая сохранить в базе
данных результаты вычисления алгебраических выражений, и операция переименования
атрибутов, дающая возможность корректно сформировать заголовок (схему) результирующего
отношения. Если не вдаваться в некоторые тонкости, которые мы рассмотрим в следующих
подразделах, то почти все операции предложенного выше набора обладают очевидной и простой
интерпретацией:
1. Объединение. При выполнении операции объединения двух отношений производится
отношение, включающее все кортежи, входящие хотя бы в одно из отношений-операндов.
Объединением двух совместимых по типу отношений
и
называется отношение с тем же
заголовком, что и у отношений и , и телом, состоящим из кортежей, принадлежащих или ,
или , или обоим отношениям.
Синтаксис операции объединения:
Объединение, как и любое отношение, не может содержать одинаковых кортежей. Поэтому, если
некоторый кортеж входит и в отношение , и отношение , то в объединение он входит один
раз.
Пример 3.1 Пусть даны два отношения и с информацией о сотрудниках:
Отношение A
Табельный номер Фамилия Зарплата
1
Иванов
1000
2
Петров
2000
3
Сидоров
3000
Отношение В
Табельный номер Фамилия Зарплата
Объединение отношений
1
Иванов
4
Пушников 2500
3
Сидоров
1000
3000
и
Отношение A UNION B будет иметь вид:
Табельный
Фамилия Зарплата
номер
1
Иванов
32
1000
2
Петров
2000
3
Сидоров
3000
4
Пушников 2500
2. Пересечение. Операция пересечения двух отношений производит отношение, включающее все
кортежи, входящие в оба отношения-операнда. Пересечением двух совместимых по типу
отношений и называется отношение с тем же заголовком, что и у отношений и , и телом,
состоящим из кортежей, принадлежащих одновременно обоим отношениям и .
Синтаксис операции пересечения:
Пример 3.2 Для тех же отношений и , что и в предыдущем примере пересечение
A INTERSECT B имеет вид:
Табельный номер Фамилия Зарплата
1
Иванов
1000
3
Сидоров 3000
3. Разность. Отношение, являющееся разностью двух отношений включает все кортежи,
входящие в отношение - первый операнд, такие, что ни один из них не входит в отношение,
являющееся вторым операндом. Вычитанием (разностью) двух совместимых по типу отношений
и называется отношение с тем же заголовком, что и у отношений и , и телом, состоящим
из кортежей, принадлежащих отношению и не принадлежащих отношению .
Синтаксис операции вычитания:
Пример 3.3 Для тех же отношений и , что и в предыдущем примере вычитание Отношение A
MINUS B имеет вид:
Табельный номер Фамилия Зарплата
2
Петров
2000
4. Декартово произведение.
При выполнении прямого произведения двух отношений
производится отношение, кортежи которого являются конкатенацией (сцеплением) кортежей
первого и второго операндов. Декартовым произведением двух отношений
и
называется отношение, заголовок которого является сцеплением заголовков
и
, а тело состоит из кортежей, являющихся сцеплением кортежей отношений
отношений
и .
Синтаксис операции декартового произведения:
Замечание. Мощность произведения
равна произведению мощностей отношений и
, т.к. каждый кортеж отношения соединяется с каждым кортежем отношения .
Замечание. Если в отношения и имеются атрибуты с одинаковыми наименованиями, то перед
выполнением операции декартового произведения такие атрибуты необходимо переименовать.
Замечание. Перемножать можно любые два отношения, совместимость по типу при этом не
требуется.
Пример 3.4 Пусть даны два отношения и с информацией о поставщиках и деталях:
Отношение A (Поставщики)
Номер поставщика Наименование поставщика
1
Иванов
2
Петров
3
Сидоров
Отношение B (Детали)
33
Номер детали Наименование детали
1
Болт
2
Гайка
3
Винт
Декартово произведение отношений и Отношение A TIMES B будет иметь вид:
Номер
Наименование Номер Наименование
поставщика поставщика
детали детали
1
Иванов
1
Болт
1
Иванов
2
Гайка
1
Иванов
3
Винт
2
Петров
1
Болт
2
Петров
2
Гайка
2
Петров
3
Винт
3
Сидоров
1
Болт
3
Сидоров
2
Гайка
3
Сидоров
3
Винт
Замечание. Сама по себе операция декартового произведения не очень важна, т.к. она не дает
никакой новой информации, по сравнению с исходными отношениями. Для реальных запросов эта
операция почти никогда не используется. Однако операция декартового произведения важна для
выполнения специальных реляционных операций, о которых речь пойдет ниже.
5. Ограничение (выборка, селекция). Результатом ограничения отношения по некоторому условию
является отношение, включающее кортежи отношения-операнда, удовлетворяющее этому
условию. Выборкой (ограничением, селекцией) на отношении
с условием
называется
отношение с тем же заголовком, что и у отношения , и телом, состоящем из кортежей, значения
атрибутов которых при подстановке в условие
дают значение ИСТИНА. представляет собой
логическое выражение, в которое могут входить атрибуты отношения
и (или) скалярные
выражения.
В простейшем случае условие
имеет вид
, где
- один из операторов сравнения
(
и т.д.), а и - атрибуты отношения или скалярные значения.
Синтаксис операции выборки:
, или
Пример 3.5 Пусть дано отношение с информацией о сотрудниках:
Отношение A
Табельный номер Фамилия Зарплата
Результат выборки
1
Иванов
1000
2
Петров
2000
3
Сидоров
3000
будет иметь вид:
Табельный номер Фамилия Зарплата
1
Иванов
1000
2
Петров
2000
Смысл операции выборки очевиден - выбрать кортежи отношения, удовлетворяющие некоторому
34
условию. Таким образом, операция выборки дает «горизонтальный срез» отношения по
некоторому условию.
6. Проекция. При выполнении проекции отношения на заданный набор его атрибутов
производится отношение, кортежи которого производятся путем взятия соответствующих
значений из кортежей отношения-операнда. Проекцией отношения по атрибутам
, где
каждый из атрибутов принадлежит отношению
, называется отношение с заголовком
и телом, содержащим множество кортежей вида
отношении
найдутся кортежи со значением атрибута
равным
равным , …, значением атрибута равным .
, таких, для которых в
, значением атрибута
Синтаксис операции проекции:
Замечание. Операция проекции дает «вертикальный срез» отношения, в котором удалены все
возникшие при таком срезе дубликаты кортежей.
Пример 3.6 Пусть дано отношение с информацией о поставщиках, включающих наименование
и месторасположение:
Отношение A (Поставщики)
Номер поставщика Наименование поставщика Город поставщика
Проекция
1
Иванов
Уфа
2
Петров
Москва
3
Сидоров
Москва
4
Сидоров
Челябинск
будет иметь вид:
Город поставщика
Уфа
Москва
Челябинск
7. Соединение. При соединении двух отношений по некоторому условию образуется
результирующее отношение, кортежи которого являются сцеплением кортежей первого и второго
отношений и удовлетворяют этому условию. Соединением отношений
и
по условию
называется отношение
представляет собой логическое выражение, в которое могут входить атрибуты отношений и
и (или) скалярные выражения. Таким образом, операция соединения есть результат
последовательного применения операций декартового произведения и выборки. Если в
отношениях и имеются атрибуты с одинаковыми наименованиями, то перед выполнением
соединения такие атрибуты необходимо переименовать.
Операция соединения отношений, наряду с операциями выборки и проекции, является одной из
наиболее важных реляционных операций.
Обычно рассматривается несколько разновидностей операции соединения:
 общая операция соединения;

-соединение (тэта-соединение);
 эквисоединение;
 естественное соединение
Наиболее важным из этих частных случаев является операция естественного соединения. Все
разновидности соединения являются частными случаями общей операции соединения.
Тэта-соединение. Пусть отношение содержит атрибут , отношение содержит атрибут , а
- один из операторов сравнения (
и т.д.). Тогда -соединением отношения по
35
атрибуту
с отношением
по атрибуту
называют отношение
Это частный случай операции общего соединения.
Пример 3.7 Рассмотрим некоторую компанию, в которой хранятся данные о поставщиках и
поставляемых деталях. Пусть поставщикам и деталям присвоен некий статус. Пусть бизнес
компании организован таким образом, что поставщики имеют право поставлять только те детали,
статус которых не выше статуса поставщика (смысл этого может быть в том, что хороший
поставщик с высоким статусом может поставлять больше разновидностей деталей, а плохой
поставщик с низким статусом может поставлять только ограниченный список деталей, важность
которых (статус детали) не очень высока).
Отношение A (Поставщики)
Номер поставщика Наименование поставщика X
(Статус поставщика)
1
Иванов
4
2
Петров
1
Сидоров
2
3
Отношение B (Детали)
Номер Наименование Y
детали детали
(Статус
детали)
1
Болт
3
2
Гайка
2
3
Винт
1
Ответ на вопрос "какие поставщики имеют право поставлять какие детали?" дает
: Отношение "Какие поставщики поставляют какие детали"
Номер
Наименование
X
Номер
Наименование
поставщика
поставщика
(Статус
детали
детали
поставщика)
-соединение
Y
(Статус
детали)
1
Иванов
4
1
Болт
3
1
Иванов
4
2
Гайка
2
1
Иванов
4
3
Винт
1
2
Петров
1
3
Винт
1
3
Сидоров
2
2
Гайка
2
3
Сидоров
2
3
Винт
1
Эквисоединение. Наиболее важным частным случаем
-соединения является случай, когда
есть
просто равенство. Синтаксис эквисоединения:
Пример 3.8 Пусть имеются отношения
,
и
, хранящие информацию о поставщиках,
деталях и поставках соответственно (для удобства введем краткие наименования атрибутов):
Отношение P (Поставщики)
Номер поставщика Наименование поставщика
PNUM
PNAME
1
Иванов
36
2
Петров
3
Сидоров
Отношение D (Детали)
Номер детали Наименование детали
DNUM
DNAME
1
Болт
2
Гайка
3
Винт
Отношение PD (Поставки)
Номер
Номер Поставляемое
поставщика детали количество
PNUM
DNUM VOLUME
1
1
100
1
2
200
1
3
300
2
1
150
2
2
250
3
Ответ
на
вопрос,
какие
детали
1
1000
поставляются поставщиками,
дает
эквисоединение
. На самом деле, т.к. в отношениях имеются одинаковые атрибуты, то
требуется сначала переименовать атрибуты, а потом выполнить эквисоединение. В результате
имеем отношение «Какие детали поставляются какими поставщиками?»
Номер
Наименование
Номер
Номер
Поставляемое
поставщика
поставщика
поставщика
детали
количество
PNUM1
PNAME
PNUM2
DNUM
VOLUME
1
Иванов
1
1
100
1
Иванов
1
2
200
1
Иванов
1
3
300
2
Петров
2
1
150
2
Петров
2
2
250
3
Сидоров
3
1
1000
Недостатком эквисоединения является то, что если соединение происходит по атрибутам с
одинаковыми наименованиями (а так чаще всего и происходит!), то в результирующем отношении
появляется два атрибута с одинаковыми значениями. В нашем примере атрибуты PNUM1 и
PNUM2 содержат дублирующие данные. Избавиться от этого недостатка можно, взяв проекцию
по всем атрибутам, кроме одного из дублирующих. Именно так действует естественное
соединение.
Естественное
соединение.
Пусть
даны
отношения
и
, имеющие одинаковые атрибуты
(т.е. атрибуты с
одинаковыми именами и определенные на одинаковых доменах). Тогда естественным
соединением
отношений
и
называется
отношение
с
заголовком
37
и
,
телом,
таких,
содержащим
множество
кортежей
что
и
.
Естественное соединение настолько важно, что для него используют специальный синтаксис:
Замечание. В синтаксисе естественного соединения не указываются, по каким атрибутам
производится соединение. Естественное соединение производится по всем одинаковым атрибутам.
Замечание. Естественное соединение эквивалентно следующей последовательности реляционных
операций:
1. Переименовать одинаковые атрибуты в отношениях
2. Выполнить декартово произведение отношений
3. Выполнить выборку по совпадающим значениям атрибутов, имевших одинаковые имена
4. Выполнить проекцию, удалив повторяющиеся атрибуты
5. Переименовать атрибуты, вернув им первоначальные имена
Пример 3.9 В предыдущем примере ответ на вопрос «Какие детали поставляются
поставщиками?», более просто записывается в виде естественного соединения трех отношений
(для удобства просмотра порядок атрибутов изменен, это является допустимым
по свойствам отношений):
Отношение P JOIN PD JOIN D
Номер
Наименование
Номер
Наименование
Поставляемое
поставщика
поставщика
детали
детали
количество
PNUM
PNAME
DNUM
DNAME
VOLUME
1
Иванов
1
Болт
100
1
Иванов
2
Гайка
200
1
Иванов
3
Винт
300
2
Петров
1
Болт
150
2
Петров
2
Гайка
250
3
Сидоров
1
Болт
1000
8. Деление. У операции реляционного деления два операнда - бинарное и унарное отношения.
Результирующее отношение состоит из одноатрибутных кортежей, включающих значения первого
атрибута кортежей первого операнда таких, что множество значений второго атрибута (при
фиксированном значении первого атрибута) совпадает со множеством значений второго операнда.
Пусть даны отношения
и
общие для двух отношений. Делением отношений
на
и телом, содержащим множество кортежей
, причем атрибуты
называется отношение с заголовком
, таких, что для всех
кортежей
в отношении найдется кортеж
.
Отношение
выступает в роли делимого, отношение
выступает в роли делителя. Деление
отношений аналогично делению чисел с остатком.
Синтаксис операции деления:
Замечание. Типичные запросы, реализуемые с помощью операции деления, обычно в своей
формулировке имеют слово «все» - «Какие поставщики поставляют все детали?».
Пример 3.10 В примере с поставщиками, деталями и поставками ответим на вопрос, «Какие
поставщики поставляют все детали?».
В качестве делимого возьмем проекцию
поставщиков и номера поставляемых ими деталей:
38
, содержащую номера
Проекция X=PD[PNUM,DNUM]
Номер поставщика Номер детали
PNUM
DNUM
1
1
1
2
1
3
2
1
2
2
3
1
В качестве делителя возьмем проекцию
(не обязательно поставляемых кем-либо):
Проекция Y=D[DNUM]
, содержащую список номеров всех деталей
Номер
детали
DNUM
1
2
3
Деление
дает список номеров поставщиков, поставляющих все детали:
Отношение X DEVIDEBY Y
Номер поставщика
PNUM
1
Оказалось, что только поставщик с номером 1 поставляет все детали.
9. Переименование. Операция переименования производит отношение, тело которого совпадает с
телом операнда, но имена атрибутов изменены.
10. Присваивание. Операция присваивания позволяет сохранить результат вычисления
реляционного выражения в существующем отношении БД.
3.6 Особенности операций реляционной алгебры
Хотя в основе теоретико-множественной части реляционной алгебры лежит классическая
теория множеств, соответствующие операции реляционной алгебры обладают некоторыми
особенностями.
Начнем с операции объединения (все, что будет говориться по поводу объединения,
переносится на операции пересечения и взятия разности). Смысл операции объединения в
реляционной алгебре в целом остается теоретико-множественным. Но если в теории множеств
операция объединения осмысленна для любых двух множеств-операндов, то в случае реляционной
алгебры результатом операции объединения должно являться отношение. Если допустить в
реляционной алгебре возможность теоретико-множественного объединения произвольных двух
отношений (с разными схемами), то, конечно, результатом операции будет множество, но
множество разнотипных кортежей, т.е. не отношение. Если исходить из требования замкнутости
реляционной алгебры относительно понятия отношения, то такая операция объединения является
бессмысленной.
Все эти соображения приводят к появлению понятия совместимости отношений по
объединению: два отношения совместимы по объединению в том и только в том случае, когда
обладают одинаковыми заголовками. Более точно, это означает, что в заголовках обоих
39
отношений содержится один и тот же набор имен атрибутов, и одноименные атрибуты
определены на одном и том же домене.
Если два отношения совместимы по объединению, то при обычном выполнении над ними
операций объединения, пересечения и взятия разности результатом операции является отношение
с корректно определенным заголовком, совпадающим с заголовком каждого из отношенийоперандов. Напомним, что если два отношения «почти» совместимы по объединению, т.е.
совместимы во всем, кроме имен атрибутов, то до выполнения операции типа соединения эти
отношения можно сделать полностью совместимыми по объединению путем применения
операции переименования.
Заметим, что включение в состав операций реляционной алгебры трех операций
объединения, пересечения и взятия разности является очевидно избыточным, поскольку известно,
что любая из этих операций выражается через две других. Тем не менее, Э. Кодд в свое время
решил включить все три операции, исходя из интуитивных потребностей потенциального
пользователя системы реляционных БД, далекого от математики.
Другие проблемы связаны с операцией взятия декартового произведения двух отношений.
Следует заметить, что операция взятия декартового произведения не является слишком
осмысленной на практике. Во-первых, мощность ее результата очень велика даже при допустимых
мощностях операндов, а во-вторых, результат операции не более информативен, чем взятые в
совокупности операнды. Как мы увидим немного ниже, основной смысл включения операции
расширенного декартового произведения в состав реляционной алгебры состоит в том, что на ее
основе определяется действительно полезная операция соединения.
По поводу теоретико-множественных операций реляционной алгебры следует еще заметить,
что все четыре операции являются ассоциативными. Если обозначить через OP любую из четырех
операций, то (A OP B) OP C = A ОР (B OP C), и следовательно, без введения двусмысленности
можно писать A OP B OP C (A, B и C - отношения, обладающие свойствами, требуемыми для
корректного выполнения соответствующей операции). Все операции, кроме взятия разности,
являются коммутативными, т.е. A OP B = B OP A.
Не все операции реляционной алгебры являются независимыми - некоторые из них
выражаются через другие реляционные операции. Операция соединения определяется через
операции декартового произведения и выборки. Для операции естественного соединения
добавляется операция проекции. Операция пересечения выражается через вычитание следующим
образом:
Операция деления выражается через операции вычитания, декартового произведения и проекции
следующим образом:
Несмотря на мощь языка реляционной алгебры, имеется ряд типов запросов, которые
принципиально нельзя выразить только при помощи операций реляционной алгебры. Это вовсе не
означает, что ответы на эти запросы нельзя получить вообще. Просто, для получения ответов на
подобные запросы приходится применять процедурные расширения реляционных языков.
3.7 Реляционное исчисление
Пример 3.11 Предположим, что мы работаем с базой данных, обладающей схемой СОТРУДНИКИ
(СОТР_НОМ, СОТР_ИМЯ, СОТР_ЗАРП, ОТД_НОМ) и ОТДЕЛЫ (ОТД_НОМ, ОТД_КОЛ,
ОТД_НАЧ), и хотим узнать имена и номера сотрудников, являющихся начальниками отделов с
количеством сотрудников больше 50.
Если бы для формулировки такого запроса использовалась реляционная алгебра, то мы
получили бы алгебраическое выражение, которое читалось бы, например, следующим образом:
 выполнить соединение отношений СОТРУДНИКИ и ОТДЕЛЫ по условию СОТР_НОМ =
ОТД_НАЧ;
 ограничить полученное отношение по условию ОТД_КОЛ > 50;
 спроецировать результат предыдущей операции на атрибуты СОТР_ИМЯ, СОТР_НОМ.
40
Мы четко сформулировали последовательность шагов выполнения запроса, каждый из
которых соответствует одной реляционной операции. Если же сформулировать тот же запрос с
использованием реляционного исчисления, которому посвящается этот раздел, то мы получили бы
формулу, которую можно было бы прочитать, например, следующим образом: Выдать
СОТР_ИМЯ и СОТР_НОМ для сотрудников таких, что существует отдел с таким же значением
ОТД_НАЧ и значением ОТД_КОЛ большим 50.
Во второй формулировке мы указали лишь характеристики результирующего отношения, но
ничего не сказали о способе его формирования. В этом случае система должна сама решить, какие
операции и в каком порядке нужно выполнить над отношениями СОТРУДНИКИ и ОТДЕЛЫ.
Обычно говорят, что алгебраическая формулировка является процедурной, т.е. задающей правила
выполнения запроса, а логическая - описательной (или декларативной), поскольку она всего лишь
описывает свойства желаемого результата. На самом деле эти два механизма эквивалентны и
существуют не очень сложные правила преобразования одного формализма в другой.
Реляционное исчисление является прикладной ветвью формального механизма исчисления
предикатов первого порядка. Базисными понятиями исчисления являются понятие переменной с
определенной для нее областью допустимых значений и понятие правильно построенной
формулы, опирающейся на переменные, предикаты и кванторы.
Предикатом называется логическая функция, принимающая значения ИСТИНА или ЛОЖЬ
в зависимости от значений входящих в нее переменных.
Различают исчисление кортежей и исчисление доменов. В исчислении кортежей областями
определения переменных являются отношения базы данных, т.е. допустимым значением каждой
переменной является кортеж некоторого отношения. В исчислении доменов областями
определения переменных являются домены, на которых определены атрибуты отношений базы
данных, т.е. допустимым значением каждой переменной является значение некоторого домена.
Рассмотрим более подробно исчисление кортежей, при этом будем использовать необходимые
синтаксические конструкции, близкие синтаксису языка БД QUEL, который долгое время являлся
основным языком СУБД Ingres.
Для определения кортежной переменной используется оператор RANGE. Например, для того,
чтобы определить переменную СОТРУДНИК, областью определения которой является отношение
СОТРУДНИКИ, нужно употребить конструкцию
RANGE СОТРУДНИК IS СОТРУДНИКИ
Из этого определения следует, что в любой момент времени переменная СОТРУДНИК
представляет некоторый кортеж отношения СОТРУДНИКИ. При использовании кортежных
переменных в формулах можно ссылаться на значение атрибута переменной (это аналогично тому,
как, например, при программировании на языке Си можно сослаться на значение поля
структурной переменной). Например, для того, чтобы сослаться на значение атрибута СОТР_ИМЯ
переменной СОТРУДНИК, нужно употребить конструкцию СОТРУДНИК.СОТР_ИМЯ.
Правильно построенные формулы (ППФ) служат для выражения условий, накладываемых на
кортежные переменные. Основой ППФ являются простые сравнения (comparison),
представляющие собой операции сравнения скалярных значений (значений атрибутов переменных
или литерально заданных констант). Например, конструкция "СОТРУДНИК.СОТР_НОМ = 140"
является простым сравнением. По определению, простое сравнение является ППФ, а ППФ,
заключенная в круглые скобки, является простым сравнением.
Более сложные варианты ППФ строятся с помощью логических связок NOT, AND, OR и IF ...
THEN. Так, если form - ППФ, а comp - простое сравнение, то NOT form, comp AND form, comp OR
form и IF comp THEN form являются ППФ.
Наконец, допускается построение ППФ с помощью кванторов. Если form – это ППФ, в
которой участвует переменная var, то конструкции EXISTS var (form) и FORALL var (form)
представляют ППФ. Все переменные, входящие в ППФ, при построении которой не
использовались кванторы, являются свободными. Если имя переменной использовано сразу после
квантора при построении ППФ вида EXISTS var (form) или FORALL var (form), то var –это
связанная переменная.
ППФ F: EXISTS СОТР2 (СОТР1. СОТР_ЗАРП> СОТР2. СОТР_ЗАРП) , где СОТР1 и СОТР2 –
41
кортежные переменные. ППФ для текущего значения кортежа СОТР1 принимает значение true в
том и только в том случае, если во всем отношении СОТРУДНИКИ найдется кортеж (связанный с
переменной СОТР2) такой, что значение его атрибута СОТР_ЗАРП удовлетворяет условию.
ППФ: FORALL СОТР2 (СОТР1. СОТР_ЗАРП> СОТР2. СОТР_ЗАРП)
ППФ для текущего значения кортежа СОТР1 принимает значение true в том и только в том
случае, если для всех кортежей отношения СОТРУДНИКИ (связанных с переменной СОТР2)
значение атрибута СОТР_ЗАРП удовлетворяют условию сравнения.
3.7 Вопросы и упражнения для самоконтроля к главе 3
1. Чем отличается домен от типа данных?
2. Что такое степень отношения?
3. В чем отличие схемы отношения от отношения?
4. Можно ли считать любую прямоугольную таблицу данных отношением?
5. В чем, по вашему мнению, основа популярности реляционной модели?
6. Приведите пример БД и укажите, какие ограничения целостности в ней должны
поддерживаться.
7. Какие из реляционных операций взяты из теории множеств?
8. В чем заключается замкнутость реляционной алгебры?
9. В чем заключается совместимость операндов по реляционному объединению (пересечению,
разности)?
10. Для чего нужны реляционные операции присваивания, переименования?
11. Назовите виды соединений?
12. Укажите последовательность действий при выполнении экви-соединения.
13. Какая реляционная операция в чистом виде почти не выполняется?
14. На каком математическом аппарате основано реляционное исчисление?
15. Укажите последовательность реляционных операций при выполнении запроса для БД примера
3.11 «Выбрать начальников отделов, заработная плата которых превышает 10000 рублей»
16. Задайте формулу реляционного исчисления для реализации запроса (БД примера 3.11 )
«Выбрать начальников отделов, заработная плата которых превышает 10000 рублей».
Глава 4 Элементы языка SQL
4.1 История языка SQL
Увеличение объема и структурной сложности хранимых данных, расширение круга
пользователей информационных систем привели к широкому распространению наиболее удобных
и сравнительно простых для понимания реляционных (табличных) СУБД. Для обеспечения
одновременного доступа к данным множества пользователей, нередко расположенных достаточно
далеко друг от друга и от места хранения баз данных, созданы сетевые мультипользовательские
версии СУБД. В них тем или иным путем решаются специфические проблемы параллельных
процессов, целостности (правильности) и безопасности данных, а также санкционирования
доступа. Совместная работа пользователей в сетях с помощью унифицированных средств общения
с БД возможна только при наличии стандартного языка манипулирования данными, обладающего
средствами для реализации перечисленных выше возможностей
Разрабатываемые в начале 80-х языки запросов можно отнести к двум классам:
1. Алгебраические языки, позволяющие выражать запросы средствами специализированных
операторов, применяемых к отношениям (JOIN - соединить, INTERSECT - пересечь,
SUBTRACT - вычесть и т.д.).
2. Языки исчисления предикатов представляют собой набор правил для записи выражения,
определяющего новое отношение из заданной совокупности существующих отношений.
Разработка, в основном, шла в отделениях фирмы IBM (языки ISBL, SQL, QBE) и
университетах США (PIQUE, QUEL). QUEL создавался для СУБД INGRES (Interactive Graphics
and Retrieval System), которая была разработана в начале 70-х годов в Университете шт.
Калифорния и сегодня входит в пятерку лучших профессиональных СУБД. Сегодня из всех этих
языков полностью сохранились и развиваются QBE (Query-By-Example - запрос по образцу) и
SQL, а из остальных взяты в расширение внутренних языков СУБД только наиболее интересные
42
конструкции. SQL был разработан в 1974 году фирмой IBM для экспериментальной реляционной
СУБД System R. После появления на рынке двух пионерских СУБД этой фирмы - SQL/DS (1981
год) и DB2 (1983 год) - он приобрел статус стандарта де-факто для профессиональных
реляционных СУБД. В 1989 году SQL стал международным стандартом языка баз данных, а в
1992 году вышла вторая версия этого стандарта.
В данной главе рассматриваются элементы языка SQL (Structured Query Language). Первый
международный стандарт SQL был принят в 1989 г. (SQL/89 или SQL1). Стандарт был принят
ANSI (Американский Национальный Институт Стандартов) и ISO (международная организация по
стандартизации). Следующая версия стандарта языка SQL принята в 1992 г. (Официальное
название стандарта - Международный стандарт языка баз данных SQL (1992) (International Standart
Database Language SQL), неофициальное название - SQL/92, или SQL-92, или SQL2). Документ,
описывающий стандарт, содержит более 600 страниц. Рассмотрим только некоторые основные
понятия языка. Далее был разработан SQL/99 или SQL3, принятый стандарт объектнореляционного расширения SQL. Подмножества этого стандарта уже реализованы в коммерческих
продуктах, включая Oracle V8 компании Oracle и DB2 корпорации IBM.
Язык SQL стал фактически стандартным языком доступа к базам данных. Все СУБД,
претендующие на название «реляционные», реализуют тот или иной диалект SQL: SQL*Plus
корпорации Oracle; Transact-SQL для СУБД Microsoft SQL Server и др. В диалектах язык может
быть дополнен операторами процедурных языков программирования. Многие системы, не
являющиеся реляционными, также имеют в настоящее время средства доступа к реляционным
данным. Целью стандартизации является переносимость приложений между различными СУБД.
Нужно заметить, что в настоящее время, ни одна система не реализует стандарт SQL в полном
объеме. Кроме того, во всех диалектах языка имеются возможности, не являющиеся
стандартными. Таким образом, можно сказать, что каждый диалект - это надмножество
некоторого подмножества стандарта SQL. Это затрудняет переносимость приложений,
разработанных для одних СУБД, в другие СУБД.
Язык SQL оперирует терминами, несколько отличающимися от терминов реляционной
теории, например, вместо «отношений» используются «таблицы» (см. таблицу 3.1) Стандарт
языка SQL, хотя и основан на реляционной теории, но во многих местах отходит он нее.
Например, отношение в реляционной модели данных не допускает наличия одинаковых кортежей,
а таблицы (результаты применения запросов) в терминологии SQL могут иметь одинаковые
строки. Имеются и другие отличия.
Язык SQL является реляционно-полным. Это означает, что любой оператор реляционной
алгебры может быть выражен подходящим оператором SQL.
Имеются две формы языка SQL: интерактивный и вложенный. В интерактивной форме SQL
любая введенная команда выполнится сразу же и можно увидеть результаты работы команды.
Вложенный SQL состоит из команд SQL, встроенных внутрь программ, написанных на некотором
другом языке (типа Visual Basic или С).
В этой главе будет представлен SQL в интерактивной
форме. Интерактивный SQL - это форма, наиболее полезная непрограммистам. Все что,
рассмотрим относительно интерактивного SQL, в основном, применимо и к вложенной форме.
В настоящее время наибольшее распространение получили реляционные СУБД трех групп:
I. Мощные крупные коммерческие СУБД, ориентированные на хранение огромных объемов
информации (от гигабайт). Наиболее известными СУБД в этой группе являются: Oracle (Oracle
Corp.), Ingres (Computer Associates International), Sybase SQL server (Sybase Inc.).
II. Мобильные компактные свободно распространяемые СУБД, использование которых оправдано
и для БД объемом всего лишь в десятки килобайт. К наиболее популярным СУБД этой группы
относятся: PostgreSQL (организации PostgreSQL), mySQL (T.C.X. DataKonsult AB), Microsoft
SQL Server (Microsoft).
III. Настольные персональные СУБД, ориентированные на простые варианты построения БД,
решение менее сложных задач, на персональные компьютеры и, на меньшие объемы и
сравнительно простую структуру данных. К настольным СУБД относятся: Access, входящая в
состав пакета Microsoft Office и рассчитанная на одного пользователя; Visual FoxPro.
СУБД первых двух групп построены по принципу «клиент-сервер».
43
4.2 Структура языка SQL
Основу языка SQL составляют операторы, условно разбитые на несколько групп по выполняемым
функциям. Можно выделить следующие группы операторов (перечислены не все операторы SQL):
DDL (Data Definition Language) - операторы определения объектов базы данных:
 CREATE SCHEMA - создать схему базы данных;
 DROP SHEMA - удалить схему базы данных;
 CREATE DATABASE - создать базы данных;
 DROP DATABASE - удалить базу данных;
 CREATE TABLE - создать таблицу;
 ALTER TABLE - изменить таблицу;
 DROP TABLE - удалить таблицу;
 CREATE DOMAIN - создать домен;
 ALTER DOMAIN - изменить домен;
 DROP DOMAIN - удалить домен;
 CREATE INDEX - создать индекс;
 DROP INDEX - удалить индекс;
 CREATE COLLATION - создать последовательность;
 DROP COLLATION - удалить последовательность;
 CREATE VIEW - создать представление;
 DROP VIEW - удалить представление.
DML (Data Manipulation Language) - операторы манипулирования данными:
 SELECT - отобрать строки из таблиц;
 INSERT - добавить строки в таблицу;
 UPDATE - изменить строки в таблице;
 DELETE - удалить строки в таблице;
DCL (Data Control Language) - операторы контроля данных, защиты и управления данными:
 CREATE ASSERTION - создать ограничение;
 DROP ASSERTION - удалить ограничение;
 COMMIT - зафиксировать внесенные изменения;
 ROLLBACK - откатить внесенные изменения.
 GRANT - предоставить привилегии пользователю или приложению на манипулирование
объектами;
 REVOKE - отменить привилегии пользователя или приложения.
Кроме того, есть группы операторов установки параметров сеанса, получения информации о базе
данных, операторы статического SQL, операторы динамического SQL.
Наиболее важными для пользователя являются операторы манипулирования данными (DML).
В языке SQL/89 поддерживаются следующие типы данных (таблица 4.1):
Таблица 4.1 – Типы данных SQL/89
Тип данных SQL/89
Определяемые данные
CHARACTER(n) или CHAR(n)
символьные строки с постоянной длиной n
NUMERIC[(n,m)], DECIMA[(n,m)] или точные числа, здесь n – общее число цифр в числе;
DEC[(n,m)]
m – количество цифр слева от десятичной точки
INTEGER или INT
целые числа
SMALLINT
целые числа меньшего диапазона
REAL
вещественные числа в форме с плавающей точкой
FLOAT[(n)]
вещественные числа большой точности в форме с
плавающей точкой, здесь n – общее число байт,
44
отводимое на хранение чисел
вещественные числа большой точности в форме с
DOUBLE PRECISION
плавающей точкой
В стандарте SQL/92 добавлены типы данных:
 VARCHAR(n) – строки символов переменной длины;
 BIT(n) – строки битов постоянной длины;
 DATE – календарная дата;
 INTERVAL – временной интервал и др.
Заметим еще, что в большинстве реализаций SQL поддерживаются некоторые дополнительные
типы данных, например, TIME, INTERVAL, MONEY. Некоторые из этих типов специфицированы
в стандарте SQL/92, но в текущих реализациях синтаксические и семантические свойства таких
типов могут различаться.
Конкретными реализациями SQL поддерживаются собственные наборы типов данных и
встроенных функций, позволяющих выполнять обработку данных числового и строкового типов.
Определены арифметические операции: + | - | * | /
В качестве удобного примера при дальнейшем рассмотрении реализации операторов SQL будем
использовать учебную БД условной торговой фирмы «ЗАКАЗЫ» (пример взят у М. Грабера [3]).
БД состоит из трех таблиц (таблицы 4.2-4.4). Для продавцов заданы: номер – SNUM; имя –
SNAME; город, в котором он живет, - CITY; комиссионные, которые он получает с каждого
оформленного заказа, - COMM. Для заказчиков заданы: номер – CNUM; имя – CNAME; город, в
котором он живет, - CITY; номер продавца, который обслуживает данного заказчика, - SNUM;
оценка заказчика – rating. Для заказов (здесь они названы порядками) заданы: номер – ONUM;
сумма заказа – AMT; дата оформления заказа – ODATE; номер заказчика, который оплатил
данный заказ, - CNUM; номер продавца, который обслуживает данный заказ, - SNUM. Приняты
следующие соглашения:
 один продавец может обслуживать несколько заказчиков;
 один заказчик работает только с одним продавцом данной фирмы.
Таблица 4.2 - Продавцы
SNUM
SNAME
CITY
COMM
1001
Пил
Лондон
0.12
1002
Серенс
Мехико
0.13
1004
Мотье
Лондон
0.11
1007
Рифкин
Барселона 0.15
1003
Аксельрод
Париж
Таблица 4.3 - Заказчики
CNUM
CNAME
0.10
CITY
RATING
SNUM
2001
Хофман
Лондон
100
1001
2002
Джованни
Рим
200
1003
2003
Луи
Мехико
200
1002
2004
Грасс
Берлин
300
1002
2006
Клеменс
Лондон
100
1001
2008
Киснерос
Мехико
300
1007
2007
Перера
Рим
100
1004
Таблица 4.4 - Порядки
45
ONUM
AMT
ODATE
CNUM
SNUM
3001
18.67
10/03/2003
2008
1007
3003
767.19
10/03/2003
2001
1001
3002
1900.10
10/03/2003
2007
1004
3005
5160.45
10/03/2003
2003
1002
3006
1098.16
10/03/2003
2008
1007
3009
1713.23
10/04/2003
2002
1003
3007
75.76
10/04/2003
2004
1002
3008
4723.00
10/05/2003
2006
1001
3009
1309.95
10/06/2003
2004
1002
3011
9891.88
10/06/2003
2006
1001
4.3 Создание запроса с помощью оператора SELECT
4.3.1 Создание простых запросов
Оператор SELECT является фактически самым важным для пользователя и самым сложным
оператором SQL. Он предназначен для выборки данных из таблиц, т.е. он, собственно, и реализует
одно их основных назначений БД - предоставлять информацию пользователю.
Оператор SELECT всегда выполняется над некоторыми таблицами, входящими в базу данных.
Результатом выполнения оператора SELECT всегда является таблица. Таким образом, по
результатам действий оператор SELECT похож на операции реляционной алгебры. Любая
операция реляционной алгебры может быть выражена подходящим образом сформулированным
оператором SELECT. Сложность оператора SELECT определяется тем, что он содержит в себе все
возможности реляционной алгебры, а также дополнительные возможности, которых в
реляционной алгебре нет.
Замечание. Каждый оператор интерактивного SQL представляет собой одну команду, которая
заканчивается «;». В наших примерах служебные слова SQL будем приводить прописными
буквами.
Рассмотрим сначала простые конструкции оператора SELECT, постепенно усложняя его запись:
SELECT <список выбора> FROM <имя таблицы>;
Пример 4.1 Выбрать все данные из таблицы Продавцы:
SELECT snum, sname, city, comm FROM Продавцы;
Результатом работы этой команды будет вывод всей таблицы 4.2 .
Пример 4.2 Выбрать все данные из таблицы:
SELECT *
FROM Продавцы;
Здесь «звездочка» (*) служит кратким обозначением всех имен полей в таблице, указанной во
фразе FROM. При этом порядок вывода полей соответствует порядку, в котором эти поля
определялись при создании.
Пример 4.3
Выбрать некоторые колонки из исходной таблицы (указание списка отбираемых
колонок): SELECT sname, comm FROM Продавцы;
Эта команда выведет только два указанных столбца из таблицы.
Пример 4.4
Выбрать некоторые колонки из исходной таблицы (указание списка отбираемых
колонок): SELECT odate, snum, onum, amt
FROM Порядки;
Столбцы по этой команде будут выведены в заданном порядке.
Пример 4.5 Вывести список номеров продавцов из таблицы Порядки:
SELECT snum FROM Порядки ;
Результатом выполнения этой команды является список номеров из таблицы 4.4, в котором есть
повторяющиеся записи. Для исключения дубликатов необходимо дополнить запрос ключевым
46
словом DISTINCT (различный, различные), как показано в следующем примере.
Пример 4.6
Вывести список номеров продавцов из таблицы Порядки без повторений:
SELECT DISTINCT snum FROM Порядки;
В предыдущих примерах в операторах SELECT была реализована операция проекция. Для
реализации операции выборка необходимо в конструкцию оператора добавить предложение
WHERE: SELECT <список выбора> FROM <имя таблицы> WHERE <предикат>;
В синтаксисе предложения WHERE для отбора нужных строк таблицы можно использовать:
 операторы сравнения: = (равно), <> (не равно), < (меньше), <= (меньше или равно), >
(больше), > = (больше или равно);
 логические операции: OR, NOT, AND;
 операторы: IN, BETWEEN …. AND, LIKE, IS NULL.
Пример 4.7 Вывести имена и комиссионные всех продавцов в Лондоне:
SELECT sname, city FROM Продавцы WHERE city = ‘Лондон’;
Пример 4.8 Вывести все данные о заказчиках в Мехико, которые имеют оценку (рейтинг) выше
200: SELECT *
FROM Заказчики
WHERE city = ‘Мехико' AND rating > 200;
Будет выведена одна строка:
CNUM
CNAME
CITY
RATING
SNUM
2008
Киснерос
Мехико
300
1007
Сложные логические выражения в предикате формируются с помощью скобок.
Пример 4.9
SELECT *
FROM Порядки WHERE NOT ((odate = 10/03/2003 AND snum
>1002) OR amt > 2000.00);
В результате выполнения этого запроса будут выведены строки:
ONUM
AMT
DATE
SNUM
CNUM
3003
767.19
10/03/2003 2001
1001
3009
1713.23
10/04/2003 2002
1003
3007
75.76
10/04/2003 2004
1002
3009
1309.95
10/06/2003 2004
1002
Сложные логические выражения можно преобразовать, используя аксиомы, называемые
законами де Моргана: NOT (a AND b) ≡ NOT a OR NOT b
NOT (a OR b ≡ NOT a AND NOT b ,
где a и b – логические выражения, а символ «≡» означает «эквивалентно».
Оператор IN определяет, включено ли значение левого операнда в набор значений (список)
правого операнда. Значение предиката, образованного с помощью оператора IN, равно true в том и
только в том случае, когда значение левого операнда совпадает хотя бы с одним значением списка
правого операнда.
Пример 4.10 Найти всех продавцов, которые живут в Барселоне или в Лондоне:
SELECT
*
FROM Продавцы
WHERE city = 'Барселона' OR city = 'Лондон';
Имеется и более простой способ получить ту же информацию:
SELECT * FROM Продавцы WHERE city IN ( 'Барселона', 'Лондон' );
С помощью оператора BETWEEN ... AND ... (находится в интервале от ... до ...) можно
отобрать строки, в которых значение какого-либо столбца находятся в заданном диапазоне.
Результат «x BETWEEN y AND z» тот же самый, что результат «x >= y AND x <= z». Результат «x
NOT BETWEEN y AND z» тот же самый, что результат «NOT (x BETWEEN y AND z)».
Пример 4.11 Этот запрос выбирает всех заказчиков, чьи имена попали в определенный
алфавитный диапазон:
SELECT
*
FROM Заказчики WHERE cname BETWEEN 'Г' AND 'Л';
Вывод для этого запроса:
CNUM
CNAME
CITY
RATING
SNUM
2002
Джованни
Рим
200
1003
2004
Грасс
Берлин
300
1002
2006
Клеменс
Лондон
100
1001
2008
Киснерос
Мехико
300
1007
Обратите внимание, что Луи отсутствует. Это происходит из-за того, что BETWEEN сравнивает
47
строки неравной длины. Строка 'Л' более короткая, чем строка ‘Луи’, поэтому и не
выбирается. Важно помнить это когда используете оператор BETWEEN для выбора значений из
алфавитных диапазонов.
Обычная форма оператора LIKE «имя_столбца» LIKE «текстовая_константа» для столбца
текстового типа позволяет отыскать все значения указанного столбца, соответствующие образцу,
заданному «текстовой_константой». Символы этой константы интерпретируются следующим
образом:
 символ _ (подчеркивание) – заменяет любой одиночный символ (для СУБД ACCESS –«?»);
 символ % (процент) – заменяет любую последовательность из N символов (где N может
быть нулем) (для СУБД ACCESS –«*»);
 все другие символы означают просто сами себя.
Для оператора LIKE типы данных столбца левого операнда и образца должны быть типами
символьных строк.
Пример 4.12
Найти всех заказчиков, чьи имена начинаются с буквы ‘К’:
SELECT * FROM Заказчики WHERE cname LIKE 'К%';
Наличие неопределенных (NULL) значений повышает гибкость обработки информации,
хранящейся в БД (см. п.3.4). В нашем примере можно предположить ситуацию, что появился
новый заказчик, которому еще не был назначен продавец. Вы можете ввести строку для заказчика
со значением NULL в поле snum и заполнить это поле значением позже, когда продавец будет
назначен. Значение « IS NULL» равно true тогда и только тогда, когда значение x не определено.
Значение предиката «x NOT IS NULL» равно значению «NOT x IS NULL».
Пример 4.13 Найти все записи в таблице Заказчики с NULL значениями в snum столбце:
SELECT * FROM Заказчики WHERE snum IS NULL;
Здесь не будет никакого вывода, потому что нет значений NULL в наших типовых таблицах.
4.3.2. Агрегирование данных в запросах
В SQL существует ряд специальных стандартных функций (SQL-функций). Кроме
специального случая COUNT(*) каждая из этих функций оперирует совокупностью значений
столбца некоторой таблицы и создает единственное значение, определяемое так:
COUNT - число значений в столбце;
SUM - сумма значений в столбце;
AVG - среднее значение в столбце;
MAX - самое большое значение в столбце;
MIN - самое малое значение в столбце.
Для функций SUM и AVG рассматриваемый столбец должен содержать числовые значения.
Замечание. Следует отметить, что здесь «столбец» - это столбец виртуальной таблицы (например,
представления), в которой могут содержаться данные не только из столбца базовой таблицы, но и
данные, полученные путем функционального преобразования и (или) связывания символами
арифметических операций значений из одного или нескольких столбцов. При этом выражение,
определяющее столбец такой таблицы, может быть сколь угодно сложным, но не должно
содержать SQL-функций (вложенность SQL-функций не допускается). Однако из SQL-функций
можно составлять любые выражения.
Аргументу всех функций, кроме COUNT(*), может предшествовать ключевое слово
DISTINCT (различный), указывающее, что избыточные дублирующие значения должны быть
исключены перед тем, как будет применяться функция. Специальная же функция COUNT(*)
служит для подсчета всех без исключения строк в таблице (включая дубликаты).
Пример 4.14 Чтобы найти сумму всех покупок, необходимо ввести следующий запрос:
SELECT SUM (amt) FROM Порядки;
В результате будет выведено значение 26658.4 без подписи поля.
Пример 4.15
Подсчитать число строк в таблице Заказчики:
SELECT COUNT (*)
FROM Заказчики;
В результате будет выведено значение 7.
Фраза GROUP BY (группировать по …) инициирует перекомпоновку указанной в предложении
FROM таблицы по группам, каждая из которых имеет одинаковые значения в столбце, заданном в
48
GROUP BY, затем к каждой группе применяется заданная функция и оператор SELECT выводит
значения для каждой группы.
Пример 4.16 Найти наибольшую сумму приобретений, полученную каждым продавцом:
SELECT snum, MAX (amt) FROM Порядки GROUP BY snum;
Вывод для этого запроса:
snum
------ -------1001
767.19
1002 1713.23
1003
75.75
1004 1309.95
1007 1098.16
Замечание. В список отбираемых полей оператора SELECT, содержащего раздел GROUP BY,
можно включать только агрегатные функции и поля, которые входят в условие группировки.
Поэтому команда SELECT onum, snum, MAX (amt) FROM Порядки GROUP BY snum; не будет
выполнена и появится сообщение о синтаксической ошибке. Причина ошибки в том, что в список
отбираемых полей включено поле onum, которое не входит в раздел GROUP BY.
Можно также использовать GROUP BY с несколькими полями, задавая уровни группировки.
Пример 4.17 Вывести наибольшую сумму приобретений, получаемую каждым продавцом каждый день:
SELECT snum, odate, MAX (amt) FROM Порядки GROUP BY snum, odate;
Вывод для этого запроса:
snum
odate
------ ----------------1001
10/03/2003
767.19
1001
10/05/2003
4723.00
1001
10/06/2003 9891.88
1002
10/03/2003
5160.45
1002
10/04/2003
75.75
1002
10/06/2003
1309.95
1003
10/04/2003
1713.23
1004
10/03/2003
1900.10
1007 10/03/2003 1098.16
Фраза HAVING играет такую же роль для групп, что и фраза WHERE для строк: она используется
для исключения групп, точно так же, как WHERE используется для исключения строк. Эта фраза
включается в предложение лишь при наличии предложения GROUP BY, а выражение в
предложении HAVING должно принимать единственное значение для группы, т.е. использоваться
агрегатная функция.
Пример 4.18
Предположим, что в предыдущем примере, необходимо увидеть только
максимальные суммы приобретений, значение которых выше $3000.00:
SELECT snum, odate, MAX (amt) FROM Порядки GROUP BY snum, odate
HAVING MAX (amt) > 3000.00;
Замечание. В одном запросе могут встретиться как условия отбора строк в разделе WHERE, так и
условия отбора групп в разделе HAVING. Условия отбора групп нельзя перенести из раздела
HAVING в раздел WHERE. Аналогично и условия отбора строк нельзя перенести из раздела
WHERE в раздел HAVING, за исключением условий, включающих поля из списка группировки
GROUP BY. Добавим в запрос предыдущего примера раздел WHERE:
SELECT snum, MAX (amt) FROM Порядки WHERE snum IN (1002,1007) GROUP BY snum
HAVING MAX (amt) > 3000.00;
Эта команда будет выполняться в следующей последовательности:
1. отбираются строки, удовлетворяющие предикату в предложении WHERE;
2. выявляются группы, заданные предложением GROUP BY;
3. внутри каждой группы вычисляется значение функции (MAX (amt) );
4. исключаются из вывода группы, не удовлетворяющие условию, указанному в
49
предложении HAVING.
В список вывода оператора SELECT можно добавить любые строковые константы и
вычисляемые выражения.
Пример 4.19
Представить комиссионные продавцов в процентном отношении (а не в виде
десятичных чисел):
SELECT snum, sname, city, comm * 100, ' % ' FROM Продавцы;
Таблицы - это неупорядоченные наборы данных, и выводимые данные по запросу не
обязательно появляются в какой-то определенной последовательности.
SQL использует
предложение ORDER BY,
чтобы упорядочивать вывод.
Многочисленные столбцы
упорядочиваются один внутри другого, также как с GROUP BY, и можно определять сортировку
по возрастанию (ASC) или убыванию (DESC ) для каждого столбца. По умолчанию установлена
сортировка по возрастанию.
Пример 4.20 Вывести таблицу Порядки, отсортированную по номеру заказчика в порядке
убывания:
SELECT * FROM Порядки ORDER BY cnum DESC;
Предложение ORDER BY может использоваться совместно с GROUP BY для упорядочивания
групп. Структура запроса в этом случае имеет вид:
SELECT <список выбора> FROM <имя таблицы> [WHERE <предикат>] [GROUP BY
<выражение>] [HAVING <предикат>] [ORDER BY <поля>] ;
Пример 4.21
SELECT snum, odate, MAX (amt) FROM Порядки GROUP BY snum, odate ORDER BY snum ;
4.3.3 Формирование запросов на основе соединения таблиц
Очевидно, что с помощью соединения несложно сформировать запрос на обработку данных
из нескольких таблиц. Кроме того, в такой запрос можно включить любые части предложения
SELECT, рассмотренные ранее (выражения с использованием функций, группирование с отбором
указанных групп и упорядочением полученного результата). Следовательно, соединения
позволяют обрабатывать множество взаимосвязанных таблиц как единую таблицу, в которой
собрана информация о нескольких сущностей. Различные виды реляционной операции соединения
были рассмотрены в п.3.5. В этом пункте остановимся на следующих видах соединений:
1. эквисоединение (по равенству полей)
2. соединение через справочную целостность;
3. соединение таблицы с собой (рекурсия);
4. внешнее соединение.
Полное имя столбца таблицы фактически состоит из имени таблицы, сопровождаемого
точкой и затем имени столбца, например: Продавцы.snum , Продавцы.city, Порядки.odate
Ранее мы могли опускать имена таблиц при указании столбцов, потому что запрашивали только
одну таблицу одновременно, а SQL достаточно интеллектуален, чтобы присвоить
соответствующий префикс имени таблицы. Даже, если запрос включает несколько таблиц, еще
можно опускать имена таблиц, если все столбцы имеют различные имена. Но это не всегда так
бывает. Например, если в одном запросе использованы два столбца city, то нужно указать их с
именами Продавцы.city или Заказчики.city, чтобы SQL мог их различать.
Пример 4.22 Предположим, что необходимо поставить в соответствии каждому продавцу его
заказчиков в том городе, в котором они живут:
SELECT Заказчики.cname, Продавцы.sname, Продавцы.city FROM Продавцы, Заказчики
WHERE Продавцы.city = Заказчики.city;
Результат запроса:
cname
cname
city
Хофман
Пил
Лондон
Клеменс Пил
Лондон
Луи
Серенс
Мехико
Киснерос Серенс
Мехико
Хофман
Мотика
Лондон
Клеменс Мотика
Лондон
Алгоритм выполнения запроса в примере 4.22:
50
1. вычисляется декартово произведение, получаем 35 строк (5х7);
2. производится выборка из полученной таблицы только тех строк, для которых выполняется
условие Продавцы.city = Заказчики.city;
3. из полученной на шаге 2 таблицы выбираются только 3 указанных столбца (проекция).
В этом запросе использовалось эквисоединение.
Пример 4.23 Показать для каждого продавца имена всех заказчиков, которых он обслуживают:
SELECT Заказчики.cname, Продавцы.sname FROM Продавцы, Заказчики
WHERE Продавцы.snum = Заказчики.snum;
В этом примере использовано соединение таблиц через справочную целостность, поскольку поле
snum в таблице Продавцы является первичным ключом, а в таблице Заказчики – внешним ключом.
Можно создавать запросы, использующие соединение более чем двух таблиц.
Пример 4.24 Предположим, что нужно найти все порядки заказчиков, не находящихся в тех
городах, где живут их продавцы. Для этого необходимо связать все три таблицы:
SELECT onum, cname, Порядки.cnum, Порядки.snum FROM Продавцы, Заказчики, Порядки
WHERE Заказчики.city < > Продавцы.city AND Порядки.cnum = Заказчики.cnum
AND Порядки.snum = Продавцы.snum;
Результат вывода:
onum cname
cnum snum
------ ------- ----- ----3001 Киснерос 2008 1007
3002 Перера
2007 1004
3006 Джованни 2002 1003
3007 Грасс
2004 1002
3010 Грасс
2004 1002
В запросе таблица может соединяться сама с собой. В этом случае для экземпляров таблицы
задаются псевдонимы, которые определяются в предложении FROM после имени таблицы.
Пример 4.25 Найти все пары заказчиков с одинаковым рейтингом:
SELECT a.cname, b.cname, a.rating FROM Заказчики a, Заказчики b WHERE a.rating = b.rating;
Результат запроса:
cname
cname
rating
Хофман
Хофман
100
Хофман
Клеменс
100
Хофман
Перера
100
Джованни Джованни 200
Джованни Луи
200
Луи
Джованни 200
Луи
Луи
200
Грасс
Грасс
300
Грасс
Киснерос
300
Клеменс
Хофман
100
Клеменс Клеменс
100
Клеменс Перера
100
Киснерос Грасс
300
Киснерос Киснерос
300
Перера
Хофман
100
Перера
Клеменс
100
Перера
Перера
100
Обратите внимание на избыточность в выводе: каждая комбинация заказчиков выведена дважды;
выводится комбинация строки сама с собой. Для устранения избыточности необходимо добавить
еще одно условие в предикат, чтобы сделать предикат ассиметричным, и те же самые значения в
обратном порядке не будут выбираться снова, например:
Пример 4.26 SELECT a.cname, b.cname, a.rating FROM Заказчики a, Заказчики b WHERE a.rating
= b.rating AND a.cname < b.cname;
51
Вывод в этом случае будет содержать только 5 строк.
В Access для соединения таблиц используется фраза JOIN. К их числу относится операция
внутреннего соединения (INNER JOIN) и операции внешнего соединения (LEFT JOIN и RIGHT
JOIN). Эти операции могут использоваться в любом предложении FROM. Операция INNER JOIN
объединяет записи из двух таблиц, если связывающие поля содержат одинаковые значения. LEFT
JOIN выбирает все записи из левой таблицы, даже. Если в правой таблице нет совпадающих
значений. Это относится и к операции RIGHT JOIN, только все записи выбираются из правой
таблицы
Синтаксис предложения FROM:
FROM таблица_1 [INNER | LEFT| RIGHT | JOIN таблица_2 ON таблица_1.поле_1 оператор
таблица_2.поле_2],
где таблица_1, таблица_2 – имена таблиц, которые подлежат соединению;
поле_1, поле_2 – имена полей, используемые для связи;
оператор – чаще всего «=».
4.3.4 Формирование структур вложенных запросов
Следует отметить, что SQL обладает большой избыточностью в том смысле, что он часто
предоставляет несколько различных способов формулировки одного и того же запроса.
Очень удобным средством, позволяющим формулировать запросы более понятным образом,
является возможность использования подзапросов, вложенных в основной запрос.
Подзапрос - это запрос, который может входить в предикаты условия выборки предложений
WHERE и HAVING оператора SELECT или других операторов SQL, использующих WHERE
предложение. Вложенный подзапрос может содержать в своей WHERE (HAVING) фразе другой
вложенный подзапрос и т.д. Нетрудно догадаться, что вложенный подзапрос создан для того,
чтобы при отборе строк таблицы, сформированной основным запросом, можно было использовать
данные из других таблиц. В SQL/89 к подзапросам применяется то ограничение, что
результирующая таблица должна содержать в точности один столбец. Поэтому в
синтаксических правилах, определяющих подзапрос, вместо списка выборки указано
арифметическое выражение. Заметим еще, что поскольку подзапрос всегда вложен в некоторый
другой оператор SQL, то в качестве констант в арифметическом выражении выборки и логических
выражениях разделов WHERE и HAVING можно использовать значения столбцов текущих строк
таблиц, участвующих в запросах (подзапросах) более внешнего уровня.
Существуют простые и коррелированные (соотнесенные) вложенные подзапросы. Они
включаются в WHERE (HAVING) фразу с помощью операторов IN, EXISTS, ALL, ANY или
одного из условий сравнения ( = | <> | < | <= | > | > = ). Простые вложенные подзапросы
обрабатываются системой «снизу вверх». Первым обрабатывается вложенный подзапрос самого
нижнего уровня. Множество значений, полученное в результате его выполнения, используется при
реализации подзапроса более высокого уровня и т.д.
4.3.4.1 Простые подзапросы
Рассмотрим простые подзапросы.
Пример 4.27 Предположим, что известно имя продавца (Мотика), но неизвестно значение его
поля snum, и необходимо извлечь все его порядки из таблицы Порядки:
SELECT *
FROM Порядки WHERE snum =
( SELECT snum FROM Продавцы WHERE sname = 'Мотика');
Замечание. Результат выполнения запроса будет эквивалентен результату следующей
последовательности действий:
1. выполнить один раз вложенный подзапрос и получить значение номера продавца
(единственной найденной строкой естественно будет snum = 1004);
2. просканировать таблицу Порядки, каждый раз сравнивая значение номера продавца с
результатом подзапроса (WHERE snum = 1004), и отобрать только те строки, в которых
предикат принимает значение true.
Замечание. При использовании подзапросов необходимо убедиться, что подзапрос будет
выдавать одну и только одну строку вывода. Если подзапрос не выводит никаких значений, то
команда не потерпит неудачи, но основной запрос не выведет никаких значений. В этом случае
52
результат подзапроса следует рассматривать как неопределенный (неизвестный).
Можно в некоторых случаях использовать DISTINCT, чтобы обеспечить генерацию подзапросом
одиночного значения.
Пример 4.28
Предположим, что мы хотим найти все порядки для тех продавцов которые
обслуживают заказчика с номером 2001:
SELECT * FROM Порядки WHERE snum =
( SELECT DISTINCT snum FROM Заказчики WHERE cnum = 2001 );
Замечание. Обратите внимание, что предикаты, включающие подзапросы, используют структуру
< выражение > < оператор > < подзапрос >, а не < подзапрос > < оператор > < выражение > .
Любой подзапрос, использующий агрегатную функцию без предложения GROUP BY, будет
возвращать одиночное значение для использования в основном предикате.
Пример 4.29 Вывести все порядки, имеющие сумму приобретений выше средней на 4-е октября:
SELECT * FROM Порядки WHERE amt >
( SELECT AVG (amt) FROM Порядки WHERE odate = 10/04/2003 );
Средняя сумма приобретений на 4 октября – 894,38. Все строки со значением в поле amt выше
894,38 являются выбранными.
Замечание. Агрегатные функции, примененные к группе (при использовании предложения
GROUP BY), могут возвращать несколько значений, следовательно, не допускаются в
подзапросах такого характера.
Можно использовать оператор IN с подзапросами, которые возвращают любое число строк.
Пример 4.30 Вывести все атрибуты таблицы Порядки для продавцов из Лондона:
SELECT * FROM Порядки WHERE snum IN
( SELECT snum FROM Продавцы WHERE city =’Лондон’);
Можно также использовать подзапросы внутри предложения HAVING.
Пример 4.31 Подсчитать число заказчиков с оценками выше, чем средняя оценка в Мехико:
SELECT rating, COUNT ( DISTINCT cnum ) FROM Заказчики GROUP BY rating HAVING rating
> ( SELECT AVG (rating) FROM Заказчики WHERE city =’Мехико’);
4.3.4.2 Соотнесенные (коррелированные) подзапросы
Запросы с коррелированными вложенными подзапросами обрабатываются системой в
обратном порядке. Сначала выбирается первая строка рабочей таблицы, сформированной
основным запросом, и из нее выбираются значения тех столбцов, которые используются во
вложенном подзапросе (вложенных подзапросах). Если эти значения удовлетворяют условиям
вложенного подзапроса, то выбранная строка включается в результат. Затем выбирается вторая
строка и т.д., пока в результат не будут включены все строки, удовлетворяющие вложенному
подзапросу (последовательности вложенных подзапросов).
Пример 4.32 Найти всех заказчиков в порядках на 3-е октября:
SELECT *
FROM Заказчики outer WHERE 10/03/2003 IN
( SELECT odate FROM Порядки inner WHERE outer.cnum = inner.cnum );
Рассмотрим работу соотнесенного подзапроса:
1. Выбирается первая строка из внешнего запроса (строка- кандидат).
2. Сохраняются значения из строки кандидата под псевдонимом.
3. Выполняется вложенный запрос. Там, где есть ссылка на внешний запрос, используется
поле из строки кандидата.
4. Оценивается предикат внешнего запроса на основе результатов подзапроса, выполненного
на шаге 3. Если предикат принимает значение «истина», то выводится строка кандидат.
5. Выполняются шаги 1-4 для следующей строки внешнего запроса и т. д.
Пример 4.33 Вывести имена и номера всех продавцов, у которых более одного заказчика:
SELECT snum, sname FROM Продавцы main WHERE 1 <
(SELECT COUNT (*) FROM Заказчики WHERE snum = main.snum );
Предложение HAVING также может включать и коррелированные подзапросы.
Пример 4.34 Предположим, что необходимо вывести суммарные значения сумм приобретений из
таблицы Порядки, сгруппированные по датам, удалив из вывода все строки, где бы сумма не
была по крайней мере на 2000.00 выше максимальной (MAX) суммы:
53
SELECT odate, SUM (amt) FROM Порядки a GROUP BY odate HAVING SUM (amt) >
( SELECT 2000.00 + MAX (amt) FROM Порядки b WHERE a.odate = b.odate );
4.3.4.3 Запросы с использованием кванторов
Кванторы EXISTS (существования), ALL (всеобщности) - понятия, заимствованные из
формальной логики. В языке SQL предикат с квантором существования представляется
выражением EXISTS (SELECT * FROM ...). Такое выражение считается истинным только тогда,
когда результат вычисления «SELECT * FROM ...» является непустым множеством, т.е. когда
существует какая-либо запись в таблице, указанной во фразе FROM подзапроса, которая
удовлетворяет условию WHERE подзапроса. (Практически этот подзапрос всегда будет
коррелированным множеством.). Фактически любой запрос, который выражается через IN, может
быть альтернативным образом сформулирован также с помощью EXISTS. Предикат с квантором
всеобщности представляется выражением ALL (SELECT * FROM ...). Такое выражение считается
истинным только тогда, когда предикат сравнения внешнего запроса будет истинным при
сравнении со всеми строками подзапроса.
Пример 4.35 Вывести некоторые данные из таблицы Заказчики если, и только если, один или
более заказчиков в этой таблице находятся в Мехико:
SELECT cnum, cname, city FROM Заказчики WHERE EXISTS
( SELECT * FROM Заказчики WHERE city =’Мехико’);
Данный подзапрос является простым и будет выполнен один раз, а затем будут выведены
три столбца таблицы. В соотнесенном подзапросе предложение EXISTS оценивается отдельно
для каждой строки таблицы, имя которой указано во внешнем запросе, точно также как и другие
операторы предиката, когда вы используете соотнесенный подзапрос.
Пример 4.36 Вывести номера продавцов, которые имеют нескольких заказчиков:
SELECT DISTINCT snum FROM Заказчики outer WHERE EXISTS
( SELECT * FROM Заказчики inner WHERE inner.snum = outer.snum
AND inner.cnum < > outer.cnum );
Пример 4.37
Один из способов, которым можно найти всех продавцов только с одним
заказчиком, будет состоять в том, чтобы инвертировать наш предыдущий пример:
SELECT DISTINCT snum FROM Заказчики outer WHERE NOT
EXISTS
( SELECT * FROM Заказчики inner WHERE inner.snum = outer.snum
AND inner.cnum < > outer.cnum );
Кроме предиката EXISTS в подзапросах могут использоваться предикаты ANY (SOME), ALL.
Пример 4.38 Имеется новый способ нахождения продавцов, у которых заказчики размещены в
тех же городах:
SELECT *
FROM Продавцы WHERE city = ANY
(SELECT city FROM Заказчики );
Оператор ANY берет все значения, выведенные подзапросом (для этого случая - это все значения
city в таблице Заказчики), и оценивает их как верные, если любое (ANY) из их равняется
значению города текущей строки внешнего запроса.
Можно также использовать оператор IN, чтобы создать запрос аналогичный предыдущему:
SELECT *
FROM Продавцы WHERE city IN (SELECT city FROM Заказчики );
С помощью ALL, предикат принимает значение «истина», если каждое значение выбранное
подзапросом удовлетворяет условию в предикате внешнего запроса.
Пример 4.39 Вывести только тех заказчиков, чьи оценки, выше чем у каждого заказчика в
Риме: SELECT * FROM Заказчики WHERE rating > ALL
(SELECT rating FROM Заказчики WHERE city = Rome );
Приведем основные правила записи подзапросов:
1. подзапрос должен быть заключен в круглые скобки;
2. подзапрос должен находиться справа от оператора сравнения в предикате;
3. в подзапросе нельзя использовать GROUP BY.
4.3.5 Объединение нескольких запросов в один
Напоминаем, что реляционная операция объединение позволяет получить отношение,
состоящее из всех строк, входящих в одно или оба объединяемых отношений. Но при этом
54
исходные отношения или их объединяемые проекции должны быть совместимыми по
объединению. Для SQL это означает, что две таблицы можно объединять тогда и только тогда,
когда:
a. они имеют одинаковое число столбцов, например, m;
b. для всех i (i = 1, 2, ..., m) i-й столбец первой таблицы и i-й столбец второй таблицы имеют в
точности одинаковый тип данных.
Пример 4.40
Получить всех продавцов и заказчиков, размещенных в Лондоне и вывести их как
единое целое:
SELECT snum, sname FROM Продавцы WHERE city = 'Лондон'
UNION
SELECT cnum, cname FROM Заказчики WHERE city = 'Лондон';
Замечание. Заголовки столбца при выводе исключены, потому что ни один из столбцов,
выведенных объединением, не был извлечен непосредственно из только одной таблицы.
Кроме того, обратите внимание, что только последний запрос заканчивается точкой с запятой.
Отсутствие точки с запятой дает понять SQL, что имеется еще один или более запросов.
UNION будет автоматически исключать дубликаты строк из вывода. Это нечто несвойственное
для SQL, так как одиночные запросы обычно содержат DISTINCT чтобы устранять дубликаты.
Например, вывод следующего запроса не будет содержать дубликатов:
SELECT snum, city FROM Заказчики
UNION
SELECT snum, city FROM Продавцы;
Пример 4.41 Предположим, что вы должны сделать отчет о том, какие продавцы оформляют
наибольшие и наименьшие порядки по датам. Можно объединить два запроса, вставив туда текст,
чтобы различать вывод для каждого из них:
SELECT a.snum, sname, onum, ‘наибольший на’, odate FROM Продавцы a, Порядкиs b
WHERE a.snum = b.snum AND b.amt = ( SELECT MAX (amt) FROM Порядки c
WHERE c.odate = b.odate )
UNION
SELECT a.snum, sname, onum, ‘наименьший на’, odate FROM Продавцы a, Порядкиs b
WHERE a.snum = b.snum AND b.amt = ( SELECT MIN (amt) FROM Порядки c
WHERE c.odate = b.odate);
4.3.6 Синтаксис оператора SELECT
Приведем общий синтаксис оператора SELECT:
SELECT * | { [ DISTINCT | ALL] <список выбора >,….}
FROM { < имя_таблицы> [ < псевдоним > ] }.,..
[ WHERE <предикат>]
[ GROUP BY <имя_столбца>.,..]
[ HAVING <предикат>]
[ ORDER BY <имя_столбца>.,. | <номер_столбца>.,..]
[ { UNION [ALL]
SELECT * | { [DISTINCT | ALL] < < выражение >.,..}
FROM .] } ] ...;
Элементы, используемые в команде SELECT:
< список выбора > - выражения, включающее имена столбцов, функции, знаки операций
<предикат>::=< выражение1 > < оператор> < выражение2> | [NOT] EXISTS< выражение2 >
< оператор> ::= > | < | >= | <= | <> | = | IN | LIKE | BETWEEN …AND | OR | AND | NOT
< выражение2 >::= < выражение1> | [ANY | SOME | ALL ] <подзапрос>
<подзапрос>::= (SELECT * | { [ DISTINCT | ALL] < выражение >,….}
FROM { < имя_таблицы> [ < псевдоним > ] }.,..
[ WHERE <предикат>] …)
55
4.4 Операторы манипулирования данных
Модификация данных может выполняться с помощью операторов DELETE (удалить),
INSERT (вставить) и UPDATE (обновить). Подобно оператору SELECT они могут оперировать
как базовыми таблицами, так и представлениями. Однако по ряду причин не все представления
являются обновляемыми.
4.4.1 Оператор удаления данных DELETE
Оператор DELETE имеет формат:
DELETE FROM <базовая таблица | представление> [WHERE <предикат>];
и позволяет удалить содержимое всех строк указанной таблицы (при отсутствии WHERE фразы)
или тех ее строк, которые выделяются WHERE фразой.
Пример 4.42 Удалить все содержимое таблицы Продавцы:
DELETE FROM Продавцы;
Теперь, когда таблица пуста, ее можно окончательно удалить командой DROP TABLE. Обычно,
нужно удалить только некоторые определенные строки из таблицы. Чтобы определить, какие
строки будут удалены, используется предикат, так же как и для запросов.
Пример 4.43 Удалить продавца Аксельрода из таблицы Продавцы:
DELETE FROM Продавцы WHERE snum = 1003;
Замечание.
Рекомендуется сначала выполнить оператор SELECT, имеющий такое же
предложение WHERE, чтобы убедиться те ли строки будем удалять.
Пример 4.44
Если закрыто ведомство в Лондоне, то чтобы удалить всех заказчиков
назначенных, к продавцам в Лондоне, используем следующий оператор:
DELETE FROM Заказчики WHERE snum = ANY
( SELECT snum FROM Продавцы WHERE city = 'Лондон' );
Эта команда удалит из таблицы Заказчики строки с заказчиками Хофман и Клеменс
(назначенных для Пила), и Перера (назначенного к Мотика).
4.4.2 Оператор вставки данных INSERT
Оператор INSERT имеет один из следующих форматов:
INSERT INTO <базовая таблица | представление> [(<столбец> [,<столбец>] ...)]
VALUES (<константа>|<переменная> [,<константа>| <переменная>] ...);
или
INSERT
INTO <базовая таблица | представление> [(<столбец> [,<столбец>] ...)] <подзапрос>;
В первом формате в таблицу вставляется строка со значениями полей, указанными в перечне
фразы VALUES (значения), причем i-е значение соответствует i-му столбцу в списке столбцов
(столбцы, не указанные в списке, заполняются NULL-значениями). Если в списке VALUES фразы
указаны все столбцы модифицируемой таблицы и порядок их перечисления соответствует порядку
столбцов в описании таблицы, то список столбцов в предложении INTO можно опустить.
Пример 4.45 Добавить нового продавца:
INSERT INTO Продавцы VALUES (1009, 'Вильсон', 'Лондон', 0.12);
Замечание. Команды DML не производят никакого вывода, но СУБД должна дать некоторое
подтверждение того, что данные были использованы. Имя таблицы (в нашем случае - Продавцы)
должно быть предварительно определено в команде CREATE TABLE (см. п.4.5 ), а каждое
значение, заданное в предложении значений VALUES, должно совпадать с типом данных столбца,
в который оно вставляется.
Во втором формате сначала выполняется подзапрос, т.е. по предложению SELECT в памяти
формируется рабочая таблица, а потом строки рабочей таблицы загружаются в модифицируемую
таблицу. При этом i-й столбец рабочей таблицы (i-й элемент списка выбора SELECT)
соответствует i-му столбцу в списке столбцов модифицируемой таблицы. Здесь также при
выполнении указанных выше условий может быть опущен список столбцов фразы INTO.
Можно также использовать команду INSERT, чтобы выбирать значения из одной таблицы и
помещать их в другую. Чтобы сделать это, вы просто заменяете предложение VALUES (из
предыдущего примера) на соответствующий запрос:
Пример 4.46 INSERT INTO Лондон_1 SELECT * FROM Продавцы WHERE city = 'Лондон';
56
Здесь выбираются все значения, произведенные запросом - все строки из таблицы Продавцы со
значениями city = ‘Лондон’ - и помещаются в таблицу, называемую Лондон_1. Эта таблица
должна отвечать следующим условиям:

она должна уже быть создана командой CREATE TABLE.;

она должна иметь четыре столбца, которые совпадают с таблицей Продавцы по типу
данных.
4.4.3 Оператор обновления данных UPDATE
Оператор UPDATE имеет формат:
UPDATE <базовая таблица | представление>
SET
<столбец>= <значение> [,<столбец>= <значение>] ...
[WHERE <предикат>];
где <значение>::=<столбец> |< выражение> | <константа> | <переменная>
и может включать столбцы лишь из обновляемой таблицы, т.е. значение одного из столбцов
модифицируемой таблицы может заменяться на значение ее другого столбца или выражения,
содержащего значения нескольких ее столбцов, включая изменяемый.
При отсутствии WHERE фразы обновляются значения указанных столбцов во всех строках
модифицируемой таблицы. WHERE фраза позволяет сократить число обновляемых строк,
указывая условия их отбора.
Пример 4.47 Предположим, что продавец Мотика ушел на пенсию, и необходимо переназначить
его номер новому продавцу:
UPDATE Продавцы SET sname = 'Гибсон', city = 'Бостон', comm = .10 WHERE snum = 1004;
Эта команда передаст новому продавцу Гибсону, всех текущих заказчиков бывшего продавца
Мотика и их порядки.
Пример 4.48 Можно, используя коррелированный подзапрос, увеличить комиссионные всех
продавцов, которые были назначены по крайней мере двум заказчикам:
UPDATE Продавцы
SET comm = comm + .01
WHERE 2 < =
(SELECT COUNT (cnum) FROM Заказчики WHERE Заказчики.snum =
Продавцы.snum);
Теперь продавцы Пил и Серенс, имеющие нескольких заказчиков, получат повышение своих
комиссионных.
4.5 Операторы определения объектов базы данных
4.5.1 Операторы определения таблицы
Базовые таблицы описываются в SQL с помощью предложения CREATE TABLE (создать
таблицу). Рассмотрим синтаксис этого предложения:
CREATE TABLE <имя_таблицы> (<элемент_таблицы>
[,<элемент_таблицы >...] [ограничения_целостности_таблицы]);
< элемент_таблицы > ::= <определение_столбца>
< определение_столбца > ::= <имя_столбца> <тип_данных>
[DEFAULT <значение>] [<ограничения_ целостности_столбца>...]
< ограничения_ целостности_столбца > ::= NULL | NOT NULL [UNIQUE <спецификация>]
| REFERENCES <спецификация> | CHECK (<проверочное_ограничение>)|PRIMARY
KEY|FOREIGN KEY
Кроме имени таблицы, в операторе специфицируется список элементов таблицы, каждый из
которых служит либо для определения столбца, либо для определения ограничения целостности
определяемой таблицы. Требуется наличие хотя бы одного определения столбца. Для столбца
задается имя и его тип данных, а также два необязательных раздела: раздел значения столбца по
умолчанию и раздел ограничений целостности столбца.
Ограничение – это свойство, назначенное столбцу или таблице, которое запрещает ввод в
указанный столбец (или столбцы) недопустимых значений. Основные виды ограничений: NULL,
NOT NULL, DEFAULT, PRIMARY KEY, FOREIGN KEY, REFERENCES, CHECK, UNIQUE.
57
Ограничения могут быть без имени или с именем, тогда перед ограничением вставляется слово
CONSTRAINT <имя_ограничения>. Наличие имени ограничения позволяет ссылаться на него в
операторе изменения таблицы, например:
ALTER TABLE Tab1 ADD CONSTRAINT col1 CHECK (col1 BETWEEN 0 AND 1);
В разделе значения по умолчанию DEFAULT указывается значение, которое должно быть
помещено в строку, заносимую в данную таблицу, если значение данного столбца явно не указано.
Значение по умолчанию может быть указано в виде литеральной константы с типом,
соответствующим типу столбца, или путем задания ключевого слова NULL, означающего, что
значением по умолчанию является неопределенное значение. Если значение столбца по
умолчанию не специфицировано, и в разделе ограничений целостности столбца указано NOT
NULL, то попытка занести в таблицу строку с NULL-значением данного столбца приведет к
ошибке.
Указание в разделе ограничений целостности NOT NULL приводит к неявному порождению
проверочного ограничения целостности для всей таблицы «CHECK (C IS NOT NULL)» (где C имя данного столбца). Если ограничение NOT NULL не указано, и раздел умолчаний отсутствует,
то неявно порождается раздел умолчаний DEFAULT NULL. Если указана спецификация
уникальности, то порождается соответствующая спецификация уникальности для таблицы.
Если в разделе ограничений целостности указано ограничение по ссылкам данного столбца
(REFERENCES <спецификация>), то порождается соответствующее определение ограничения по
ссылкам для таблицы:
FOREIGN KEY(C) REFERENCES <спецификация>
Пример 4.49 Создать таблицу:
CREATE TABLE Заказчики
( cnum
integer NOT NULL PRIMARY KEY,
cname char (10) NOT NULL,
city
char (10) DEFAULT = 'Лондон',
rating integer,
snum
integer NOT NULL,
UNIQUE (cnum, snum));
UNIQUE (cnum, snum) – это ограничение целостности таблицы, утверждающее, что комбинация
номеров должна быть уникальной, т.е. у каждого заказчика только один продавец.
Пример 4.50 В следующем примере для задания составного первичного ключа используется
ограничение целостности таблицы PRIMARY KEY для пар:
CREATE TABLE Имена
( firstname
char (10) NOT NULL,
lastname
char (10) NOT NULL
city
char (10),
PRIMARY KEY ( firstname, lastname ));
Пример 4. 51 В данном примере использовано ограничение по ссылкам:
CREATE TABLE Продавцы
(snum integer NOT NULL PRIMARY KEY,
sname char(10) NOT NULL,
city char(10),
comm decimal,
cnum integer REFERENCES Customers);
Существующую базовую таблицу можно в любой момент уничтожить с помощью
предложения:
DROP TABLE <имя_таблицы>;
по которому удаляется описание таблицы, ее данные, связанные с ней представления и индексы,
построенные для столбцов таблицы.
В SQL существует также предложение ALTER TABLE (изменить таблицу), которое
позволяет добавить справа к таблице новый столбец, изменить или удалить столбец, т.е.
модифицировать описание таблицы.
58
Для построения индекса в SQL существует предложение CREATE INDEX (создать индекс),
имеющее формат:CREATE [UNIQUE] INDEX <имя_индекса> ON < имя_таблицы >
(<столбец >[[ASC] | DESC] [, <столбец> [[ASC] | DESC]] ...);
где UNIQUE (уникальный) указывает, что никаким двум строкам в индексируемой базовой
таблице не позволяется принимать одно и то же значение для индексируемого столбца (или
комбинации столбцов) в одно и то же время.
Для удаления индекса используется предложение:
DROP INDEX <имя_индекса>;
Замечание. Так как индексы могут создаваться или уничтожаться в любое время, то перед
выполнением запросов целесообразно строить индексы лишь для тех столбцов, которые
используются в WHERE и ORDER BY фразах запроса, а перед модификацией большого числа
строк таблиц с индексированными столбцами эти индексы следует уничтожить.
4.5.2 Оператор определения представлений CREATE VIEW
Представление - это виртуальная таблица, которая сама по себе не существует, но для
пользователя выглядит таким образом, как будто она существует. Представление не
поддерживаются его собственными физическими хранимыми данными. Вместо этого в каталоге
таблиц хранится определение, оговаривающее, из каких столбцов и строк других таблиц оно
должно быть сформировано. Механизм представлений (view) является мощным средством языка
SQL, позволяющим скрыть реальную структуру БД от некоторых пользователей за счет
определения представления БД, которое реально является некоторым хранимым в БД запросом с
именованными столбцами, а для пользователя ничем не отличается от базовой таблицы БД (с
учетом технических ограничений). Любая реализация должна гарантировать, что состояние
представляемой таблицы точно соответствует состоянию базовых таблиц, на которых определено
представление. Синтаксис предложения CREATE VIEW имеет вид:
CREATE VIEW <имя_представления>
[(<столбец>[,<столбец>] ...)]
AS подзапрос
[WITH CHECK OPTION];
где подзапрос, следующий за AS и являющийся определением данного представления, не
исполняется, а просто сохраняется в каталоге;
необязательная фраза «WITH CHECK OPTION» (с опцией проверки) указывает, что для операций
INSERT и UPDATE над этим представлением должна осуществляться проверка, обеспечивающая
удовлетворение WHERE фразы подзапроса;
список имен столбцов должен быть обязательно определен лишь в тех случаях, когда:
а) хотя бы один из столбцов подзапроса не имеет имени (создается с помощью выражения, SQLфункции или константы);
б) два или более столбцов подзапроса имеют одно и то же имя;
если же список отсутствует, то представление наследует имена столбцов из подзапроса.
Пример 4.52
Например, создадим представление Лондон_продавцы, которое может
рассматриваться пользователем как новая таблица в базе данных:
CREATE VIEW Лондон_продавцы
AS SELECT *
FROM Продавцы
WHERE city = 'Лондон';
Пример 4. 53 Следующее представление содержит данные о количестве заказчиков с каждым
значением рейтинга: CREATE VIEW Оценка (rating, number)
AS SELECT rating, COUNT (*) FROM Заказчики GROUP BY rating;
Пример 4. 54 Предположим, что компания предусматривает премию для тех продавцов, которые
имеют заказчика с самым высоким порядком для любой указанной даты. Можно проследить эту
информацию с помощью представления:
CREATE VIEW Максимум AS
SELECT b.odate, a.snum, a.sname, FROM Продавцы a, Порядки b WHERE a.snum = b.snum
AND b.amt = (SELECT MAX (amt) FROM Порядки c WHERE c.odate = b.odate);
59
Представляемая таблица V является модифицируемой (т.е. по отношению к V можно использовать
операторы DELETE, UPDATE, INSERT) в том и только в том случае, если выполняются
следующие условия для спецификации запроса:
 в списке выборки не указано ключевое слово DISTINCT;
 каждое арифметическое выражение в списке выборки представляет собой одну
спецификацию столбца, и спецификация одного столбца не появляется более одного раза
(не должно быть агрегатных функций и выражений);
 в разделе FROM указана только одна таблица, являющаяся либо базовой таблицей, либо
модифицируемым представлением;
 в условии выборки раздела WHERE не используются подзапросы;
 отсутствуют разделы GROUP BY и HAVING.
Таким образом, могут быть модифицируемые представления (пример 4.52) и представления
только для чтения, которые разрешается использовать только в команде SELECT (примеры 4.53,
4.54). С помощью представлений можно создать библиотеку сложных запросов и работать с
сохраненными представлением как с таблицами.
Возможна ситуация, когда в модифицируемое представление добавляются данные, которые
«проглатываются» (swallowed) в базовой таблице.
Пример 4. 55 Рассмотрим такое представление:
CREATE VIEW Рейтинг
AS SELECT cnum, rating FROM Заказчики WHERE rating = 300;
Это - представление модифицируемое. Оно просто ограничивает доступ к определенным строкам
и столбцам в таблице. Предположим, что вы вставляете (INSERT) следующую строку:
INSERT INTO Рейтинг
VALUES (2018, 200);
Это - допустимая команда INSERT в этом представлении. Строка будет вставлена с помощью
представления Рейтинг в таблицу Заказчики. Однако когда она появится там, она исчезнет из
представления, поскольку значение оценки не равно 300. Это - обычная проблема. Пользователь
не сможет понять, почему введя строку, он не может ее увидеть, и будет неспособен при этом
удалить ее. Вы можете быть гарантированы от модификаций такого типа с помощью предложения
WITH CHECK OPTION в определение представления.
Пример 4. 56 Добавим это предложение в команду примера 4.55:
CREATE VIEW Рейтинг
AS SELECT cnum, rating FROM Заказчики WHERE rating = 300 WITH CHECK OPTION;
Вышеупомянутая вставка будет отклонена.
Замечание. Требование WITH CHECK OPTION в определении представления имеет смысл только
в случае определения модифицируемой представляемой таблицы.
Для удаления представления используется оператор:
DROP VIEW <имя_представления>;
4.6 Операторы контроля данных, защиты и управления данными
4.6.1 Операторы управления привилегиями
В контексте баз данных термин «безопасность» означает защиту данных от
несанкционированного раскрытия, изменения или уничтожения. SQL позволяет индивидуально
защищать как целые таблицы, так и отдельные их поля. Для этого имеются две более или менее
независимые возможности:

механизм представлений, рассмотренный ранее и используемый для скрытия засекреченных
данных от пользователей, не обладающих правом доступа;

подсистема
санкционирования
доступа,
позволяющая
предоставить
указанным
пользователям определенные привилегии на доступ к данным и дать им возможность
избирательно и динамически передавать часть выделенных привилегий другим
пользователям, отменяя впоследствии эти привилегии, если потребуется.
Каждый пользователь в среде SQL , имеет специальное идентификационное имя или номер.
Команда, посланная в базе данных, ассоциируется с определенным пользователем, или иначе,
специальным идентификатором доступа. Команда интерпретируется и разрешается (или
60
запрещается) на основе информации, связанной с идентификатором (ID) доступа пользователя,
подавшего команду.
Обычно при установке СУБД в нее вводится какой-то идентификатор, который должен далее
рассматриваться как идентификатор наиболее привилегированного пользователя - системного
администратора. Каждый, кто может войти в систему с этим ID (и может выдержать тесты на
достоверность), будет считаться системным администратором до выхода из системы. Системный
администратор может создавать БД и имеет все привилегии на их использование. Эти привилегии
или их часть могут предоставляться другим пользователям (пользователям с другими ID). В свою
очередь, пользователи, получившие привилегии от системного администратора, могут передать их
(или их часть) другим пользователям, которые могут их передать следующим и т.д.
Определение привилегий производится в следующем синтаксисе:
GRANT <привилегии> ON < объект> TO < субъект >
[{<субъект >}...] [WITH GRANT OPTION];
<привилегии>::= ALL [PRIVILEGES] | <действие> [{,<действие> }...]
<действие>::= SELECT | INSERT | DELETE | UPDATE [(<список столбцов>)]
| REFERENCES [(<список столбцов>)]
[(<список столбцов>)]::= <имя_столбца> [{,<имя_столбца> }...]
<субъект> ::= PUBLIC | <идентификатор_доступа_пользователя>
<привилегии> - список, состоящий из одной или нескольких привилегий, разделенных запятыми,
либо фраза ALL PRIVILEGES (все привилегии); <объект> - имя и, если надо, тип объекта (база
данных, таблица, представление, индекс и т.п.); <субъекты> - список, включающий один или
более идентификаторов доступа, разделенных запятыми, либо специальное ключевое слово
PUBLIC (общедоступный).
Замечание. Привилегией REFERENCES по отношению к указанным столбцам таблицы T1
необходимо обладать, чтобы иметь возможность при определении таблицы T определить
ограничение по ссылкам между этой таблицей и существующей к этому моменту таблицей T1.
Замечание. Когда вы предоставляете привилегии для публикации,
все пользователи
автоматически их получают. Наиболее часто, это применяется для привилегии SELECT в
определенных базовых таблицах или представлениях, которые вы хотите сделать доступными
для любого пользователя.
Пример 4. 57 GRANT SELECT, INSERT ON Порядки TO Адриан, Диана;
Пример 4. 58 GRANT ALL ON Заказчики TO Стефан;
Пример 4. 59 GRANT SELECT ON Orders TO PUBLIC;
Пользователь должен иметь возможность передать привилегии (или их часть) другим
пользователям. Обычно это делается в системах, где один или более пользователей создают
несколько (или все) базовые таблицы в БД, а затем передают ответственность за них тем, кто будет
фактически с ними работать. SQL позволяет делать это с помощью предложения WITH GRANT
OPTION.
Пример 4. 60 Если Диана хотела бы, чтобы Адриан имел право предоставлять привилегию
SELECT в таблице Заказчики другим пользователям, она дала бы ему привилегию SELECT с
использованием предложения WITH GRANT OPTION:
GRANT SELECT ON Заказчики TO Адриан WITH GRANT OPTION;
После выполнения этой команды Адриан получил право передавать привилегию SELECT
третьим лицам
Если пользователь USER_1 предоставил какие-либо привилегии другому пользователю
USER_2, то он может впоследствии отменить все или некоторые из этих привилегий. Отмена
осуществляется с помощью предложения REVOKE (отменить), общий формат которого очень
похож на формат предложения GRANT:
REVOKE <привилегии> ON < объект> FROM < субъект > [{,<субъект >}...];
Пример 4. 61 REVOKE INSERT, DELETE ON Заказчики FROM Адриан, Стефан.
61
4.6.2 Операторы управления транзакциями
Транзакция - это неделимая, с точки зрения воздействия на СУБД, последовательность
операций манипулирования данными. Для пользователя транзакция выполняется по принципу
«все или ничего», т.е. либо транзакция выполняется целиком и переводит базу данных из одного
целостного состояния в другое целостное состояние, либо, если по каким-либо причинам, одно
из действий транзакции невыполнимо, или произошло какое-либо нарушение работы системы, БД
возвращается в исходное состояние, которое было до начала транзакции (происходит откат
транзакции). С этой точки зрения, транзакции важны как в многопользовательских, так и в
однопользовательских системах. В однопользовательских системах транзакции - это логические
единицы работы, после выполнения которых БД остается в целостном состоянии. Транзакции
также являются единицами восстановления данных после сбоев - восстанавливаясь, система
ликвидирует следы транзакций, не успевших успешно завершиться в результате программного
или аппаратного сбоя. Эти два свойства транзакций определяют атомарность (неделимость)
транзакции. В многопользовательских системах, кроме того, транзакции служат для обеспечения
изолированной работы отдельных пользователей - пользователям, одновременно работающим с
одной базой данных, кажется, что они работают как бы в однопользовательской системе и не
мешают друг другу.
Транзакция или логическая единица работы БД, - это в общем случае последовательность ряда
таких операций, которые преобразуют некоторое непротиворечивое состояние базы данных в
другое непротиворечивое состояние, но не гарантируют сохранения непротиворечивости во все
промежуточные моменты времени.
Транзакция обладает четырьмя важными свойствами, известными как свойства АСИД:
 (А) Атомарность. Транзакция выполняется как атомарная операция - либо выполняется
вся транзакция целиком, либо она целиком не выполняется.
 (С) Согласованность. Транзакция переводит базу данных из одного согласованного
(целостного) состояния в другое согласованное (целостное) состояние. Внутри транзакции
согласованность базы данных может нарушаться.
 (И) Изоляция. Транзакции разных пользователей не должны мешать друг другу (например,
как если бы они выполнялись строго по очереди).
 (Д) Долговечность. Если транзакция выполнена, то результаты ее работы должны
сохраниться в базе данных, даже если в следующий момент произойдет сбой системы.
Транзакция обычно начинается автоматически с момента присоединения пользователя к СУБД и
продолжается до тех пор, пока не произойдет одно из следующих событий:
 подана команда COMMIT (зафиксировать транзакцию);
 подана команда ROLLBACK (откатить транзакцию);
 произошло отсоединение пользователя от СУБД;
 произошел сбой системы.
Свойства АСИД транзакций не всегда выполняются в полном объеме. Особенно это
относится к свойству И (изоляция). В идеале, транзакции разных пользователей не должны
мешать друг другу, т.е. они должны выполняться так, чтобы у пользователя создавалась иллюзия,
что он в системе один. Простейший способ обеспечить абсолютную изолированность состоит в
том, чтобы выстроить транзакции в очередь и выполнять их строго одну за другой. Очевидно, при
этом теряется эффективность работы системы. Поэтому реально одновременно выполняется
несколько транзакций (смесь транзакций). Различается несколько уровней изоляции транзакций.
На низшем уровне изоляции транзакции могут реально мешать друг другу, на высшем - они
полностью изолированы. За большую изоляцию транзакций приходится платить большими
накладными расходами системы и замедлением работы. Пользователи или администратор
системы могут по своему усмотрению задавать различные уровни изоляции всех или отдельных
транзакций. Более подробно изоляция транзакций рассматривается в п. 4.6.3.
Свойство Д (долговечность) также не является абсолютными свойством, т.к. некоторые системы
допускают вложенные транзакции. Если транзакция Б запущена внутри транзакции А, и для
транзакции Б подана команда COMMIT, то фиксация данных транзакции Б является условной, т.к.
62
внешняя транзакция А может откатиться. Результаты работы внутренней транзакции Б будут
окончательно зафиксированы только, если будет зафиксирована внешняя транзакция А.
Свойство (С) - согласованность транзакций определяется наличием понятия согласованности базы
данных. База данных находится в согласованном (целостном) состоянии, если выполнены
(удовлетворены) все ограничения целостности, определенные для базы данных.
Ограничение целостности (бизнес-правило) - это некоторое утверждение, которое может быть
истинным или ложным в зависимости от состояния базы данных.
Примерами ограничений целостности могут служить следующие утверждения:
Пример 4.62. У каждого заказчика только один продавец.
Пример 4.63. Каждый сотрудник имеет уникальный табельный номер.
Пример 4.64 Сотрудник обязан числиться только в одном отделе.
Пример 4.65. Сумма денег накладной обязана равняться сумме произведений цен товаров на
количество товаров для всех товаров, входящих в накладную.
Как видно из этих примеров, некоторые из ограничений целостности являются ограничениями
реляционной модели данных (см. гл. 3). Пример 4.63 представляет ограничение, реализующее
целостность сущности. Примеры 4.62, 4.64 представляют ограничения, реализующие ссылочную
целостность. Другие ограничения являются достаточно произвольными утверждениями,
утверждениями связанными с правилами в конкретной предметной области (пример 4.65). Любое
ограничение целостности является семантическим понятием, т.е. появляется как следствие
определенных свойств объектов предметной области и/или их взаимосвязей.
Вместе с понятием целостности базы данных возникает понятие реакции системы на попытку
нарушения целостности. Система должна не только проверять, не нарушаются ли ограничения в
ходе выполнения различных операций, но и должным образом реагировать, если операция
приводит к нарушению целостности. Имеется два типа реакции на попытку нарушения
целостности:
1. Отказ выполнить "незаконную" операцию.
2. Выполнение компенсирующих действий.
Работа системы по проверке ограничений изображена на рисунке 4.1.
Каждая система обладает своими средствами поддержки ограничений целостности. Ограничения
целостности классифицируются несколькими способами:
 по способам реализации;
 по времени проверки;
 по области действия.
По способам реализации различают:
 декларативную поддержку ограничений целостности - средствами языка определения
данных (DDL);
 процедурную поддержку ограничений целостности - посредством триггеров и хранимых
процедур.
63
Рисунок 4.1 Работа системы по проверке ограничений
По времени проверки ограничения делятся на:
 немедленно проверяемые ограничения;
 ограничения с отложенной проверкой.
По области действия ограничения делятся на:
 ограничения домена;
 ограничения атрибута;
 ограничения кортежа;
 ограничения отношения;
 ограничения базы данных.
Стандарт языка SQL поддерживает только декларативные ограничения целостности,
реализуемые как:
 ограничения домена;
 ограничения, входящие в определение таблицы;
 ограничения, хранящиеся в базе данных в виде независимых утверждений (assertion).
Проверка ограничений допускается как после выполнения каждого оператора, могущего
нарушить ограничение, так и в конце транзакции. Во время выполнения транзакции можно
изменить режим проверки ограничения.
Стандарт SQL не предусматривает процедурных ограничений целостности, реализуемых при
помощи триггеров и хранимых процедур. В стандарте SQL 92 отсутствует понятие «триггер», хотя
триггеры имеются во всех промышленных СУБД SQL-типа. Таким образом, реализация
ограничений средствами конкретной СУБД обладает большей гибкостью, нежели с
использованием исключительно стандартных средств SQL.
4.6.3 Проблемы параллельной работы транзакций
Современные многопользовательские системы допускают одновременную работу большого числа
пользователей. При этом, если не предпринимать специальных мер, транзакции будут мешать друг
другу. Этот эффект известен как проблемы параллелизма.
Имеются три основных следствия проблемы параллелизма:
 проблема потери результатов обновления;
 проблема незафиксированной зависимости (чтение "грязных" данных, неаккуратное
считывание);
 проблема несовместимого анализа.
64
Решение проблем параллелизма состоит в нахождении такой стратегии запуска транзакций, чтобы
обеспечить сериальность графика запуска и не слишком уменьшить степень параллельности.
Под сериализаций параллельно выполняющихся транзакций понимается такой порядок
планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен
эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси
транзакций - это такой план, который приводит к сериализации транзакций. График запуска
набора транзакций называется последовательным, если транзакции выполняются строго по
очереди. Если график запуска набора транзакций содержит чередующиеся элементарные операции
транзакций, то такой график называется чередующимся. Два графика называются
эквивалентными, если при их выполнении будет получен один и тот же результат, независимо от
начального состояния базы данных. График запуска транзакции называется верным
(сериализуемым), если он эквивалентен какому-либо последовательному графику.
Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то
для каждого пользователя, по инициативе которого образована транзакция, присутствие других
транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с
однопользовательским режимом).
Одним из методов обеспечения сериальности графика запуска является протокол доступа к
данным при помощи блокировок. В простейшем случае различают S-блокировки (Shared locks
разделяемые) и X-блокировки (eXclusive locks монопольные). Протокол доступа к данным имеет
вид:
1. Прежде, чем прочитать объект, транзакция должна наложить на этот объект S-блокировку.
2. Прежде, чем обновить объект, транзакция должна наложить на этот объект X-блокировку.
Если транзакция уже заблокировала объект S-блокировкой (для чтения), то перед
обновлением объекта S-блокировка должна быть заменена X-блокировкой.
3. Если блокировка объекта транзакцией B отвергается оттого, что объект уже заблокирован
транзакцией A, то транзакция B переходит в состояние ожидания. Транзакция B будет
находиться в состоянии ожидания до тех пор, пока транзакция A не снимет блокировку
объекта.
4. X-блокировки, наложенные транзакцией A, сохраняются до конца транзакции A.
Если все транзакции в смеси подчиняются протоколу доступа к данным, то проблемы
параллелизма решаются (почти все, кроме «фантомов»), но появляются тупики. Состояние тупика
(dead locks) характеризуется тем, что две или более транзакции пытаются заблокировать одни и те
же объекты, и бесконечно долго ожидают друг друга.
Для разрушения тупиков система периодически или постоянно поддерживает граф ожидания
транзакций. Наличие циклов в графе ожидания свидетельствует о возникновении тупика. Для
разрушения тупика одна из транзакций (наиболее дешевая с точки зрения системы) выбирается в
качестве жертвы и откатывается.
Для решения проблемы «фантомов», а также для уменьшения накладных расходов, вызываемых
большим количеством блокировок, применяются более сложные методы. Одним из таких методов
являются преднамеренные блокировки, блокирующие объекты разной величины - строки,
страницы, таблицы, файлы и др.
1.
2.
3.
4.
5.
6.
7.
8.
9.
4.7 Вопросы и упражнения для самоконтроля к главе 4
Сколько версий языка SQL было принято?
Используется ли в какой-либо СУБД язык SQL в том виде, как он описан в стандарте?
Что означает символ «*» в операторе SELECT?
Как организуется вывод данных с группированием по какому-либо полю (столбцу) таблицы?
Как подсчитать число строк таблицы?
Как задаются имена столбцов, если в запросе используются несколько таблиц?
Какие виды подзапросов вы знаете и каковы ограничения при их использовании?
Что может включать предикат в предложениях WHERE и HAVING?
В каком случае запрос, содержащий конструкцию … EXISTS (подзапрос), может не вывести
никаких данных?
65
10. Как выполнить объединение таблиц?
11. Какие действия выполняет оператор DELETE без фразы WHERE?
12. Какими способами можно заполнить созданную таблицу данными?
13. Как организовать перерасчет значений каких-либо столбцов таблицы?
14. Напишите оператор создания таблицы Товары с указанием значений по умолчанию и условий
проверки данных в некоторых полях.
15. Как задать составной первичный ключ при создании таблицы?
16. Для чего нужны представления?
17. Как определяются модифицируемые представления?
18. Что показывает фраза WITH CHECK OPTION при создании представлений?
19. Что понимается под привилегиями языка SQL и как они передаются?
20. Что такое транзакция в БД и как она задается?
21. В чем заключается проблема параллелизма?
Глава 5 Проектирование баз данных
Процесс проектирования БД представляет собой последовательность переходов от неформального
словесного описания информационной структуры предметной области к формализованному
описанию объектов ПО в терминах некоторой модели. В общем случае можно выделить
следующие этапы проектирования:
I.
Системный анализ и словесное описание информационных объектов ПО. Существуют два
подхода к выбору состава и структуры предметной области:
 Функциональный подход. Он реализует принцип движения «от задач» и применяется тогда,
когда известны функции некоторой группы лиц и комплексов задач, для облуживания
информационных потребностей которых создается БД. В этом случае можно четко выделить
необходимый минимальный набор объектов, которые должны быть описаны.
 Предметный подход. Информационные потребности будущих пользователей жестко не
зафиксированы. Невозможно выделить необходимый минимальный набор объектов, которые
необходимо описывать. В описание ПО в этом случае включаются такие объекты и
взаимосвязи, которые наиболее характерны и существенны для нее. Проектируемая БД
называется предметной и может быть использована для множества разнообразных, заранее
неопределенных задач. Такой подход кажется наиболее перспективным, однако может
привести к избыточности задач или потребностей пользователей, а с другой стороны,
учитывает возможность наращивания новых приложений.
II.
Проектирование инфологической модели ПО. Задача инфологического этапа проектирования:
получение семантических (смысловых) моделей данных (например, в терминах ER-моделей).,
отображающих информационное содержание конкретной ПО. Вначале выполняется выделение
из воспринимаемой реальности требуемой части ПО, определяются ее границы, происходит
абстрагирование от несущественных частей для конкретного применения БД. В результате
определяются объекты, их свойства и связи, которые будут существенны для будущих
пользователей системы.
III.
Даталогическое или логическое проектирование БД, т.е. описание БД в терминах принятой
даталогической модели данных (например, реляционной). Задачей логического этапа
проектирования является организация данных, выделенных на предыдущем этапе, в такую
форму, которая принята в выбранной конкретной СУБД, используя ее типы и модели данных.
Даются рекомендации по выбору методов доступа к данным.
IV.
Физическое проектирование БД, т.е. выбор эффективного размещения БД на внешних
носителях для обеспечения наиболее эффективной работы приложения. Задачей физического
этапа проектирования является выбор рациональной структуры хранения данных. и методов
доступа к ним, исходя из того арсенала средств и методов, который предоставляет
разработчику конкретная СУБД.
При проектировании базы данных решаются две основных проблемы:
 Каким образом отобразить объекты предметной области в абстрактные объекты модели
данных? Эту проблему называют проблемой логического проектирования баз данных.
66
Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом,
имея в виду особенности конкретной СУБД, расположить данные во внешней памяти,
создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту
проблему называют проблемой физического проектирования баз данных.
В случае реляционных баз данных трудно представить какие-либо общие рецепты по части
физического проектирования. Здесь слишком много зависит от используемой СУБД. Поэтому мы
ограничимся вопросами логического проектирования реляционных баз данных, которые
существенны при использовании любой реляционной СУБД.
Более того, мы не будем касаться очень важного аспекта проектирования - определения
ограничений целостности (за исключением ограничения первичного ключа). Дело в том, что при
использовании СУБД с развитыми механизмами ограничений целостности (например, SQLориентированных систем) трудно предложить какой-либо общий подход к определению
ограничений целостности. Эти ограничения могут иметь очень общий вид, и их формулировка
пока относится скорее к области искусства, чем инженерного мастерства. Самое большее, что
предлагается по этому поводу в литературе, это автоматическая проверка непротиворечивости
набора ограничений целостности.
Так что будем считать, что проблема проектирования реляционной базы данных состоит в
обоснованном принятии решений о том,
 из каких отношений должна состоять БД и
 какие атрибуты должны быть у этих отношений
Можно выделить три основных подхода к проектированию БД:
1. сбор информации об объектах решаемой задачи в рамках одной таблицы и последующая ее
декомпозиция на несколько взаимосвязанных таблиц на основе процедур нормализации
(классический метод);
2. переход от семантической (инфологической) модели второго этапа с помощью CASEсредств к готовой схеме БД или даже готовой прикладной информационной системе (ИС);
3. структурирование информации для использования в ИС в процессе проведения системного
анализа на основе совокупности практических правил и рекомендаций.

5.1 Проектирование реляционных БД с использованием принципов нормализации
Сначала будет рассмотрен классический подход, при котором весь процесс проектирования
производится в терминах реляционной модели данных методом последовательных приближений к
удовлетворительному набору схем отношений. Исходной точкой является представление ПО в
виде одного или нескольких отношений, и на каждом шаге проектирования производится
некоторый набор схем отношений, обладающих лучшими свойствами. Процесс проектирования
представляет собой процесс нормализации схем отношений, причем каждая следующая
нормальная форма обладает свойствами лучшими, чем предыдущая.
В теории реляционных баз данных обычно выделяется следующая последовательность
нормальных форм:
 первая нормальная форма (1NF);
 вторая нормальная форма (2NF);
 третья нормальная форма (3NF);
 нормальная форма Бойса-Кодда (BCNF);
 четвертая нормальная форма (4NF);
 пятая нормальная форма (5NF или PJ/NF).
Основные свойства нормальных форм:
 каждая следующая нормальная форма в некотором смысле лучше предыдущей;
 при переходе к следующей нормальной форме свойства предыдущих нормальных свойств
сохраняются.
В основе процесса проектирования лежит метод нормализации, декомпозиция отношения,
находящегося в предыдущей нормальной форме, в два или более отношения, удовлетворяющих
требованиям следующей нормальной формы.
67
Наиболее важные на практике нормальные формы отношений основываются на фундаментальном
в теории реляционных баз данных понятии функциональной зависимости. Для дальнейшего
изложения нам потребуются несколько определений.
Определение 1. Функциональная зависимость
В отношении R атрибут Y функционально зависит от атрибута X (X и Y могут быть составными) в
том и только в том случае, если каждому значению X соответствует в точности одно значение Y:
R.X ->R.Y.
Определение 2. Полная функциональная зависимость
Функциональная зависимость R.X ->R.Y называется полной, если атрибут Y не зависит
функционально от любого точного подмножества X.
Определение 3. Транзитивная функциональная зависимость
Функциональная зависимость R.X -> R.Y называется транзитивной, если существует такой
атрибут Z, что имеются функциональные зависимости R.X -> R.Z и R.Z -> R.Y и отсутствует
функциональная зависимость R.Z -/-> R.X.
Определение 4. Неключевой атрибут
Неключевым атрибутом называется любой атрибут отношения, не входящий в состав первичного
ключа (в частности, первичного).
Определение 5. Взаимно независимые атрибуты
Два или более атрибута взаимно независимы, если ни один из этих атрибутов не является
функционально зависимым от других.
Поскольку требование первой нормальной формы является базовым требованием
классической реляционной модели данных, мы будем считать, что исходный набор отношений уже
соответствует этому требованию, т.е. все атрибуты атомарны. Если таблица содержит составные
атрибуты, то привести ее к 1NF можно, используя алгоритм нормализации, предложенный Э.
Коддом:
1. начиная с исходной таблицы, берется ее первичный ключ и добавляется в каждую
подчиненную таблицу (составной атрибут);
2. первичный ключ каждой расширенной таблицы состоит из первичного ключа подчиненной
таблицы и добавленного родительского первичного ключа;
3. после этого из родительской таблицы вычеркиваются все непростые атрибуты, и эта
процедура повторяется для каждой из подчиненных таблиц;
4. условие окончания алгоритма - атомарность всех атрибутов.
Пример 5.1 Рассмотрим в качестве предметной области некоторую организацию, выполняющую
некоторые проекты. Модель предметной области опишем следующим неформальным текстом:
1. Сотрудники организации выполняют проекты.
2. Проекты состоят из нескольких заданий.
3. Каждый сотрудник может участвовать в одном или нескольких проектах, или временно не
участвовать ни в каких проектах.
4. Над каждым проектом может работать несколько сотрудников, или временно проект может
быть приостановлен, тогда над ним не работает ни один сотрудник.
5. Над каждым заданием в проекте работает ровно один сотрудник.
6. Каждый сотрудник числится в одном отделе.
7. Каждый сотрудник имеет телефон, находящийся в отделе сотрудника.
В ходе дополнительного уточнения того, какие данные необходимо учитывать, выяснилось
следующее:
1. Для каждого сотрудника необходимо хранить табельный номер. Табельный номер является
уникальным для каждого сотрудника.
2. Каждый отдел имеет уникальный номер.
3. Каждый проект имеет номер. Номер проекта является уникальным.
4. Каждое задание из проекта имеет номер, уникальный в пределах проекта.
Представим схему отношения (вся информация в одной таблице):
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ
(СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
68
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР, ПРО_НОМЕР -> СОТР_ЗАДАН
Как видно, хотя первичным ключом является составной атрибут СОТР_НОМЕР, ПРО_НОМЕР,
атрибуты СОТР_ЗАРП и ОТД_НОМЕР функционально зависят от части первичного ключа,
атрибута СОТР_НОМЕР. В результате мы не сможем вставить в отношение СОТРУДНИКИОТДЕЛЫ-ПРОЕКТЫ кортеж, описывающий сотрудника, который еще не выполняет никакого
проекта (первичный ключ не может содержать неопределенное значение). При удалении кортежа
мы не только разрушаем связь данного сотрудника с данным проектом, но утрачиваем
информацию о том, что он работает в некотором отделе. При переводе сотрудника в другой отдел
мы будем вынуждены модифицировать все кортежи, описывающие этого сотрудника, или
получим несогласованный результат. Такие неприятные явления называются аномалиями схемы
отношения. Они устраняются путем нормализации.
Определение 6. Вторая нормальная форма (в этом определении предполагается, что
единственным ключом отношения является первичный ключ)
Отношение R находится во второй нормальной форме (2NF) в том и только в том случае, когда
находится в 1NF, и каждый не ключевой атрибут полностью зависит от первичного ключа.
Можно произвести следующую декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ в
два отношения СОТРУДНИКИ-ОТДЕЛЫ и СОТРУДНИКИ-ПРОЕКТЫ:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, СОТР_ЗАРП, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> СОТР_ЗАРП
СОТР_НОМЕР -> ОТД_НОМЕР
ОТД_НОМЕР -> СОТР_ЗАРП
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Первичный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Каждое из этих двух отношений находится в 2NF, и в них устранены отмеченные выше аномалии
(легко проверить, что все указанные операции выполняются без проблем).
Рассмотрим еще раз отношение СОТРУДНИКИ-ОТДЕЛЫ, находящееся в 2NF. Заметим, что
функциональная зависимость СОТР_НОМЕР -> СОТР_ЗАРП является транзитивной; она является
следствием функциональных зависимостей СОТР_НОМЕР -> ОТД_НОМЕР и ОТД_НОМЕР ->
СОТР_ЗАРП. Другими словами, заработная плата сотрудника на самом деле является
характеристикой не сотрудника, а отдела, в котором он работает (это не очень естественное
предположение, но достаточное для примера).
В результате мы не сможем занести в базу данных информацию, характеризующую заработную
плату отдела, до тех пор, пока в этом отделе не появится хотя бы один сотрудник (первичный
ключ не может содержать неопределенное значение). При удалении кортежа, описывающего
последнего сотрудника данного отдела, мы лишимся информации о заработной плате отдела.
Чтобы согласованным образом изменить заработную плату отдела, мы будем вынуждены
предварительно найти все кортежи, описывающие сотрудников этого отдела. Т.е. в отношении
СОТРУДИКИ-ОТДЕЛЫ по-прежнему существуют аномалии. Их можно устранить путем
дальнейшей нормализации.
Определение 7. Третья нормальная форма (определение дается в предположении существования
единственного ключа.)
69
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если
находится в 2NF и каждый не ключевой атрибут не транзитивно зависит от первичного ключа.
Можно произвести декомпозицию отношения СОТРУДНИКИ-ОТДЕЛЫ в два отношения
СОТРУДНИКИ и ОТДЕЛЫ:
СОТРУДНИКИ (СОТР_НОМЕР, ОТД_НОМЕР)
Первичный ключ:
СОТР_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> ОТД_НОМЕР
ОТДЕЛЫ (ОТД_НОМЕР, СОТР_ЗАРП)
Первичный ключ:
ОТД_НОМЕР
Функциональные зависимости:
ОТД_НОМЕР -> СОТР_ЗАРП
Каждое из этих двух отношений находится в 3NF и свободно от отмеченных аномалий.
Если отказаться от того ограничения, что отношение обладает единственным ключом, то
определение 3NF примет следующую форму:
Определение 7*
Отношение R находится в третьей нормальной форме (3NF) в том и только в том случае, если
находится в 2NF, и каждый не ключевой атрибут не является транзитивно зависимым от какоголибо ключа R.
На практике третья нормальная форма схем отношений достаточна в большинстве случаев, и
приведением к третьей нормальной форме процесс проектирования реляционной базы данных
обычно заканчивается.
Однако иногда полезно продолжить процесс нормализации.
Пример 5.2 Рассмотрим следующий пример схемы отношения:
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможные ключи:
СОТР_НОМЕР, ПРО_НОМЕР
СОТР_ИМЯ, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР -> CОТР_ИМЯ
СОТР_НОМЕР -> ПРО_НОМЕР
СОТР_ИМЯ -> CОТР_НОМЕР
СОТР_ИМЯ -> ПРО_НОМЕР
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
СОТР_ИМЯ, ПРО_НОМЕР -> CОТР_ЗАДАН
В этом примере мы предполагаем, что личность сотрудника полностью определяется как его
номером, так и именем (это снова не очень жизненное предположение, но достаточное для
примера).
В соответствии с определением 7* отношение СОТРУДНИКИ-ПРОЕКТЫ находится в 3NF.
Однако тот факт, что имеются функциональные зависимости атрибутов отношения от атрибута,
являющегося частью первичного ключа, приводит к аномалиям. Например, для того, чтобы
изменить имя сотрудника с данным номером согласованным образом, нам потребуется
модифицировать все кортежи, включающие его номер.
Определение 8. Детерминант
Детерминант - любой атрибут, от которого полностью функционально зависит некоторый другой
атрибут.
Определение 9. Нормальная форма Бойса-Кодда
Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае,
если каждый детерминант является возможным ключом.
Очевидно, что это требование не выполнено для отношения СОТРУДНИКИ-ПРОЕКТЫ. Можно
произвести его декомпозицию к отношениям СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ:
70
СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ)
Возможные ключи:
СОТР_НОМЕР
СОТР_ИМЯ
Функциональные зависимости:
СОТР_НОМЕР -> CОТР_ИМЯ
СОТР_ИМЯ -> СОТР_НОМЕР
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН)
Возможный ключ:
СОТР_НОМЕР, ПРО_НОМЕР
Функциональные зависимости:
СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Возможна альтернативная декомпозиция, если выбрать за основу СОТР_ИМЯ. В обоих случаях
получаемые отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им не
свойственны отмеченные аномалии.
Пример 5.3 Рассмотрим пример следующей схемы отношения:
ПРОЕКТЫ (ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников,
которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники
могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания.
Каждый кортеж отношения связывает некоторый проект с сотрудником, участвующим в этом
проекте, и заданием, который сотрудник выполняет в рамках данного проекта (мы предполагаем,
что любой сотрудник, участвующий в проекте, выполняет все задания, предусмотренные этим
проектом). По причине сформулированных выше условий единственным возможным ключом
отношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нет никаких
других детерминантов. Следовательно, отношение ПРОЕКТЫ находится в BCNF. Но при этом
оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному
проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем
предусмотрено.
Определение 10. Многозначные зависимости
В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том
случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и
не зависит от С.
В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости:
ПРО_НОМЕР -> -> ПРО_СОТР
ПРО_НОМЕР -> -> ПРО_ЗАДАН
Легко показать, что в общем случае в отношении R (A, B, C) существует многозначная
зависимость R.A -> -> R.B в том и только в том случае, когда существует многозначная
зависимость R.A -> -> R.C.
Дальнейшая нормализация отношений, подобных отношению ПРОЕКТЫ, основывается на
следующей теореме:
Теорема Фейджина
Отношение R (A, B, C) можно спроецировать без потерь в отношения R1 (A, B) и R2 (A, C) в том и
только в том случае, когда существует MVD A -> -> B | C.
Под проецированием без потерь понимается такой способ декомпозиции отношения, при котором
исходное отношение полностью и без избыточности восстанавливается путем естественного
соединения полученных отношений.
Определение 11. Четвертая нормальная форма
Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в
случае существования многозначной зависимости A -> -> B все остальные атрибуты R
функционально зависят от A.
В нашем примере можно произвести декомпозицию отношения ПРОЕКТЫ в два отношения
ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:
71
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН)
Оба эти отношения находятся в 4NF и свободны от отмеченных аномалий.
Во всех рассмотренных до этого момента нормализациях производилась декомпозиция одного
отношения в два. Иногда это сделать не удается, но возможна декомпозиция в большее число
отношений, каждое из которых обладает лучшими свойствами.
Пример 5.4 Рассмотрим, например, отношение
СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ (СОТР_НОМЕР, ОТД_НОМЕР, ПРО_НОМЕР)
Предположим, что один и тот же сотрудник может работать в нескольких отделах и работать в
каждом отделе над несколькими проектами. Первичным ключом этого отношения является полная
совокупность его атрибутов, отсутствуют функциональные и многозначные зависимости.
Поэтому отношение находится в 4NF. Однако в нем могут существовать аномалии, которые
можно устранить путем декомпозиции в три отношения.
Определение 12. Зависимость соединения
Отношение R (X, Y, ..., Z) удовлетворяет зависимости соединения * (X, Y, ..., Z) в том и только в
том случае, когда R восстанавливается без потерь путем соединения своих проекций на X, Y, ..., Z.
Определение 13. Пятая нормальная форма
Отношение R находится в пятой нормальной форме (нормальной форме проекции-соединения PJ/NF) в том и только в том случае, когда любая зависимость соединения в R следует из
существования некоторого возможного ключа в R.
Введем следующие имена составных атрибутов:
СО = {СОТР_НОМЕР, ОТД_НОМЕР}
СП = {СОТР_НОМЕР, ПРО_НОМЕР}
ОП = {ОТД_НОМЕР, ПРО_НОМЕР}
Предположим, что в отношении СОТРУДНИКИ-ОТДЕЛЫ-ПРОЕКТЫ существует зависимость
соединения:
* (СО, СП, ОП)
На примерах легко показать, что при вставках и удалениях кортежей могут возникнуть проблемы.
Их можно устранить путем декомпозиции исходного отношения в три новых отношения:
СОТРУДНИКИ-ОТДЕЛЫ (СОТР_НОМЕР, ОТД_НОМЕР)
СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР)
ОТДЕЛЫ-ПРОЕКТЫ (ОТД_НОМЕР, ПРО_НОМЕР)
Пятая нормальная форма - это последняя нормальная форма, которую можно получить путем
декомпозиции. Ее условия достаточно нетривиальны, и на практике 5NF не используется.
Заметим, что зависимость соединения является обобщением как многозначной зависимости, так и
функциональной зависимости.
Замечание. Если отношения не нормализованы,
то возникает проблемы избыточности,
потенциальной противоречивости (аномалии обновления), аномалии включения, аномалии
удаления.
5.2 Проектирование реляционных БД с использованием семантических моделей
5.2.1 Применение семантических моделей при проектировании
Широкое распространение реляционных СУБД и их использование в самых разнообразных
приложениях показывает, что реляционная модель данных достаточна для моделирования
предметных областей. Однако проектирование реляционной базы данных в терминах отношений
на основе механизма нормализации часто представляет собой очень сложный и неудобный для
проектировщика процесс.
При этом проявляется ограниченность реляционной модели данных в следующих аспектах:
 Модель не предоставляет достаточных средств для представления смысла данных. Семантика
реальной предметной области должна независимым от модели способом представляться в
голове проектировщика.
 Для многих приложений трудно моделировать предметную область на основе плоских таблиц.
В ряде случаев на самой начальной стадии проектирования проектировщику приходится
72
производить насилие над собой, чтобы описать предметную область в виде одной (возможно,
даже ненормализованной) таблицы.
 Хотя весь процесс проектирования происходит на основе учета зависимостей, реляционная
модель не предоставляет каких-либо средств для представления этих зависимостей.
 Несмотря на то, что процесс проектирования начинается с выделения некоторых
существенных для приложения объектов предметной области («сущностей») и выявления
связей между этими сущностями, реляционная модель данных не предлагает какого-либо
аппарата для разделения сущностей и связей.
Моделирование структуры базы данных при помощи алгоритма нормализации, описанного в п.5.1,
имеет серьезные недостатки:
1. Первоначальное размещение всех атрибутов в одном отношении является очень
неестественной операцией. Интуитивно разработчик сразу проектирует несколько отношений
в соответствии с обнаруженными сущностями.
2. Невозможно сразу определить полный список атрибутов. Пользователи имеют привычку
называть разными именами одни и те же вещи или, наоборот, называть одними именами
разные вещи.
3. Для проведения процедуры нормализации необходимо выделить зависимости атрибутов, что
тоже очень нелегко, т.к. необходимо явно выписать все зависимости, даже те, которые
являются очевидными
В реальном проектировании структуры базы данных применяются другой метод - так называемое,
семантическое моделирование. Семантическое моделирование представляет собой моделирование
структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического
моделирования используются различные варианты диаграмм сущность-связь (ER - EntityRelationship).
Первый вариант модели сущность-связь был предложен в 1976 г. Питером Пин-Шэн Ченом . В
дальнейшем многими авторами были разработаны свои варианты подобных моделей (нотация
Мартина, нотация IDEF1X, нотация Баркера и др.). Кроме того, различные программные средства,
реализующие одну и ту же нотацию, могут отличаться своими возможностями. По сути, все
варианты диаграмм сущность-связь исходят из одной идеи - рисунок всегда нагляднее текстового
описания. Все такие диаграммы используют графическое изображение сущностей предметной
области, их свойств (атрибутов), и взаимосвязей между сущностями.
Прежде, чем мы коротко рассмотрим особенности одной из распространенных семантических
моделей, остановимся на их возможных применениях:
1. Наиболее часто на практике семантическое моделирование используется на первой стадии
проектирования базы данных. При этом в терминах семантической модели производится
концептуальная схема базы данных, которая затем вручную преобразуется к реляционной (или
какой-либо другой) схеме. Этот процесс выполняется под управлением методик, в которых
достаточно четко оговорены все этапы такого преобразования.
2. Реализуется автоматизированная компиляция концептуальной CASE-схемы в реляционную.
При этом известны два подхода:
 на основе явного представления концептуальной схемы как исходной информации для
компилятора;
 построения интегрированных систем проектирования с автоматизированным созданием
концептуальной схемы на основе интервью с экспертами предметной области.
И в том, и в другом случае в результате производится реляционная схема БД в третьей
нормальной форме.
3. Работа с базой данных в семантической модели, т.е. СУБД, основанные на семантических
моделях данных. При этом снова рассматриваются два варианта:
 обеспечение пользовательского интерфейса на основе семантической модели данных с
автоматическим отображением конструкций в реляционную модель данных (это задача
примерно такого же уровня сложности, как автоматическая компиляция концептуальной
схемы базы данных в реляционную схему)
73

прямая реализация СУБД, основанная на какой-либо семантической модели данных. Наиболее
близко ко второму подходу находятся современные объектно-ориентированные СУБД, модели
данных которых по многим параметрам близки к семантическим моделям (хотя в некоторых
аспектах они более мощны, а в некоторых - более слабы).
5.2.2. Основные понятия модели Entity-Relationship
Опишем работу с ER-диаграммами близко к нотации Баркера, как довольно легкой в понимании
основных идей.
Определение 1. Сущность - это класс однотипных объектов, информация о которых должна быть
учтена в модели.
Каждая сущность должна иметь наименование, выраженное существительным в единственном
числе. Примерами сущностей могут быть такие классы объектов как «Поставщик», «Сотрудник»,
«Накладная».
Каждая сущность в модели изображается в виде прямоугольника с наименованием (рис.5.1).
Рисунок 5.1 Пример сущности
Определение 2. Экземпляр сущности - это конкретный представитель данной сущности.
Например, представителем сущности «Сотрудник» может быть «Сотрудник Иванов».
Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые
свойства, уникальные для каждого экземпляра этой сущности.
Определение 3. Атрибут сущности - это именованная характеристика, являющаяся некоторым
свойством сущности.
Наименование атрибута должно быть выражено существительным в единственном числе
(возможно, с характеризующими прилагательными). Примерами атрибутов сущности
«Сотрудник» могут быть такие атрибуты как «Табельный номер», «Фамилия», «Имя», «Отчество»,
«Должность», «Зарплата» и т.п.
Атрибуты изображаются в пределах прямоугольника, определяющего сущность (рис.5.2).
Рисунок 5.2 Пример сущности с указанием атрибутов
Определение 4. Ключ сущности - это неизбыточный набор атрибутов, значения которых в
совокупности являются уникальными для каждого экземпляра сущности. Неизбыточность
заключается в том, что удаление любого атрибута из ключа нарушается его уникальность.
Сущность может иметь несколько различных ключей.
Ключевые атрибуты изображаются на диаграмме подчеркиванием (рис.5.3).
Рисунок 5.3 Пример сущности с указанием ключа
74
Определение 5. Связь - это графически изображаемая ассоциация, устанавливаемая между двумя
сущностями. Эта ассоциация всегда является бинарной и может существовать между двумя
разными сущностями или между сущностью и ей же самой (рекурсивная связь).
Связи позволяют по одной сущности находить другие сущности, связанные с нею.
Например, связи между сущностями могут выражаться следующими фразами – «СОТРУДНИК
может иметь несколько ДЕТЕЙ», «каждый СОТРУДНИК обязан числиться ровно в одном
ОТДЕЛЕ».
Графически связь изображается линией, соединяющей две сущности (рис.5.4).
Рисунок 5.4 Пример связи двух сущностей
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в
неопределенной глагольной форме: "иметь", "принадлежать" и т.п. Каждое из наименований
относится к своему концу связи. Иногда наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи (рис.5.5.:
Рисунок 5.5 Графическое изображение типов связей
Связь типа один-к-одному означает, что один экземпляр первой сущности (левой) связан с одним
экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том,
что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с
несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип
связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много")
- дочерней. Характерный пример такой связи приведен на рис.5.4.
Связь типа много-ко-многим означает, что каждый экземпляр первой сущности может быть связан
с несколькими экземплярами второй сущности, и каждый экземпляр второй сущности может быть
связан с несколькими экземплярами первой сущности. Тип связи много-ко-многим является
временным типом связи, допустимым на ранних этапах разработки модели. В дальнейшем этот
тип связи должен быть заменен двумя связями типа один-ко-многим путем создания
промежуточной сущности.
Каждая связь может иметь одну из двух модальностей связи (рис.5.6).
Рисунок 5.6 Графическое изображение модальностей связи
Модальность «может» означает, что экземпляр одной сущности может быть связан с одним или
несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.
Модальность «должен» означает, что экземпляр одной сущности обязан быть связан не менее чем
с одним экземпляром другой сущности. Связь может иметь разную модальность с разных концов
(как на рис. 5.4).
Описанный графический синтаксис позволяет однозначно читать диаграммы, пользуясь
следующей схемой построения фраз:
75
<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ>
<ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.
Каждая связь может быть прочитана как слева направо, так и справа налево. Связь на рис. 5.4
читается так:
Слева направо: «каждый сотрудник может иметь несколько детей».
Справа налево: «Каждый ребенок обязан принадлежать ровно одному сотруднику».
Как и в реляционных схемах баз данных, в ER-схемах вводится понятие нормальных форм,
причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Заметим,
что формулировки нормальных форм ER-схем делают более понятным смысл нормализации
реляционных схем. Приведем только очень краткие и неформальные определения трех первых
нормальных форм.
В первой нормальной форме ER-схемы устраняются повторяющиеся атрибуты или группы
атрибутов, т.е. производится выявление неявных сущностей, «замаскированных» под атрибуты.
Во второй нормальной форме устраняются атрибуты, зависящие только от части уникального
идентификатора. Эта часть уникального идентификатора определяет отдельную сущность.
В третьей нормальной форме устраняются атрибуты, зависящие от атрибутов, не входящих в
уникальный идентификатор. Эти атрибуты являются основой отдельной сущности
5.2.3 Пример разработки простой ER-модели
При разработке ER-моделей мы должны получить следующую информацию о предметной
области:
1. Список сущностей предметной области.
2. Список атрибутов сущностей.
3. Описание взаимосвязей между сущностями.
ER-диаграммы удобны тем, что процесс выделения сущностей, атрибутов и связей является
итерационным. Разработав первый приближенный вариант диаграмм, мы уточняем их, опрашивая
экспертов предметной области. При этом документацией, в которой фиксируются результаты
бесед, являются сами ER-диаграммы.
Предположим, что перед нами стоит задача разработать информационную систему по заказу
некоторой оптовой торговой фирмы. В первую очередь мы должны изучить предметную область и
процессы, происходящие в ней. Для этого мы опрашиваем сотрудников фирмы, читаем
документацию, изучаем формы заказов, накладных и т.п.
Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что
проектируемая система должна выполнять следующие действия:
 Хранить информацию о покупателях.
 Печатать накладные на отпущенные товары.
 Следить за наличием товаров на складе.
Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на
сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком
вопроса):
 Покупатель - явный кандидат на сущность.
 Накладная - явный кандидат на сущность.
 Товар - явный кандидат на сущность
 (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет
кандидатом на новую сущность.
 (?)Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?
Сразу возникает очевидная связь между сущностями – «покупатели могут покупать много
товаров» и «товары могут продаваться многим покупателям». Первый вариант диаграммы
выглядит так (рис.5.7).
76
Рисунок 5.7 Первый вариант диаграммы
Задав дополнительные вопросы менеджеру, мы выяснили, что фирма имеет несколько складов.
Причем, каждый товар может храниться на нескольких складах и быть проданным с любого
склада. Куда поместить сущности «Накладная» и «Склад» и с чем их связать? Как связаны эти
сущности между собой и с сущностями «Покупатель» и «Товар»? Пока известно, что:
 Покупатели покупают товары, получая при этом накладные, в которые внесены данные о
количестве и цене купленного товара.
 Каждый покупатель может получить несколько накладных.
 Каждая накладная обязана выписываться на одного покупателя.
 Каждая накладная обязана содержать несколько товаров (не бывает пустых накладных).
 Каждый товар, в свою очередь, может быть продан нескольким покупателям путем
оформления нескольких накладных.
 Каждая накладная должна быть выписана с определенного склада, и с любого склада может
быть выписано много накладных.
Таким образом, после уточнения, диаграмма будет выглядеть следующим образом (рис.5.8).
Рисунок 5.8 Второй вариант диаграммы
Пора подумать об атрибутах сущностей. Беседуя с сотрудниками фирмы, мы выяснили
следующее:
 Каждый покупатель является юридическим лицом и имеет наименование, адрес, банковские
реквизиты.
 Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.
 Каждая накладная имеет уникальный номер, дату выписки, список товаров с количествами и
ценами, а также общую сумму накладной. Накладная выписывается с определенного склада и
на определенного покупателя.
 Каждый склад имеет свое наименование.
Снова выпишем все существительные, которые будут потенциальными атрибутами, и
проанализируем их:
 юридическое лицо - термин ненужный, т.к.фирма не работает с физическими лицами. Не
обращаем внимания;
77
наименование покупателя - явная характеристика покупателя;
адрес - явная характеристика покупателя;
банковские реквизиты - явная характеристика покупателя;
наименование товара - явная характеристика товара;
(?)цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от
цены в накладной?
 единица измерения - явная характеристика товара;
 номер накладной - явная уникальная характеристика накладной;
 дата накладной - явная характеристика накладной;
 (?)список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить
этот список в отдельную сущность;
 (?)количество товара в накладной - это явная характеристика, но характеристика чего? Это
характеристика не просто «товара», а «товара в накладной»;
 (?)цена товара в накладной - опять же это должна быть не просто характеристика товара, а
характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
 сумма накладной - явная характеристика накладной. Эта характеристика не является
независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную;
 наименование склада - явная характеристика склада.
В ходе дополнительной беседы с менеджером удалось прояснить различные понятия цен.
Оказалось, что каждый товар имеет некоторую текущую цену. Эта цена, по которой товар
продается в данный момент. Естественно, что эта цена может меняться со временем. Цена одного
и того же товара в разных накладных, выписанных в разное время, может быть различной. Таким
образом, имеется две цены - цена товара в накладной и текущая цена товара.
С возникающим понятием «Список товаров в накладной» все довольно ясно. Сущности
«Накладная» и «Товар» связаны друг с другом отношением типа много-ко-многим. Такая связь,
как мы отмечали ранее, должна быть расщеплена на две связи типа один-ко-многим. Для этого
требуется дополнительная сущность. Этой сущностью и будет сущность «Список товаров в
накладной». Связь ее с сущностями «Накладная» и «Товар» характеризуется следующими
фразами:
 каждая накладная обязана иметь несколько записей из списка товаров в накладной;
 каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную;
 каждый товар может включаться в несколько записей из списка товаров в накладной;
 каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром.
Атрибуты «Количество товара в накладной» и «Цена товара в накладной» являются атрибутами
сущности «Список товаров в накладной».
Точно также поступим со связью, соединяющей сущности «Склад» и «Товар». Введем
дополнительную сущность «Товар на складе». Атрибутом этой сущности будет «Количество
товара на складе». Таким образом, товар будет числиться на любом складе и количество его на
каждом складе будет свое.
Теперь можно внести все это в диаграмму «Оптовая фирма» (рис. 5.9).
Замечание. Утверждения, которые были сформулированы в ходе бесед с сотрудниками фирмы,
например: «Каждый покупатель может получить несколько накладных», являются бизнесправилами. Бизнес-правила описывают правила работы данной организации и для БД это, по сути,
ограничения целостности.





78
Рисунок 5.9 Диаграмма «Оптовая фирма»
Для построения логических моделей реляционных баз данных методом декомпозиции
сформулирован ряд правил, получивших название правила преобразования ER-диаграмм в
отношения базы данных. Правила позволяют исключить потенциальные недостатки метода
декомпозиции и нацелены на приведения схемы отношений базы данных к нормальным формам.
Правило 1. Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей является
обязательным, то требуется построение только одного отношения. При этом первичным ключом
отношения может быть ключ любой сущности.
Правило 2. Если степень бинарной связи 1:1 и класс принадлежности одной сущности является
обязательным, а другой сущности - не обязательным, то требуется построение двух отношений по одному на каждую сущность. При этом первичным ключом каждого отношения является ключ
его сущности, а ключ сущности с необязательным классом принадлежности добавляется в
отношение для сущности с обязательным классом принадлежности в качестве атрибута (миграция
ключа).
Правило 3. Если степень бинарной связи 1:1 и класс принадлежности обеих сущностей не является
обязательным, то требуется построение трех отношений - по одному на каждую объектную
сущность и одному для связывающего отношения. При этом ключ каждой сущности является
первичным ключом соответствующего отношения и одного отношения для связи, с первичным
ключом, составленным из ключей объектных сущностей.
Правило 4. Если степень бинарной связи 1:N, и класс принадлежности n-связной сущности
является обязательным, то достаточно построить два отношения - по одному на каждую сущность.
При этом ключ каждой сущности является первичным ключом соответствующего отношения, а
ключ 1-связной сущности добавляется в отношение для n-связной сущности в качестве атрибута.
Правило 5. Если степень бинарной связи 1:N и класс принадлежности n-связной сущности не
является обязательным, то необходимо построить три отношения - по одному на каждую
сущность. При этом ключ каждой сущности является первичным ключом соответствующего
отношения и одного отношения для связи. Ключи сущностей должны быть атрибутами
последнего отношения.
Правило 7. Если связь является трехсторонней, необходимо построить четыре отношения - по
одному на каждую сущность. При этом ключ каждой сущности является первичным ключом
79
соответствующего отношения и одного отношения для связи. Ключи сущностей должны быть
атрибутами последнего отношения.
Правило 8. Исходная сущность служит источником генерации одного отношения. Ключ сущности
есть ключ отношения. Подчиненные сущности (ролевые элементы) и связи, соединяющие их,
порождают такое количество отношений, которое определяется набором правил 1-7, причем
каждый ролевой элемент трактуется как обычная сущность.
5.3 Практические рекомендации по проектированию БД
Только небольшие организации могут обобществить данные в одной полностью
интегрированной базе данных. Чаще всего администратор баз данных (даже, если это группа лиц)
практически не в состоянии охватить и осмыслить все информационные требования сотрудников
организации (т.е. будущих пользователей системы). Поэтому информационные системы больших
организаций содержат несколько десятков БД, нередко распределенных между несколькими
взаимосвязанными ЭВМ различных подразделений.
Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких
прикладных задач, или данные, относящиеся к какой-либо предметной области (например,
финансам, студентам, преподавателям и т. п.). Первые обычно называют прикладными
(функциональными) БД, а вторые – предметными БД (соотносящимся с предметами организации,
а не с ее информационными приложениями).
Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений,
поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД.
Вследствие этого предметные БД создают основу для обработки неформализованных,
изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно
заранее определить требования к данным). Такая гибкость и адаптивность позволяет создавать на
основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых
большинство изменений можно осуществить без вынужденного переписывания старых
приложений.
Основывая же проектирование БД на текущих и предвидимых приложениях, можно
существенно ускорить создание высокоэффективной информационной системы, т.е. системы,
структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Поэтому
прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере
роста числа приложений таких информационных систем быстро увеличивается число прикладных
БД, резко возрастает уровень дублирования данных и повышается стоимость их ведения.
Таким образом, каждый из рассмотренных подходов к проектированию воздействует на
результаты проектирования в разных направлениях. Желание достичь и гибкости, и
эффективности привело к формированию методологии проектирования, использующей как
предметный, так и прикладной подходы. В общем случае предметный подход используется для
построения первоначальной информационной структуры, а прикладной – для ее
совершенствования с целью повышения эффективности обработки данных.
Основная цель проектирования БД – это сокращение избыточности хранимых данных, а
следовательно, экономия объема используемой памяти, уменьшение затрат на многократные
операции обновления избыточных копий и устранение возможности возникновения противоречий
из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, «чистый»
проект БД («Каждый факт в одном месте») можно создать, используя методологию нормализации
отношений. Использование строгой методологии нормализации часто заменяется применением
практических методик и правил. В [5]
предлагаются 4 фундаментальных правила для
проектирования БД с рациональной структурой:
I. В каждой таблице должен быть уникальный идентификатор (первичный ключ). Если это
правило не выполняется, то таблицу можно нормализовать, добавив столбец, уникально
идентифицирующий каждую строку.
II. В таблице должны храниться сведения лишь об одном типе объектов. Например, если в
таблице КНИГИ содержатся сведения о самих книгах (индекс_книги, название) и
80
издательствах (название, адрес), то это данные о двух типах объектов. Такое хранение
создает проблемы: если адрес издательства изменился, то коррективы придется вносить во
все записи о книгах, изданных данным издательством. Для нормализации следует разбить
таблицу КНИГИ на две: КНИГИ и ИЗДАТЕЛЬСТВА.
III. В таблице не должно быть списков значений для некоторой единицы информации.
Допустим, требуется учитывать названия и авторов книг в таблице КНИГИ. У книги может
быть несколько авторов. Можно, конечно, хранить список всех авторов в одном столбце, но
это затруднит обработку и поиск по отдельному автору. Другое решение – изменить
структуру таблицы и добавить еще один или два столбца Автор1, Автор2. А если авторов
три или больше? Если необходимо хранить список значений, следует предусмотреть
размещение дублирующих данных в другой таблице, связанной с главной. Для нашего
примера получаем таблицы: КНИГИ(индекс_книги, название), АВТОРЫ(код_автора,
ФИО), КНИГИ_АВТОРЫ(индекс_книги, код_автора). Такая структура позволяет описать
книгу с любым числом авторов без изменеия определения таблицы и не допускает наличия
пустых мест при сохранении книги с одним автором.
IV. В таблицах следует избегать столбцов, допускающих пустые значения.
Фундаментальные правила можно дополнить практическими рекомендации, которые
рекомендует Б. Послед [9]:
1. Предусмотреть возможность добавления таблиц, полей таким образом, чтобы не пришлось
все переделывать.
2. Нужно рационально распределить информацию по таблицам. Обычно вся информация
хранится в таблицах двух типов:
 базовые, содержащие записи об основных объектах и событиях ПО (накладные,
счета и т.д.)
 таблицы-справочники, элементы которых состоят из уникального номера и
описания, например справочник Товары может содержать следующие поля: номер
товара; наименование; единица измерения; категория и т.д.
3. Связать все базовые таблицы со справочниками.
4. По возможности использовать индексы. Это ускоряет сортировку и поиск информации.
5.4 Вопросы и упражнения для самоконтроля к главе 5
1. Что является исходной информацией на первом шаге процесса проектирования
классическим методом?
2. Какие нормальные формы вы знаете?
3. Приведение к какой нормальной форме считается достаточным для завершения процесса
нормализации?
4. К каким ситуациям может привести работа с ненормализованными таблицами?
5. В чем вы видите недостатки процесса проектирования с использованием принципов
нормализации?
6. Каково практическое применение семантических моделей?
Глава 6 Функции СУБД и системы обработки транзакций
6.1 Основные функции СУБД
К основным функция СУБД принято относить следующие:
1.Непосредственное управление данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней памяти как для хранения
данных, непосредственно входящих в БД, так и для служебных целей, например, для ускорения
доступа к данным в некоторых случаях (обычно для этого используются индексы). В некоторых
реализациях СУБД активно используются возможности существующих файловых систем, в
других работа производится вплоть до уровня устройств внешней памяти. Но подчеркнем, что в
развитых СУБД пользователи в любом случае не обязаны знать, использует ли СУБД файловую
систему, и если использует, то, как организованы файлы. В частности, СУБД поддерживает
собственную систему именования объектов БД.
81
2. Управление буферами оперативной памяти
СУБД обычно работают с БД значительного размера; этот размер чаще всего существенно больше
доступного объема оперативной памяти. При обращении к любому элементу данных во время
обмена с внешней памятью вся система будет работать со скоростью устройства внешней памяти.
Практически единственным способом реального увеличения этой скорости является буферизация
данных в оперативной памяти. При этом, даже если операционная система производит
общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД.
Поэтому в развитых СУБД поддерживается собственный набор буферов оперативной памяти с
собственной дисциплиной замены буферов.
Замечание. Существует отдельное направление СУБД, которое ориентировано на постоянное
присутствие в оперативной памяти всей БД. Это направление основывается на предположении,
что в будущем объем оперативной памяти компьютеров будет настолько велик, что позволит не
беспокоиться о буферизации.
3. Управление транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое.
Либо транзакция успешно выполняется, и СУБД фиксирует (COMMIT) изменения БД,
произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не
отражается на состоянии БД (см. п.4.6.2). Понятие транзакции необходимо для поддержания
логической целостности БД. Таким образом, поддержание механизма транзакций является
обязательным условием даже однопользовательских СУБД. Но понятие транзакции гораздо более
важно в многопользовательских СУБД.
То свойство, что каждая транзакция начинается при целостном состоянии БД и оставляет это
состояние целостным после своего завершения, делает очень удобным использование понятия
транзакции как единицы активности пользователя по отношению к БД. При соответствующем
управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из
пользователей может в принципе ощущать себя единственным пользователем СУБД.
С управлением транзакциями в многопользовательской СУБД связаны важные понятия
сериализации транзакций и сериального плана выполнения смеси транзакций (см. п.4.6.3).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД
наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД.
При использовании любого алгоритма сериализации возможны ситуации конфликтов между
двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания
сериализации необходимо выполнить откат (ликвидировать все изменения, произведенные в БД)
одной или более транзакций. Это один из случаев, когда пользователь многопользовательской
СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций
других пользователей.
4. Журнализация
Одним из основных требований к СУБД является надежность хранения данных во внешней
памяти.
Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить
последнее согласованное состояние БД после любого аппаратного или программного сбоя.
Обычно рассматриваются два возможных вида аппаратных сбоев:
 мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера
(например, аварийное выключение питания);
 жесткие сбои, характеризуемые потерей информации на носителях внешней памяти.
Примерами программных сбоев могут быть:
 аварийное завершение работы СУБД по причине ошибки в программе или в результате
некоторого аппаратного сбоя. Эту ситуацию можно рассматривать как особый вид мягкого
аппаратного сбоя;
 аварийное завершение пользовательской программы, в результате чего некоторая транзакция
остается незавершенной и требуется ликвидировать последствия только одной транзакции.
Поддержание надежности хранения данных в БД требует избыточности хранения данных, причем
та часть данных, которая используется для восстановления, должна храниться особо надежно.
82
Наиболее распространенным методом поддержания такой избыточной информации является
ведение журнала изменений БД.
Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой
тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных
физических дисках), в которую поступают записи обо всех изменениях основной части БД. В
разных СУБД изменения БД журнализуются на разных уровнях, запись в журнале может
соответствовать:
 некоторой логической операции изменения БД (например, операции удаления строки из таблицы
реляционной БД);
 минимальной внутренней операции модификации страницы внешней памяти;
 и то и другое (в некоторых системах одновременно используются оба подхода).
Во всех случаях придерживаются стратегии «упреждающей» записи в журнал (так называемого
протокола Write Ahead Log - WAL). Эта стратегия заключается в том, что запись об изменении
любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект
попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно
соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления
БД после любого сбоя. Рассмотрим различные ситуации при восстановлении:
- Индивидуальный откат транзакции (самая простая ситуация восстановления). Достаточно для
каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в
этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя
от конца локального журнала. Но в большинстве систем локальные журналы не поддерживают, а
индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи
от одной транзакции связывают обратным списком (от конца к началу).
- Мягкий сбой. При этом во внешней памяти основной части БД могут находиться объекты,
модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать
объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по
причине использования буферов оперативной памяти, содержимое которых при мягком сбое
пропадает). При соблюдении протокола WAL во внешней памяти журнала должны
гарантированно находиться записи, относящиеся к операциям модификации обоих видов
объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней
памяти основной части БД, которое возникло бы при фиксации во внешней памяти изменений
всех завершившихся транзакций и которое не содержало бы никаких следов незаконченных
транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций
(undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты
которых не отображены во внешней памяти.
-Жесткий сбой. Для восстановления БД после жесткого сбоя используют журнал и архивную
копию БД. Идеально, архивная копия - это полная копия БД к моменту начала заполнения
журнала (имеется много вариантов более гибкой трактовки смысла архивной копии). Конечно, для
нормального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. Как
уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо
повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии,
по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя.
5. Поддержка языков БД
Для работы с базами данных используются специальные языки, в целом называемые языками
баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям
языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition
Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил
главным образом для определения логической структуры БД, т.е. той структуры БД, какой она
представляется пользователям. DML содержал набор операторов манипулирования данными, т.е.
операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать
существующие данные.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий
все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый
83
пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных
в настоящее время реляционных СУБД является язык SQL (Structured Query Language). В качестве
языка DML используется также язык создания запросов по образцу (QBE - Query by Example).
Например, СУБД Access поддерживает SQL и QBE – создание запросов на выборку данных,
изменение, удаление с помощью конструктора.
Язык SQL сочетает средства SDL и DML, т.е. позволяет определять схему реляционной БД и
манипулировать данными. При этом именование объектов БД (для реляционной БД - именование
таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка
SQL производит преобразование имен объектов в их внутренние идентификаторы на основании
специально поддерживаемых служебных системных таблиц-каталогов. Системный каталог - это
набор таблиц, в которых содержится информация, необходимая для правильного
функционирования СУБД: о поддерживаемых базах данных и их базовых таблицах,
представлениях, курсорах, индексах, пользователях и их правах доступа к информации, правилах
модификации данных и т.д. В разных СУБД, поддерживающих SQL, существует от десятка до
нескольких десятков системных таблиц, структура которых ничем не отличается от уже знакомой
нам структуры пользовательских таблиц.
Так, в каждой строке системной таблицы SYSTABLES хранится описание одной из таблиц
пользовательских или системной баз данных. Для каждой из них указывается имя таблицы, имя
пользователя, который создал эту таблицу, число столбцов в ней и ряд других элементов
информации. В таблице SYSCOLUMNS содержится строка для каждого столбца каждой таблицы,
в которой указано имя столбца, имя таблицы, частью которой является данный столбец, тип
данных для этого столбца и много другой информации о столбце.
С помощью предложения SELECT пользователь может получить информацию из любой
системной таблицы. Например, он может дать запрос на получение имен таблиц, числа их
столбцов и строк, владельца и краткого описания (если таковое вводилось в базу данных):
SELECT Tab_name, N_col, N_row, Tab_owner, Comments
FROM SYSTABLES;
Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Опять
же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение
контроля целостности БД производится на языковом уровне, т.е. при компиляции операторов
модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности
генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять представления БД, фактически
являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является
таблица) с именованными столбцами. Для пользователя представление является такой же
таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно
ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание
представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на основе специального набора
операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида
пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД,
обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий
входит полномочие на передачу всех или части полномочий другим пользователям, включая
полномочие на передачу полномочий. Полномочия пользователей описываются в специальных
таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
6.2 Системы обработки транзакций
Среди фактографических информационных систем важное место занимают два класса:
системы оперативной обработки данных и системы, ориентированные на анализ данных и
поддержку принятия решений
6.2.1 OLTP-системы
Сильно нормализованные модели данных хорошо подходят для так называемых OLTPприложений (On-Line Transaction Processing - оперативная обработка транзакций). Типичными
84
примерами OLTP-приложений являются системы складского учета, системы заказов билетов,
банковские системы, выполняющие операции по переводу денег, системы отслеживания
компонентов во время сборки конечного продукта на производстве и т.п. Основная функция
подобных систем заключается в выполнении большого количества коротких транзакций. Сами
транзакции выглядят относительно просто, например, «снять сумму денег со счета А, добавить эту
сумму на счет В». Время ожидания типичных запросов в таких системах не должна превышать
нескольких секунд. Проблемы OLTP-систем заключается в том, что:
1) транзакций очень много;
2) выполняются они одновременно (к системе может быть подключено несколько тысяч
одновременно работающих пользователей);
3) при возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к
состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты
со счета А, но не поступили на счет В).
Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки,
обновления, удаления. Запросы на выборку в основном предназначены для предоставления
пользователям возможности выбора из различных справочников. Большая часть запросов, таким
образом, известна заранее еще на этапе проектирования системы. Пример запроса: «есть ли
свободные места в купе поезда Москва-Сочи, отправляющегося 20 августа в 23:15». Таким
образом, критическим для OLTP-приложений является скорость и надежность выполнения
коротких операций обновления данных. Чем выше уровень нормализации данных в OLTPприложении, тем оно, как правило, быстрее и надежнее. OLTP-системы требуют защиты от
несанкционированного доступа, от нарушения целостности, аппаратных и программных сбоев.
6.2.2 OLAP -системы
Другим типом приложений являются OLAP-приложения (On-Line Analitical Processing оперативная аналитическая обработка данных). Это обобщенный термин, характеризующий
принципы построения систем поддержки принятия решений (СППР) (Decision Support System DSS), хранилищ данных (Data Warehouse), систем интеллектуального анализа данных (Data
Mining). Такие системы предназначены для нахождения зависимостей между различными
данными. Приведем примеры запросов: «как связан объем продаж товаров с характеристиками
потенциальных покупателей»; «каким будет объем продаж железнодорожных билетов в
следующие 3 месяца с учетом сезонных колебаний»), для проведения анализа "что если…". OLAPприложения оперируют с большими массивами данных, уже накопленными в OLTP-приложениях,
взятыми из электронных таблиц или из других источников данных. Такие системы
характеризуются следующими признаками:
 Добавление в систему новых данных происходит относительно редко крупными блоками
(например, раз в квартал загружаются данные по итогам квартальных продаж из OLTPприложения).
 Данные, добавленные в систему, обычно никогда не удаляются.
 Перед загрузкой данные проходят различные процедуры «очистки», связанные с тем, что в одну
систему могут поступать данные из многих источников, имеющих различные форматы
представления для одних и тех же понятий, данные могут быть некорректны, ошибочны.
 Запросы к системе являются нерегламентированными и, как правило, достаточно сложными.
Очень часто новый запрос формулируется аналитиком для уточнения результата, полученного в
результате предыдущего запроса.
 Скорость выполнения запросов важна, но не критична.
Данные OLAP-приложений обычно представлены в виде одного или нескольких гиперкубов,
измерения которого представляют собой справочные данные, а в ячейках самого гиперкуба
хранятся собственно данные. Например, можно построить гиперкуб, измерениями которого
являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся
объемы продаж. Такой гиперкуб будет содержать данных о продажах различных типов товаров по
кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы вроде "у
какого подразделения самые лучшие объемы продаж в текущем году?", или "каковы тенденции
продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?"
85
Физически гиперкуб может быть построен на основе специальной многомерной модели данных
(MOLAP - Multidimensional OLAP) или построен средствами реляционной модели данных (ROLAP
- Relational OLAP).
Оперативность обработки больших объемов данных в системах OLAP достигается за счет
применения мощной многопроцессорной ВТ, сложных методов анализа и специальных хранилищ
данных, накапливающих информацию из разных источников за большой период времени и
обеспечивающих быстрый доступ к ней (Data Warehouse ). В большинстве случаев сложный
аналитический запрос невозможно сформулировать в терминах языка SQL, поэтому приходится
применять специализированные языки, ориентированные на аналитическую обработку данных. К
их числу можно отнести, например, язык Express 4GL (язык четвертого поколения - 4 Generation
Language фирмы.Oracle).
6.2.3 Мониторы транзакций
С ростом сложности распределенных вычислительных систем возникают проблемы
эффективного использования их ресурсов. Для решения этих проблем в состав распределенных
OLTP-систем вводят дополнительный компонент – монитор транзакций (TPM – Transaction
Processing Monitor). Мониторы транзакций выполняют две основные функции:
 динамическое распределение запросов в системе (выравнивание нагрузки);
 оптимизация числа выполняемых серверных приложений.
Кратко рассмотрим реализацию этих функций. Если в системе функционирует несколько
серверов, предоставляющих одинаковый сервис, например, доступ к БД, то для оптимизации
пропускной способности системы (числа обрабатываемых запросов в единицу времени)
необходимо добиться сбалансированной их загрузки. Необходимо обеспечить, чтобы на каждый
из серверов поступало примерно равное количество пользовательских запросов. При
распределении запросов может учитываться также удаленность серверов, их готовность,
содержимое запроса. Реализуется функция выравнивания нагрузки следующим образом (рис.6.1):
 запрос клиентского приложения поступает монитору транзакций, который определяет
получателя этого запроса. Для этого он обращается к динамической маршрутной таблице, по
которой определяет систему, предоставляющую соответствующий сервис;
 если таких систем несколько, то по соответствующему алгоритму выбирается одна из них, и ей
перенаправляется запрос клиентского приложения;
 результат выполнения запроса через монитор транзакций перенаправляется приложению,
пославшему запрос.
Сервер 1
Сервер 2
ответ
запрос
ответ
Монитор
транзакций
ответ
запрос
Клиентское
приложение
Рисунок 6.1 Упрощенная схема работы монитора транзакций
Клиентские приложения не знают, какой системе будут направлены их запросы, предлагается
ли нужный сервис одним или несколькими серверами, расположен ли нужный сервер локально,
86
удаленно, - в любом случае их запрос будет обработан оптимальным образом. Подобную схему
обработки запросов называют «прозрачность местонахождения серверов» (service location
transparency).
Скорость обработки транзакций напрямую зависит от числа запущенных серверных
приложений. Чем больше приложений одновременно обслуживают запросы, тем выше пропускная
способность вычислительной системы. В идеале для эффективного использования системных
ресурсов нужно по мере необходимости увеличивать или уменьшать число серверных
приложений в зависимости от числа обрабатываемых запросов. Для решения этой задачи
мониторы транзакций периодически измеряют отношение запросов в очереди к числу
работающих серверных приложений. Если это отношение превышает максимальное пороговое
значение, то запускается дополнительная копия серверного приложения. Если это отношение
падает ниже минимального порогового значения, то одна из копий завершается.
На рынке мониторов транзакций доступно довольно много программных продуктов: CICS фирмы
IBM; TUXEDO фирмы USL; ACSMS фирмы DEC; TOP END фирмы NCR.
Монитор транзакций CICS (Custom Information Control System), имеющий богатую историю, более
чем за 30 лет своего существования стал в своей области лидером. Именно программное
обеспечение промежуточного слоя является надежным хребтом для построения OLTP-систем.
Монитор транзакций — достаточно сложный продукт, который привносит функции контроля
целостности данных при выполнении операций. Сложная OLTP-система может иметь несколько
источников данных (СУБД, файлы и т.д.); монитор транзакций позволяет прикладной программе
работать с ними одновременно и изменять их состояние. При этом, если в рамках транзакции хотя
бы один источник данных не будет переведен в последующее состояние, то и остальные
источники будут возвращены в состояние до начала транзакции. Это гарантирует целостность
данных, предотвращает рассогласование данных в источниках. Такая служба отсутствует в
большинстве операционных систем. При этом источники данных могут быть как локальными, так
и распределенными, находясь на различных серверах и платформах. Если в системе используется
монитор транзакций, то со стороны разработчика не требуется ощутимых затрат для поддержки
функций контроля целостности на уровне прикладной логики.
Будучи реализован практически для всех основных платформ, CICS позволяет построить сложную
распределенную гетерогенную транзакционную среду. CICS использует интерфейс Применение
монитора транзакций делает систему более масштабируемой по сравнению решениями, «в центр»
которых помещена СУБД. Так, на базе стандартных редакций CICS можно строить системы с
пиковой производительностью 500 транзакций в секунду, а при помощи специальных версий
(например, ПО Transaction Processing Facility, применяемое в системах оперативного
резервирования авиабилетов) и с более высокими пиковыми нагрузками.
CICS поддерживает пять типов высокоуровневого взаимодействия между серверами, которые
могут быть организованы поверх любых сетевых протоколов (TCP/IP, SNA, NetBIOS и др.).
 Function Shipping (FS). Изменение источников данных (файлов), которые являются
удаленными по отношению к локальному серверу CICS. При обращении из транзакции на
локальном сервере CICS к такому источнику, он автоматически перенаправляет запрос к тому
серверу, который владеет этим источником данных. Обеспечивается целостность данных в
случае каких-либо сбоев.
 Transaction Routing (TR). Перенаправление вызова транзакции между серверами CICS. Можно
«переселять» транзакцию с сервера на сервер, при этом требуется лишь переопределить
ссылку на сервере CICS без изменения кода программы.
 Asynchronous Processing (AP). Асинхронный запуск транзакции на другом сервере CICS. Новая
транзакция начинает «жить» самостоятельно, а управление немедленно возвращается в
вызвавшую транзакцию.
 Distributed Program Link (DPL). Вызов удаленной транзакции с возвратом управления после
окончания работы вызванной транзакции. Этот тип взаимодействия в прикладных системах
используется наиболее часто.
 Distributed Transaction Processing (DTP). Диалог в оперативном режиме двух транзакций,
работающих на разных серверах CICS.
87
6.3 Архитектура СУБД
Обычно современная СУБД содержит следующие компоненты (рис. 6.2):
исполнения
Программа в
машинном коде
Ядро
СУБД
Процессор языка
запросов
Программа во
внутреннем коде СУБД
подсистема времени
Физическая БД
Рисунок 6.2 Схема СУБД
ядро (часто его называют Data Base Engine), которое отвечает за управление данными во
внешней и оперативной памяти и журнализации;
 процессор языка запросов (компилятор языка БД, обычно SQL), обеспечивающий
оптимизацию запросов на извлечение и изменение данных и создание машинно-независимого
внутреннего кода;
 подсистему поддержки времени выполнения, которая интерпретирует программы
манипуляции данными, создающие пользовательский интерфейс с СУБД;
 набор утилит.
В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение
можно провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами
оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно
выделить такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти
компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и
менеджер журнала. Функции этих компонентов взаимосвязаны, и для обеспечения корректной
работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и
проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным
пользователям напрямую и используемым в программах, производимых компилятором SQL (или в
подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является
основной резидентной частью СУБД. При использовании архитектуры «клиент-сервер» ядро
является основной составляющей серверной части системы.
Основной функцией компилятора языка БД является компиляция операторов языка БД в
некоторую выполняемую программу. Серьезной проблемой реляционных СУБД является то, что
языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в операторе такого
языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой,
а лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому
компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести
программу. Применяются достаточно сложные методы оптимизации операторов. Результатом
компиляции является выполняемая программа, представляемая в некоторых системах в машинных
кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем
случае реальное выполнение оператора производится с привлечением подсистемы поддержки
времени выполнения, представляющей собой, по сути дела, интерпретатор этого внутреннего
языка.
Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком
накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор
статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с

88
использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.
6.4 Администрация и пользователи БД
Централизованный
характер
управления
данными
вызывает
необходимость
администрирования базы данных как сложной системы. Поэтому особую роль играет
администрация базы или банка данных (АБД). Создание, функционирование и развитие БД
обеспечиваются администрацией базы, которая выполняет работы на протяжении всего
жизненного цикла системы. В состав АБД входят:
· системные аналитики;
· проектировщики структур данных и внешнего по отношению к БД информационного
обеспечения;
· проектировщики технологических процессов обработки данных;
· системные и прикладные программисты;
· операторы;
· специалисты по техническому обслуживанию;
· специалисты по маркетингу (для коммерческих БД).
В обязанности АБД входит выполнение следующих функций.
1. Анализ предметной области, ее описание, формулировка ограничений целостности,
определение потребностей и статуса пользователей.
2. Проектирование структуры БД: определение состава и структуры информационных
единиц БД, связей между ними.
3. Задание ограничений целостности при описании структуры БД и процедур обработки
данных.
4. Первоначальная загрузка и ведение БД: разработка технологии загрузки и ведения БД,
проектирование форм ввода, создание программных модулей.
5. Защита данных:
· обеспечение парольного входа в систему;
· определение прав доступа пользователей к данным;
· выбор и создание программно-технических средств защиты данных;
· тестирование средств защиты данных;
· сбор статистики об использовании данных;
· исследование случаев нарушения защиты данных;
· обеспечение восстановления БД, ведение системных журналов.
6. Анализ обращений пользователей к БД.
7. Работа с конечными пользователями.
8. Работа над совершенствованием и динамическим развитием БД
Главными потребителями информационного ресурса являются конечные пользователи, т.е.
специалисты, ведущие различные участки работы с БД. Их состав неоднороден, они различаются
по квалификации, степени профессионализма, уровню в системе управления и т. д. Так, главный
бухгалтер, бухгалтер, операционист, начальник кредитного отдела рассматриваются как
пользователи банковской информационной системы. Удовлетворение их информационной
потребности требует решения большого числа проблем организации БД.
Специальную группу пользователей БД образуют прикладные программисты. Их задача – создать
удобные пользовательские информационной системы.
1.
2.
3.
4.
5.
6.
7.
6.4 Вопросы и упражнения для самоконтроля по главе 6
Для чего СУБД использует журналы?
Какова последовательность действий по восстановлению БД при жестком сбое?
Что содержится в системных таблицах БД?
Какие требования предъявляются к OLTP-системам?
Как используются хранилища данных в OLAP-системах?
Каковы функции монитора транзакций?
Какие компоненты можно выделить в ядре СУБД?
89
8. Составьте перечень основных функциональных обязанностей администратора БД.
Глава 7 Технологии, модели и архитектура систем обработки данных
7.1 Технологии и модели архитектуры «клиент-сервер»
Потребность в данных коллективного пользования в последнее время все возрастает.
Выделим следующие основные понятия сетевой и распределенной обработки данных:
 распределенная обработка данных;
 базы данных с сетевым доступом;
 архитектура «клиент-сервер»;
 распределенные базы данных.
Параллельный доступ к одной БД нескольких пользователей, в том случае если БД
расположена на одной машине, соответствует режиму распределенного доступа к
централизованной БД и такая система называется системой распределенной обработки данных.
Если же БД распределена по нескольким компьютерам, расположенным в сети, и к ней возможен
параллельный доступ нескольких пользователей, то такая система называется системой
распределенных баз данных.
Системы БД с сетевым доступом построены с помощью сетевых версий СУБД на основе
оборудования и программного обеспечения локальных вычислительных сетей.
Модель взаимодействия компьютеров сети получила название архитектуры «клиент-сервер».
Каждый из составляющих эту архитектуру элементов играет свою роль: сервер владеет и
распоряжается информационными ресурсами системы (например, БД); клиент имеет возможность
пользоваться ими. Для современных СУБД архитектура «клиент-сервер» стала фактическим
стандартом.
Если предполагается, что проектируемая ИС будет иметь архитектуру «клиент-сервер», то
прикладные программы, реализованные в ее рамках, будут иметь распределенный характер, т.е.
часть функций будет реализована в программе-клиенте, а другая – в программе-сервере. Основной
принцип технологии «клиент-сервер» заключается в разделении функций стандартного
интерактивного приложения на четыре группы:
1. функции ввода и отображения данных;
2. прикладные функции, характерные для предметной области (например, открытие счета для
банковской системы);
3. фундаментальные функции хранения и управления информационными ресурсами (БД,
файловыми системами);
4. служебные функции, играющие роль связок между функциями первых трех групп.
Исходя из этого деления любое приложение может состоять из компонентов (таблица 7.1).
Таблица 7.1 – Связь между компонентами и функциями приложения
№
Функции
Логический компонент
1
Ввода и отображения данных
Компонент представления (КП)
2
Прикладные
Прикладной компонент (ПрК)
3
Хранения
и
управления Компонент доступа к ресурсам (КДР)
информационными ресурсами
Различия в реализациях технологии «клиент-сервер» определяются четырьмя факторами:
 тем, в какие виды программного обеспечения интегрированы каждый из этих компонентов;
 тем, какие механизмы программного обеспечения используются для реализации функций
первых 3 групп;
 как логические компоненты распределяются между компьютерами в сети;
 какие механизмы используются для связи компонентов между собой.
Выделяют четыре подхода, реализованных в моделях «клиент-сервер»:
 модель файлового сервера (File Server – FS);
 модель доступа к удаленным данным (Remote Data Access - RDA);
 модель сервера БД (Database Server – DBS );
 модель сервера приложений (Application Server - AS).
90
1.
FS- модель (модель файл-сервера)-базовая для локальных сетей персональных компьютеров.
Применялась для разработки ИС на основе СУБД FoxPro, Clipper, Paradox.
Файлы
Компонент
доступа к
ресурсам
Компонент
Прикладной
представления компонент
Клиент
Сервер
Рисунок 7.1 Модель файлового сервера
Технология: выделяется файл-сервер для хранения и обработки файлов других узлов сети, а в
остальных узлах функционирует приложение, в кодах которого совмещены компоненты
представления и прикладной (рис. 7.1). Запрос от приложения направляется на файловый сервер,
который передает требуемый файл данных на компьютер-клиент. Вся обработка осуществляется
на компьютере-клиенте. FS-модель послужила фундаментом для расширения возможностей
персональных компьютеров в направлении поддержки многопользовательского режима.
Недостатки: высокий сетевой трафик (передача множества файлов); небольшой спектр операций
манипулирования; отсутствие адекватных средств безопасности доступа к данным.
2 RDA-модель (модель удаленного доступа). Коды компонента представления и прикладного
совмещены и выполняются на компьютере-клиенте, а доступ к информационным ресурсам
обеспечивается операторами языка запросов SQL (рис. 7.2).
SQL-запросы
Компонент
Компонент Прикладной
доступа к
представления компонент
ресурсам
Данные
Клиент
Сервер
Рисунок 7.2 Модель доступа к удаленным данным
Технология: клиентский запрос направляется на сервер, где ядро СУБД обрабатывает запрос и
возвращает результат (набор данных) клиенту. Ядро СУБД играет пассивную роль, так как
инициатором манипуляций с данными являются программы на компьютере-клиенте.
Достоинства: уменьшается загрузка сети, так как по сети передаются запросы языке SQL;
унифицирован интерфейс «клиент-сервер» в виде языка SQL, который используется в качестве
стандарта общения клиента и сервера.
Недостатки: удовлетворительное администрирование приложений невозможно из-за совмещения
в одной программе различных по своей природе функций (представления и прикладных).
3 DBS-модель (модель сервера БД) – реализована в реляционных СУБД Informix, Oracle, Ingres.
Основой модели является механизм хранимых процедур – средство программирования SQLсервера (подробнее в п.7.3). Процедуры хранятся в словаре БД, разделяются между несколькими
клиентами и выполняются на компьютере, где функционирует SQL-сервер (рис. 7.3).
91
вызов
процедур
Компонент
представления
Прикладной
компонент
Компонент
доступа к
ресурсам
SQL
данные
Клиент
Сервер
Рисунок 7.3 Модель сервера баз данных
Технология: компонент представления выполняется на компьютере-клиенте, а прикладной
компонент и ядро СУБД на компьютере-сервере БД. Процедуры хранятся в словаре БД на SQLсервере и являются средством программирования SQL-сервера. Процедуры разделяются между
несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер.
Язык, на котором разрабатываются хранимые процедуры, является процедурным расширением
языка SQL и уникальным для каждой CУБД (например, PL/SQL для Oracle). В DBS-модели
компонент представления выполняется на компьютере-клиенте, в то время как прикладной
компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД,
там же находится и компонент доступа к данным, т е ядро СУБД.
Достоинства:
 возможность централизованного администрирования прикладных функций;
 снижение трафика, т. к. по сети отправляются вызовы хранимых процедур вместо SQLзапросов;
 возможность разделения процедур между несколькими приложениями;
 экономия ресурсов компьютера за счет использования один раз созданного плана выполнения
процедуры.
Недостатки: ограниченность языковых средств, используемых для написания хранимых
процедур. Процедурные расширения SQL не выдерживают никакого сравнения с
функциональными возможностями языков программирования высокого уровня и сфера их
использования ограничена конкретной СУБД.
На практике чаще используется разумный синтез RDA и DBS-моделей для построения
многопользовательских ИС. Поддержка целостности БД и некоторые простейшие прикладные
функции поддерживаются хранимыми процедурами (DBS- модель), а более сложные функции
реализуются в прикладной программе, которая выполняется на компьютере-клиенте (RDAмодель)
4 AS-модель (модель сервера приложения). В модели реализована трехзвенная схема разделения
функций (рис. 7.4), где прикладной компонент выделен как изолированный элемент приложения
и реализован как группа процессов, выполняющих прикладные функции, и называется сервером
приложения.
Технология: В этой модели компоненты приложения делятся между тремя исполнителями:
 на компьютере-клиенте выполняется процесс, отвечающий за интерфейс с пользователем; этот
процесс, обращаясь за выполнением услуг к прикладному компоненту, играет роль клиента
приложения;
 серверы приложений хранят и используют наиболее общие правила бизнес-логики,
поддерживают каталоги с данными, обеспечивают обмен сообщениями;
 серверы БД обеспечивают функции создания и ведения БД, поддерживают целостность БД и
выполняют другие функции СУБД.
Достоинства: эта модель обладает большей гибкостью, чем двухзвенные модели. Большая часть
бизнес-логики клиента в этой модели изолирована от возможностей встроенного SQL,
реализованного в конкретной СУБД, и может быть выполнена на стандартных языках
программирования. Это повышает переносимость и масштабируемость системы.
AS-модель является фундаментом для построения мониторов транзакций. Наиболее заметны
92
преимущества модели сервера приложений в тех случаях, когда клиенты выполняют сложные
аналитические расчеты над БД, которые относятся к области OLAP-приложений.
Компонент
представления
Клиент
запуск
процедур
Прикладной
компонент
данные
SQL
Сервер приложений
Рисунок 7.4 Модель сервера приложений
Компонент
доступа к
ресурсам
Сервер БД
7.2 Распределенная обработка данных
По мере роста БД, использование их в территориально разнесенных организациях приводит к
тому, что централизованная СУБД плохо справляется с ростом числа обрабатываемых транзакций.
Это приводит к снижению общей надежности и производительности системы при обработке
запросов пользователей.
В качестве возможного решения этих проблем предполагается децентрализация данных.
Децентрализация процессов обработки данных в ИС позволяет повысить общую
производительность системы вследствие распределения нагрузки по нескольким узлам обработки
(хотя и за счет снижения требований к целостности, непротиворечивости, безопасности данных).
Распределенная обработка данных позволяет разместить базу данных (или несколько баз) в
различных узлах компьютерной сети. Таким образом, каждый компонент базы данных
располагается по месту наличия техники и ее обработки. Например, при организации сети
филиалов какой-либо организационной структуры удобно обрабатывать данные в месте
расположения филиала. Распределение данных осуществляется по разным компьютерам в
условиях реализации вертикальных и горизонтальных связей для организаций со сложной
структурой.
В одной и той же системе одни данные могут быть централизованными, другие децентрализованными. Основная задача при проектировании распределенной БД - распределение
данных по сети. Способы решения этой задачи:
 в каждом узле сети хранится и используется собственная БД, однако хранимые в ней данные
доступны для других узлов сети;
 все данные распределенной БД полностью дублируются в каждом узле сети;
 хранимые в центральном узле данные, частично дублируются в тех периферийных узлах, в
которых они используются.
Под распределенной БД (Distributed DataBase - DDB) обычно подразумевают базу данных,
включающую фрагменты из нескольких баз данных, которые располагаются на различных узлах
сети компьютеров, и, возможно управляются различными СУБД. Распределенная база данных
выглядит с точки зрения пользователей и прикладных программ как обычная локальная база
данных. В этом смысле слово «распределенная» отражает способ организации базы данных, но не
внешнюю ее характеристику («распределенность» базы данных невидима извне). Примерами
СУБД, обеспечивающих распределенную обработку данных являются: R-Star, Distributed Ingres,
Oracle 7, Ingres/Star, CA-OpenIngres, Sybase, Informix-OnLine Dynamic Server.
Распределенная БД предполагает хранение и выполнение функций управления данными в
нескольких узлах и передачу данных между этими узлами в процессе выполнения запросов.
При построении систем распределенных обработки данных применяются две технологии:
1. Технология распределенной БД (Технология STAR), при которой фрагменты данных
расположены на разных узлах сети. Все изменения должны синхронно передаваться во все узлы.
Такая схема предъявляет жесткие требования к производительности и надежности каналов связи.
2. Технология тиражирования, при которой в каждом узле дублируются данные всех других
узлов, а передаются только операции изменения данных, а не сами данные как в технологии
STAR. Передача может быть асинхронной (неодновременной для разных узлов).
93
7.2.1
Аспекты сетевого взаимодействия
Традиционной и наиболее популярной является модель доступа к удаленным данным (RDAмодель). Рассмотрим ее более подробно. Имеется компьютер-клиент, на котором запускаются
программы переднего плана (в которых реализованы как функции интерфейса с пользователем,
так и прикладные функции). Этот компьютер, называемый локальным узлом (local node) соединен
в сети с компьютером, на котором выполняется сервер БД, и находится сама БД (обычно его
называют удаленным узлом – remote node). Все проблемы, возникающие при взаимодействии
клиента и сервера, должен решать специальный компонент СУБД, называемый
коммуникационным сервером (Communication Server, DBMS Server Net). Для поддержки
взаимодействия клиента и сервера он должен функционировать на удаленном узле; в то время на
локальном узле должна выполняться программа связи, взаимодействующая с коммуникационным
сервером (DBMS Client Net).
В основу взаимодействия клиентов и сервера БД положены 12 принципов, сформулированных К.
Дейтом и определяющих функциональные возможности современных СУБД и требования к ним
при сетевом взаимодействии и распределенной обработки данных:
1 Локальная автономия (local autonomy). Это качество означает, что управление данными на
каждом из узлов распределенной системы выполняется локально. БД, расположенная на одном
из узлов, является неотъемлемым компонентом распределенной системы. Будучи фрагментом
общего пространства данных, она, в то же время функционирует как полноценная локальная
база данных; управление ею выполняется локально и независимо от других узлов системы
1. Независимость узлов (no reliance on central site). В идеальной системе все узлы равноправны и
независимы, а расположенные на них базы являются равноправными поставщиками данных в
общее пространство данных. БД на каждом из узлов самодостаточна - она включает полный
собственный словарь данных и полностью защищена от несанкционированного доступа
3. Непрерывные операции (continuous operation). Это качество можно трактовать как возможность
непрерывного доступа к данным (известное «24 часа в сутки, семь дней в неделю») в рамках
DDB вне зависимости от их расположения и вне зависимости от операций, выполняемых на
локальных узлах. Это качество можно выразить лозунгом «данные доступны всегда, а
операции над ними выполняются непрерывно».
4 Прозрачность расположения (location independence). Это свойство означает полную
прозрачность расположения данных. Пользователь, обращающийся к DDB, ничего не должен
знать о реальном, физическом размещении данных в узлах информационной системы. Все
операции над данными выполняются без учета их местонахождения. Транспортировка
запросов к базам данных осуществляется встроенными системными средствами.
5. Прозрачная фрагментация (fragmentation independence). Это свойство трактуется как
возможность распределенного (то есть на различных узлах) размещения данных, логически
представляющих собой единое целое. Существует фрагментация двух типов: горизонтальная и
вертикальная. Первая означает хранение строк одной таблицы на различных узлах
(фактически, хранение строк одной логической таблицы в нескольких идентичных физических
таблицах на различных узлах). Вторая означает распределение столбцов логической таблицы
по
нескольким
узлам.
Пример 7.1 Рассмотрим пример, иллюстрирующий оба типа фрагментации. Имеется таблица
employee (emp_id, emp_name, phone), определенная в базе данных на узле в Фениксе. Имеется
точно такая же таблица, определенная в базе данных на узле в Денвере. Обе таблицы хранят
информацию о сотрудниках компании. Кроме того, в базе данных на узле в Далласе
определена таблица emp_salary (emp_id, salary). Тогда запрос «получить информацию о
сотрудниках компании» может быть сформулирован так:
SELECT * FROM employee@phoenix, employee@denver ORDER BY emp_id
В то же время запрос «получить информацию о заработной плате сотрудников компании»
будет выглядеть следующим образом:
SELECT employee.emp_id, emp_name, salary FROM employee@denver, employee@phoenix,
emp_salary@dallas
WHERE employee.emp_id= salary. emp_id ORDER BY emp_id
94
Прозрачное тиражирование (replication independence). Тиражирование данных - это
асинхронный (в общем случае) процесс переноса изменений объектов исходной базы данных в
базы, расположенные на других узлах распределенной системы. В данном контексте
прозрачность тиражирования означает возможность переноса изменений между базами данных
средствами, невидимыми пользователю распределенной системы. Данное свойство означает,
что тиражирование возможно и достигается внутрисистемными средствами.
7. Обработка распределенных запросов (distributed query processing). Это свойство DDB
трактуется как возможность выполнения операций выборки над распределенной базой данных,
сформулированных в рамках обычного запроса на языке SQL. То есть операцию выборки из
DDB можно сформулировать с помощью тех же языковых средств, что и операцию над
локальной базой данных.
Пример 7.2 SELECT customer.name, customer.address, order.number, order.date FROM
customer@london, order@paris WHERE customer.cust_number = order.cust_number
8. Обработка распределенных транзакций (distributed transaction processing). Это качество DDB
можно трактовать как возможность выполнения операций обновления распределенной БД
(INSERT, UPDATE, DELETE), не разрушающих целостность и согласованность данных. Эта
цель достигается применением двухфазового или двухфазного протокола фиксации транзакций
(two-phase commit protocol), ставшего фактическим стандартом обработки распределенных
транзакций. Его применение гарантирует согласованное изменение данных на нескольких
узлах в рамках распределенной (или, как ее еще называют, глобальной) транзакции.
9. Независимость от оборудования (hardware independence). Это свойство означает, что в
качестве узлов распределенной системы могут выступать компьютеры любых моделей и
производителей - от мэйнфреймов до ПК.
10. Независимость от операционных систем (operationg system independence). Это качество
вытекает из предыдущего и означает многообразие операционных систем, управляющих
узлами распределенной системы.
11. Прозрачность сети (network independence). Доступ к любым БД может осуществляться по
сети. Спектр поддерживаемых конкретной СУБД сетевых протоколов не должен быть
ограничением системы с распределенными базами данных. Данное качество формулируется
максимально широко - в распределенной системе возможны любые сетевые протоколы.
12. Независимость от СУБД (DBMS independence). Это качество означает, что в распределенной
системе могут мирно сосуществовать СУБД различных производителей, и возможны операции
поиска
и
обновления
в
базах
данных
различных
моделей
и
форматов.
Исходя из определения Дэйта, можно рассматривать DDB как слабосвязанную сетевую структуру,
узлы которой представляют собой локальные базы данных. Локальные базы данных автономны,
независимы и самоопределены; доступ к ним обеспечиваются СУБД, в общем случае от
различных поставщиков. Связи между узлами - это потоки тиражируемых данных. Топология
DDB варьируется в широком диапазоне - возможны варианты иерархии, структур типа "звезда" и
т.д. В целом топология DDB определяется географией информационной системы и
направленностью
потоков
тиражирования
данных.
Посмотрим, во что выливается некоторые наиболее важные свойства DDB, если рассматривать их
практически
В DDB поддержка целостности и согласованности данных, ввиду свойств 1-2, представляет собой
сложную проблему. Ее решение - синхронное и согласованное изменение данных в нескольких
локальных базах данных, составляющих DDB - достигается применением протокола двухфазной
фиксации транзакций. Если DDB однородна - то есть на всех узлах данные хранятся в формате
одной базы и на всех узлах функционирует одна и та же СУБД, то используется механизм
двухфазной фиксации транзакций данной СУБД. В случае же неоднородности DDB для
обеспечения согласованных изменений в нескольких базах данных используют менеджеры
распределенных транзакций. Если в DDB предусмотрено тиражирование данных, то это сразу
предъявляет дополнительные жесткие требования к дисциплине поддержки целостности данных
на узлах, куда направлены потоки тиражируемых данных. Проблема в том, что изменения в
6.
95
данных инициируются как локально - на данном узле - так и извне, посредством тиражирования.
Неизбежно возникают конфликты по изменениям, которые необходимо отслеживать и разрешать.
Прозрачность расположения в реальных продуктах должна поддерживаться соответствующими
механизмами. Разработчики СУБД придерживаются различных подходов.
Пример 7.3 Рассмотрим пример из Oracle. Допустим, что DDB включает локальную базу данных,
которая размещена на узле в Лондоне. Создадим вначале ссылку (database link), связав ее с
символическим именем (london_unix), транслируемым в IP-адрес узла в Лондоне.
CREATE PUBLIC DATABASE LINK london.com CONNECT TO london_unix USING oracle_user_ID;
Теперь мы можем явно обращаться к базе данных на этом узле, запрашивая, например, в операторе
SELECT таблицу, хранящуюся в этой базе:
SELECT customer.cust_name, order.order_date FROM customer@london.com, order WHERE
customer.cust_number = order.cust_number;
Очевидно, однако, что мы написали запрос, зависящий от расположения базы данных, поскольку
явно использовали в нем ссылку. Определим customer и customer@london.com как синонимы:
CREATE SYNONYM customer FOR customer@london.com;
и в результате можем написать полностью независимый от расположения базы данных запрос:
SELECT customer.cust_name, order.order_date FROM customer, order WHERE customer.cust_number =
order.cust_number
Задача решается с помощью оператора SQL CREATE SYNONYM, который позволяет создавать
новые имена для существующих таблиц. При этом оказывается возможным обращаться к другим
базам
данных
и
к
другим
компьютерам..
Во многих СУБД задача управления именами объектов DDB решается путем использования
глобального словаря данных, хранящего информацию о DDB: расположение данных, возможности
других СУБД (если используются шлюзы), сведения о скорости передачи по сети с различной
топологией и т.д.
Обработка распределенных запросов (Distributed Query -DQ) - задача, более сложная, нежели
обработка локальных и она требует интеллектуального решения с помощью особого компонента оптимизатора DQ.
Пример 7.4 Обратимся к базе данных, распределенной по двум узлам сети. Таблица Деталь
хранится на одном узле, таблица Поставщик - на другом. Размер первой таблицы - 10000 строк,
размер второй - 100 строк (множество деталей поставляется небольшим числом поставщиков).
Допустим, что выполняется запрос:
SELECT Деталь _имя, Поставщик _имя, Поставщик _адрес
FROM Деталь, Поставщик
WHERE Деталь. Поставщик _номер = Поставщик. Поставщик _номер;
Результирующая таблица представляет собой соединение таблиц Деталь и Поставщик, выполненное
по столбцу Деталь.Поставщик.номер (внешний ключ) и Поставщик. Поставщик.номер (первичный
ключ).
Данный запрос - распределенный, так как затрагивает таблицы, принадлежащие различным
локальным базам данных. Для его нормального выполнения необходимо иметь обе исходные
таблицы на одном узле. Следовательно, одна из таблиц должна быть передана по сети. Очевидно,
что это должна быть таблица меньшего размера, то есть таблица Поставщик. Следовательно,
оптимизатор DQ запросов должен учитывать:
 размер таблиц;
 статистику распределения данных по узлам;
 объем данных, передаваемых между узлами;
 скорость коммуникационных линий;
 структуры хранения данных;
 соотношение производительности процессоров на разных узлах и т.д.
От интеллекта оптимизатора DQ впрямую зависит скорость выполнения распределенных
запросов.
96
Важным качеством для DDB является межоперабельность, означающая две вещи. Во-первых, это качество, позволяющее обмениваться данными между БД различных поставщиков. Как,
например, тиражировать данные из базы данных Informix в Oracle и наоборот? Известно, что
штатные средства тиражирования в составе данной конкретной СУБД позволяют переносить
данные в однородную базу. Так, средствами CA-Ingres/Replicator можно тиражировать данные
только из Ingres в Ingres. Как быть в неоднородной DDB? Ответом стало появление продуктов,
выполняющих
тиражирование
между
разнородными
базами
данных.
Во-вторых, это возможность некоторого унифицированного доступа к данным в DDB из
приложения. Возможны как универсальные решения (стандарт ODBC), так и специализированные
подходы. Очевидный недостаток ODBC - недоступность для приложения многих полезных
механизмов каждой конкретной СУБД, поскольку они могут быть использованы в большинстве
случаев только через расширения SQL в диалекте языка данной СУБД, но в стандарте ODBC эти
расширения
не
поддерживаются.
Специальные подходы - это, например, использование шлюзов, позволяющее приложениям
оперировать над базами данных в «чужом» формате так, как будто это собственные базы данных.
Вообще, цель шлюза - организация доступа к унаследованным (legacy) БД и служит для решения
задач согласования форматов баз данных при переходе к какой-либо одной СУБД. Так, если
компания долгое время работала на СУБД IMS и затем решила перейти на Oracle, то ей очевидно
потребуется шлюз в IMS. Следовательно, шлюзы можно рассматривать как средство,
облегчающее миграцию, но не как универсальное средство межоперабельности в распределенной
системе.
7.2.2 Технология распределенной БД (технология STAR)
Системы распределенных БД состоят из набора узлов, связанных вместе коммуникационной
сетью, в которой:
1) каждый узел обладает собственной системой БД;
2) узлы работают согласованно, поэтому пользователь может получить доступ к данным на
любом узле сети, как будто все данные находятся на его собственном узле.
Пример 7.5 Пусть БД «Склад» расположена на узле «узел_1», а БД «Предприятие» на узле
«узел_2». В первой содержится таблицы Деталь, а во второй Поставщик. Пусть БД
«Номенклатура» должна включать таблицы Деталь и Поставщик, физически принадлежащие
различным БД. Логически она будет рассматриваться как нераспределенная БД. Следующие
операторы SQL устанавливают ссылки на таблицы локальных БД. Они включены в в описание
распределенной БД и передаются серверу БД.
REGISTER TABLE Деталь AS LINK WITH NODE=узел_1, DATABASE=Склад;
REGISTER TABLE Поставщик AS LINK WITH NODE=узел_2, DATABASE=Предприятие;
Таким образом, при описании распределенной БД «Номенклатура» явно задаются ссылки на
конкретные таблицы реально существующих БД, однако при работе с такой БД это физическое
распределение прозрачно для пользователя.
Наибольшую сложность при организации работы распределенной БД вызывает решение
следующих задач:
 управление именами в распределенной среде;
 оптимизация распределенных запросов;
 управления распределенными транзакциями.
Задачи рассмотрены выше в п. 7.2.1. Решение этих трех задач возложено на специальный
компонент СУБД – сервер распределенных баз данных (Distributed Database Server). Возможны
следующие варианты организации работы распределенной БД:
1) Если БД расположена на одном узле и прикладная программа выполняется там же, то не
требуется ни коммуникационный сервер, ни сервер распределенных БД.
2) Когда же прикладная программа выполняется на локальном узле, БД находится на удаленном
узле и там же выполняется сервер БД, то на удаленном узле необходим коммуникационный
сервер, а на локальном – сервисная коммуникационная программа.
97
3) Если же распределенная БД состоит из таблиц локальных БД, которые находятся на одном
узле, и там же функционирует сервер распределенной БД, и выполняется прикладная
программа, то коммуникационный сервер не нужен, так как нет взаимодействия по сети.
4) Если же локальные БД расположены на нескольких узлах, то для доступа к распределенной БД
необходим и сервер распределенной БД, и коммуникационный сервер
Главное требование технологии STAR - синхронное завершение транзакций одновременно
на нескольких узлах распределенной системы, то есть синхронная фиксация изменений в DDB.
Уязвимым местом этой технологии являются - жесткие требования к производительности и
надежности каналов связи. Если база данных распределена по нескольким территориально
удаленным узлам, объединенным медленными и ненадежными каналами связи, а число
одновременно работающих пользователей составляет сотни и выше, то вероятность того, что
распределенная транзакция будет зафиксирована в обозримом временном интервале, становится
чрезвычайно малой. В таких условиях (характерных, кстати, для большинства отечественных
организаций)
обработка
распределенных
данных
практически
невозможна.
7.2.3
Технология тиражирования данных
Принципиальная характеристика тиражирования (репликации) данных (Data Replication DR) заключается в отказе от физического распределения данных. Суть DR состоит в том, что
любая база данных (как для СУБД, так и для работающих с ней пользователей) всегда является
локальной; данные размещаются локально на том узле сети, где они обрабатываются; все
транзакции в системе завершаются локально. DR – это набор технологий, который позволяет
поддерживать несколько копий одних и тех же данных на нескольких узлах.
Тиражирование данных - это асинхронный перенос изменений объектов исходной базы данных в
базы, принадлежащим различным узлам распределенной системы. Функции DR выполняет, как
правило, специальный модуль СУБД - сервер тиражирования данных, называемый репликатором
(так устроены СУБД CA-OpenIngres и Sybase). В Informix-OnLine Dynamic Server репликатор
встроен в сервер, в Oracle 7 для использования DR необходимо приобрести дополнительно к
Oracle7
DBMS
опцию
Replication
Option.
Специфика механизмов DR зависит от используемой СУБД. Простейший вариант DR использование «моментальных снимков» (snapshot).
Пример 7.6 Рассмотрим пример из Oracle:
CREATE SNAPSHOT unfilled_orders
REFRASH COMPLETE
START WITH TO_DATE ('DD-MON-YY HH23:MI:55')
NEXT SYSDATE + 7
AS SELECT customer_name, customer_address, order_date
FROM customer@paris, order@london
WHERE customer.cust_name = order.customer_number AND
order_complete_flag = "N";
«Моментальный снимок» в виде горизонтальной проекции объединения таблиц customer и order
будет выполнен в 23:55 и будет повторяться каждые 7 дней. Каждый раз будут выбираться только
завершенные
заказы.
Реальные схемы тиражирования, разумеется, устроены более сложно. В качестве базиса для
тиражирования выступает транзакция к базе данных. В то же время возможен перенос изменений
группами транзакций, периодически или в некоторый момент времени, что дает возможность
исследовать
состояние
принимающей
базы
на
определенный
момент
времени.
Детали тиражирования данных полностью скрыты от прикладной программы; ее
функционирование никак не зависят от работы репликатора, который целиком находится в
ведении администратора базы данных. Следовательно, для переноса программы в распределенную
среду с тиражируемыми данными не требуется ее модификации. В этом, собственно, состоит
качество
6
в
определении
Дэйта.
Технология распределенных БД и DR-технология - в определенном смысле антиподы. DR98
технология не требует синхронной фиксации изменений, и в этом ее сильная сторона. В
действительности далеко не во всех задачах требуется обеспечение идентичности БД на
различных узлах в любое время. Достаточно поддерживать тождественность данных лишь в
определенные критичные моменты времени. Можно накапливать изменения в данных в виде
транзакций в одном узле и периодически копировать эти изменения на другие узлы.
Преимуществами технологии тиражирования данных являются:
 данные всегда расположены там, где они обрабатываются - следовательно, скорость доступа к
ним существенно увеличивается;
 передача только операций, изменяющих данные (а не всех операций доступа к удаленным
данным), и к тому же в асинхронном режиме позволяет значительно уменьшить трафик;
 со стороны исходной базы для принимающих баз репликатор выступает как процесс,
инициированный одним пользователем, в то время как в физически распределенной среде с
каждым локальным сервером работают все пользователи распределенной системы,
конкурирующие за ресурсы друг с другом;
 никакой продолжительный сбой связи не в состоянии нарушить передачу изменений. Дело в
том, что тиражирование предполагает буферизацию потока изменений (транзакций); после
восстановления связи передача возобновляется с той транзакции, на которой тиражирование
было прервано.
DR-технология данных не лишена недостатков. Например, невозможно полностью исключить
конфликты между двумя версиями одной и той же записи. Он может возникнуть, когда вследствие
асинхронности два пользователя на разных узлах исправят одну и ту же запись в тот момент, пока
изменения в данных из первой базы данных еще не были перенесены во вторую. При
проектировании распределенной среды с использованием DR-технологии необходимо
предусмотреть конфликтные ситуации и запрограммировать репликатор на какой-либо вариант их
разрешения. Необходимо отметить, что при этой технологии предъявляются высокие требования
к аппаратным ресурсам узлов.
Технология тиражирования нашла применение там, где предъявляются повышенные требования к
надежности - в сфере банковских информационных систем.
7.3 Концепция активного сервера в модели DBS
Профессиональные СУБД обладают мощным активным сервером БД. Идея активного
интеллектуального сервера БД стала ответом на следующие задачи реальной жизни:
 БД должна отражать реальное состояние ПО, т е данные должны быть взаимно
непротиворечивыми;
 БД должна отражать правила, по которым ПО функционирует, – бизнес-правила;
 необходим постоянный контроль за состоянием БД, отслеживание всех изменений и
адекватная реакция на них (особенно для систем реального времени);
 необходимо, чтобы возникновение некоторой ситуации в БД четко и оперативно влияло на ход
выполнения прикладной программы;
 контроль типов данных
До недавнего времени функции управления знаниями о ПО оставались за границами
возможностей реляционных СУБД или были очень ограничены. Традиционно рассмотренные
выше задачи решались следующим образом:
 правила были заложены в прикладной программе. При их изменении (а в экономических ИС
они меняются довольно часто) приходилось переписывать программу;
 задачи контроля за состоянием БД и уведомлением прикладных программ обо всех
происходящих в ней событиях опирается на механизмы опроса прикладными программами БД
через определенные интервалы времени.
 синхронизация работы нескольких прикладных программ обеспечивается средствами
многозадачной ОС;
 ограничение на типы данных преодолевалось путем приведения данных новых типов к
стандартным.
99
Итак, в традиционной технологии решение задач, о которых речь шла выше, целиком ложится на
прикладные программы. Сервер БД при этом играет пассивную роль:
a) сервер БД лишен функций хранений и обработки знаний о предметной области;
b) за границами сервера остается контроль за состоянием БД и программирование реакции на ее
изменения;
c) пассивный сервер не имеет средств отслеживания событий в БД, а также средств воздействия
на работу прикладных программ и возможностей их синхронизации.
Идеи, реализованные в некоторых СУБД третьего поколения, заключаются в том, что знания
выносятся за рамки прикладных программ и оформляются как объекты БД. Функции применения
знаний начинает выполнять непосредственно сервер БД. Такая концепция активного сервера
опирается на четыре «столпа»:
1. процедуры БД;
2. правила (триггеры);
3. события в БД;
4. типы данных, определяемые пользователем прикладных программ.
Хранимые (stored, присоединяемые, разделяемые) процедуры - это процедуры и функции,
хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут
запускаться пользователями или приложениями, работающими с базой данных. Выполняемый или
интерпретируемый код хранимой процедуры сохраняется в базе данных, а сама она может быть
вызвана из любой прикладной программы авторизованного пользователя (того, кто получил
привилегию на выполнение этой процедуры) с указанием фактических параметров (рисунок 7.5).
Хранимые процедуры обычно пишутся либо на специальном процедурном расширении языка SQL
(например, PL/SQL для ORACLE или Transact-SQL для MS SQL Server), или на некотором
универсальном языке программирования, например, C++, с включением в код операторов SQL в
соответствии со специальными правилами такого включения. Основное назначение хранимых
процедур - реализация бизнес-процессов предметной области. Использование процедур БД
преследует четыре цели:
1. обеспечение независимого уровня централизованного контроля доступа к данным,
осуществляемого администратором БД;
2. одна процедура может быть использована несколькими прикладными программами;
3. значительное снижение трафика сети с архитектурой «клиент-сервер» за счет вызова
процедур, а не пересылки запросов.
4. процедуры БД в сочетании с правилами предоставляют администратору мощные средства
поддержки целостности БД.
Пример 7.7 Разработать процедуру, которая переводила бы рядового сотрудника в резерв на
выдвижение на руководящую должность:
CREATE PROCEDURE Назначение (Номер_сотр integer not null) AS
BEGIN
INSERT INTO Резерв SELECT * FROM Сотрудник WHERE номер= Номер_сотр;
DELETE FROM Сотрудник WHERE номер= Номер_сотр;
END
Вызов процедуры осуществляется с помощью команды EXECUTE …,например:
EXECUTE PROCEDURE Назначение (115)
100
Рисунок. 7.5. Подготовка и использование хранимой процедуры
Триггеры - это хранимые процедуры без параметров, связанные с некоторыми событиями,
происходящими во время работы базы данных. В качестве таких событий выступают операции
вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то
он запускается автоматически всегда при возникновении события, с которым этот триггер связан.
Очень важным является то, что пользователь не может обойти триггер. Триггер срабатывает
независимо от того, кто из пользователей и каким способом инициировал событие, вызвавшее запуск
триггера. Таким образом, основное назначение триггеров - автоматическая поддержка целостности
базы данных. Кроме поддержки целостности БД, триггеры позволяют решать следующие задачи:
 расчет промежуточных результатов и других вычисляемых значений;
 создание записей аудита для обеспечения безопасности или просто отслеживания операций,
выполняемых над таблицей;
 вызов внешних действий, например, процедуры для посылки почтового сообщения при
срабатывании триггера;
 реализация сложной защиты целостности данных.
Триггеры могут быть как достаточно простыми, например, поддерживающими ссылочную
целостность, так и довольно сложными, реализующими какие-либо сложные ограничения предметной
области или сложные действия, которые должны произойти при наступлении некоторых событий.
Пример 7.8 Например, с операцией вставки нового товара в накладную может быть связан триггер,
который выполняет следующие действия - проверяет, есть ли необходимое количество товара на
складе, при наличии товара добавляет его в накладную и уменьшает данные о наличии товара на
складе, при отсутствии товара формирует заказ на поставку недостающего товара и тут же посылает
заказ по электронной почте поставщику
Укажем основные цели механизма правил:
1. отражение некоторых внешних правил деятельности организации;
Пример 7.9 Одно из правил деятельности завода заключается в том, что недопустима ситуация, когда
на складе количество деталей любого типа становится меньше 1000. Это требование описывается
правилом:
CREATE RULE Проверить_деталь
AFTER UPDATE (количество) OF Деталь WHERE деталь.количество<1000
EXECUTE PROCEDURE Заказать_деталь (Ном_дет=Деталь.ном, остаток=Деталь.количество);
2. обеспечение целостности БД, особенно целостности по ссылкам
101
Механизм событий в БД позволяет прикладным программам и серверу БД уведомлять другие
программы о наступлении в БД определенного события и тем самым синхронизировать их работу.
Операторы языка SQL, которые обеспечивают уведомление, называются сигнализаторами событий
в БД database event alerters). Функции управления событиями целиком ложатся на сервер БД.
Различные прикладные программы и процедуры вызывают события, а сервер оповещает монитор
прикладных программ об их наступлении. Реакция монитора на событие заключается в выполнении
действий, которые предусмотрел разработчик.
Механизм событий используется следующим образом:
1. вначале в БД для каждого события создается флажок, состояние которого будет оповещать
прикладные программы о том, что некоторое событие имело место (оператор CREATE DBEVENT –
создать событие);
2. во все прикладные программы, на ход которых может повлиять это событие, включается оператор
REGISTER DBEVENT (зарегистрировать событие), который оповещает сервер БД, что данная
программа заинтересована в получении сообщения о наступлении события.
3. любая прикладная программа или процедура теперь может вызвать событие оператором RAISE
DBEVENT;
4. каждая зарегистрированная программа может получить информацию о событии, для чего должна
запросить очередное сообщение из очереди событий оператором GET DBEVENT (получить событие).
Типы данных, определяемые пользователем. Проблемы с типами данных решаются за счет
интеграции в сервер новых типов данных. Например, СУБД Ingres предоставляет программисту
возможность определять собственные типы данных и операции над ними и использовать их в
операторах SQL. Для этого надо написать и откомпилировать функции на языке С. Введение новых
типов данных является по сути изменением ядра СУБД. В Ingres типы данных, определяемые
пользователем могут быть параметризированы. Определение нового типа данных сводится к
указанию его нового имени, размера и идентификатора в глобальной структуре, описывающей типы
данных. Чтобы с новым типом данных можно было использовать функции, которые реализуют
стандартные операции (сравнение, преобразование в различные форматы и т.д.) программист должен
их разработать самостоятельно (интерфейс функций предопределен). Указатели на эти функции
являются элементами глобальной структуры. Как только новый тип определен, то все операции
выполняются над ним как над данными стандартного типа. Разрешение пользователю создавать свои
типы данных – это один из шагов развития реляционных СУБД в направлении объектнореляционных систем.
7.4 Вопросы и упражнения для самоконтроля к главе 7
1) Какие факторы влияют на реализацию технологии «клиент-сервер»?
2) Какой спектр операций манипулирования данными используется в модели файлового сервера?
3) Что означает пассивная роль сервера БД в модели доступа к удаленным данным?
4) Какие ограничения языка SQL можно отнести к недостаткам модели сервера приложений?
5) Как распределены роли клиента и сервера в модели сервера приложений?
6) Какие технологии используются при построении систем распределенных обработки данных?
7) Как реализуется выполнение требования прозрачности расположения данных?
8) Что такое фрагментация? Назовите ее типы?
9) Какие параметры учитываются при оптимизации распределенных запросов?
10) Составьте сравнительные характеристики технологий распределенных обработки данных?
11) Для чего нужны хранимые процедуры?
12) В каких случаях должны срабатывать триггеры?
Литература
1. Дейт К. Введение в системы баз данных, 6-е издание.– М.: Издательский дом «Вильямс»,
1999.
2. Базы данных: модели, разработка, реализация / Карпова Т.С. – СПб.: Питер, 2002.
102
3. Грабер М. Введение в SQL /пер. с англ.. – М. : Мир,1998.
4. Пушников А.Ю. Введение в системы управления базами данных. Часть 1. Реляционная
модель данных: Учебное пособие. - Уфа: Изд-е Башкирского ун-та. -, 1999. - 108 с. - ISBN
5-7477-0350-1.
5. Проектирование и реализация баз данных Microsoft SQL Server 2000. Учебный курс
MCSE/Пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2001. – 704 стр.:
ил. ISBN 5-7502-0149-X.
6. Пушников А.Ю. Введение в системы управления базами данных. Часть 2. Нормальные
формы отношений и транзакции: Учебное пособи. - Уфа: Изд-е Башкирского ун-та, 1999. 138 с. - ISBN 5-7477-0351-X.
7. С.Д. Кузнецов. Основы современных баз данных / Информационно-аналитические
материалы
/Центр
Информационных
технологий
МГУ,
<http://citforum.ru/database/osbd/contents.htm>
8. Корнеев В.В., Гареев А.Ф., Васютин С.В., Райх В.В. Базы данных. Интеллектуальная
обработка информации. - М.: «Нолидж», 2000.
9. Послед Б.С. Access 2000. Базы данных и приложения. Лекции и упражнения. – К.:
Издательство «ДиаСофт», 2000.
10. Лебедева Т.Ф. Лабораторный практикум по работе с базами данных в среде СУБД
ACCESS: Учебное пособие. – Кемерово: КемИ РГТЭУ, 2002.
11. Гудов А.М., Шмакова Л.Е. Введение в язык структурированных запросов SQL / Учебное
пособие. – Кемерово: КемГУ, 2001.
103