М. П. Малыхина

Базы

данных:

ОСНОВЫ, ПРОЕКТИРОВАНИЕ,
ИСПОЛЬЗОВАНИЕ
2-е издание

Допущено Министерством образования и науки Российской Федерации
в качестве учебного пособия для студентов высших учебных заведений,
обучающихся по направлению подготовки "Информатика и вычислительная
техника "

Санкт-Петербург
«БХВ-Петербург»

УДК 681.3.06
ББК 32.973.26-018.2
М20

Малыхина М. П.
М20

Базы данных: основы, проецирование, использование, 2-е изд. перераб.
и доп. — СПб.: БХВ-Петербург, 2006. — 528 с.: ил.
ISBN 5-94157-941-1
В простой и доступной форме рассказывается об основных концепциях про­
ектирования и построения баз данных, а также проблемах администрирования
и безопасности использования баз данных. Подробно описываются архитектуры
современных СУБД и модели данных (особое внимание уделяется реляционной
модели), рассматриваются вопросы последовательной нормализации отноше­
ний, преобразования концептуальной модели в реляционную и дается описание
языков запросов — SQL и QBE, а также новых технологий баз данных. К каж­
дой главе даны контрольные вопросы и упражнения.

,

Д ля широкого круга читателей интересующихся разработкой
и проектированием баз данных

УДК 681.3.06
ББК 32.973.26-018.2

Группа подготовки издания:
Главный редактор
Зам. главного редактора
Зав. редакцией
Редакторы:
Компьютерная верстка
Корректоры:
Дизайн серии
Оформление обложки
Зав. производством

Екатерина Кондукова
Татьяна Лапина
Григорий Добин
Ирина Радченко
Екатерина Капалыгина
Натальи Караваевой
Елена Самсонович
Наталия Першакова
Игоря Цырульникова
Елены Беляевой
Николай Тверских

П щ енэия ИД № 02429 от 24.07.00. Подписано в печать 12.05.00.
Ф ормат 70x10071в. Печать офсетная. Уел. печ. л. 42,57.
Тираж 2000 экз. Заказ Ne 3303
“БХВ-Петербург", 194354, Санкт-Петербург, ул. Есенина, 5Б.
Санитарно-эпидемиологическое заключение на продукцию
No 77.99.02.953.Д.006421.11.04 от 11.11.2004 г. выдано Федеральной службой
по надзору в сф ере защиты прав потребителей и благополучия человека.
Отпечатано с готовых диапозитивов
в ГУП Типограф ия "Наука"
199034, Санкт-Петербург, 9 линия, 12

ISBN 5-94157-941-1

О Малыхина М. П., 2006
О Оформление, издательство "БХВ-Петербург", 2006

Оглавление

Предисловие..............................................................................................................1
ЧАСТЬ I. БАЗЫ ДАННЫХ: ОСНОВНЫЕ ПОНЯТИЯ.................................... 5
Глава 1. Введение в базы данных.......................................................................... 7
1.1. Определения.................................................................................................. 7
1.2. Развитие технологий обработки данных....................................................9
1.3. Современное состояние технологий баз данных.................................... 18
1.4. Базы данных................................................................................................ 20
1.5. Системы управления базами данных....................................................... 25
1.6. Компоненты среды СУБД............................
27
1.7. СУБД — это хорошо или плохо?.............................................................. 30
Вопросы и упражнения..................................................................................... 32
Глава 2. Архитектура СУБД................................................................................. 33
2.1. Трехуровневая архитектура описания базы данных...............................33
2.1.1. Внешний уровень................................................................................. 36
2.1.2. Концептуальный уровень.................................................................... 36
2.1.3. Внутренний уровень............................................................................. 37
2.2. Функции СУБД........................................................................................... 38
2.2.1. Управление данными во внешней памяти........................................39
2.2.2. Управление транзакциями.................................................................. 39
2.2.3. Восстановление базы данных............................................................. 39
2.2.4. Поддержка языков БД ......................................................................... 40
2.2.5. Словарь данных.................................................................................... 40
2.2.6. Управление параллельным доступом.................................................41
2.2.7. Управление буферами оперативной памяти.....................................41
2.2.8. Контроль доступа к данным............................................................... 41
2.2.9. Поддержка обмена данными...............................................................42

2.2.10. Поддержка целостности данных.......................................................42
2.2.11. Поддержка независимости отданных.............................................43
2.2.12. Вспомогательные функции...............................................................43
2.3. Типовая организация современной СУБД..............................................43
2.4. Языки баз данных....................................................................................... 45
2.4.1. Язык определения данных.................................................................. 46
2.4.2. Языки манипулирования данными....................................................47
2.5. Архитектура многопользовательских СУБД............................................50
2.5.1. Тенденции развития многопользовательских систем......................50
2.5.2. Модели двухуровневой технологии "клиент — сервер"...................53
2.5.3. Сервер приложений. Трехуровневая модель.....................................60
Вопросы и упражнения..................................................................................... 61
ЧАСТЬ II. ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ..............................................
Глава 3. Концепции проектирования.................................................................. ..
3.1. Жизненный цикл БД.................................................................................. 66
3.1.1. Планирование разработки базы данных............................................ 67
3.1.2. Определение требований к системе................................................... 68
3.1.3. Сбор и анализ требований пользователей.........................................68
3.1.4. Проектирование базы данных............................................................ 69
3.1.5. Разработка приложений.......................................................................
3.1.6. Реализация..............................................................................................
3.1.7. Загрузка данных......................................................................................
3.1.8. Тестирование..........................................................................................
3.1.9. Эксплуатация и сопровождение...........................................................
3.2. Концептуальное проектирование...............................................................
3.2.1. Фундаментальные понятия................................................................. 79
3.2.2. Объекты..................................................................................................
3.2.3. Атрибуты................................................................................................ 81
3.2.4. Ключи.................................................................................................... 83
3.2.5. Связи между объектами....................................................................... 84
3.2.6. Составные объекты.............................................................................102
Вопросы и упражнения....................................................................................Ю6
Глава 4. Модели данных..................................................................................... Ю8
4.1. Классификация моделей данных...........................................................Ю9
4.1.1. Объектные модели данных.................................................................Ю9
4.1.2. Модели данных на основе записей.................................................. Ю9

4.1.3. Физическая модель данных............................................................. ПО
4.2. Сетевая модель...........................................................................................111
4.2.1. Структуры данных сетевой модели.................................................. 112
4.2.2. Сетевой граф БД..................................................................................114
4.2.3. Преобразование концептуальной модели в сетевую...................... 115
4.2.4. Реализация наборов............................................................................118
4.2.5. Управляющая часть сетевой модели................................................ 119
4.3. Иерархическая модель данных.................................................................121
4.3.1. Структурная часть иерархической модели...................................... 121
4.3.2. Преобразование концептуальной модели
в иерархическую модель данных...................................................... 123
4.3.3. Управляющая часть иерархической модели.................................... 127
4.3.4. Ограничения целостности................................................................. 128
4.4. Достоинства и недостатки ранних СУБД.............................................. 129
Вопросы и упражнения.....................................................................................129
Глава 5. Реляционная модель данных............................................................... 130
5.1. История вопроса........................................................................................130
5.2. Структурная часть реляционной модели....................................
135
5.2.1. Реляционное отношение....................................................................135
5.2.2. Свойства и виды отношений.............................................................138
5.2.3. Реляционные ключи.......................................................................... 139
5.2.4. Обновление отношений......................................................................146
5.3. Целостность базы данных........................................................................ 147
Итоги.................................................................................................................. 150
Вопросы и упражнения....................................................................................151
Глава 6. Проектирование базы данных............................................................. 152
6.1. Последовательная нормализация............................................................ 153
6.1.1. Избыточность данных в Б Д .............................................................. 154
6.1.2. Аномалии обновления в базе данных.............................................. 155
6.1.3. Процесс нормализации...................................................................... 159
6.2. Проектирование реляционной базы данных......................................... 184
6.2.1. Логическое проектирование реляционной БД ............................... 186
6.2.2. Упрощение концептуальной модели данных.................................. 186
6.2.3. Методика преобразования концептуальных структур данных
в реляционные структуры................................................................. 193
6.2.4. Проверка модели с помощью концепций
последовательной нормализации..................................................... 207

6.2.5. Проверка модели в отношении транзакций пользователей......... 207
6.2.6. Проверка поддержки целостности данных.....................................208
Вопросы и упражнения................................................................................... 208
Глава 7. Физическая организация данных.........................................................210
7.1. Технологии хранения данных в СУБД................................................... 210
7.1.1. Доступ к базе данных......................................................................... 212
7.1.2. Страничная организация данных в СУБД...................................... 212
7.1.3. Файловые структуры баз данных...................................................... 216
7.1.4. Хеширование....................................................................................... 218
7.1.5. Индексирование.........................................................................
221
7.1.6. Организация индексов в виде Б-деревьев....................................... 225
7.1.7. Моделирование отношений "один ко многим"..............................227
7.1.8. Инвертированные списки................................................................. 229
7.2. Технологии хранения данных в MS SQL Server....................................230
7.2.1. Формат страницы SQL Server........................................................... 231
Вопросы и упражнения................................................................................... 235
Глава 8. Управление реляционной базой данных............................................. 236
8.1. Реляционная алгебра................................................................................ 237
8.1.1. Основные операции реляционной алгебры.................................... 238
8.1.2. Дополнительные операции реляционной алгебры.........................243
8.2. Реляционное исчисление......................................................................... 248
8.2.1. Целевой список и определяющее выражение................................250
8.2.2. Формулы исчисления кортежей....................................................... 252
8.2.3. Квантор существования..................................................................... 254
8.2.4. Квантор всеобщности........................................................................ 256
Вопросы и упражнения................................................................................... 257
ЧАСТЬ III. ЯЗЫКИ БАЗ ДАННЫХ................................................................ 259
Глава 9. Язык SQL.............................................................................................. 261
9.1. Исторические аспекты развития SQL.................................................... 261
9.2. Структура и типы данных языка SQL.................................................... 263
9.3. Операторы языка SQL.............................................................................. 266
9.3.1. Оператор выбора SELECT. Формирование запросов
к базе данных...................................................................................... 269
9.3.2. Операторы манипулирования данными.......................................... 292
9.3.3. Операторы определения данных...................................................... 296

9.4. Встроенный SQL..................................................................................... 303
9.4.1. Однострочные запросы...................................................................... 304
9.4.2. Многострочные запросы................................................................... 304
Вопросы и упражнения................................................................................... 308
Глава 10. Язык запросов по образцу................................................................. 310
10.1. Создание запросов в MS Access............................................................ 311
10.2. Создание запросов на выборку............................................................. 313
10.2.1. Задание критериев отбора............................................................... 314
10.2.2. Многотабличные запросы............................................................... 315
10.2.3. Запросы с обобщением.................................................................... 316
10.2.4. Запросы с параметром..................................................................... 318
10.2.5. Перекрестные запросы.................................................................... 320
10.2.6. Запросы с автоподстановкой........................................................... 321
10.2.7. Другие запросы на выборку............................................................ 322
10.3. Активные запросы.................................................................................. 323
10.3.1. Создание таблиц............................................................................... 324
10.3.2. Удаление данных.............................................................................. 325
10.3.3. Обновление данных......................................................................... 326
10.3.4. Добавление записей......................................................................... 326
Вопросы и упражнения................................................................................... 327
ЧАСТЬ IV. ИСПОЛЬЗОВАНИЕ БАЗ ДАННЫХ...........................................329
Глава 11. Обеспечение функционирования баз данных...................................331
11.1. Управление транзакциями..................................................................... 331
11.1.1. Модель транзакции.......................................................................... 332
11.1.2. Свойства транзакции........................................................................ 333
11.1.3. Журнализация................................................................................... 334
11.1.4. Проблемы многопользовательских систем....................................338
11.1.5. Блокировка........................................................................................ 340
11.2. Триггеры................................................................................................... 350
11.2.1. Основные сведения.......................................................................... 350
11.2.2. Создание триггера............................................................................ 351
11.2.3. Триггер удаления.............................................................................. 353
11.3. Хранимые процедуры............................................................................. 355
11.3.1. Назначение хранимых процедур..................................................... 355
11.3.2. Создание и использование хранимых процедур...........................357
11.4. Администрирование баз данных........................................................... 360
11.4.1. Создание и удаление баз данных.................................................. 360

11.4.2. У п р ав л ен и е уч етн ы м и за п и с я м и и правам и д оступ а
в M icrosoft S Q L S e rv e r................................................................................... 364
11.4.3. Р езер в н о е к о п и р о в а н и е и в о сстан о вл ен и е б аз д а н н ы х ...................366
В оп р о сы и у п р а ж н е н и я .....................................................................................................369

Глава 12. Новые технологии Б Д .....................................................................................370
12.1. О б ъ е к т н о -о р и е н т и р о в а н н ы е С У Б Д .................................................................. 370
12.1.1. С тан д ар т об ъ ектн ы х б аз д ан н ы х O D M G -9 3 ..........................................371
12.1.2. О б ъ ектн ая и р е л я ц и о н н а я т е х н о л о г и и .....................................................378
12.2. О б ъ е к т н о -р е л я ц и о н н ы е С У Б Д ............................................................................ 379
12.2.1.
12.2.2.
12.2.3.
12.2.4.

П одходы к п о с тр о е н и ю о б ъ е к т н о -р е л я ц и о н н ы х С У Б Д .................381
П ер вая п о п ы тк а со зд ан и я О Р С У Б Д ..........................................................384
С тан д ар т S Q L 3 .....................................................................................................388
К . Д е й т об о б ъ к т н о -р е л я ц и о н н ы х С У Б Д ...............................................389

12.3. Х р ан и л и щ а д а н н ы х ................................................................................................... 391
12.3.1. О п е р а ти в н ы е с и с т е м ы ......................................................................................391
12.3.2. И н ф о р м а ц и о н н ы е с и с т е м ы ........................................................................... 392
12.3.3. П р и ч и н ы с о зд ан и я х р а н и л и щ д а н н ы х .....................................................394
12.3.4. О с н о в о п о л агаю щ и е к о н ц е п ц и и .................................................................. 395
12.3.5. О сн о в н ы е к о м п о н е н т ы х р а н и л и щ а д а н н ы х ..........................................396
12.3.6. О сн о в н ы е п о то ки д ан н ы х в х р а н и л и щ е ................................................. 397
12.3.7. Т и п ы х р а н и л и щ д а н н ы х .................................................................................398
12.3.8. С У Б Д д ля х р ан и л и щ а д а н н ы х ......................................................................402
12.3.9. М у л ьти х р ан и ли щ а д а н н ы х ............................................................................402
12.3.10. А рхи тектурн ы е р е ш е н и я .............................................................................. 404
12.3.11. П р о ек ти р о в ан и е х р ан и л и щ д а н н ы х ....................................................... 410
12.4. П р и н ц и п ы п р о ек ти р о в ан и я
и и сп о л ь зо в ан и я м н о го м ер н ы х баз д а н н ы х .................................................. 415
12.4.1. Т р еб о в ан и я к средствам р е а л и за ц и и си стем о п е р а т и в н о й
и а н а л и т и ч е с к о й о б р аб о тки д а н н ы х ........................................................ 417
12.4.2. М н о го м е р н а я м одель д а н н ы х ....................................................................... 421
12.4.3. М н о го м ер н о е п р ед ставл ен и е
при о п и с а н и и структур д а н н ы х .................................................................. 422
12.4.4. Г и п ер ку б и ч еск и е и п о л и к у б и ч еск и е м одели д а н н ы х ......................423
12.4.5. О п е р а ц и и м а н и п у л и р о в а н и я И з м е р е н и я м и ......................................... 424
12.4.6. П р о е к т и р о в а н и е м н о го м е р н о й Б Д ............................................................ 426

Глава 13. Современные С У БД.........................................................................................428
13.1. M icrosoft Visual F o x P ro 9 .0 .................................................................................... 428
13.1.1. И с т о р и ч е с к а я с п р а в к а ......................................................................................429

13.1.2. Общая характеристика Microsoft Visual FoxPro 9.0.....................430
13.1.3. Элементы проекта............................................................................ 434
13.1.4. Создание баз данных и_приложений.............................................436
13.2. MS SQL Server 2005.........
458
13.2.1. Язык SQL........................................................................................... 459
13.2.2. Нововведения относительно предыдущих версий...................... 459
13.2.3. Варианты поставки SQL Server 2005..............................................461
13.2.4. Создание базы данных..................................................................... 462
13.2.5. Удаление базы данных..................................................................... 468
13.2.6. Создание таблиц............................................................................... 470
13.2.7. Заполнение таблиц данными.......................................................... 475
13.2.8. Архитектура системы безопасности SQL Server2005 ..................480
13.3. Access 2003 ...............................................................................................482
13.3.1. Историческая справка...................................................................... 482
13.3.2. Требования к системе...................................................................... 483
13.3.3. Новые возможности Access 2003..................................................... 484
13.3.4. Работа в Access 2003......................................................................... 485
Литература.......................................................................................................... 509
Предметный указатель

513

Предисловие

В настоящее время трудно представить какую-либо сферу деятельности че­
ловека, где бы ни стояла проблема создания и использования информаци­
онных систем. Сегодня такие системы стали насущной потребностью,
и спрос на грамотных специалистов в этой области постоянно растет.
А поскольку все здание информационных систем базируется на концепции
баз данных, то естественно, что без более или менее детального знакомства
с основами дисциплины "Базы данных" в наше время невозможно быть не
только квалифицированным программистом, но даже и грамотным пользо­
вателем компьютеров. Поэтому можно смело сказать, что навыки работы
в этой области не только повышают интеллектуальный потенциал пользова­
теля, но являются в этом вопросе одним из основополагающих факторов.
Сегодня в соответствии с действующим государственным образователь­
ным стандартом базы данных изучаются как самостоятельная дисциплина
(на компьютерных специальностях) или как раздел дисциплины "Информа­
тика" (на прочих специальностях).
Предлагаемая читателю книга представляет собой переработанный и расши­
ренный вариант учебного пособия автора, вышедшего в университетском
издательстве в 1999 году с грифом УМО Министерства образования РФ для
студентов специальности 22.04 — "Программное обеспечение вычислитель­
ной техники и автоматизированных систем" и апробированного автором
в течение ряда лет при чтении курса лекций по дисциплине "Базы данных"
Основное назначение книги — ознакомить читателя с основными идеями и
методами, которые используются в современных реляционных системах
управления базами данных. В книге описаны теоретические основы баз
данных, методы проектирования баз данных, а также вопросы управления
базами данных: все то, что необходимо специалисту, работающему в области
информационных систем.
Автор стремился представить необходимый теоретический и практический
материал в доходчивом изложении и в такой последовательности, которая
позволит читателю самостоятельно спроектировать структуру базы данных,

реализовать ее с помощью средств современных СУБД, а также осуществ­
лять поддержку функционирования созданной информационной системы.
Материал книги разбит на четыре части.
□ Часть 1. Базы данных: основные понятия.
□ Часть 2. Проектирование баз данных.
□ Часть 3. Языки баз данных.
□ Часть 4. Использование баз данных.
Каждая из перечисленных частей включает ряд глав, содержащих большое
количество примеров, а также контрольные вопросы и упражнения.
В первой части книги, объединяющей первую и вторую главы, анализируются
современное состояние технологий баз данных, трехуровневая архитектура
баз данных и архитектура многопользовательских систем, а также типовая
организация современных систем управления базами данных и основные
функции, которые они должны поддерживать.
Вторая часть книги (главы 3—8) посвящена современным методологиям
проектирования баз данных, базирующимся на концепции жизненного цик­
ла баз данных. Достаточно много места здесь уделено рассмотрению отдель­
ных этапов проектирования баз данных, типов моделей данных и возможно­
стей их использования. Ряд глав этой части посвящен теоретическому
базису реляционной модели, благодаря которой произошла революция
в области баз данных. Вводятся основные понятия модели данных, обсуж­
даются основные свойства отношений, рассматриваются два базовых меха­
низма манипулирования данными: реляционная алгебра и реляционное ис­
числение. Здесь же излагаются принципы нормализации, на которых
основан классический подход к проектированию реляционных баз данных.
Наконец, описывается современный.подход к проектированию баз данных,
основанный на использовании семантических моделей данных.
Третья часть книги, к которой относятся девятая и десятая главы, полно­
стью посвящена языкам манипулирования данными реляционных СУБД.
Здесь достаточно полно рассматривается язык SQL (Structured Query
Language — язык структурированных запросов), благодаря удачной про­
граммной разработке ставший в настоящее время наиболее распространен­
ным программным продуктом такого рода, а также QBE (Query-byExample — язык запросов по образцу), использующий визуальный подход
для организации доступа к информации в базе данных и задуманный как
средство, облегчающее работу для неспециалистов.
В четвертую часть (главы 11—13) помещен материал под общим названием
"Использование баз данных" Здесь рассматриваются основные аспекты
обеспечения оперативной работы баз данных в многопользовательском ре­
жиме, некоторые современные СУБД, а также новые технологии баз дан­
ных, реализованные по причине того, что основополагающие принципы

организации реляционных баз данных налагают жесткие ограничения на
модель данных в базе, что не всегда устраивает при моделировании кон­
кретных предметных областей. Ожидается, что развитие постреляционных
моделей баз данных позволит вывести процессы хранения и обработки дан­
ных на новый, более мощный по производительности, уровень.
Книга адресована широкому кругу пользователей. Она ориентирована на
студентов высших учебных заведений, изучающих дисциплины: "Базы дан­
ных", "Информационные системы", "Проектирование информационных сис­
тем", и будет весьма полезна разработчикам баз данных, прикладным про­
граммистам и другим специалистам в области информационных систем,
а также всем желающим расширить свои профессиональные знания в облас­
ти компьютерных технологий.
Автор выражает свою признательность и благодарность М. Янаевой,
В. Бахчагулян, А. Берсеневу, М. Соловьеву, А. Варнавскому, А. Жердеву
и С. Карпулину за помощь в подготовке рукописи к изданию.
Автор благодарит рецензентов за ряд ценных замечаний, которые способст­
вовали улучшению книги.

Часть I

БАЗЫ ДАННЫХ:
ОСНОВНЫЕ ПОНЯТИЯ

Глава 1. Введение в базы данных
Глава 2. Архитектура СУБД

Глава 1

Введение в базы данных
"История исследований систем баз данных —ото, по сути, история развития
приложений, достигших исключительной производительности и оказавших
потрясающее влияние на экономику. Если еще 20 лет назад эта сфера была
всего лишь областью фундаментальных научных исследований, то теперь на
исследованиях баз данных основана целая индустрия информационных ус­
луг, ежегодный бюджет которой только в США составляет 10 миллиардов
долларов. Достижения в исследованиях баз данных стали основой фунда­
ментальных разработок коммуникационных систем, транспорта и логисти­
ки, финансового менеджмента, систем с базами знаний, методов доступа
к научной литературе, а также большого количества гражданских и военных
приложений. Они также послужили фундаментом значительного прогресса
в ведущих областях науки — от информатики до биологии" Эта цитата,
приведенная в [1] и взятая ее авторами из материалов семинара по систе­
мам баз данных, как нельзя лучше и концентрированнее отражает то поло­
жение, которое занимает предмет книги в деловом и научном мире, и обос­
новывает важность рассматриваемых далее вопросов.

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

или информационным средством. Для компьютерных технологий данные —
это информация в дискретном, фиксированном виде, удобная для хранения,
обработки на ЭВМ, а также для передачи по каналам связи.
База данных (БД) — именованная совокупность данных, отражающая со­
стояние объектов и их отношений в рассматриваемой предметной области,
или иначе БД — это совокупность взаимосвязанных данных при такой ми­
нимальной избыточности, которая допускает их использование оптималь­
ным образом для одного или нескольких приложений в определенной пред­
метной области. БД состоит из множества связанных файлов.
Система управления базами данных (СУБД) — совокупность языковых и
программных средств, предназначенных для создания, ведения и совмест­
ного использования БД многими пользователями.
Автоматизированная информационная система (АИС) — это система, реали­
зующая автоматизированный сбор, обработку, манипулирование данны­
ми, функционирующая на основе ЭВМ и других технических средств
и включающая соответствующее программное обеспечение (ПО) и персо­
нал. В дальнейшем в этом качестве будет использоваться термин информаци­
онная система (ИС), который подразумевает понятие автоматизированная.
ИС может функционировать самостоятельно или служить компонентом бо­
лее сложной системы.
Каждая ИС в зависимости от ее назначения имеет дело с той или иной ча­
стью реального мира, которую принято называть предметной областью
(ПрО) системы. Выявление ПрО — это необходимый начальный этап разра­
ботки любой ИС. Именно на этом этапе определяются информационные
потребности всей совокупности пользователей будущей системы, которые,
в свою очередь, предопределяют содержание ее базы данных. По области
применения ИС можно разделить на системы, используемые в образовании,
производстве, бизнесе, науке и других областях.
В большинстве случаев прибегают к разбиению всего множества объектов
ПрО на группы объектов, однородных по структуре, обладающих одинако­
выми свойствами, например. В каждом фрагменте ПрО выделяется система
объектов и связи между объектами, выделяются процессы, происходящие
в этом фрагменте, а также конечное число пользователей.
Банк данных (БнД) является разновидностью ИС. БнД — это система специ­
альным образом организованных данных: баз данных, программных, техни­
ческих, языковых, организационно-методических средств, предназначенных
для обеспечения централизованного накопления и коллективного многоце­
левого использования данных.
Под задачами обработки данных обычно понимается специальный класс ре­
шаемых на ЭВМ задач, связанных с видом, хранением, сортировкой, отбо­
ром по заданному условию и группировкой записей однородной структуры.

При этом для пользователя предусматривается генерация различных отче­
тов, как правило, табличной формы.
Отдельные программы или комплекс программ, реализующие автоматиза­
цию решения прикладных задач обработки данных, называются приложе­
ниями. Поскольку одни и те же данные могут использоваться для решения
многих задач, то и приложений к одной и той же базе данных может быть
много. Приложения, созданные средствами СУБД, относят к приложениям
СУБД. Приложения, созданные вне среды СУБД с помощью систем про­
граммирования, использующих средства доступа к БД, к примеру, Delphi
или C++Builder, называют внешними приложениями. Все приложения, рабо­
тающие с одной и той же базой данных, должны функционировать коррект­
но, не мешать друг другу и учитывать все изменения, которые вносятся
другими приложениями. Такая координация работы приложений осуществ­
ляется СУБД.

1.2. Развитие технологий обработки данных
Ретроспективный взгляд на процесс развития компьютерных технологий и
на то место, которое занимала и занимает в нем автоматизация процессов
обработки данных и управление ими, имеет немалое значение. Оно обу­
словлено необходимостью понимания проблем, присущих ранним ИС.
Многолетний опыт, накопленный в этой области, позволяет глубже понять
задачи современного состояния и дальнейшего развития технологий баз
данных. Рассмотрим основные факторы, предопределившие направления
эволюции технологий баз данных.
В ряду компьютерных применений решение информационных задач ввиду
своей специфики занимает особое место. В отличие от вычислительных за­
дач со сложными алгоритмами обработки эпизодически используемых дан­
ных простой структуры, информационные задачи характеризуются противо­
положными отправными моментами. Это, прежде всего:
□ большие объемы обрабатываемой информации;
□ данные сложной структуры;
□ сравнительно простые алгоритмы обработки.
Современный компьютерный мир и его возможности возникли не сразу.
И если последний пункт изначально при постановке информационной за­
дачи не создавал никаких трудностей, то первые два, дополненные такими
требованиями, как:
□ обеспечение надежности хранения информации;
□ высокая производительность
долгое время являлись камнем преткновения на нелегком пути програм­
мистов.

В течение продолжительного периода времени некоторые перечисленные
требования находились в постоянном конфликте друг с другом. Действи­
тельно, долгое время слабым звеном вычислительных средств, помимо всего
прочего, являлись ограниченные возможности хранения информации. Гово­
рить о надежном и долговременном хранении информации можно только
при наличии запоминающих устройств, сохраняющих информацию после
выключения электрического питания. Из используемых видов памяти для
этой цели подходила только долговременная память на магнитных лентах
или на магнитных барабанах.
Емкость магнитных лент считается неограниченной, но использование их
имеет ряд серьезных недостатков, главным из которых является низкая ско­
рость обмена информацией, существенно ограничивающая производитель­
ность вычислительных средств. А применительно к информационным зада­
чам на первую линию выдвигалось еще одно ограничение использования
магнитных лент — последовательный доступ к информации.
Другой вид используемой в то время внешней памяти — магнитные бараба­
ны были лишены последнего недостатка запоминающих устройств на маг­
нитных лентах. Они предоставляли возможность произвольного доступа
к памяти, но ограниченный объем памяти магнитных барабанов, а также не­
высокая скорость обмена информацией не позволяли и в этом случае в пол­
ной мере создавать адекватное отображение предметной области реального
мира в виде совокупности взаимосвязанных информационных объектов и
обеспечивать быструю реакцию системы на различные запросы пользователя.
Итак, необходимо согласиться со следующим заключением: основным тор­
мозом на пути развития технологии баз данных продолжительный период
времени являлось отсутствие таких видов памяти, которые бы удовлетворяли
всем вышеперечисленным требованиям.
Насущная потребность в таком виде памяти была удовлетворена с появле­
нием сменных магнитных дисков. Эти устройства внешней памяти обладали
существенно большей емкостью, чем магнитные барабаны (сменность дис­
ков делала ее неограниченной), обеспечивали удовлетворительную скорость
доступа к данным, произвольный доступ к ним. С решением проблемы па­
мяти и начался период интенсивного развития технологий баз данных.
При рассмотрении истории развития технологий информационных систем
следует обратить внимание на тот факт, что мощным локомотивом этого
развития всегда служили нужды и потребности делового и производствен­
ного мира. С одной стороны, их роль можно сравнить с естественным отбо­
ром в генетике. Успешно приживались и в дальнейшем развивались те ре­
шения, внедрение которых обеспечивало превышение получаемой выгоды
от внедрения над затратами на нее. С другой стороны, потребности этого
локомотива росли параллельно с развитием технологий, постоянно ставя
новые задачи и требуя их решения.

Первые внедрения коммерческих компьютерных программ происходили
там, где их особенно ждали — в бухгалтерских расчетах. Вполне объяснимо
то, что эти программы на начальных стадиях своего развития осуществляли
те же операции и выдавали те же документы, которые раньше выполнялись
и формировались вручную.
Определив основные сдерживающий и подталкивающий факторы развития
информационных технологий, дадим более подробную характеристику раз­
личных его фаз.
В 60-е годы до появления ЭВМ третьего поколения обработка данных осуще­
ствлялась в основном при помощи операций ввода — вывода. Файлы при
такой обработке были организованы последовательным способом. При этом
физическая структура данных и логическая структура файла совпадали.
Пользователям файл в этой ситуации представляется, как линейная после­
довательность записей, где структура записи файла известна только про­
грамме, которая с ним работает, поскольку эта структура содержится только
в ней. Если структура файла изменяется, требуется вносить изменения и
в саму программу. Такая ситуация характеризуется как зависимость про­
грамм от данных. Положение дел еще более усугубляется, если учесть тот
факт, что для информационных систем характерным является наличие
большого числа пользователей одними и теми же данными, каждый из ко­
торых имеет свой алгоритм обработки информации. Изменения, вносимые
в структуру данных одним пользователем, приводят к необходимости моди­
фицировать абсолютно все программы.
Следующая существенная проблема описываемого периода развития систем
обработки информации, в большой мере усложняющая ситуацию, — значи­
тельная степень избыточности данных в файлах. Дело в том, что при рассмат­
риваемом способе организации даже в тех случаях, когда наборы данных соз­
даются и оптимизируются для одной задачи, обеспечение нормальных
условий функционирования обработки данных приводит к необходимости
хранения нескольких копий одного и того же файла, отсортированных по
различным полям записей.
К нарисованной негативной картине нельзя не добавить еще несколько харак­
теристик процесса создания и функционирования информационных систем,
являющихся следствием уже упомянутых выше факторов. К ним относятся:
□ отсутствие централизованных методов управления доступом к информации;
□ значительные затраты труда программистов как на создание приложения,
так и на поддержание его работы;
□ сложности администрирования режимом доступа к файлу, а следователь­
но и сложность реализации многопользовательского режима работы.
Указанные проблемы ранних систем обработки данных требовали своего
решения и служили мощным толчком для поиска новых подходов к хране­
нию и управлению информацией.

Следующий этап развития ИС характеризуется изменением как природы
файлов, так и используемых для их хранения устройств. Подобная ситуация
стала возможной с появлением файлов произвольного доступа к данным и
особенно индексно-последовательных (ИП) файлов, широко распространив­
шихся в 60-е годы.
Помимо отсутствия в этом случае необходимости просмотра всех предшест­
вующих записей, изменилась природа и методы хранения самих носителей
информации, позволивших значительно сократить время обращения к па­
мяти, а значит существенно увеличить производительность таких систем.
Появилось некоторое различие логической и физической структур данных,
правда, взаимосвязь между ними сохранялась все еще достаточно простая.
Проявилась и кое-какая независимость программ от данных. Новые подхо­
ды позволили заменять запоминающие устройства без изменения приклад­
ной программы, используя специальные языки заданий. В этот период раз­
вития уже применяются определенные средства защиты данных. Тем не
менее практика быстро показала, что при всех своих достоинствах файлы
с произвольным доступом решали проблемы лишь частично, так как файло­
вые системы любого типа обладают некоторыми врожденными недостатками:
□ типовое программное обеспечение системы обработки данных представля­
ет собой методы доступа, а не управление данными, так как файловые сис­
темы не позволяют устанавливать связь между данными разных файлов;
□ сохраняется значительная избыточность данных;
□ отсутствует централизованный контроль на уровне элементов данных;
часто один и тот же элемент данных имеет несколько имен в зависимо­
сти от того, в какие файлы он входит;
□ требуются большие затраты труда программистов, которым постоянно
приходится определять новые наборы данных для новых приложений,
выполнять очень сложные манипулирования данными;
□ не устранены сложности администрирования режимом доступа к файлу,
а следовательно и сложность реализации многопользовательского режима
работы.
Необходимость решения перечисленных проблем заставила разработчиков
информационных систем предложить новые концепции:
□ хранения информации — базы данных;
□ управления информацией — системы управления базами данных.
Дальнейшая история развития систем обработки данных — это эпоха разви­
тия баз данных и систем управления базами данных. Начало этой эпохи оз­
наменовалось введением в эксплуатацию в 1968 году первой промышленной
СУБД системы IMS фирмы IBM. Можно утверждать, что появление баз
данных, создающихся и работающих под управлением СУБД, стало самым
важным достижением в области программного обеспечения. В то же время

именно это появление стало мощным катализатором многих значительных
достижений не только в области создания программных продуктов, но и
в других связанных с ней областях. Остановимся на краткой характеристике
тридцатилетней предыстории нынешнего состояния этой проблемы, ответив
вначале на следующий вопрос.
Так в чем же суть новых упомянутых концепций?
База данных — это единое, вместительное хранилище разнообразных данных
и описаний их структур, которое после своего определения, осуществляе­
мого отдельно и независимо от приложений, используется одновременно
многими приложениями. Хранимые данные организованы в совместно ис­
пользуемый набор и логически связаны между собой, точно также как
в рассматриваемой соответствующей предметной области взаимосвязаны
между собой объекты и явления. Поскольку структуры данных определяют­
ся средствами СУБД отдельно от приложений и хранятся в базе данных, то
добавление новых структур данных или изменение существующих не влияет
на приложения, не использующие измененные данные.
Система управления базами данных — это программное обеспечение, с по­
мощью которого можно:
□ определять базу данных, структуры ее данных, а также задавать ограни­
чения для хранимых данных;
□ манипулировать данными, организуя выполнение разнообразных не фик­
сированных заранее запросов;
□ предоставлять контролируемый доступ к информации базы данных;
□ осуществлять поддержку обеспечения безопасности данных;
□ обеспечивать целостность данных;
□ управлять многопользовательским режимом работы, контролируя про­
цессы совместного доступа к данным;
□ восстанавливать информацию базы данных, потерянную в результате раз­
личных аппаратных или программных сбоев.
Заметим, что в полной мере эти концепции и их составляющие формирова­
лись не сразу, а со временем.
Программное обеспечение первых СУБД связано с обработкой элементов или
групп элементов данных. В подобной ситуации доступ к одним и тем же
данным уже может осуществляться из разнообразных прикладных программ
различными путями. Программное же обеспечение должно содержать сред­
ства уменьшения избыточности. Разные логические файлы могут быть полу­
чены из одних и тех же физических данных. Многие элементы данных яв­
ляются общими для различных прикладных программ. Данные адресуются
на уровне полей и групп полей, а не на уровне записей. Поиск возможен по
многим ключам. Усложнение форм организации данных не влияет на при­
кладные программы.

Создатели первых СУБД ориентировались на организацию баз данных на
больших машинах (IBM 360/370, EC-ЭВМ) и на мини-ЭВМ (PDP1I) с хра­
нением их во внешней памяти центральной ЭВМ. Интерактивный режим
пользователя обеспечивался с помощью консольных терминалов, исполь­
зуемых в качестве устройств ввода — вывода центральной ЭВМ. Программы
обработки информации баз данных использовали такие же языки програм­
мирования, как и числовые задачи.
По мере накопления опыта использования первых СУБД довольно скоро стало
очевидно, что необходим дополнительный уровень обеспечения программ­
ными средствами логической и физической независимости данных. Логиче­
ская независимость предполагает не изменение прикладных программ при
изменении логической структуры данных. Физическая независимость означа­
ет, что физическое расположение и организация данных могут изменяться, не
вызывая изменений в общей логической структуре данных и прикладных
программах. В таких системах обязательно нужно иметь: администратора баз
данных; эффективную защиту данных; язык описания данных; язык запро­
сов для пользователя и языки программирования для прикладного програм­
миста; эффективную систему контроля, статистики и исполнения работы
системы.
Следует отметить, что насущная потребность отыскания наилучших реше­
ний перечисленных проблем была столь велика, что их мозговым штурмом
занялись теоретики и практики всего мира. Все ждали кардинальных изме­
нений, и они произошли.
Так, например, именно к этому времени относятся следующие достижения,
которые трудно переоценить:
□ предложена новая модель данных — реляционная, по обоснованию и
формализации которой проводятся серьезные работы; создается первая
СУБД, реализующая эту идеологию;
□ выполняются теоретические работы по оптимизации запросов и управле­
нию распределенным доступом к централизованной базе данных;
□ большие успехи достигнуты в области администрирования данных.
И в то же самое время:
□ функции управления распределением ресурсов в основном осуществля­
ются средствами операционной системы (ОС);
П манипулирование данными реализуется с помощью языков низкого
уровня.
Этот этап развития СУБД, также как и предыдущий, связан с организацией
централизованных баз данных на больших машинах под управлением мощ­
ных мультипрограммных операционных систем (MVS, SVM, OSRV, RSX,
UNIX).

Следующая фаза развития технологии баз данных совпадает по времени и во
многом определяется появлением и захватом персональными компьютерами
(ПК) всех сфер человеческой жизни: деловой, производственной, научной,
бытовой. Этот захват приветствовался абсолютно всеми: опытными про­
граммистами и начинающими пользователями, руководителями всех рангов
и исполнителями, взрослыми и детьми.
Опрокинув все бытовавшие ранее представления о месте и роли вычисли­
тельной техники в жизни общества, персональные компьютеры не могли не
проделать то же самое в области информационных систем. Разработчики
программного обеспечения для ПК легко добились своей цели — собрать
вокруг ПК как можно больше пользователей различных уровней подготовки
для работы на них. Случилось это потому, что появилось множество про­
стых в обращении и интуитивно понятных программ с дружественным и
комфортным интерфейсом, позволяющих не только производить различного
рода вычисления, формировать тексты, документы, таблицы, графические
изображения, но и автоматизировать многие сферы деятельности.
Всеобщее признание получила интуитивно понятная реляционная модель
данных Кодда, имеющая в своей основе капитальную теоретическую базу.
Наконец-то возникло доступное средство, о котором все мечтали: позво­
ляющее автоматизировать процесс хранения, пополнения и обработки
имеющейся в наличии информации, вести документацию и автоматизиро­
вать многие учетные функции — в конторе, в отделе, дома. Тем более что на
рынке появилась новая разновидность программных продуктов — системы
управления базами данных, которые наделяют даже начинающего пользова­
теля возможностью организовать хранение данных с помощью встроенных
в СУБД различных инструментальных средств: построителей, мастеров,
конструкторов, организовать формирование разнообразных форм ввода и
просмотра данных, отчетов и многого другого.
Однако, как часто бывает, широкая "демократизация" процесса доступа
к ПК имела и свою негативную сторону. Негативность данного процесса
"демократизации" заключалась в том, что она привлекла в область обработки
данных огромную армию дилетантов. Эти новобранцы, не приобретя систе­
матических знаний в данной области и имея в своем распоряжении компь­
ютерного "Сезама", наплодили большое количество недолговечных баз дан­
ных и приложений к ним, не отражающих достоверно объекты и связи
избранной предметной области реального мира.
К сожалению, указанная армия не редеет, выбывают одни — появляются
другие. Возможно, некоторые из них со временем уже и стали опытными
программистами, а созданные ими системы хранения и управления инфор­
мацией послужили вехами в процессе постижения необходимых знаний
в данной области, но плохо то, что очень часто эти программные уродцы
остаются жить. Бесценная для фирмы информация накоплена, и чтобы ее

не потерять, сегодняшним специалистам приходится тратить массу усилий
на то, чтобы перевести процесс обработки данных на современные рельсы.
Вот почему всем желающим поработать в области создания информацион­
ных систем прежде всего необходимо ознакомиться с их теоретическими
основами и практическими руководствами по использованию тех или иных
программных продуктов, чтобы кажущаяся простота не сыграла и с ними
злую шутку.
Положение некоторых фирм усугубили и некоторые программисты, приняв
совсем необоснованно решение осуществить разработку СУБД своими си­
лами, используя стандартные языки программирования. Время показало,
что такие системы не выдержали острую конкуренцию ведущих фирмпроизводителей программных продуктов в области создания систем обра­
ботки данных. А попытка в рассматриваемом случае повысить производи­
тельность системы путем перехода к новой современной СУБД — совсем
непростое дело, так как в этом случае обязателен перенос данных из
нестандартных форматов, который порой требует настолько больших трудо­
затрат, что они сравнимы с теми, которые необходимы при разработке но­
вой информационной системы.
Каковы же основные характеристики СУБД, устанавливаемых на персо­
нальных компьютерах? Приведем их.
□ Поддержка реляционной модели данных.
□ Сравнительно невысокие требования к техническим параметрам аппа­
ратного обеспечения.
□ Ориентация на создание баз данных в монопольном режиме работы.
□ Практическое отсутствие функций администрирования БД.
□ Развитый и удобный интерфейс.
□ Разнообразный инструментарий для разработки готовых приложений без
программирования.
□ Поддержка как появившихся новых высокоуровневых языков манипули­
рования данными, так и низкоуровневых языков манипулирования дан­
ными на уровне отдельных строк таблицы.
□ Поддержка только внешнего уровня представления модели данных.
□ Отсутствие средств поддержки ссылочной и структурной целостности БД.
Наибольшую известность и распространение в рассматриваемый период
времени получили такие СУБД, как: DbaseIII+, DbaselV, Paradox, FoxPro,
Clipper, через тесное знакомство с которыми прошли многие программисты,
очень хорошо освоившие разнообразные нюансы работы с ними.
Потребности в персональных СУБД не иссякают, поскольку число владель­
цев персональных компьютеров растет с большой скоростью. Во многих

случаях для решения требуемых проблем дешевле и проще обойтись средст­
вами персональной СУБД. Поэтому на рынок выходят все новые современ­
ные, впитывающие в себя последние технические и научные достижения
в области обработки информации версии персональных СУБД.
Эйфория от процесса "персонализации" баз данных закончилась так, как и
должна была закончиться — осознанием возможностей таких баз и сфер их
применения. Задача "интеграции" информации вышла на самый первый
план, она настойчиво требовала своего решения. Для этого понадобилось
разрабатывать новые подходы и концепции в организации баз данных, оты­
скивать новые аппаратные и программные их реализации. Разработчикам
компьютерных и программных систем пришлось "бешеными" темпами на­
ращивать мощность компьютеров и расширять возможности коллективной
работы с данными за счет объединения данных в сети.
Трудились, что называется, "в поте лица" И результаты не замедлили ска­
заться. Весь мир еще не до конца осознал, что же он получил. Сегодня он
опутан паутиной различных сетей — локальных, корпоративных, глобаль­
ных, по которым ураганом, от компьютера к компьютеру, передается разно­
образная информация. Такой стиль жизни диктует свои правила. Каждая
вновь возникшая фирма знает, что ее первоочередная задача — оснастить
себя компьютерами, следом за которой необходимо решить другие — орга­
низовать купленные компьютеры в локальную сеть и создать свою инфор­
мационную систему, а затем — обеспечить выход в глобальную сеть, с тем
чтобы иметь доступ к любой понадобившейся информации.
Быстрыми темпами прошел свой эволюционный путь и основной инстру­
мент для работы с данными — СУБД: от однопользовательских систем, ко­
торые устанавливаются на отдельном ПК, до многопользовательских и сер­
верных систем.
На настоящий момент серверы баз данных представляют собой наиболее
мощное и надежное прикладное программное обеспечение для коллектив­
ной работы с данными. Однако известная истина, что за все надо платить, и
в этом случае доказала свою справедливость: обладая большими возможно­
стями такие системы отличаются повышенной сложностью и стоимостью.
Причем очевидно, что сам процесс становления информационных техно­
логий постоянно порождает очередные новые проблемы. Специалисты ут­
верждают, что”развитие систем баз данных еще не завершено, как это может
показаться на первый взгляд, можно сказать, что мы находимся в конце
начала их развития"
Вот такой оценкой сегодняшнего состояния дел в области информационных
технологий заканчивается этот подраздел, основные моменты которого бу­
дут рассмотрены в следующем.

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

□ СУБД;
□ словарь или каталог данных;
□ администратора;
□ вычислительную систему;
□ обслуживающий персонал.
Схематично это выглядит так, как показано на рис. 1.1.

Р ис. 1 .1 . Банк данных

Поскольку о сути понятий БД и СУБД уже много говорилось, дадим крат­
кие определения остальным составляющим этой схемы, так как подробное
рассмотрение их помещено позже.
Словарь или каталог данных служит для централизованного накопления и
описания ресурса данных. Словарь данных следит за определением всех
элементов данных базы, включая структуры данных на уровне групп и запи­
сей, отслеживает отношения, существующие между отдельными группами
данных. Наличие словаря позволяет уменьшить избыточность данных. Он
содержит описание ПрО, сведения о структуре БД, о связях между элемен­
тами БД, кроме того, может содержать сведения о кодах данных, о разгра­
ничениях доступа к данным. Словарь данных можно рассматривать как
часть самой базы данных. В этом случае база данных является самоописываемой, поскольку она содержит информацию о своей структуре.
Администратор БД
(АБД)— человек или группа лиц, которые
решения. Основные функции АБД:
□ участие в разработке БД;
□ контроль правильности функционирования БД.

Вычислительная система (ВС) — включает программные (ПС) и аппаратные
средства (ТС).
Обслуживающий персонал (ОП) — это лица, прямыми обязанностями кото­
рых является создание и поддержание корректного функционирования бан­
ка данных. Они ответственны за работу БнД и прикладного программного
обеспечения. К обслуживающему персоналу относятся: разработчики и ад­
министраторы базы данных, аналитики, программисты.
При дальнейшем изложении материала, если не будет присутствовать особая
необходимость, понятия ИС и БнД разграничиваться не будут.

1.4. Базы данных
Итак, из материалов предыдущих разделов следует два первостепенных
вывода:
□ современная информационная система должна иметь дело с данными,
организованными в базы данных;
□ создание баз данных и поддержка их функционирования должны осуще­
ствляться с помощью предназначенных именно для этих целей специ­
альных программных продуктов, которые называются системами управ­
ления базами данных.
В данном подразделе рассмотрим более детально первое заключение. Неко­
торые сведения, посвященные второму заключению, помещены в после­
дующий подраздел.
Как уже отмечалось, БД — это единое хранилище данных, которое одно­
кратно определяется, а после этого многократно используется разными
пользователями для удовлетворения возникающих многообразных потребно­
стей в информации. Для того чтобы указанные потребности удовлетворя­
лись быстро, просто и комфортно, информация в БД должна быть органи­
зована особым образом.
□ Информационная система может быть персональной — однопользова­
тельской, т. е. в одно и то же время к базе данных может получить доступ
только один пользователь. ИС может быть многопользовательской —
к базе данных одновременно могут получить доступ сразу несколько
пользователей. Разновидность создаваемой информационной системы
определяется потребностями пользователей и теми вычислительными ре­
сурсами, которые выделяются для ИС.
О В информационной системе данные могут быть организованы в одну или
несколько баз данных.
□ БД, как правило, создается как общий ресурс всего предприятия, где дан­
ные являются интегрированными и общими. Под понятием интегрированные

данные подразумевается возможность представить базу данных как объе­
динение нескольких отдельных файлов данных, полностью или частично
не перекрывающихся. Под понятием общие данные подразумевается воз­
можность использования отдельных областей данных в БД несколькими
различными пользователями для разных целей. Причем такой доступ
в многопользовательской ИС может осуществляться в одно и то же время.
Одним из следствий данного положения является то, что любой кон­
кретный пользователь имеет дело с какой-то небольшой частью всей БД,
и одну и ту же область БД два различных пользователя могут восприни­
мать по-разному.
□ В базе данных информация должна быть организована так, чтобы обес­
печить минимальную долю ее избыточности. Очевиден факт, что избы­
точность отсутствует там, где данные не повторяются. Но, как станет яс­
но позже, в базе данных представить взаимосвязанную информацию как
объединение нескольких отдельных файлов данных, полностью не пере­
крывающихся между собой, невозможно. Частичная избыточность ин­
формации необходима, но она должна быть минимизирована, так как
чрезмерная избыточность данных влечет за собой ряд негативных по­
следствий. Главные из них:
• увеличение объема информации, а значит, потребность дополнитель­
ных ресурсах для хранения и обработки дополнительных объемов
данных;
• появление ошибок при вводе дублирующей информации, нару­
шающих целостность базы данных и создающих противоречивые
данные.
□ БД содержит не только данные, всесторонне характеризующие деятель­
ность самой организации, фирмы, процесса или другой предметной об­
ласти, но и описания этих данных. Информацию о данных принято
называть ''метаданными", т. е. "данными о данных" В совокупности опи­
сания всех данных образуют словарь данных. Наличие его обеспечивает
в БД определение данных отдельно от приложений, которым доступно
только внешнее их описание, а следовательно, такая ситуация обеспечи­
вает независимость между программами и данными.
□ В БД должны храниться данные, логически связанные между собой. Для
того чтобы данные можно было связать между собой, и связать так, чтобы
эти связи соответствовали реально существующим в данной предметной
области, последнюю подвергают детальному анализу, выделяя сущности
или объекты. Сущность или объект — это то, о чем необходимо хранить
информацию. Объекты имеют некоторые свойства, которые тоже необ­
ходимо сохранять в БД. Свойства по своей внутренней структуре могут
быть простыми, а могут быть сложными. Простые свойства могут быть
представлены простыми типами данных. Различного рода графические

изображения, являющиеся свойствами объектов, — это пример сложного
свойства. Определив объекты и их свойства, необходимо перейти к выяв­
лению связей, которые могут существовать между некоторыми объекта­
ми. Связь — это то, что объединяет два или более объектов. Связи между
объектами также являются частью данных, и они также должны хранить­
ся в базе данных.
Если все это: объекты, свойства объектов и связи между объектами опреде­
лено, то схема базы данных может выглядеть примерно так, как представле­
но на рис. 1.2. На нем показан пример схемы базы данных, которую можно
назвать ФАКУЛЬТЕТ. Естественно, что данный учебный пример облегчен и
не охватывает всесторонне деятельность на факультете, но, поскольку книга
в первую очередь ориентированна на студентов, а им указанная деятель­
ность близка и знакома, то именно этот пример хочется использовать для
первой иллюстрации изложения материала.
Схема, которая называется ER-диаграммой (Entity-Relationship), состоит из
следующих компонентов:
□ шести объектов, которые изображены прямоугольниками, каждый из ко­
торых имеет свои свойства, помещенные в овалы, а в нижеприведенном
списке они перечислены в круглых скобках рядом с именем объекта:
• ФАКУЛЬТЕТ: (Код_факульт, Назв_Факультета, ФИО_декана);
КАФЕДРА: (Код_кафедры, Назв_кафедры, Завкафедрой);
СПЕЦИАЛЬНОСТЬ: (Код, Назв);
ПРЕПОДАВАТЕЛЬ: (Код_сотрудн, ФИО, Должность);
ГРУППА: (Код, ФИО_старосты);
СТУДЕНТ: (Ном зач книжки, ФИО, Пол);
□ пяти связей, которые обозначены стрелками и связывают те объекты, на
которые они направлены:
• связь ВКЛЮЧАЕТ показывает, что на факультете несколько кафедр;
• связь ВХОДИТ изображает, что одна и та же кафедра готовит специа­
листов по нескольким специальностям;
• связь РАБОТАЕТ определяет то, что на кафедре работают ряд препо­
давателей;
• связь ОБУЧАЕТ с двойными стрелками в обоих направлениях поясня­
ет тот факт, что один и тот же преподаватель преподает в разных груп­
пах, а одна и та же группа занимается с разными преподавателями;
• связь ОБУЧАЕТСЯ определяет, что каждая группа включает в себя
ряд студентов.
Из представленной диаграммы понятно, что данные обладают определенной
структурой. Для выявления этой структуры база данных должна пройти

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

Рис. 1.2. Пример ER-диаграммы базы данных ФАКУЛЬТЕТ

Для успешной реализации системы на основе БД на первом месте стоит
проектирование структуры данных, а затем только осуществляется разработ­
ка приложений. Плохо спроектированная база данных будет поставлять
некорректную информацию, порождать ошибки, способные привести к приня­
тию неправильных решений с далеко идущими последствиями.
Методологии проектирования баз данных разработаны и изложены во мно­
гих изданиях, но, к сожалению, весьма часто организации и отдельные раз­
работчики по незнанию или по привычке обходятся без них. Именно это
обстоятельство считается главной причиной неудач при разработке ИС —
когда созданные базы данных неэффективны, представленная на них доку­
ментация недостаточна, а время разработки затянуто.
В данной книге детально рассмотрены все этапы проектирования баз дан­
ных и даны подробные рекомендации их осуществления.
Проектируемая БД должна обладать определенными свойствами. Назовем
основные свойства БД.
Целостность. В каждый момент времени существования БД сведения, со­
держащиеся в ней, должны быть непротиворечивы. Целостность БД дости­
гается вследствие введения ограничений целостности, в частности, к ним
относятся ограничения, связанные с нормализацией БД. Желательно отсле­
живать диапазон допустимых значений, соотношения между значениями
в полях, особенности написания формата. Существуют ограничения, рабо­
тающие только при удалении записей. Например, нельзя удалять запись,
связанную с другой неудаляемой записью.
Восстанавливаемость. Данное свойство предполагает возможность восста­
новления БД после сбоя системы или отдельных видов порчи системы. Сю­
да относится проверка наличия файлов, составляющих приложение. В ос­
новном свойство восстанавливаемости обеспечивается дублированием БД и
использованием техники повышенной надежности.
Безопасность. Безопасность БД предполагает защиту данных от преднамерен­
ного и непреднамеренного доступа, модификации или разрушения. Применя­
ется запрещение несанкционированного доступа, защита от копирования и
криптографическая защита. Также необходимы и чисто административные
меры, например ограничение доступа к носителям информации.
Эффективность. Свойство эффективности обычно понимается как:
□ минимальное время реакции на запрос пользователя;
□ минимальные потребности в памяти;
□ сочетание этих параметров.
Предельные размеры и эксплуатационные ограничения. Предельные размеры,
а также другие ограничения, накладываемые эксплуатацией данной БД>
могут существенно повлиять на проектное решение.

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

1.5. Системы управления базами данных
Итак, как уже не один раз упоминалось, СУБД — это программное обеспе­
чение, с помощью которого пользователи могут определять, создавать и
поддерживать базу данных, а также осуществлять к ней контролируемый
доступ.
По степени универсальности различаются два класса СУБД — системы об­
щего назначения и специализированные системы.
СУБД общего назначения не ориентированы на какую-либо конкретную
предметную область или на информационные потребности конкретной
группы пользователей. Каждая система такого рода реализуется как про­
граммный продукт, способный функционировать на некоторой модели ЭВМ
в определенной операционной обстановке. СУБД общего назначения обла­
дает средствами настройки на работу с конкретной БД в условиях конкрет­
ного применения.
Использование СУБД общего назначения в качестве инструментального
средства для создания ИС, основанных на технологии БД, позволяет суще­
ственно сокращать сроки разработки, экономить трудовые ресурсы. Запас
"мощности" таких систем позволяет поддерживать эволюционный процесс
развития ИС в рамках ее жизненного цикла. Однако в некоторых ситуациях
доступные СУБД общего назначения не позволяют добиться требуемых про­
ектных и эксплуатационных характеристик (производительность, занимае­
мый объем памяти и прочее). Тем не менее создание специализированных
СУБД— весьма трудоемкий процесс и для того, чтобы его реализовать,
нужны очень веские основания.
Область интересов данной книги определяют СУБД общего назначения,
предназначенные для выполнения всей совокупности функций, связанных
с созданием и эксплуатацией данных ИС.
В процессе реализации своих функций СУБД постоянно взаимодействует
с базой данных и с другими прикладными программными продуктами поль­
зователя, предназначенными для работы с данной БД и называемыми при­
ложениями.
Для того чтобы СУБД успешно справлялась со своими задачами, она долж­
на обладать определенными возможностями. Следует заметить, что с тече­
нием времени количество и качество возможностей выходящих на рынок

СУБД в значительной степени эволюционируют: появляются новые, расши­
ряя спектр услуг пользователю, совершенствуются старые, приспосаблива­
ясь к возникающим новым требованиям.
Если проанализировать предлагаемые на рынке несколько десятков систем
управления базами данных, то можно увидеть, что реальный объем возмож­
ностей каждой из них отличается друг от друга. Тем не менее, не вдаваясь
в подробности, можно дать следующую обобщенную характеристику воз­
можностям современных СУБД.
□ СУБД включает язык определения данных, с помощью которого можно
определить базу данных, ее структуру, типы данных, а также средства за­
дания ограничений для хранимой информации. В многопользователь­
ском варианте СУБД этот язык позволяет формировать представления
как некоторое подмножество базы данных, с поддержкой которых поль­
зователь может создавать свой взгляд на хранимые данные, обеспечивать
дополнительный уровень безопасности данных и многое другое.
□ СУБД позволяет вставлять, удалять, обновлять и извлекать информацию
из базы данных посредством языка управления данными. Этот язык но­
сит еще одно название — язык запросов и позволяет пользователю фор­
мировать различные по содержанию запросы к базе данных.
□ Большинство СУБД могут работать на компьютерах с разной архитекту­
рой и под разными операционными системами, причем на работу поль­
зователя при доступе к данным практически тип платформы влияния не
оказывает.
□ Многопользовательские СУБД имеют достаточно развитые средства ад­
министрирования БД.
□ СУБД предоставляет контролируемый доступ к базе данных с помощью:
• системы обеспечения безопасности, предотвращающей несанкциони­
рованный доступ к информации базы данных;
• системы поддержки целостности базы данных, обеспечивающей
непротиворечивое состояние хранимых данных;
• системы управления параллельной работой приложений, контроли­
рующей процессы их совместного доступа к базе данных;
• системы восстановления, позволяющей восстановить базу данных до
предыдущего непротиворечивого состояния, нарушенного в результате
аппаратного или программного обеспечения;
• доступного пользователям каталога, содержащего описание хранимой
в базе данных информации.
Применительно к каждой конкретной СУБД приведенные выше общие
сведения, естественно, нуждаются в уточнении. Причем в полной мере всеми
перечисленными возможностями обладают только некоторые современные

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

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

С точки зрения пользователя именно данные являются наиболее важным
компонентом среды СУБД. Ради общения с ними на должном уровне требу­
ется наличие остальных компонентов. Как уже упоминалось, база данных
хранит как рабочие данные, так и характеристики данных. Рабочие данные
содержатся в БД в структурированном виде. Структуры данных определяет
схема базы данных, которая формируется на этапе проектирования БД.
БД, прежде всего, должна содержать:
□ имена, типы и размеры элементов данных;
□ имена связей;
□ ограничения целостности данных;
□ имена зарегистрированных пользователей и их права по доступу к дан­
ным;
О используемые индексы и структуры хранения.
Для хранения данных и различного рода программного обеспечения, а так­
же функционирования ИС необходимо аппаратное обеспечение. Аппаратное
обеспечение — это набор физических устройств, на которых существуют
база данных, СУБД и другие компоненты информационной системы. Аппа­
ратное обеспечение должно соответствовать требованиям использующей его

организации, требованиям употребляемой СУБД, требованиям разрабаты­
ваемой базы данных. Это может быть один персональный компьютер или
сеть. Для успешной работы информационной системы все компоненты
СУБД должны быть тщательно подобраны, с тем чтобы они были в состоя­
нии совместно работать согласованно.
Следующим компонентом по порядку рассмотрения является программное
обеспечение. К его составляющим необходимо отнести:
□ операционную систему, включая сетевое программное обеспечение, если
СУБД работает в сети;
□ программное обеспечение самой СУБД;
□ прикладные программы-приложения.
Поскольку второй указанной в данном списке составляющей, ее назначе­
нию и поддерживаемым ею функциям посвящена добрая часть этой книги,
а вопросы, относящиеся к операционным системам, в общей массе выходят
за рамки обсуждаемого в ней материала, остановимся немного на последней
составляющей программного обеспечения — прикладных программах.
Прикладные программы, которые создаются для нужд организации, могут
быть написаны на стандартном алгоритмическом языке программирования
высокого уровня, например, таком как С, Ada, Pascal, с внедренными
операторами языка SQL, который относят к языкам четвертого поколения.
Прикладные программы используют средства СУБД для обращения к дан­
ным и их обработки, создавая формы, отчеты и другие документы, необхо­
димые для работы данной организации. Многие современные СУБД имеют
специальные программные средства, называемые инструментами, для быст­
рой разработки приложений с употреблением встроенных непроцедурных
языков.
Среди пользователей БД можно выделить четыре категории лиц, каждая из
которых имеет свой круг интересов и связана с определенным этапом разра­
ботки и существования БД. Определим эти основные категории лиц, а так­
же их роли и функции на разных стадиях существования баз данных:
□ администраторы данных и баз данных;
□ разработчики баз данных;
□ прикладные программисты;
□ конечные пользователи.
Данные — это важный ресурс организации, и ими надо умело управлять.
Столь важная функция возложена на специалистов определенного рода —
Администраторов данных (АД). Они работают с данными с самого начала
процесса проектирования базы данных и отвечают за концептуальное и ло­
гическое проектирование базы данных, управление данными, разработку и
сопровождение стандартов, бизнес-правил и деловых процедур.

Физическое проектирование и физическая реализация базы данных, обеспе­
чение безопасности и целостности данных, обеспечение максимальной про­
изводительности приложений — это область действия компетенции Админи­
стратора базы данных (АБД). Как видно по сравнению с АД, обязанности
АБД более связаны с решением технических проблем.
Разработчики баз данных — это такая группа пользователей, которая функ­
ционирует во время проектирования, создания и реорганизации базы дан­
ных и результатом деятельности которой является хорошо спроектированная
БД, снабжающая достоверной и непротиворечивой информацией всех заин­
тересованных в этом лиц.
При проектировании больших БД все разработчики распадаются на две
группы:
□ разработчики логической базы данных;
□ разработчики физической базы данных.
Разработчики логической базы данных занимаются выявлением интересующих
объектов и их свойств, связей между объектами и тех ограничений, которые
необходимо наложить на хранимые данные. Скажем, при составлении рас­
писания занятий студентов некоторого университета, имеющего корпуса для
занятий в различных частях города (что очень часто встречается), можно
определить следующие бизнес-правила:
□ в течение одного учебного дня занятия группы студентов должны прово­
диться в одном учебном корпусе или в корпусах, расположенных рядом,
чтобы они не были вынуждены тратить время на переезды;
□ в течение одного учебного дня занятия, которые должны проводиться
одним преподавателем, обязаны планироваться в одном учебном корпусе
или в корпусах, расположенных рядом, чтобы и он не был вынужден тра­
тить время на переезды.
Осуществление своей деятельности указанные разработчики выполняют
в два этапа, которые в последующих главах будут рассмотрены весьма под­
робно:
□ разработка концептуальной модели БД;
О разработка логической модели БД.
Разработчики физической базы данных должны разбираться в функциональ­
ных возможностях выбранной СУБД, знать все варианты возможного физи­
ческого воплощения полученной логической модели данных и понимать их
достоинства и недостатки, с тем чтобы выбрать наиболее оптимальный
вариант для данного случая и правильно выстроить всю стратегию хранения
и использования данных.
Сразу после создания базы данных следует приступить к разработке прило­
жений, предоставляющих пользователям необходимые им функциональные

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

1.7. СУБД — это хорошо или плохо?
В заключение этой главы еще раз сконцентрируем внимание на основных
преимуществах, которыми обладают СУБД.
Наличие интегрированной централизованной базы данных. База данных при­
надлежит всей организации в целом и может совместно использоваться все­
ми зарегистрированными пользователями.
Минимизация избыточности данных. При использовании базы данных осуще­
ствляется минимизация избыточности данных за счет интеграции файлов,
чтобы избежать хранения нескольких копий одного и того же элемента ин­
формации. Однако полностью избыточность информации в базах данных не
исключается, а лишь контролируется ее степень. В одних случаях ключевые
элементы данных необходимо дублировать для моделирования связей, а в
других случаях некоторые данные потребуется дублировать из соображений
повышения производительности системы.
Непротиворечивость данных и контроль их целостности. Устранение избы­
точности данных или контроль над ней позволяет сократить риск возникно­
вения противоречивых состояний. Целостность базы данных означает кор­
ректность и непротиворечивость хранимых в ней данных.
Повышенная безопасность. Безопасность базы данных заключается в защите
базы данных от несанкционированного доступа со стороны пользователей.
Интеграция позволяет АБД определить требуемую систему безопасности
базы данных, а СУБД — привести ее в действие.
Увеличение гибкости при обслуживании запросов пользователя. Во многих
СУБД предусмотрены языки запросов или инструменты для создания отче­
тов, которые позволяют пользователям задавать непредусмотренные заранее

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

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

Вопросы и упражнения
1. Объясните своими словами смысл терминов:
• база данных;
• предметная область;
• информационная система.
2. Назовите основные компоненты информационной системы и поясните
их назначение.
3. Дайте ретроспективный анализ развития технологий обработки данных.
4. Поясните основные концепции технологии баз данных.
5. Чем характеризуется современное состояние технологии баз данных?
6. Что представляет собой банк данных?
7. Какими свойствами должна обладать проектируемая база данных?
8. Какие различают классы СУБД? Дайте характеристику отдельным классам.
9. Какими возможностями обладает современная СУБД?
10. Опишите компонентный состав среды СУБД и назначение ее компо­
нентов.
11. Объясните преимущества, которые несет в себе использование СУБД.

Глава 2

Архитектура СУБД
Говоря о том, каким должен быть столь сложный программный продукт,
как СУБД, прежде всего необходимо четко обусловить основную концеп­
цию системы, определяющую все последующие этапы ее разработки.
Основные положения этой концепции:
□ архитектура СУБД должна обеспечивать, в первую очередь, разграниче­
ние пользовательского и системного уровней;
□ необходимо дать возможность каждому пользователю иметь свое, отлич­
ное от других представление о свойствах хранимых данных.
Тогда начальной стадией проектирования любой конкретной информацион­
ной системы должны являться абстрактные описания информационных по­
требностей каждой группы пользователей, на основе которых генерируется
также абстрактное, но уже общее для всей организации описание структур
хранимых данных, а СУБД, посредством которой эта ИС будет создаваться
и поддерживаться, обязана иметь для этого определенные возможности.
Материал данной главы посвящен рассмотрению архитектурных решений
построения СУБД и ее функциональных характеристик, а также типовой
организации современной СУБД, позволяющей воплотить эти решения и
характеристики в эффективный программный продукт.

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

большинство существующих систем. Однако это не означает, что современ­
ный рынок программных продуктов предлагает только системы, строго сле­
дующие этой архитектуре как единственно возможной. Рассматривая кон­
кретные системы управления данными, иногда можно заметить отсутствие
поддержки некоторых аспектов данной архитектуры.
Одна и та же БД в зависимости от точки зрения может иметь различные
уровни описания. По числу уровней описания данных, поддерживаемых
СУБД, различают одно-, двух- и трехуровневые системы. В настоящее время
чаще всего поддерживается трехуровневая архитектура описания БД (рис. 2.1),
с тремя уровнями абстракции, на которых можно рассматривать базу дан­
ных. Такая архитектура включает:
□ внешний уровень, на котором пользователи воспринимают данные, где
отдельные группы пользователей имеют свое представление (ПП) на базу
данных;
□ внутренний уровень, на котором СУБД и операционная система воспри­
нимают данные;
□ концептуальный уровень представления данных, предназначенный для
отображения внешнего уровня на внутренний уровень, а также для обес­
печения необходимой их независимости друг от друга; он связан с обоб­
щенным представлением пользователей.
Данная архитектура вызревала не сразу, а постепенно, в течение ряда лет.
Первые предложения поступили в 1971 году от рабочей группы CODASYL
(Conference on Data Systems and Languages — Конференция по языкам и сис­
темам данных), которая обосновала необходимость использования двухуров­
невого подхода, построенного на основе выделения системного представления
и пользовательских представлений.
В 1975 году Комитет планирования стандартов и норм SPARC (Standards Plan­
ning and Requirements Committee) Американского национального института
стандартов ANSI (American National Standards Institute) предложил обобщен­
ную структуру систем баз данных, признав необходимость использования
трехуровневой архитектуры, которая и была официально признана в 1978 году.
Описание структуры данных на любом уровне называется схемой. Существу­
ет три различных типа схем базы данных, которые определяются в соответ­
ствии с уровнями абстракций трехуровневой архитектуры. На самом
высоком уровне имеется несколько внешних схем или подсхем, которые соот­
ветствуют разным представлениям данных. На концептуальном уровне опи­
сание базы данных называют концептуальной схемой, а на самом низком
уровне абстракции — внутренней схемой.
Основным назначением трехуровневой архитектуры является обеспечение
независимости от данных. Суть этой независимости заключается в том, что
изменения на нижних уровнях никак не влияют на верхние уровни. Разли­
чают два типа независимости от данных: логическую и физическую.

Группы
пользователей

1

ПП1

FlilN

ПП2

Внешний уровень

Концептуальный уровень

JL -

Внутренний уровень

т
JL
БАЗА

ДАННЫХ

Рис. 2 .1 . Трехуровневая архитектура описания СУБД

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

2.1.1. Внешний уровень
Внешний уровень — это пользовательский уровень. Пользователем может
быть программист, или конечный пользователь, или администратор базы
данных. Представление базы данных с точки зрения пользователей называ­
ется внешним представлением. Каждая группа пользователей выделяет в мо­
делируемой предметной области, общей для всей организации, те сущности,
атрибуты и связи, которые ей интересны. Выражая их в наиболее удобной для
себя форме, она формирует свое пользовательское представление, причем од­
ни и те же данные могут отображаться по-разному в разных пользователь­
ских представлениях. Например, в информационной системе ВУЗ пользова­
теля из бухгалтерии будет интересовать информация о студентах, которым
должна быть начислена стипендия, но его совершенно не будет интересо­
вать информация об успеваемости всех студентов и многое другое.
Эти частичные или переопределенные описания БД для отдельных групп
пользователей или ориентированные на отдельные аспекты предметной об­
ласти называют подсхемой.
При рассмотрении внешнего уровня БД важно отметить, что каждый тип
пользователей может применять для работы с БД свой язык общения. Ко­
нечные пользователи употребляют либо язык запросов, либо специальный
язык, поддерживаемый приложениями и вызывающий определенные для
пользователя экранные формы и пользовательские меню. Прикладные про­
граммисты чаще применяют либо языки высокого уровня, например С, Pas­
cal и т. п., либо специальные языки СУБД. Языки последнего типа относят
к языкам четвертого поколения.
Какой бы язык высокого уровня не использовался (он в этом случае назы­
вается базовым), он должен включать в себя и подъязык для работы с дан­
ными. Система может поддерживать любое количество подъязыков данных,
любое количество базовых языков. Но язык SQL поддерживается практиче­
ски всеми системами. Он может использоваться и как встроенный в другие
языки, и как отдельный самостоятельный язык запросов.

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

структура всей базы данных. Для каждой базы данных имеется только одна
концептуальная схема.
Концептуальная схема должна содержать:
□ объекты и их атрибуты;
□ связи между объектами;
□ ограничения, накладываемые на данные;
□ семантическую информацию о данных;
□ обеспечение безопасности и поддержки целостности данных.
Концептуальный уровень поддерживает каждое внешнее представление,
в том смысле, что любые доступные пользователю данные должны содер­
жаться (или могут быть вычислены) на этом уровне. Однако этот уровень не
содержит никаких сведений о методах хранения данных.

2.1.3. Внутренний уровень
Внутренний уровень является третьим уровнем архитектуры БД. Внутреннее
представление не связано с физическим уровнем, так как физический уро­
вень хранения информации обладает значительной индивидуальностью для
каждой системы. На внутреннем же уровне все эти индивидуальности не
учитываются, и область хранения представляется как бесконечное линейное
адресное пространство.
На нижнем уровне находится внутренняя схема, которая является полным
описанием внутренней модели данных. Для каждой базы данных существует
только одна внутренняя схема.
Внутренняя схема описывает физическую реализацию базы данных и пред­
назначена для достижения оптимальной производительности и обеспечения
экономного использования дискового пространства. Именно на этом уровне
осуществляется взаимодействие СУБД с методами доступа операционной
системы (вспомогательными функциями хранения и извлечения записей
данных) с целью размещения данных на запоминающих устройствах, созда­
ния индексов, извлечения данных и т. д. На внутреннем уровне хранится
следующая информация:
□ распределение дискового пространства для хранения данных и индексов;
□ описание подробностей сохранения записей (с указанием реальных раз­
меров сохраняемых элементов данных);
□ сведения о размещении записей;
□ сведения о сжатии данных и выбранных методах их шифрования.
СУБД отвечает за установление соответствия между всеми тремя типами
схем разных уровней, а также за проверку их непротиворечивости.

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

2.2. Функции СУБД
В СУБД часто выделяют систему разработчика и систему времени выполне­
ния. Система разработчика включает в себя компоненты СУБД, которые
используются на этапе создания приложения БД. К ним относятся средства
описания схем и подсхем БД, генераторы форм и кода, средства визуальной
разработки приложения. Система времени выполнения — это часть СУБД,
необходимая при работе с базой данных. В основном ее назначение состоит
в обработке запросов к БД и в поддержании ее целостности.
В этом разделе рассматриваются функции, которые должна обеспечивать
типичная СУБД.

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

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

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

состояние БД после любого аппаратного или программного сбоя. Обычно
рассматриваются два возможных вида аппаратных сбоев:
□ мягкие сбои, которые можно трактовать как внезапную остановку работы
компьютера (например, аварийное выключение питания);
□ жесткие сбои, характеризуемые потерей информации на носителях
внешней памяти.
Примерами программных сбоев могут быть: аварийное завершение работы
СУБД (по причине ошибки в программе или в результате некоторого аппа­
ратного сбоя) или аварийное завершение пользовательской программы,
в результате чего некоторая транзакция остается незавершенной. Первую
ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя;
при возникновении последней требуется ликвидировать последствия только
одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать
некоторой дополнительной информацией. Другими словами, поддержание
надежности хранения данных в БД требует избыточности хранения данных,
причем та часть данных, которая используется для восстановления, должна
храниться особо надежно. Наиболее распространенным методом поддержания
такой избыточной информации является ведение журнала изменений БД.

2.2.4. Поддержка языков БД
Для работы с базами данных используются специальные языки, называемые
языками баз данных.
В современных СУБД обычно поддерживается единый интегрированный
язык, содержащий все необходимые средства для работы с БД, начиная от
ее создания, и обеспечивающий базовый пользовательский интерфейс с ба­
зами данных. Стандартным языком наиболее распространенных в настоящее
время реляционных СУБД является язык SQL (Structured Query Language —
язык структурированных запросов). Язык SQL позволяет определять схему
реляционной БД и манипулировать данными.

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

зависит от типа используемой СУБД. Но, тем не менее, можно выделить
следующую информацию, которая обычно содержится в словаре данных:
□ имена, типы и размеры элементов данных;
□ имена связей;
□
□
□
□

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

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

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

2.2.8. Контроль доступа к данным
СУБД должна иметь механизм, гарантирующий возможность доступа к базе
даных только санкционированных пользователей и защищающий ее от лю­
бого несанкционированного доступа.

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

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

2.2.10. Поддержка целостности данных
Термин целостность используется для описания корректности и непротиво­
речивости хранимых в БД данных. Реализация поддержки целостности дан­
ных предполагает, что СУБД должна содержать сведения о тех правилах,
которые нельзя нарушать при работе с данными, и обладать инструментами
контроля за тем, чтобы данные и их изменения соответствовали заданным
правилам.
Таким образом, целостность связана с качеством самих данных и, следова­
тельно, с обеспечением безопасности и может рассматриваться как еще
один тип защиты базы данных. Аспекты целостности необходимо учитывать

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

2.2.11. Поддержка независимости от данных
СУБД должна обладать инструментами поддержки независимости про­
грамм от фактической структуры данных. Обычно это достигается за счет
реализации механизма поддержки представлений или подсхем. Этот меха­
низм включает несколько типов допустимых изменений физических харак­
теристик базы данных, которые никак не влияют на представления. Как
правило, система легко адаптируется к добавлению нового объекта, атрибута
или связи, но не к их удалению. Однако добиться полной логической неза­
висимости от данных значительно сложнее.

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

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

СУБД состоит из нескольких программных компонентов, каждый из кото­
рых нацелен на выполнение специфической операции.
Логически в современной реляционной СУБД можно выделить внутреннюю
часть — ядро СУБД, компилятор языка БД (обычно SQL), подсистему под­
держки времени выполнения, набор утилит. В некоторых системах эти части
выделяются явно, в других — нет, но логически такое разделение можно
провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управле­
ние буферами оперативной памяти, управление транзакциями и журнализа­
цию. Соответственно можно выделить такие компоненты ядра, как менед­
жер данных, менеджер буферов, менеджер транзакций и менеджер журнала.
Функции этих компонентов взаимосвязаны, и для обеспечения корректной
работы СУБД все эти компоненты должны взаимодействовать по тщательно
продуманным и проверенным протоколам.
Ядро СУБД обладает собственным интерфейсом, недоступным пользовате­
лям напрямую и используемым в программах, производимых компилятором
SQL и утилитах БД. Ядро СУБД является основной резидентной частью
СУБД. При использовании архитектуры "клиент — сервер" ядро является
основной составляющей серверной части системы.
В этом подразделе хотелось бы показать обобщенную компонентную струк­
туру СУБД. Но сделать это практически невозможно, поскольку она очень
сильно различается в разных системах. Поэтому здесь рассматривается один
из возможных вариантов структуры СУБД, где представлены следующие ос­
новные программные компоненты среды СУБД.
□ Процессор запросов преобразует запросы в последовательность низко­
уровневых инструкций для контроллера базы данных.
□ Компилятор языка определения данных преобразует его команды в на­
бор таблиц, содержащих метаданные. Затем эти таблицы сохраняются
в системном каталоге, а управляющая информация — в заголовках фай­
лов с данными.
□ Препроцессор языка манипулирования данными преобразует внедренные
в прикладные программы его операторы в вызовы стандартных функций
базового языка. Для генерации соответствующего кода препроцессор
этого языка должен взаимодействовать с процессором запросов. Основ­
ной его функцией является компиляция операторов языка БД в некото­
рую выполняемую программу. Поскольку языки этих систем являются
непроцедурными, то компилятор, используя достаточно сложные методы
оптимизации операторов, должен решить, каким образом выполнять
оператор языка.
□ Контроллер словаря. Контроллер словаря управляет доступом к систем­
ному каталогу и обеспечивает работу с ним. Системный каталог доступен
большинству компонентов СУБД.

□ Контроллер файлов манипулирует предназначенными для хранения дан­
ных файлами и отвечает за распределение доступного дискового про­
странства. Он создает и поддерживает список структур и индексов, опре­
деленных во внутренней схеме. Однако контроллер файлов не управляет
физическим вводом и выводом данных непосредственно, а лишь передает
запросы соответствующим методам доступа, которые считывают данные
в системные буферы или записывают их оттуда на диск.
□ Контроллер базы данных взаимодействует с запущенными пользователя­
ми прикладными программами и запросами. Контроллер базы данных
принимает запросы и проверяет внешние и концептуальные схемы для
определения тех концептуальных записей, которые необходимы для
удовлетворения требований запроса. Затем контроллер базы данных вы­
зывает контроллер файлов для выполнения поступившего запроса. В со­
став контроллера базы данных входят следующие основные программные
компоненты:
• контроль прав доступа проверяет наличие у данного пользователя
полномочий для выполнения затребованной операции;
• процессор команд получает управление после проверки полномочий
пользователя для выполнения затребованной операции;
• средства контроля целостности осуществляют в случае выполнения
операций, которые изменяют содержимое базы данных, проверку того,
удовлетворяет ли затребованная операция всем установленным огра­
ничениям поддержки целостности данных;
• оптимизатор запросов определяет оптимальную стратегию выполнения
запроса;
• контроллер транзакций осуществляет требуемую обработку операций,
поступающих в процессе выполнения транзакций;
• планировщик отвечает за бесконфликтное выполнение параллельных
операций с базой данных и управляет относительным порядком вы­
полнения операций, затребованных в отдельных транзакциях;
• контроллер восстановления гарантирует восстановление базы данных до
непротиворечивого состояния при возникновении сбоев;
• контроллер буфера отвечает за перенос данных между оперативной па­
мятью и жестким диском.

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

для выполнения всех вычислительных операций языков программирования
высокого уровня.
Многие СУБД поддерживают возможность внедрения операторов подъязы­
ков данных в языки высокого уровня, таких, например, как COBOL,
Fortran, Pascal, Ada, С. Как уже отмечалось, в этом случае язык высокого
уровня считается базовым, а подъязык данных — внедренным.
Для реализации данного внедрения СУБД должна иметь свой механизм.
Наиболее часто откомпилированный объектный модуль базового языка
компонуется с библиотекой, в которую помещены функции подъязыка дан­
ных. После этого полученный программный текст будет готов к выполне­
нию. Помимо механизма внедрения, для большинства подъязыков данных
также предоставляются средства интерактивного выполнения их операторов,
вводимых пользователем непосредственно со своего терминала.
С точки зрения пользователя базовый язык и подъязык данных могут быть
сильно связанными, если они почти неразличимы, и слабо связанными, ес­
ли они легко различаются. Некоторые специалисты в области обработки
данных прогнозируют постепенное продвижение к более сильно связанным
системам, способным предоставить пользователям более унифицированный
набор возможностей.
В СУБД поддерживается несколько специализированных по своим функци­
ям подъязыков. Их можно разбить на две категории:
□ язык определения данных БД — ЯОД (DDL — Data Definition Language);
□ язык манипулирования данными — ЯМД (DML — Data Manipulation
Language).

2.4.1. Язык определения данных
Язык определения данных — описательный язык, с помощью которого опи­
сывается предметная область: именуются объекты, определяются их свойст­
ва и связи между объектами. Он используется главным образом для опреде­
ления логической структуры БД.
Схема базы данных, выраженная в терминах специального языка определения
данных, состоит из набора определений. Язык ЯОД используется как для
определения новой схемы, так и для модификации уже существующей.
Следуя трехуровневой архитектуре БД, можно было бы предположить наличие
подъязыков ЯОД для описания схем для каждого из трех уровней. Однако
сложилось так, что в настоящее время используется только один общий язык
ЯОД для описания внешних и концептуальных схем.
Результатом компиляции ЯОД — операторов является набор таблиц, храни­
мый в системном каталоге, в котором содержатся метаданные — т. е. дан­
ные, которые включают определения записей, элементов данных, а также

другие объекты, представляющие интерес для пользователей или необходи­
мые для работы СУБД. Перед доступом к реальным данным СУБД обычно
обращается к системному каталогу.
Таким образом, язык ЯОД предназначен только для описания схем, его нель­
зя использовать для управления данными. Схема создается в процессе проек­
тирования базы данных, причем предполагается, что она изменяется доста­
точно редко.

2.4.2. Языки манипулирования данными
Язык манипулирования данными содержит набор операторов манипулирова­
ния данными, т. е. операторов, позволяющих заносить данные в БД, уда­
лять, модифицировать или выбирать существующие данные. Хотя, как было
подчеркнуто выше, схема БД изменяется достаточно редко, однако содер­
жащаяся в базе данных информация может меняться часто — например,
всякий раз при вставке сведений о новом сотруднике или студенте. Сово­
купность информации, хранящейся в базе данных в любой определенный
момент времени, называется состоянием базы данных. Следовательно, од­
ной и той же схеме базы дайных может соответствовать множество ее раз­
личных состояний.
Гибкость управления БД определяется множеством операций, разрешенных
над данными. С помощью этих операций БД переводится из одного состоя­
ния в другое.
Множество операций над данными можно классифицировать следующим
образом:
□ операции селекции;
□ действия над данными:
• выборка — чтение экземпляра записи из БД;
• включение — ввод экземпляра записи в БД с установкой его связей;
• удаление — исключение экземпляра записи из БД с установкой новых
связей;
• модификация — изменение содержимого экземпляра записи и кор­
рекция связей при необходимости.
Таким образом, одна из основных функций СУБД заключается в поддержке
языка манипулирования данными, с помощью которого пользователь может
создавать выражения для выполнения перечисленных выше операций
с данными. Понятие манипулирования данными применимо как к внешне­
му и концептуальному уровням, так и к внутреннему уровню. Однако на
внутреннем уровне для этого необходимо определить очень сложные проце­
дуры низкого уровня, способные обеспечить эффективный доступ к дан­
ным. На более высоких уровнях, наоборот, акцент переносится в сторону

большей простоты использования, и основные усилия направляются на
обеспечение эффективного взаимодействия пользователя с системой.
Языки манипулирования данными делятся на два типа. Это разделение обу­
словлено коренным различием в подходах к работе с данными, а следовательно,
различием в базовых конструкциях в работе с данными.
Первый тип — это процедурный ЯМД.
Второй тип — это декларативный (непроцедурный) ЯМД.
Работая с процедурным ЯМД, пользователь должен четко представлять себе то,
что он должен получить, и как он может это сделать с помощью средств ЯМД.
Эти средства представляют собой операторы над данными, которые необходимо
выполнить в определенном порядке для получения требуемой информации.
Обычно такой процедурный язык позволяет извлечь запись, обработать ее и,
в зависимости от полученных результатов, извлечь другую запись, которая
должна быть подвергнута аналогичной обработке и т. д. Подобный процесс
извлечения данных продолжается до тех пор, пока не будут извлечены все
запрашиваемые данные. Языки ЯМД сетевых и иерархических СУБД обыч­
но являются процедурными. В таких процедурных языках, как правило,
записи рассматриваются по отдельности.
К процедурным языкам манипулирования данными относятся и языки, под­
держивающие операции реляционной алгебры, которую основоположник тео­
рии реляционных баз данных Э. Ф. Кодд ввел для управления реляционной
базой данных. Реляционная алгебра — это процедурный язык обработки реля­
ционных таблиц, где в качестве операндов выступают таблицы в целом.
Декларативные языки ЯМД предоставляют пользователю средства, позво­
ляющие указать лишь то, какие данные требуются. Решение вопроса о том,
как их следует извлекать, берет на себя процессор данного языка, работаю­
щий с целыми наборами записей.
Непроцедурные языки ЯМД позволяют определить весь набор требуемых
данных с помощью одного оператора извлечения или обновления. СУБД
транслирует выражение на языке ЯМД в процедуру (или набор процедур),
которая обеспечивает манипулирование затребованным набором записей.
Данный подход освобождает пользователя от необходимости знать детали
внутренней реализации структур данных и особенности алгоритмов, исполь­
зуемых для извлечения и возможного преобразования данных. Непроцедур­
ные языки обычно проще понять и использовать, чем процедурные языки.
Реляционные СУБД обычно включают поддержку непроцедурных языков
манипулирования данными — чаще всего это бывает язык структурирован­
ных запросов SQL или язык запросов по образцу QBE.
Вообще ход исторического развития языков типа ЯМД идет по пути
предоставления пользователю таких возможностей, которые бы с его сторо­
ны требовали минимальных усилий и минимальных знаний по поводу того,

как будут реализовываться эти возможности. При сегодняшнем наличии ИС
во всех сферах жизни человека такое стремление вполне понятно. Понятно
и то, что приоритет в применении в реальных СУБД получают именно те
языки, которые с этой проблемой справляются успешнее.
В настоящее время нормой является поддержка декларативного языка SQL,
в основе которого лежит реляционное исчисление, также введенное Э. Коддом.
Этот язык стал стандартом для языков реляционных баз данных, что позво­
ляет использовать один и тот же синтаксис и структуру команд при перехо­
де от одной СУБД к другой. Сейчас практически все крупнейшие разработ­
чики СУБД создают свои продукты с использованием SQL.
Следует отметить, что язык SQL имеет сразу два компонента: язык DDL
(ЯОД) для описания структуры базы данных, и язык DML (ЯМД) для
выборки и обновления данных.
Другим широко используемым языком обработки данных является язык
QBE, который заслужил репутацию одного из самых простых способов из­
влечения информации из базы данных. Особенно это ценно для пользовате­
лей, не являющихся профессионалами в этой области. Язык предоставляет
графические средства создания запросов на выборку данных с использова­
нием шаблонов. Ответ на запрос также представляет собой графическую
информацию.
Часть непроцедурного языка ЯМД, которая отвечает за извлечение данных,
называется языком запросов. Язык запросов можно определить как высоко­
уровневый узкоспециализированный язык, предназначенный для удовлетво­
рения различных требований по выборке информации из базы данных.
Анализируя тенденции в развитии языков обработки данных, можно пред­
положить, что и в дальнейшем оно пойдет, скорее всего, по направлению
развития непроцедурных языков с использованием компонентов высокого
уровня, которые часто называют "инструментами четвертого поколения"
Ожидается, что языки четвертого поколения позволят повысить производи­
тельность работы на порядок за счет ограничения типов задач, которые
можно будет решать с их помощью.
Современные СУБД уже предлагают нам целый ряд упомянутых инструмен­
тов — это различного рода генераторы:
□ экранных форм для быстрого создания шаблонов ввода и отображения
данных;
□ отчетов на основе хранимой в базе информации;
□ запросов к базе данных;
□ графического представления данных в виде различного рода диаграмм;
□ приложений для создания программ обработки данных.

2.5. Архитектура
многопользовательских СУБД
Архитектура систем баз данных ANSI/SPARC в зависимости от точки зре­
ния определяет для одной и той же БД три различных уровня описания.
Основным назначением трехуровневой архитектуры является обеспечение
независимости от данных. В этом разделе предлагается посмотреть на базу
данных несколько иначе, а именно — кто и в каком порядке может исполь­
зовать данные, хранимые в базе данных.
Если компьютер работает в монопольном режиме, то и размещенная на
персональном компьютере БД будет функционировать также в монопольном
режиме даже в том случае, если с БД работают несколько пользователей,
поскольку они могут обращаться к ней только последовательно.
При переходе к многопользовательскому режиму, а здесь есть только один
путь — интеграция компьютеров в локальные сети, как следствие этого про­
цесса, возникает возможность распределения приложений, работающих
с единой базой данных, и даже самой базы данных по созданной сети.

2.5.1. Тенденции развития
многопользовательских систем
Традиционной архитектурой многопользовательских систем, которая сложи­
лась до появления ПК, считалась схема, при которой один мощный компь­
ютер с единственным процессором был соединен с несколькими пользова­
тельскими терминалами, не имеющими для хранения и обработки данных
собственных ресурсов. Системы распределенной обработки данных строи­
лись на мультипрограммных операционных системах и использовали цен­
трализованное хранение БД на устройствах внешней памяти центральной
ЭВМ и терминальный многопользовательский режим доступа к ней. СУБД
и приложения также располагались на центральной ЭВМ. Пользовательские
приложения обращались к необходимым службам СУБД. Таким же образом
сообщения возвращались назад на пользовательский терминал. Естественно,
что при такой архитектуре основная и чрезвычайно большая нагрузка воз­
лагалась на центральный компьютер, который должен выполнять не только
действия прикладных программ и СУБД, но и большую работу по обслужи­
ванию терминалов (рис. 2.2).
Первой системой, работающей в многопользовательском режиме, была
СУБД SYSTEM R, разработанная фирмой IBM. В ней были реализованы
основные принципы синхронизации, применяемые при распределенной об­
работке данных, которые до сих пор являются базисными практически во
всех коммерческих СУБД.

Рис. 2.2. Схема ранней многопользовательской системы

С момента появления СУБД SYSTEM R прошел длительный период време­
ни. В этот период происходили значительные колебания в вычислительных
ресурсах и схемах их применения, используемых для хранения и обработки
информации. Наблюдались и отдельные тенденции в этих колебаниях:
□ Downsizing — децентрализация;
□ UpSizing — централизация;
□ RightSizing — определение размера и схемы в соответствии с реальной
ситуацией.
Первая тенденция была вызвана к жизни движением от отдельных Mainframe-систем к открытым распределенным системам, использующим сети
персональных компьютеров, и привела к более эффективным с точки зре­
ния эксплуатационных затрат системам. Этот подход отражает организаци­
онную структуру компании, логически состоящую из отдельных подразде­
лений, которые распределены по разным офисам.
Встречный по отношению к только что рассмотренной тенденции процесс
происходил практически параллельно с первым и был обусловлен бурным
развитием персональных компьютеров, появлением локальных сетей. Высо­
кие темпы роста производительности и функциональных возможностей ПК
позволили разработчикам профессиональных СУБД выпустить в свет ряд
систем, получивших широкое распространение.
Однако рано или поздно встречные процессы должны были погасить в не­
которой степени амплитуду подобных колебаний. В результате этого господ­
ствующее положение должна была занять тенденция создания информаци­
онных систем на такой платформе, которая точно соответствовала бы ее
масштабам и задачам.

Различные варианты реализации режимов работы систем баз данных можно
представить в виде схемы (рис. 2.3).

Технологии
использования

Однопользова­
тельская БД

Многопользова­
тельская БД

С последователь!
ным до ступ ом ^

Централизо­
ванная БД

С параллель» '
ным доступом

Распреде­
ленная БД

Рис. 2 .3 . Технологии использования БД

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

2.5.2. Модели двухуровневой
технологии "клиент — сервер"
Еще раз подчеркнем, что общая цель систем баз данных — поддержка раз­
работки и выполнения приложений баз данных. Систему баз данных можно
рассматривать как систему, где осуществлено распределение процесса вы­
полнения по принципу взаимодействия двух программных процессов, один
из которых в этой модели называется "клиентом", а другой, обслуживающий
клиента, — сервером (машина, хранящая базы данных). Клиентский процесс
запрашивает некоторые услуги, а серверный процесс обеспечивает их вы­
полнение. При этом предполагается, что один серверный процесс может
обслужить множество клиентских процессов (рис. 2.4).
База
данных

Рис. 2.4. Структура системы БД с выделением клиентов и сервера

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

взаимосвязи между ними. Обычно в приложении выделяются следующие
группы функций:
□ функции ввода и отображения данных;
□ прикладные функции, определяющие основные алгоритмы решения за­
дач приложения;
□ функции обработки данных внутри приложения;
□ функции управления информационными ресурсами;
□ служебные функции, играющие роль связок между функциями первых
четырех групп.
Функции ввода и отображения данных — презентационная часть приложения —
определяются тем, что пользователь видит на своем экране, когда работает
приложение. Поэтому основными задачами этой части приложения являются:
□ формирование экранных изображений;
□ чтение и запись в экранные формы информации;
□ управление экраном;
□ обработка движений мыши и нажатий клавиш клавиатуры.
Прикладные функции определяют основные алгоритмы решения конкретных
задач приложения. Обычно код приложения пишется с использованием раз­
личных языков программирования, таких как С, Cobol, SmallTalk, Pascal.
Функции обработки данных связаны с обработкой данных внутри приложения.
Данными управляет собственно СУБД. Для обеспечения доступа к данным
используются язык запросов и средства манипулирования данными стан­
дартного языка SQL. Обычно операторы языка SQL встраиваются в языки,
которые используются для написания кода приложения.
Функции управления информационными ресурсами (процессор управления дан­
ными) — это собственно СУБД, которая обеспечивает хранение и управле­
ние базами данных.
Служебные функции выполняют роль связок между функциями других групп.
В монолитном исполнении все перечисленные компоненты приложения
располагаются в единой среде и комбинируются внутри одной исполняемой
программы.
В децентрализованной архитектуре эти части приложения распределяются
по сети.
Если все пять компонентов приложения распределяются только между дву­
мя процессами, которые выполняются на двух платформах: на клиенте и на
сервере, то такая модель называется двухуровневой. Она имеет несколько ос­
новных разновидностей. Рассмотрим их.

Файловый сервер

Модель файлового сервера называется моделью удаленного управления данными.
Данная модель предполагает следующее распределение функций: на клиенте
располагаются почти все части приложения: презентационная часть приложе­
ния, прикладные функции, а также функции управления информационными
ресурсами. Файловый сервер содержит файлы, необходимые для работы при­
ложений и самой СУБД и поддерживает доступ к файлам (рис. 2.5).
Файлсервер

База
данных
Команды

Локальная
Клиент

Файлы
Клиент

Клиент

Рис. 2.5. Модель файлового сервера

СУБД посылает запросы файловому серверу по всем необходимым ей дан­
ным. Запрос клиента формулируется в командах ЯМД. СУБД переводит
этот запрос в последовательность файловых команд. Каждая файловая
команда вызывает перекачку блока информации на клиента. Далее на кли­
енте СУБД анализирует полученную информацию, и если в полученном
блоке не содержится ответ на запрос, то принимается решение о передаче
следующего блока информации и т. д. Передача информации с сервера про­
изводится до тех пор, пока не будет получен ответ на запрос клиента.
Поскольку передача файлов представляет собой длительную процедуру, та­
кой подход характеризуется значительным сетевым трафиком, что может
привести к снижению производительности всей системы в целом.
Помимо этого недостатка использование файлового сервера несет еще и
другие:
□ на каждой рабочей станции должна находиться полная копия СУБД;
□ управление параллельностью, восстановлением и целостностью усложня­
ется, поскольку доступ к одним и тем же файлам могут осуществлять
сразу несколько экземпляров СУБД;
□ узкий спектр операций манипулирования данными, который определяет­
ся только файловыми командами;
□ защита данных осуществляется только на уровне файловой системы.
3 Зак. 3303

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

В модели удаленного доступа база данных также хранится на сервере. На
сервере же находится и ядро СУБД. На клиенте располагаются части при­
ложения, поддерживающие функции ввода и отображения данных и при­
кладные функции.
Клиент обращается к серверу с запросами на языке SQL. Структура модели
удаленного доступа приведена на рис. 2.6.
Сервер
с СУБД

База
данных
SQL-запрос,
Клиент

Локальная
— сеть _

Результаты
запроса
Клиент

Клиент

Рис. 2 .6 . Модель удаленного доступа

По отношению к файловому серверу данный подход имеет серьезные пре­
имущества. С одной стороны, установка компонента представления и при­
кладного компонента на клиентский компьютер не позволяет перегрузить
сервер БД, сводя к минимуму общее число процессов в операционной сис­
теме. С другой стороны, серверу БД выделяются только свойственные ему
функции; он загружается операциями обработки данных, запросов и тран­
закций.
Сервер принимает и обрабатывает запросы со стороны клиентов, проверяет
полномочия пользователей, гарантирует соблюдение ограничений целостно­
сти, выполняет обновление данных, выполняет запросы и возвращает ре­
зультаты клиенту, поддерживает системный каталог, обеспечивает парал­
лельный доступ к базе данных и ее восстановление. К тому же резко
уменьшается загрузка сети, так как по ней от клиентов к серверу пере­
даются не файловые команды, а запросы на SQL, и их объем существенно

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

Технологию "клиент — сервер" поддерживают большинство современных
СУБД: Informix, Ingres, Sybase, Oracle, MS SQL Server. Только та технология,
которую они поддерживают, является дальнейшим развитием только что
рассмотренной модели удаленного доступа к данным. В основу данной мо­
дели добавлен механизм хранимых процедур и механизм триггеров.
Механизм хранимых процедур позволяет создавать подпрограммы, работаю­
щие на сервере и управляемые его процессами. Подобные подпрограммы
могут быть активизированы вызывающим их приложением. Кроме того, они
могут быть вызваны правилами, поддерживающими целостность данных,
или триггерами. Хранимые процедуры тесно взаимодействуют с оптимиза­
тором сервера, что позволяет получить высокую производительность при
обработке данных.
Таким образом, размещение на сервере хранимых процедур означает, что
прикладные функции приложения разделены между клиентом и сервером.
Клиентское приложение обращается к серверу с командой запуска хра­
нимой процедуры, а сервер выполняет эту процедуру и регистрирует все из­
менения в БД, которые в ней предусмотрены. Сервер возвращает клиенту
данные, которые требуются клиенту либо для вывода на экран, либо для
выполнения той части прикладных функций, которые расположены на кли­
енте. Трафик обмена информацией между клиентом и сервером резко
уменьшается.
Централизованный контроль целостности базы данных в модели сервера баз
данных выполняется с использованием механизма триггеров. Триггеры так­
же являются частью БД.
Триггер — это особый тип хранимой процедуры, реагирующий на возникно­
вение определенного события в БД. Он активизируется при попытке изме­
нения данных — при операциях добавления, обновления и удаления. Триг­
геры определяются для конкретных таблиц БД. Они дают возможность

поддерживать целостность базы данных, не полагаясь на программное обес­
печение приложений. Ядро СУБД проводит контроль всех событий, которые
вызывают созданные и описанные триггеры в БД, и при возникновении со­
ответствующего события сервер запускает соответствующий триггер.
Триггер — это фильтр, применяемый после выполнения операции. Если
триггер вызывает ошибку в запросе, обновление информации не произво­
дится, а в приложение, выполняющее это действие, возвращается сообще­
ние об ошибке. Триггер рассматривается как единое целое — как одна тран­
закция, которая либо фиксируется, либо откатывается.
Внедрение триггеров незначительно влияет на производительность сервера и
часто используется для усиления приложений, выполняющих многокаскад­
ные операции в БД. Триггеры могут вызывать хранимые процедуры.
В данной модели (рис. 2.7) сервер является активным, потому что не только
клиент, но и сам сервер, используя механизм триггеров, может быть ини­
циатором обработки данных в БД. Поскольку функции клиента облегчены
переносом части прикладных функций на сервер, он в этом случае называ­
ется "тонким"
Сервер
с СУБД
Триггеры

чО<ранимые^ Вызов
процедуры

Клиент

хранимых
процедур

III

Результаты
для вывода

Локальная
сеть
Клиент

Рис. 2 .7 . Модель сервера БД

И хранимые процедуры, и триггеры хранятся в словаре БД, они могут быть
использованы несколькими клиентами, что существенно уменьшает дубли­
рование алгоритмов обработки данных в разных клиентских приложениях.
Для написания хранимых процедур и триггеров используется расширение
стандартного языка SQL — встроенный SQL.
При всех положительных качествах данной модели у нее все же есть один
недостаток — очень большая загрузка сервера.

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

Клиент

Сервер

► Сервер 1

► Сервер 2

Рис. 2.8. Топологии двухуровневых систем с архитектурой "клиент — сервер"
(а — "один клиент — один сервер"; б — "несколько клиентов — один сервер";
в — "несколько клиентов — несколько серверов”)

Первым шагом в создании механизма организации взаимодействия процес­
сов типа "клиент" и "сервер" можно считать выделение функции управления
данными в самостоятельную группу — сервер, который позволил, в частно­
сти, поместить сервер на одну машину, а программный интерфейс с пользо­
вателем — на другую, осуществляя взаимодействие между ними по сети. То­
пологию такой модели взаимодействия пользователя с сервером относят
к типу "один клиент — один сервер" (рис. 2.8, а), где сервер обслуживает за­
просы только одного клиента и для обслуживания нескольких клиентов тре­
буется запустить соответствующее число серверов. Естественно, что реали­
зация такой модели предъявляла повышенные требования к ресурсам ЭВМ,
на которой запускались все серверные процессы, и отличалась сложностью
обеспечения взаимодействия серверных процессов.
Системы с выделенным сервером способны обрабатывать запросы от многих
клиентов. Модели с такой архитектурой имеют топологию "несколько кли­
ентов — один сервер" (рис. 2.8, б). Она позволяет значительно уменьшить
нагрузку на операционную систему и потребности в памяти, возникающие
при работе большого числа пользователей.
Дальнейшее развитие системы "клиент — сервер" получили при применении
СУБД для мультипроцессорных платформ, где количество актуальных сер­
веров может быть согласовано с количеством процессоров в системе. Топо­
логия подобных систем такова, что клиенты подключаются не к реальному

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

2.5.3. Сервер приложений. Трехуровневая модель
Эта модель является расширением двухуровневой модели и в ней вводится
дополнительный промежуточный уровень между клиентом и сервером. Ар­
хитектура трехуровневой модели приведена на рис. 2.9.

Рис. 2.9. Архитектура трехуровневой модели

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

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

Вопросы и упражнения
1. Изобразите схематично трехуровневую архитектуру базы данных и
объясните ее основное назначение.
2. Дайте сравнительную характеристику ее внешнему, концептуальному и
внутреннему уровням.
3. Поясните назначение словаря данных.
4. Перечислите основные функции СУБД.
5. Представьте основные программные компоненты среды СУБД.
6. На какие две категории можно разбить поддерживаемые в СУБД спе­
циализированные по своим функциям подъязыки?
7. Какие группы функций выделяются в приложении?
8. Опишите тенденции развития многопользовательских систем.
9. Что собой представляет технология "клиент — сервер"?
10. Дайте характеристику моделям двухуровневой технологии "клиентсервер"
11. Каковы достоинства и недостатки модели удаленного доступа к данным?
12. Охарактеризуйте модель сервера баз данных.
13. Чем вызвано появление трехуровневых моделей технологии "клиент —
сервер"? Какие преимущества у этих моделей?

Часть II
ПРОЕКТИРОВАНИЕ БАЗ ДАННЫХ

Глава 3. Концепции проектирования
Глава 4. Модели данных
Глава 5. Реляционная модель данных
Глава 6. Проектирование базы данных
Глава 7. Физическая организация данных
Глава 8. Управление реляционной базой данных

Глава 3

ÿÿiSSS

ИНЬ

Концепции проектирования

Данная часть книги посвящена наиболее важным проблемам процесса соз­
дания баз данных. Достаточно широко известно, что ключевая роль в дос­
тижении успеха большинства ИС принадлежит не используемому оборудо­
ванию, а программному обеспечению, которое за достаточно короткое
время превратилось в большие и сложные приложения.
Тем не менее следует отметить, что на этом пути в результате больших уси­
лий и затрат подчас создавались ненадежные, сложные в сопровождении и
обладавшие недостаточной производительностью программные продукты,
а сам процесс разработки и реализации многих крупных проектов затяги­
вался. Анализ, который провела в 1996 году в Великобритании специальная
группа по изучению организационных аспектов информатики, обнаружил,
что только 10—20% созданных систем можно отнести к категории успеш­
ных. Он также показал, что:
□ примерно 80—90% компьютеризованных систем не обладают требуемой
производительностью;
□ при разработке около 80% систем были превышены установленные для
этого временные и бюджетные рамки;
О разработка около 40% систем закончилась неудачно или была прекраще­
на до завершения работы;
П менее чем 40% систем предусматривали профессиональное обучение и
повышение квалификации пользователей во всем необходимом объеме.
Тщательное рассмотрение сложившейся ситуации позволило сделать вывод
о том, что при создании программного обеспечения неудачи были вызваны,
прежде всего, отсутствием приемлемой методологии разработки.
Для разрешения указанной проблемы к разработке программного обеспече­
ния был предложен структурный подход. Фундаментом его является концеп­
ция жизненного цикла информационных систем.

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

ЖЦБД включает в себя следующие основные этапы (рис. 3.1):
□ планирование разработки базы данных;
□ определение требований к системе;
□ сбор и анализ требований пользователей;
□ проектирование базы данных:
• концептуальное проектирование базы данных;
• логическое проектирование базы данных;
• физическое проектирование базы данных;

□ разработка приложений:
• проектирование транзакций;
• проектирование пользовательского интерфейса;
□ реализация;
□ загрузка данных;
□ тестирование;
□ эксплуатация и сопровождение:
• анализ функционирования и поддержка исходного варианта БД;
• адаптация, модернизация и поддержка переработанных вариантов.
Здесь представлен перечень основных этапов ЖЦБД. Естественно, что кон­
кретное наполнение каждого этапа в значительной степени зависит от
сложности разрабатываемого продукта. Рассматриваемый ниже материал
посвящен проектированию среды большого приложения баз данных, где
более подробно описываются основные действия, выполняемые на каждом
этапе жизненного цикла базы данных.
Для малых же приложений с небольшим количеством пользователей и в не­
которых других частных случаях, наоборот, жизненный цикл базы данных
может быть значительно упрощен в результате корректировки содержания
отдельных этапов.

3.1.1. Планирование
разработки базы данных
Содержание данного этапа — разработка стратегического плана, в процессе
которой осуществляется предварительное планирование конкретной систе­
мы управления базами данных. Общая информационная модель, созданная
на этом шаге, должна быть вновь проанализирована и, если нужно, измене­
на на последующем этапе, этапе разработки проекта реализации.
Планирование разработки базы данных состоит в определении трех основ­
ных компонентов: объема работ, ресурсов и стоимости проекта. Планирова­
ние разработки базы данных должно быть связано с общей стратегией по­
строения информационной системы организации.
Важной частью разработки стратегического плана является проверка осуще­
ствимости проекта, состоящая из нескольких частей.
Первая часть — проверка технологической осуществимости. Она состоит в
выяснении вопроса, существует ли оборудование и программное обеспече­
ние, удовлетворяющее информационным потребностям фирмы.
Вторая часть — проверка операционной осуществимости — выяснение на­
личия экспертов и персонала, необходимых для работы БД.

Третья часть — проверка экономической целесообразности осуществления
проекта. При исследовании этой проблемы весьма важно дать оценку ряду
факторов, в том числе и таким:
□ целесообразность совместного использования данных разными отделами;
□ величина риска, связанного с реализацией системы базы данных;
□ ожидаемая выгода от внедрения подлежащих созданию приложений;
□ время окупаемости внедренной БД;
□ влияние системы управления БД на реализацию долговременных планов
организации.
Планирование разработки баз данных также должно включать разработку
стандартов, которые определяют, как будет осуществляться сбор данных,
каким будет их формат, какая потребуется документация, как будет выпол­
няться проектирование и реализация приложений.
Для поддержки планирования разработки базы данных может быть создана
корпоративная модель данных, имеющая вид упрощенной ER-диаграммы.
Если результат проверки осуществимости проекта оказался положительным,
можно перейти к определению требований к проекту.

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

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

Информационные потребности выясняются с помощью анкет, опросов ме­
неджеров и работников фирмы, с помощью наблюдений за деятельностью
предприятия, а также отчетов и форм, которыми фирма пользуется в теку­
щий момент.
На данном этапе необходимо создать для себя модель движения важных ма­
териальных объектов и уяснить процесс документооборота. По каждому до­
кументу необходимо установить периодичность использования, определить
данные, необходимые для выполнения выделенных функций (анализируя
существующую и планируемую документацию, выясняют, как получается
каждый элемент данных, кем получается, где в дальнейшем используется,
кем контролируется).
Самое пристальное внимание должно быть уделено дублированию инфор­
мации, возможности появления ложной информации и причинам, которые
ведут к их появлению. Также на этом этапе желательно представить общие
параметры создаваемой базы.
В итоге собранная информация о каждой важной области применения
приложения и пользовательской группе должна включать следующие ком­
поненты: исходную и генерируемую документацию, подробные сведения
о выполняемых транзакциях, а также список требований с указанием их
приоритетов. На основании всей этой информации будут составлены спе­
цификации требований пользователей в виде набора документов, описы­
вающих деятельность предприятия с разных точек зрения.
Формализация собранной на этом этапе информации может быть повышена
с помощью методов составления спецификаций требований, к числу кото­
рых относятся, например, технология структурного анализа и проектирова­
ния, диаграммы потоков данных и графики "вход — процесс — выход"
Поскольку системы с неадекватной или неполной функциональностью бу­
дут лишь раздражать пользователей, а чрезмерно увеличенный набор функ­
циональных возможностей вызовет существенное усложнение системы,
важность этого этапа в процессе разработки БД сложно переоценить.

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

□ разработка предварительного варианта проекта, структура которого по­
зволяет удовлетворить требования, предъявляемые к производительности
системы.
В создании БД как модели ПрО выделяют:
О объектную (предметную) систему, представляющую фрагмент реального
мира;
□ информационную систему, описывающую некоторую объектную систему;
□ датологическую систему, представляющую информационную систему
с помощью данных.
Оптимальная модель данных должна удовлетворять таким критериям, как:
структурная достоверность, простота, выразительность, отсутствие избыточ­
ности, расширяемость, целостность, способность к совместному использо­
ванию.
Концептуальное проектирование базы данных

Первая фаза процесса проектирования базы данных заключается в создании
для анализируемой части предприятия концептуальной модели данных. По­
строение ее осуществляется в определенном порядке: в начале создаются
подробные модели пользовательских представлений данных; затем они ин­
тегрируются в концептуальную модель данных. Концептуальное проектиро­
вание приводит к созданию концептуальной схемы базы данных.
Существует два основных подхода к проектированию систем баз данных:
"нисходящий" и "восходящий"
При восходящем подходе, который применяется для проектирования про­
стых баз данных с относительно небольшим количеством атрибутов, работа
начинается с самого нижнего уровня — уровня определения атрибутов, ко­
торые на основе анализа существующих между ними связей группируются
в отношения. Полученные отношения в дальнейшем подвергаются процессу
нормализации, который приводит к созданию нормализованных взаимосвя­
занных таблиц, основанных на функциональных зависимостях между атри­
бутами.
Проектирование сложных баз данных с большим количеством атрибутов,
поскольку установить среди атрибутов все существующие функциональные
зависимости довольно затруднительно, осуществляется использованием
нисходящего подхода. Начинается этот подход с разработки моделей дан­
ных, которые содержат несколько высокоуровневых сущностей и связей,
затем работа продолжается в виде серии нисходящих уточнений низкоуров­
невых сущностей, связей и относящихся к ним атрибутов.
Нисходящий подход демонстрируется в концепции модели "сущность —
связь" (Entity-Relationship model — ER-модель) — самой популярной техно­
логии высокоуровневого моделирования данных, предложенной П. Ченом.

Модель "сущность — связь" относится к семантическим моделям. Семанти­
ческое моделирование данных, связанное со смысловым содержанием данных,
независимо от их представления в ЭВМ, изначально возникло с целью по­
вышения эффективности и точности проектирования баз данных. Методы
семантического моделирования оказались применимы ко многим пользова­
тельским проблемам и легко преобразуемы в сетевые, иерархические и ре­
ляционные модели.
Помимо "нисходящего" и "восходящего" подходов, для проектирования баз
данных могут применяться другие подходы, являющиеся некоторыми ком­
бинациями указанных.
В построении общей концептуальной модели данных выделяют ряд этапов.
□ Выделение локальных представлений, соответствующих обычно относи­
тельно независимым данным. Каждое такое представление проектируется
как подзадача.
□ Формулирование объектов, описывающих локальную предметную об­
ласть проектируемой БД, и описание атрибутов, составляющих структуру
каждого объекта.
□ Выделение ключевых атрибутов.
□ Спецификация связей между объектами. Удаление избыточных связей.
□ Анализ и добавление не ключевых атрибутов.
□ Объединение локальных представлений.
Построение концептуальной модели данных осуществляется на основе ана­
лиза описания предметной области на естественном языке, сделанного ко­
нечным пользователем. В процессе разработки концептуальная модель дан­
ных постоянно подвергается тестированию и проверке на соответствие
требованиям пользователей. Созданная концептуальная модель данных
предприятия является источником информации для фазы логического про­
ектирования базы данных.
Логическое проектирование базы данных

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

списка требований путем объединения требований всех типов пользо­
вателей.
При использовании метода интеграции представлений осуществляется слия­
ние отдельных локальных логических моделей данных, отражающих пред­
ставления разных групп пользователей, в единую глобальную логическую
модель данных всего предприятия.
В дальнейшем процесс проектирования БД должен опираться на опреде­
ленную модель данных (реляционная, сетевая, иерархическая), которая оп­
ределяется типом предполагаемой для реализации информационной систе­
мы СУБД. После чего сама концептуальная модель данных уточняется и
преобразуется в логическую модель данных.
В процессе разработки логическая модель данных должна постоянно под­
вергаться проверке как на соответствие требованиям пользователей, так и на
отсутствие избыточности данных, способной вызвать в будущем аномалии
обновления.
Построенная логическая модель данных в. дальнейшем будет востребована
на этапе физического проектирования, а также на этапе эксплуатации и со­
провождения уже готовой системы, позволяя наглядно представить любые
вносимые в базу данных изменения.
На этом шаге желательно создание следующих документов:
□ набора подсхем;
□ спецификаций для физического проектирования приложений;
□ руководства по разработке программ (интерфейсы с пользователем и
межпрограммные интерфейсы);
□ руководства по сопровождению БД.
Концептуальное и логическое проектирование — это итеративные процес­
сы, которые включают в себя ряд уточнений, продолжающиеся до тех пор,
пока не будет получен наиболее соответствующий структуре предприятия
продукт.
Физическое проектирование базы данных

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

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

3.1.5. Разработка приложений
Параллельно с проектированием системы базы данных выполняется разра­
ботка приложений. Главные составляющие данного процесса — это проек­
тирование транзакций и пользовательского интерфейса.
Проектирование транзакций

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

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

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

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

Прикладные программы реализуются с помощью языков третьего или чет­
вертого поколений. Некоторые элементы этих прикладных программ будут
представлять собой транзакции обработки базы данных, записываемые на
языке манипулирования данными СУБД и вызываемые из программ на ба­
зовом языке программирования. Кроме того, на этом этапе создаются дру­
гие компоненты проекта приложения — например, экраны меню, формы
ввода данных и отчеты. Следует учитывать, что многие существующие
СУБД имеют свои собственные инструменты, разработки четвертого поко­
ления, позволяющие быстро создавать приложения с помощью непроцедур­
ных языков запросов, разнообразных генераторов отчетов, генераторов
форм, генераторов графических изображений и генераторов приложений.
На этом этапе реализуются также используемые приложением средства за­
щиты базы данных и поддержки ее целостности. Одни из них описываются
с помощью языка DDL выбранной СУБД, а другие могут представлять со­
бой утилиты СУБД или прикладные программы, реализующие требуемые
функции.
Реализация этого, а также и более ранних этапов проектирования БД может
осуществляться с помощью инструментов автоматизированного проектирова­
ния и создания программ, которые принято называть CASE-инструментами
(Computer-Aided Software Engineering).
Все CASE-инструменты можно разбить на три категории:
□ CASE-инструменты высокого уровня, применяемые на начальных стади­
ях жизненного цикла разработки баз данных;
□ CASE-инструменты низкого уровня, применяемые на более поздних ста­
диях, начиная со стадии реализации;
□ интегрированные CASE-инструменты, используемые на всех стадиях
жизненного цикла системы.
Использование CASE-инструментов способствует повышению производи­
тельности труда разработчиков и обеспечению эффективности самой разра­
батываемой системы. Они обеспечивают поддержку представления структу­
ры БД в наглядной диаграммной форме, сохранение всей генерируемой
информации в словаре данных в виде взаимосвязанных между собой компо­
нентов с автоматической проверкой их непротиворечивости, способствуют
расширению использования стандартов как в ходе разработки программного
проекта, так и в работе самой организации.
Некоторые CASE-инструменты позволяют автоматически преобразовывать
отдельные элементы проекта в выполняемый код, что приводит к сокраще­
нию объема работы по созданию системы и количества ошибок, вносимых
в программы во время кодирования.

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

3.1.8. Тестирование
Тщательное тестирование должен проходить любой программный продукт,
тем более такой, как прикладные программы ИС. Стратегия тестирования
должна предполагать использование реальных данных и должна быть по­
строена таким образом, чтобы весь процесс выполнялся строго последова­
тельно и методически правильно. Помимо обнаружения имеющихся в при­
кладных программах и, возможно, в структурах базы данных ошибок, сбор
статистических данных на стадии тестирования позволяет установить пока­
затели надежности и качества созданного программного обеспечения.
Пользователи новой системы должны принимать в процессе ее тестирова­
ния самое активное участие с целью выяснения их неучтенных информаци­
онных потребностей. И если такие обнаружатся, в случае необходимости
осуществляется откат назад в процессе проектирования на те стадии, где
возможно внести необходимые изменения.
Для оценки законченности и корректности выполнения приложения базы
данных может использоваться несколько различных стратегий тестирования:
□ нисходящее тестирование;
□ восходящее тестирование;
□ тестирование потоков;
□ интенсивное тестирование.
Разные стратегии могут использоваться для разных частей системы и на раз­
ных этапах общего процесса. При тестировании системы целесообразно выбрать
такую стратегию, где система тестируется не как единое целое, а помодульно.

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

3.1.9. Эксплуатация и сопровождение
Данный этап является последним, но, безусловно, и самым продолжитель­
ным в жизненном цикле правильно спроектированной базы данных. Основ­
ные действия, связанные с этим заключительным этапом, ради осуществления

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

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

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

3.2. Концептуальное проектирование
В предыдущем разделе обсуждались вопросы создания и функционирования
баз данных в организационном контексте, в основании которого лежит кон­
цепция жизненного цикла базы данных, представленного в виде отдельных,
выполняемых в определенной последовательности этапов. Было показано,
что после завершения начальных этапов ЖЦБД, таких, как: планирование
разработки БД, определение требований к системе, сбор и анализ требова­
ний пользователей, которые очень специфичны для каждой информацион­
ной системы, начинается процесс проектирования базы данных. Этот про­
цесс включает в себя полный цикл разработки базы данных и начинается

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

3.2.1. Фундаментальные понятия
Для нормального функционирования информационной системы необходи­
мо, чтобы концептуальная модель адекватно отображала реалии той пред­
метной области, для которой она разрабатывается. Фундаментальными же
реалиями в концептуальном моделировании являются данные с их свойст­
вами и связи между ними. Причем такое моделирование помимо указания
о наличии определенных данных и связей нуждается и в указаниях относи­
тельно смыслового, семантического их содержания, независимого от пред­
ставления в ЭВМ. Методологии, позволяющие эффективно отображать
существующую смысловую содержательность реальности в конструкции мо­
дели, относятся к так называемым семантическим методологиям.
Методологии проектирования, основанные на идеях семантического моде­
лирования, относятся к нисходящим методологиям, поскольку они начина­
ются на высшем уровне абстракции и заканчиваются на уровне абстракции,
представленном конкретной структурой макета базы данных.
С начала семидесятых годов было предложено несколько концептуальных
семантических моделей данных, которые подходили к проблеме моделиро­
вания данных для проектирования БД с различных точек зрения. Наиболее
популярной семантической моделью стала уже упоминавшаяся раннее мо­
дель "сущность — связь" (ER-модель), предложенная П. Ченом в 1976 году,
которая с тех пор неоднократно усовершенствовалась самим Ченом и мно­
гими другими специалистами. Данная модель данных относится к высоко­
уровневым моделям и базируется на ряде концепций, используемых для
описания структуры базы данных.
Ниже излагается методология семантического моделирования, в которой ав­
тор постарался использовать наиболее подходящие, на его взгляд, современ­
ные идеи и терминологию, расширяющие возможности оригинальной модели
Чена. Здесь используется методология, скомбинированная из модели Чена и
понятий объектно-ориентированного моделирования. Модель Чена формиру­
ет базис концептуальной модели данных, а объектно-ориентированное моде­
лирование вносит некоторые существенные усовершенствования.

Методология моделирования данных, представляющая компьютерное ото­
бражение взаимосвязанных категорий реального мира в виде "объектов",
обладающих определенными "удостоверениями личности" и атрибутами,
может быть названа объектно-ориентированной.
В то время как семантическое моделирование данных в первую очередь уде­
ляет внимание структуре данных, предметом интересов объектно-ори­
ентированного подхода главным образом служит поведение объектов данных
и способы манипуляции данными, которые можно было бы сосредоточить
в возможностях языка (запросах, вычислениях, обновлении данных).
Сближение этих двух областей произошло, когда исследователи начали
применять понятия объектно-ориентированных языков к семантическим
структурам данных. В результате чего и появилось понятие объектноориентированной базы данных. На этом стыке дисциплин преобладает объ­
ектно-ориентированная терминология, поэтому здесь говорится об объектах,
а не о сущностях, как это принято в семантической терминологии Чена.
Кроме того, объектно-ориентированные языки выделяют несколько поня­
тий, отсутствующих в исходной модели П. Чена: "удостоверение личности"
объекта, иерархия надобъектов и подобъектов, наследование.
Главными элементами семантической модели данных являются типы объек­
тов, их атрибуты и типы связей. Типы объектов часто представляют в виде
существительных, а типы связей — в виде глаголов.

Рис. 3 .2 . Обозначения элементов диаграммы

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

3.2.2. Объекты
В процессе концептуального проектирования предметная область рассмат­
ривается как объектная система, которая имеет следующие составляющие:
□ объект;
□ средство;

□ время;
□ связь.
Объекты обозначают вещи, которые пользователи считают важными в моде­
лируемой части реальности. Объект — это то, о чем накапливается информа­
ция в информационной системе и что может быть однозначно идентифици­
ровано. Объекты могут быть атомарными или составными. Для составного
объекта определяется его внутренняя структура. Каждый объект в конкретный
момент времени характеризуется своим состоянием. Это состояние определя­
ется с помощью ограниченного набора средств и связей с другими объектами.
Составляющая время позволяет моделировать динамические системы.
Объект-mun (в дальнейшем просто объект) характеризуется независимым су­
ществованием и представляет множество объектов реального мира с одинако­
выми свойствами. Отдельные объекты, которые входят в данный тип, назы­
вают экземплярами объекта. Различают реальные и концептуальные объекты.
Примерами объектов могут быть люди, товары, дома, детали, книги и так да­
лее. Это реальные объекты. Концептуальными объектами будут навыки, орга­
низации, деловые операции, штатное расписание и многое другое.
Каждый объект имеет имя и изображается на диаграммах в виде прямо­
угольника, а экземпляр объекта — в виде точки в прямоугольнике данного
объекта (рис. 3.3).
Объект

Имя объекта

Экземпляр
объекта —

ШКОЛЬНИК
школьник

Рис. 3 .3 . Обозначение объекта на ER-диаграмме

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

3.2.3. Атрибуты
Атрибут — это поименованная характеристика объекта, с помощью которой
моделируется его свойство. Каждому объекту присущи свои атрибуты.
Например, объект КНИГА должен иметь такие атрибуты: наименование,

автор, издательство, год издания. У человека есть имя, дата рождения, рост,
вес, пол, цвет волос, мать, отец и так далее.
Если для некоторого экземпляра объекта значение некоторого атрибута не
определено, то этот атрибут для данного экземпляра объекта имеет пустое
значение. На диаграммах атрибуты объекта соединяются с ним линиями
(рис. 3.4).

Рис. 3 .4 . Диаграмма представления объекта ТОВАР и его атрибутов

Значения каждого атрибута выбираются из соответствующего множества
значений, включающего все потенциальные значения, которые могут быть
присвоены атрибуту. Это множество значений называется доменом. Так, на­
пример, допустим, что количество товара определяется в единицах и может
варьироваться от нуля до 1 000 единиц. Следовательно, набор допустимых
значений для данного атрибута можно определить как набор целых чисел
от 0 до 1 000.
Объект и экземпляр объекта могут быть определены следующим образом:
Объект: СТУДЕНТ (ФИО, Группа, Год_рождения)
Экземпляр объекта (Петров П.И., 93-ОА-22, 1974)
Атрибуты делятся на простые и составные.
Простые атрибуты не могут быть разделены на более мелкие компоненты.
Например, атрибут Количество объекта ТОВАР является простым атрибутом.
Простой атрибут еще называют атомарным.
Если же атрибут можно разбить на более мелкие составляющие, то такой
атрибут называется составным. Хорошим примером составного атрибута яв­
ляется Дата рождения (Год, Месяц, Число). Каждый из его компонентов
можно использовать в отдельности. Но в тех ситуациях, где не требуется по
отдельности использовать составные части такого атрибута, его можно рас­
сматривать как простой атрибут и определять, допустим, как строковый тип.
Если атрибут является составным, то на диаграммах его атрибутыкомпоненты присоединяются к нему линиями (рис. 3.5).

Рис. 3. 5. Диаграмма представления объекта ТОВАР
с составным атрибутом Дата поступления

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

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

образом идентифицируют каждый экземпляр объекта, являются потенциаль­
ным ключом данного объекта. Потенциальных ключей может быть несколь­
ко. Например, экземпляр объекта ФАКУЛЬТЕТ (Код факультета. Название_факультета, ФИО_декана) может однозначно идентифицироваться
любым из первых двух указанных атрибутов. Третий атрибут не рекоменду­
ется использовать в качестве идентификационного, поскольку нельзя гаран­
тировать отсутствие полного совпадения значений атрибута ФИО^декана
для нескольких экземпляров данного объекта.
Рассмотрим объект:
СТУДЕНТ (Номер зачетной книжки. ФИО_студента, Дата_рождения).
Из трех перечисленных атрибутов в приведенном примере только атрибут
Номер_зачетной_книжки однозначно идентифицирует каждый экземпляр
объекта СТУДЕНТ. Атрибут Дата_Рождения, напротив, не может служить
ключом, так как любая данная дата может быть днем рождения нескольких
разных людей.
Один из потенциальных ключей может быть выбран в качестве первичного
ключа. Обычно в качестве первичного ключа выбирается тот, который имеет
наименьшую длину. Остальные потенциальные ключи называются альтер­
нативными. В рассмотренном выше примере атрибут Код_факультета имеет
меньшую длину, чем атрибут Название_факультета, поэтому его следует вы­
брать в качестве первичного ключа. Тот факт, что атрибут служит первич­
ным ключом, отмечается его подчеркиванием.
Идентификацию некоторых объектов иногда приходится осуществлять при
помощи составных ключей, которые включают несколько атрибутов.
Например, объект:
ПРИЕМ (ФИО врача. ФИО пациента. Дата приема. Заключение)
однозначно идентифицировать можно только составным ключом:
(ФИО_врача, ФИО пациента. Дата приема).
С другой стороны, если нужно, всегда можно создать идентификационный
номер, однозначность которого будет заложена в системе. Во избежание из­
лишней детализации на диаграммах часто атрибуты вовсе не изображают
или изображают только первичные атрибуты, опуская остальные.

3.2.5. Связи между объектами
Два объекта могут быть связаны между собой. Подобная связь осуществля­
ется через связь экземпляров одного объекта с экземплярами другого объек­
та, образуя набор экземпляров связи между двумя объектами, который на­
зывается типом связи.
Каждому типу связи присваивается имя, которое должно представлять его
функцию. Рассмотрим объекты ПРЕПОДАВАТЕЛЬ и КУРС. Между этими

объектами можно определить связь ЧИТАЕТ, сопоставив каждому препода­
вателю ту дисциплину, по которой он читает лекции, или, наоборот, каждой
дисциплине — преподавателя. Связь ЧИТАЕТ составлена из множества пар,
в каждой из которых преподаватель — из объекта ПРЕПОДАВАТЕЛЬ,
а дисциплина — из объекта КУРС (рис. 3.6).
Экземпляры объекта
ПРЕПОДАВАТЕЛЬ

Экземпляры типа Экземпляры объекта
связи
КУРС
ЧИТАЕТ

Рис. 3.6. Экземпляры типа связи ЧИТАЕТ

Полученная структура сама по себе является объектом, состоящим из пар
экземпляров, взятых из двух объектов, связанных между собой. Объект
ЧИТАЕТ, полученный путем связи между объектами ПРЕПОДАВАТЕЛЬ и
КУРС, называется составным объектом.
Описанная ситуация на диаграммах имеет свое графическое изображение,
где тип связи обозначается в виде ромбика с указанным на нем именем свя­
зи, который соединен линиями со связываемыми объектами (рис. 3.7).

Рис. 3.7. Диаграмма типа связи ЧИТАЕТ

В связи могут участвовать не два, а большее количество объектов, которые
в данном случае являются участниками этой связи. Количество участников
некоторой связи называется степенью связи. До сих пор обсуждались связи
между двумя объектами. Такие связи называются бинарными.
Помимо бинарных связей существуют и другие типы связей:
□ тернарные — между тремя объектами;
□ кватернарные — между четырьмя объектами;
□ N-арные — между N объектами.

В подавляющем числе случаев проектирования БД можно ограничиться рас­
смотрением бинарных связей.
Для характеристики свойств связи, также как и для объектов, можно ис­
пользовать атрибуты.
Мощность связи

Важной характеристикой связи является ее мощность, которая обозначает
максимальное количество экземпляров одного объекта, связанных с одним
экземпляром другого объекта. Например, если допустить, что у человека
может быть только один супруг, то мощность связи ЖЕНАТЫ будет равна
одному в каждом направлении (рис. 3.8).
Иногда помимо максимальной мощности полезно определять и минимальную
мощность. В рассматриваемом примере не исключаются одинокие мужчины и
женщины, поэтому минимальная мощность равна нулю в каждом направле­
нии. Такая ситуация может быть обозначена следующим образом:
0,1
МУЖЧИНА

ЖЕНАТЫ J

>

0,1
----------

ЖЕНЩИНА

Рис. 3.8. Диаграмма связи ЖЕНАТЫ
с указание минимальной и максимальной мощности

Некоторые связи не имеют конкретного значения максимальной мощности.
Например, преподаватель может читать не один курс, а, возможно, больше.
Такую мощность обозначают: 1,*, где 1 обозначает минимальную мощность,
а * обозначает "много" (существует и другой способ обозначения "много" —
вместо * ставится N). С другой стороны, если допустить, что каждый дан­
ный курс читается одним и только одним преподавателем, то мощность
в обратном направлении будет 1, 1.
Максимальная мощность является значительно более важным понятием,
чем минимальная. Поэтому для упрощения диаграмм минимальная мощ­
ность указывается только тогда, когда это необходимо.
Показатель кардинальности

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

Для того чтобы указать количество возможных связей для каждого экземп­
ляра участвующего в связи объекта, используют показатель кардинальности.
Показатели кардинальности связей между объектами определяются, прежде
всего, установленными на производстве правилами и относятся к бизнесправилам.
Для бинарных связей показатель кардинальности может иметь следующие
значения:
"один к одному" (1 :1), "один ко многим" (I : N), "много ко многим" (
Если максимальная мощность связи в обоих направлениях равна одному,
мы называем ее связью "один к
у"(1:1).
нм
од
Например, на факультете может быть один декан, и обратно, один и тот же
декан может руководить только одним факультетом, что может быть обозна­
чено следующим образом:
ФАКУЛЬТЕТ < ------- > ДЕКАН.
Если максимальная мощность в одном направлении равна одному, а в дру­
гом — многим, то связь называется "один ко многим"(1:N).
Например, в группе учится много студентов, но каждый студент учится
только в одной группе:
ГРУППА < ---- » СТУДЕНТ.
Концептуальная модель подобной связи приведена на рис. 3.9. На диаграм­
ме использовано два способа обозначения вида бинарной связи: символиче­
ская (со стороны объекта ГРУППА выход связи помечен символом 1, а со
стороны объекта СТУДЕНТ — символом N) и стрелками (в направлении,
где максимальная мощность равна многим, проставлена двойная стрелка,
а со стороны, где она равна единице — одинарная). Реально при построе­
нии диаграмм выбирают один из них.

Рис. 3.9. Д иаграмма типа связи УЧИТСЯ с указанием показателя кардинальности

4 Зак. 3303

И наконец, если максимальная мощность в обоих направлениях равна
многим, то такая связь относится к типу "много ко многим" (M:N). Напри­
мер, преподаватель работает в разных группах, и в одной и той же группе
работают различные преподаватели:
ПРЕПОДАВАТЕЛЬ « ---- » ГРУППА.
В реляционной модели данных связь между отношениями, представляющи­
ми соответствующие объекты, осуществляется посредством атрибутов.
Например, рассмотрим два объекта:
Объект:

СТУДЕНТ

Атрибуты:

Номер зачетной книжки

Объект:

ФИО студента
ГРУППА
Кол группы

Атрибуты:

Количество студентов
ФИО старосты
Для связи соответствующих этим объектам отношений в число атрибутов
отношения СТУДЕНТ необходимо добавить код группы, в которой он учит­
ся, и значение которого будет использовано для связи экземпляра одного
отношения с экземпляром другого отношения.
При нормальном использовании атрибуты имеют функциональные связи в на­
правлении от объекта к атрибуту. Это означает, что значение атрибута одно­
значно определено для каждого экземпляра объекта. Например, у каждого
человека есть ровно одна дата рождения и одна мать. Максимальная мощ­
ность связи со стороны атрибута в такой ситуации всегда равна одному, по­
этому в диаграммах ее можно опустить. Если нет необходимости использо­
вать атрибут как объект, участвующий в других связях, то для его
изображения на диаграммах применяют уже рассмотренную краткую запись.
Степень участия

В методологии проектирования баз данных весьма важной характеристикой
типов связей между объектами является степень участия объекта в связи.
Если каждый экземпляр некоторого объекта обязательно должен участвовать
в связи, то степень участия этого объекта в данной связи является полной.
О таком объекте еще говорят, что его класс принадлежности обязательный.
Если же для объекта допустимо неучастие его некоторых экземпляров в свя­
зи, то степень участия данного объекта в этой связи является частичной,
а его класс принадлежности — необязательный.

Рассмотрим еще раз связь, изображенную на рис. 3.7, между объектами
ПРЕПОДАВАТЕЛЬ и КУРС. Известно, что в состав преподавателей кафед­
ры входят специалисты разных категорий: ассистенты, старшие преподава­
тели, доценты, профессора. Ассистентам, как правило, не поручается чтение
лекций, поэтому степень участия объекта ПРЕПОДАВАТЕЛЬ в связи
ЧИТАЕТ является частичной.
В то же время для качественной подготовки специалистов необходимо, что­
бы все дисциплины, предусмотренные учебным планом, были изучены.
Предположим, что для всех дисциплин запланировано чтение лекций. Если
это так, то степень участия объекта КУРС в связи ЧИТАЕТ является полной
(рис. 3.10). Однако если учебный план содержит изучение дисциплин, по
которым чтение лекций не предусмотрено, то в этой ситуации степень уча­
стия объекта КУРС в связи ЧИТАЕТ будет также частичной.

Рис. 3.10. Диаграмма связи с полным и частичным участием объектов

На диаграммах участники связи с полным участием соединяются со знаком
связи двойной линией, а участники связи с частичным участием — одинар­
ной линией.
Рекурсивная связь

Рекурсивная связь — это особый вид связи, в которой одни и те же экземп­
ляры объекта участвуют несколько раз и в разных ролях [13]. Например,
один из сотрудников кафедры является ее заведующим. Различным ролям
в этом случае присваиваются различные имена (рис. 3.11).

Рис. 3.11. Диаграмма рекурсивной связи

Пример моделирования локальной ПрО

С помощью рассмотренных выше понятий могут быть получены ER-модели
для большинства схем баз данных в традиционных административно­

управленческих приложениях. Если ПрО обширная, то построение ее кон­
цептуальной модели будет протекать более успешно, если эту ПрО разбить
на несколько локальных предметных областей. Объем локальной ПрО выби­
рается таким образом, чтобы в нее входило не более 6—7 объектов. Как ранее
упоминалось, отправными элементами для построения ER-модели локальной
ПрО очень часто являются используемые в организации документы.

Рис. 3.12. Форма поставки

Предположим, что определена локальная ПрО: поставка товаров на склад.
Пусть используемая форма поставки имеет вид, как на рис. 3.12.
Покажем, как, используя приведенную форму, можно построить концепту­
альную модель этой небольшой локальной предметной области.
Итак, анализируемая форма содержит следующую информацию: Поставщик,
Индекс поставщика, Адрес поставщика, Товар, Индекс товара, Цена товара,
Количество товара, Поставка, Индекс поставщика, Дата поставки и Номер
склада.
Выделим два объекта: ПОСТАВЩИК и ТОВАР (рис. 3.13).
Оставшиеся атрибуты характеризуют объект — ПОСТАВКА. Сформируем
его и установим определенные типы бинарных связей между тремя объекта­
ми, исходя из следующих рассуждений: один и тот же поставщик может
осуществить ряд поставок, но каждая поставка осуществляется только од­
ним поставщиком.
Мощность связи между объектами ПОСТАВКА и ТОВАР должна быть уста­
новлена M:N, так как каждая поставка может содержать несколько товаров,
и один и тот же товар может содержаться в нескольких поставках. Исходя
из вышесказанного, диаграмма модели предметной области ПОСТАВКА
примет такой вид, как на рис. 3.14.

П о с т ав щ и к
И ндекс п о с та в щ и к а
Адрес п о став щ и к а
Т о вар
И ндекс т о в а р а
Ц ен а т о в а р а
И ндекс п о ставки
К ол и ч ество т о в а р а
Д а та п о ставки
Н ом ерсклада

ПОСТАВЩ ИК

ТОВАР

ПОСТАВКА

Рис. 3 .1 3 . П ро ПОСТАВКА

Рис. 3.14. Диаграмма модели предметной области ПОСТАВКА

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

ключа может удовлетворять некоторое множество элементов объектного
множества, а не один. Такие ключи называются вторичными ключами.
При построении концептуальной модели следует избегать избыточности
информации. После того, как выделены объекты, ключи, определяют и уда­
ляют имеющиеся избыточные связи. Большое внимание уделяется анализу
атрибутов. Забегая вперед, следует указать на то, что в хорошо спроектиро­
ванной БД должно соблюдаться правило: среди атрибутов объекта должна
наблюдаться зависимость описательного атрибута от ключевого, но не
должна существовать зависимость между описательными атрибутами.
Завершающим этапом построения концептуальной модели исследуемой
ПрО является спецификация всех объектов, входящих в модель. Для дан­
ного примера результаты этого шага должны быть сведены к следующему:
1. Спецификация объектов:
ПОСТАВЩИК: Индекс поставщика— идентификационный атрибут
Адрес_поставщика — описательный атрибут
Наименование_поставщика — описательный атрибут
ПОСТАВКА:

Индекс поставки — идентификационный атрибут
Количество_товара— описательный атрибут
Дата_поставки — описательный атрибут

ТОВАР:

Номер_склада — описательный атрибут
Индекс товара — идентификационный атрибут
Наименование_товара— описательный атрибут
Цена_товара— описательный атрибут

2. Спецификация типов связей:
ПОСТАВЛЯЕТ: связь ПОСТАВЩИК <---- » ПОСТАВКА 1:N
ВКЛЮЧАЕТ:

связь ПОСТАВКА <<---- » ТОВАР M:N

3. Спецификация атрибутов:
Индекс поставщика: символьный, 6 символов
Адрес_поставщика: символьный, 50 символов
Цена_товара: денежный
Сформированные спецификации заносятся в словарь данных.
После создания моделей каждой выделенной предметной области произво­
дится объединение локальных концептуальных моделей в одну общую, как
правило, довольно сложную схему.

Специализация и генерализация

Для удовлетворения новых требований, выдвигаемых все более усложняю­
щимися приложениями, в семантическое моделирование были введены до­
полнительные концепции, расширяющие его возможности. Такая модель
получила название расширенной ER-модели (EER-модели). Она включает
все концепции ER-модели плюс концепции специализации, генерализации
и категоризации. Все эти нововведения создают дополнительные возможно­
сти для моделирования неоднородных по своей структуре объектов. Допол­
нительные концепции базируются на таких понятиях, как суперкласс и под­
класс, а также используют процесс наследования атрибутов.
Суперкласс — это объект, включающий разные подклассы, которые необхо­
димо представить в модели данных.
Подкласс — это объект, являющийся членом суперкласса, но выполняющий
отдельную роль в нем.
Суперкласс может иметь несколько разных подклассов. Так, например,
подклассы: АССИСТЕНТ, СТАРШИЙ ПРЕПОДАВАТЕЛЬ, ДОЦЕНТ,
ПРОФЕССОР являются членами суперкласса ПРЕПОДАВАТЕЛЬ. Это оз­
начает, что каждый экземпляр подкласса является в то же время и экземп­
ляром суперкласса. Связь между суперклассом и подклассом относится
к типу "один к одному"
Использование понятий суперкласса и подклассов позволяет при моделиро­
вании выделить для подкласса свои собственные атрибуты и атрибуты, на­
следуемые им от суперкласса. Так, например, подкласс ДОЦЕНТ должен
иметь те же атрибуты, что и все преподаватели — это наследуемые им от
суперкласса ПРЕПОДАВАТЕЛЬ атрибуты. Однако он имеет и свой собст­
венный атрибут, который не определяется для других категорий преподава­
телей — Номер_диплома_доцента. В отсутствие выделенных подклассов
в этой ситуации пришлось бы для объекта ПРЕПОДАВАТЕЛЬ ввести такой
атрибут, который бы имел неопределенное значение для всех преподавате­
лей, не являющихся доцентами.
Подкласс может иметь свои собственные связи, которые не подходят для
всех экземпляров суперкласса. Например, профессору разрешается руково­
дить аспирантами.
На диаграмме (рис. 3.15) подклассы соединяются линиями с кружком, кото­
рый в свою очередь соединяется с суперклассом. На каждой линии, идущей
от подкласса, располагается U-образный символ, который обозначает на­
правление включения. Верхняя часть U "открывается" в сторону суперклас­
са. Внутри кружка располагается буква D, если подклассы не пересекаются,
и буква О — для пересекающихся подклассов. В последнем случае экземпляр
супер-класса может быть членом сразу нескольких подклассов. Изображенная

на диаграмме ситуация исключает пересечение подклассов, поэтому в кру­
жок помещен символ D.

Р и с . 3 .1 5 . Диаграмма с использованием понятий суперкласс и подкласс

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

тот же объект ПРЕПОДАВАТЕЛЬ можно специфицировать, разбив его на
два подкласса: ОСНОВНАЯ_РАБОТА и РАБОТА_ПО_СОВМЕСГИТЕШ>СГВУ.
К первому подклассу относятся те преподаватели, для которых эта работа яв­
ляется основной, ко второму — те, которые ее совмещают с другой основ­
ной работой. Это пример специализации на пересекающиеся подклассы,
поскольку один и тот же преподаватель может быть участником обоих под­
классов. Такая ситуация, например, возникает при наличии вакансий, то
есть тогда, когда количество имеющихся в наличии преподавателей меньше
требуемого. В этой ситуации некоторому преподавателю может быть пору­
чено выполнение дополнительной нагрузки, а он сам будет оформлен еще
и как совместитель.
Генерализация представляет собой восходящий подход, а именно: процесс
сведения различий между объектами к минимуму путем выделения их об­
щих характеристик. Этот подход позволяет создать суперкласс на основе
различных исходных подклассов. Допустим, что в наличии имеются сле­
дующие объекты: АССИСТЕНТ, СТАРШИЙ ПРЕПОДАВАТЕЛЬ, ДОЦЕНТ,
ПРОФЕССОР. Применение метода генерализации к ним приведет к выяв­
лению их общих свойств и связей. Общность их заключается в том, что все
они являются преподавателями, а значит, можно определить суперкласс
ПРЕПОДАВАТЕЛЬ, который будет иметь все совместно используемые
атрибуты.
На процедуру специализации, помимо ограничения пересечения, может
быть наложено еще одно ограничение, которое называется ограничением уча­
стия, и оно может быть полным или частичным.
При специализации с полным участием каждый экземпляр суперкласса дол­
жен быть экземпляром этой специализации, то есть принадлежать какомулибо выделенному подклассу. Для обозначения на диаграммах полного уча­
стия между суперклассом и кружком проводят двойную линию.

Р и с . 3 .1 6 .

Наследование подклассом связей суперкласса

Примером специализации с полным участием мбгут служить суперкласс
ПРЕПОДАВАТЕЛЬ и его подклассы, где каждый преподаватель должен от­
носиться к одной из указанных четырех категорий (рис. 3.15).
Специализация с частичным участием означает, что каждый экземпляр объ­
екта не обязательно должен быть членом подкласса этой специализации.
Для обозначения на диаграммах частичного участия между суперклассом и
кружком проводят одинарную линию.
Подклассы наследуют не только атрибуты, но и все связи суперкласса
(рис. 3.16).
Категоризация

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

Рис. 3.17. Диаграмма с совместно используемым подклассом

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

Рис. 3.18. Диаграмма с категоризацией

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

В данном подразделе рассматривается пример создания EER-модели пред­
метной области УЧЕБНЫЙ ПРОЦЕСС. Несмотря на то, что выделенные
в ней объекты и связи не охватывают все нюансы данной проблемы и по­
становка задачи не претендует на полноту, тем не менее окончательная
диаграмма этой модели получилась довольно сложная. Для облегчения вос­
приятия сложных диаграмм разрешается не наносить атрибуты объектов
(или обозначать только идентификационные атрибуты), а связи между объ­
ектами только надписывать, опуская их обозначения.
В результате сбора требований в данной предметной области и их анализа
были сформулированы следующие спецификации (табл. 3.1).
Таблица

3. 1. Объекты и их атрибуты

Объект

Атрибут

Первичный ключ

ФАКУЛЬТЕТ

Код_факультета

Код_факультета

Наименование_факультета
КАФЕДРА

Код_кафедры
Наименование.кафедры

ОБЩАЯ
ВЫПУСКАЮЩАЯ

Код_каф едры

Таблица 3.1 (окончание)
Объект

Атрибут

Первичный ключ

СОТРУДНИК

Табельный.номер

Т абел ьный.номер

ФИО
Стаж
ИНЖ_ЛАБОР_СОСТАВ

Должность

ПРЕПОДАВАТЕЛЬ

Педагогический.стаж

ЛЕКТОР
АССИСТЕНТ
СТАРШИЙПРЕПОДАВАТЕЛЬ
ДОЦЕНТ

Диплом_доцента

ПРОФЕССОР

Диплом.профессора

СПЕЦИАЛЬНОСТЬ

Ш иф р, специальности
Наименование.
специальности

КУРС

Номер.курса

УЧЕБНЫЙ_ПЛАН

Ш иф р, специальности

ДИСЦИПЛИНА

Код-Дисциплины

Ш иф р .
специальности
Номер.курса
Код_дисциплины

Наименование, дисциплины
ЛЕКЦИИ

Количество.часов

ПРОЧИЕ
ГРУППА

Код_группы

Код_группы

Староста
Количество.студентов
СТУДЕНТ

Номер.зачетной.книжки
ФИО

Номер.зачетной
книжки

Адрес
ДИПЛОМ НИК

Тема_диплома

□ Факультет объединяет ряд кафедр. Среди кафедр есть общеобразователь­
ные кафедры и кафедры, выпускающие специалистов. Кафедра может го­
товить специалистов по нескольким специальностям. Лица, работающие
на кафедре, относятся к категории СОТРУДНИК.
□ Все сотрудники делятся на две части: обслуживающий персонал — инже­
нерно-лаборантский состав и преподавательский состав. Каждый препо­
даватель должен относиться к одной из четырех категорий: ассистент,
старший преподаватель, доцент, профессор, причем все категории, кроме
категории ассистент, входят в лекторский состав. Представителям лек­

торского состава поручается чтение лекций и руководство дипломным
проектированием.
□ Преподавание студентам каждой специальности ведется в соответствии
с утвержденным учебным планом, где определены дисциплины, подле­
жащие изучению, виды занятий, отводимое под них количество часов,
а также определена форма контроля знаний по этой дисциплине: зачет
или экзамен.
□ По данной специальности обучение студентов ведется на одном или бо­
лее курсов. На каждом курсе может быть одна или несколько групп од­
ной и той же специальности, где обучается ряд студентов.
Для упрощения концептуальной модели базы данных остались не прорабо­
танными такие моменты учебного процесса, как: кто и где ведет определен­
ный вид занятий. Из процесса обучения по данной дисциплине выделены
только лекции, а все другие виды занятий, а также формы контроля отнесе­
ны к объекту ПРОЧИЕ.
Объекты, выделенные в рассматриваемой модели, а также относящиеся
к ним атрибуты, которые выявлены из спецификаций требований пользова­
телей, приведены в табл. 3.1.
Изучение состава атрибутов каждого объекта позволило выделить те из них,
которые можно использовать в качестве первичных ключей. Они также по­
мещены в таблицу 3.1. Нетрудно заметить, что не все позиции в колонке
Первичный ключ заполнены. Свободными остались те позиции, которые от­
носятся к объектам-подклассам, полученным путем специализации. По­
скольку подкласс наследует все атрибуты суперкласса, а следовательно, и
идентификационные атрибуты и каждый экземпляр подкласса связан только
с одним экземпляром суперкласса, то и идентификационные атрибуты у них
одни и те же.
Для выделенных объектов необходимо установить важнейшие типы связей,
соответствующие тем, что существуют в реальном мире. Для каждой связи
следует также определить показатель кардинальности и степень участия сто­
рон в связи. Все связи и их характеристики приведены в таблице 3.2.
Приведенная в таблице информация должна быть использована при по­
строении EER-диаграммы (рис. 3.19).
Поскольку для упрощения диаграммы символы для обозначения связей не
использовались, то вместо них на линиях связи помещены точки, разде­
ляющие линии связи на две части. Каждая такая часть используется для
обозначения степени участия объекта, прилегающего с соответствующей
стороны к точке в связи. Если объект подсоединяется к точке двойной
линией, то степень его участия в связи — полная, если же одинарной,
то степень его участия в связи — частичная.

Таблица 3.2. Типы связей и их характеристики
Связь

Объекты

входит

ФАКУЛЬТЕТ

Показатель
кардинальности
1:N

КАФЕДРА

1:N

УТВЕРЖДЕН

ИМЕЕТ

ВЫПУСКАЮЩАЯ
СПЕЦИАЛЬНОСТЬ

1:N

СПЕЦИАЛЬНОСТЬ
УЧЕБНЫЙ ПЛАН

1:1

СПЕЦИАЛЬНОСТЬ

1:N

КУРС

ВКЛЮЧАЕТ

УЧИТСЯ.В

1:N

N:M

УЧЕБНЫЙ ПЛАН
ДИСЦИПЛИНА

1:N

ГРУППА

1:N

ЛЕКТОР

ЛЕКТОР

ДИПЛОМНИКОМ

ДИПЛОМНИК

ГОТОВИТ_К_ЗАЩИТЕ

СПЕЦИАЛЬНОСТЬ
ДИПЛОМ НИК

Полная
Полная
Полная
Полная

N:M

Полная
Полная

1:N

Частичная
Полная

ЛЕКЦИИ
РУКО В О ДИТ.

Полная
Полная

СТУДЕНТ
ЧИТАЕТ_ПО

Полная
Полная

ПРЕПОДАВАТЕЛЬ
ДИСЦИПЛИНА

ДИСЦИПЛИНА

Полная
Полная

СТУДЕНТ
ОБУЧАЕТСЯЛО

Полная
Полная

ГРУППА
ВЕДЕТ

Полная
Полная

КУРС
СОСТОИТ

Полная
Частичная

СОТРУДНИК
ГОТОВИТ

Полная
Полная

КАФЕДРА
РАБОТАЕТ

Степень
участия

1:N

Частичная
Полная

1:N

Частичная
Полная

Для большинства объектов рассматриваемой предметной области определена
полная степень участия в связи. Это значит, что каждый экземпляр объекта
должен участвовать в связи. Исключение из данного правила составляют сле­
дующие объекты: СОТРУДНИК в связи РАБОТАЕТ (не каждый сотрудник
работает на кафедре, поскольку в вузе существуют и другие структуры),

ЛЕКТОР в связях ЧИТАЕТ и РУКОВОДИТ_ДИПЛОМНИКОМ (он может
и не читать лекции, и не руководить дипломным проектированием),
СПЕЦИАЛЬНОСТЬ в связи ГОТОВИТ_К_ЗАЩИТЕ (возможно, по данной
специальности еще нет выпускников).
входит

ФАКУЛЬТЕТ

КАФ ЕДРА
РАБОТАЕТ

ОБЩАЯ
С О ТРУД НИ К
ГОТО ВИТ

СПЕЦИАЛЬНО СТЬ

ИНЖЕН.

ИМ ЕЕТ
1

1

.. .

ПРЕП ОДАВАТЕЛЬ

УТВЕРЖ ДЕН

КУРС

СОСТОИТ

УЧББН
АССИСТЕНТ

1КЛЮЧАЕ1
ГРУПП А
УЧИТСЯ_В
ЛЕКТОР

ДИСЦИПЛИНА

СТУДЕНТ

СТПРЕП

ЛЕКЦИ И

ПРОЧИЕ

ДОЦЕНТ
РУ К О В О Д И Т \
ДИПЛОМНИКОМ
ДИПЛОМНИК

ДИПЛОМ

Рис. 3.19. EER-диаграмма предметной области УЧЕБНЫЙ ПРОЦЕСС

В рассматриваемой модели проведена спецификация ряда объектов с обра­
зованием суперклассов и подклассов.
□ Так, например, имеется суперкласс КАФЕДРА и его подклассы
ВЫПУСКАЮЩАЯ и ОБЩАЯ. Появление указанных подклассов объяс­
няется тем, что у них различные функции. ВЫПУСКАЮЩАЯ ответст­
венна за подготовку специалистов, а ОБЩАЯ только принимает участие
в ведении определенных дисциплин.
□ В модели образованы также два подкласса ИНЖЕНЕР_ЛАБОРАНТ и
ПРЕПОДАВАТЕЛЬ суперкласса СОТРУДНИК, поскольку подкласс
ИНЖЕНЕР_ЛАБОРАНТ лишь обеспечивает процесс обучения, а непо­
средственно в ведении дисциплин не участвует.
□ Аналогично выделены подклассы ЛЕКТОР и АССИСТЕНТ суперкласса
ПРЕПОДАВАТЕЛЬ, специфика деятельности которых различна: ЛЕКТОР
читает лекции и ведет дипломное проектирование, в то время как
АССИСТЕНТ, как правило, этим не занимается.
□ Наличие подкласса ДИПЛОМНИК, выделенного из суперкласса
СТУДЕНТ, определяется тем, что студент, выполняющий дипломный
проект на определенную тему, закрепленную приказом, нуждается в ру­
ководителе.
□ В данной модели суперкласс ДИСЦИПЛИНА имеет всего два подкласса —
ЛЕКЦИИ и ПРОЧИЕ, хотя реальная картина существенно от этого от­
личается. Но, как было сказано выше, более детальная проработка этой
ситуации опущена в целях упрощения результирующей диаграммы. Лек­
ции же пришлось специализировать, так как этот вид учебного процесса
в отличие от всех других видов нагрузки поручается только преподавателям-лекторам.
□ Подклассы СТАРШИЙ_ПРЕПОДАВАТЕЛЬ, ДОЦЕНТ, ПРОФЕССОР
суперкласса ПРЕПОДАВАТЕЛЬ выделены для того, чтобы избежать пус­
тых значений атрибутов всех преподавателей там, где необходимо указать
сведения о дипломе доцента или профессора.

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

Обсудим основные положения такого подхода.
Ранее было показано, что два связанных объекта можно использовать как
объект. Например, объекты ПРЕПОДАВАТЕЛЬ и КУРС со связью ЧИТАЕТ
составляют новую структуру, которая сама по себе является объектом. По­
добные объекты могут обладать атрибутами (Аудитория, Время) и участво­
вать в других связях. Иногда составным объектам дают объектные имена —
существительные (ЛЕКЦИЯ), что очень удобно, если такой новый объект
связывается с другими.
Составной объект может быть изображен так, как показано на рис. 3.20.

ПРЕПОДАВАТЕЛЬ

ЧИТАЕТ

КУРС

ЛЕКЦИЯ
—

Аудитория

Время
Рис. 3 .2 0 . Составной объект Л Е К Ц И Я

Во всех ранее рассмотренных примерах присутствовали бинарные связи. Свя­
зи трех и более объектов называются связями высокого порядка. Обычно для
упрощения процесса моделирования связи высокого порядка разбиваются
на последовательность вложенных бинарных связей. Такая замена допусти­
ма, но следует учесть, что при этом не все бинарные связи будут иметь ка­
кой-либо "физический" смысл. Поэтому иногда при построении моделей
данных для более точного отражения процессов в реальном мире целесооб­
разнее пользоваться N-арными связями. В соответствии с максимальными
мощностями связей высокого порядка часто используется проверенное на
практике допущение, что все бинарные связи, составляющие связь высокого
порядка, имеют тип "много ко многим"
Вернемся к рассмотрению процесса построения концептуальной модели
предметной области ПОСТАВКА ТОВАРОВ. Рассмотрим его в несколько
измененном виде, а именно ПОСТАВКА ТОВАРОВ НА СКЛАД. Экземпляр
объекта ТОВАР связан с экземпляром объекта СКЛАД. Эта связь обозначе­
на, как ПОСТУПИЛ НА. Объединение двух указанных связанных объектов
в один объект позволяет связать последний связью ПОСТУПИЛ В с объек­
том ДАТА, что дает новый объект (рис. 3.21).
Отметим, что в данном случае ДАТА рассматривается как объект, а не атри­
бут. В формировании всех составных объектов были использованы бинар­
ные связи. Атрибут Количество относится к результирующему, самому

внешнему объекту, так как для определения количества поставленного това­
ра надо знать элементы всех трех объектов: ТОВАР, СКЛАД, ДАТА. Однако
может оказаться более удобным представить эту модель так, чтобы в ней
была использована одна тернарная связь вместо двух бинарных связей. Ес­
тественно, что атрибут Количество будет являться атрибутом результирую­
щего объекта.

Рис. 3.21. Составной объект с двумя бинарными связями

Пользуясь изложенным подходом, рассмотрим концептуальную модель
предметной области НИР, где создаваемая модель данных предназначается
для получения информации о производимых специалистам выплатах за про­
деланную работу по определенным темам НИР, а также о затратах на обору­
дование по каждой теме.
В разрабатываемой модели предполагается использовать пять объектов:
СПЕЦИАЛИСТ, ВИД_РАБОТЫ, ОБОРУДОВАНИЕ, ЗАКАЗЧИК, НИР,
которые и изображены на рис. 3.22.
Объекты СПЕЦИАЛИСТ и ВИД_РАБОТЫ образуют самый внутренний
составной объект. Они имеют свои атрибуты, назначение которых очевидно
и не требует дополнительных разъяснений, за исключением атрибута Харак­
теристика, который представляет собой поле свободного формата, где поль­
зователь может записать любую информацию описательного характера.
Связь этих объектов имеет название ВЫПОЛНЯЕТ и определена как
"много ко многим", так как предполагается, что один и тот же специалист
может выполнять различные виды работ, и одна и та же работа может вы­
полняться разными специалистами.
Полученный составной объект в свою очередь имеет связь с объектом НИР.
Эта связь определена также как "много ко многим": один и тот же элемент
составного объекта может участвовать в различных НИР, и в одной и той же
НИР могут принимать участие различные экземпляры составного объекта.
Объекту НИР приписаны атрибуты: Иццекс темы, Название, Руководитель,

и он связан еще с двумя объектами ЗАКАЗЧИК и ОБОРУДОВАНИЕ. Объ­
ект ЗАКАЗЧИК определяет кто, с каким адресом и с каким счетом оплачи­
вает проводимые работы. Естественно, одна и та же тема может иметь толь­
ко одного заказчика, но никто не запрещает некоторому заказчику
заключить несколько договоров на выполнение НИР. Поэтому связь Для
квалифицируется как "один ко многим"

Гчас_оплата^)

Рис. 3 .2 2 . Модель предметной области НИР

Связь На определяет: по какой НИР какое оборудование и в каком количе­
стве было приобретено. Разумеется, что здравый подход к решению пробле­
мы требует эту связь определить как "много ко многим"
При дальнейшем анализе разрабатываемой модели оказывается, что очень
полезно построенный ранее составной объект объединить с объектом НИР
в новый составной объект. И атрибуты Часовая плата, Количество часов
приписать уже новому (внешнему) составному объекту, так как они опреде­
ляются в нашем случае для каждого специалиста по каждому виду работ
и для каждой НИР, то есть свои у каждого экземпляра внешнего составного
объекта.
Изображенную выше на схеме модель данных, пусть и очень упрощенную,
можно использовать для получения множества разнообразных отчетов.
Например, можно создать отчет, отражающий, какие виды работ каждый

специалист выполнял для каждого заказчика и в какой НИР. Можно оце­
нить эту работу в часах, в полученной заработной плате. Можно получить
разнообразные сведения об оборудовании и еще многое другое.
Составные объекты и связи высокого порядка — мощные средства, часто
применяющиеся при моделировании сложных предметных областей.

Вопросы и упражнения
1. Объясните своими словами смысл терминов:
• база данных;
• предметная область;
• информационная система;
• жизненный цикл базы данных.
2. Охарактеризуйте жизненный цикл базы данных. Какие основные этапы
он включает?
3. Назовите основные цели процесса проектирования базы данных и дайте
характеристику его фазам.
4. Какие стратегии тестирования прикладных программ информационных
систем существуют?
5. Объясните своими словами смысл терминов:
• объект;
• атрибут;
• бинарная связь;
"один-ко-многим";
• мощность;
• показатель кардинальности;
• степень участия;
• ключ;
• рекурсивная связь;
• составной объект.
6. Объясните, какой информацией можно воспользоваться для определения
следующих конструкций концептуальной модели данных:
• объектов;
• атрибутов;
• связей.

7. Приведите пример концептуальной модели некоторой предметной об­
ласти.
8. Постройте концептуальную модель некоторой предметной области, ис­
пользуя понятие составного объекта.
9. Объясните понятия специализации, генерализации, категоризации.
10. Создайте концептуальную модель данных некоторого университета, ко­
торая бы позволяла получить следующую информацию:
• количество преподавателей, работающих на факультете;
• список преподавателей факультета;
• дисциплины, изучаемые студентами определенной специальности
в шестом семестре;
• объем лекций по дисциплинам второго семестра для определенной
специальности факультета;
• фамилии преподавателей, ведущих высшую математику на факультете.

Глава 4

ЩЩЩЩЩЦ

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

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

4.1. Классификация моделей данных
В настоящее время описано много разнообразных моделей, построение ко­
торых преследует разные цели. Из множества опубликованных моделей дан­
ных можно выделить три категории:
□ объектные модели данных;
□ модели данных на основе записей;
□ физические модели данных.
Применительно к трехуровневой архитектуре баз данных следует отметить,
что первые две категории используются для описания данных на внешнем
и концептуальном уровнях, а последняя категория — на внутреннем уровне.

4.1.1. Объектные модели данных
Среди объектных моделей следует выделить ER-модель, которая наиболее
часто используется в методологии проектирования баз данных (подробно
рассматривалась в предыдущей главе), а также объектно-ориентированную
модель, последнее время широко используемую в технологиях баз данных.
Объектно-ориентированная модель расширяет понятие объекта, используе­
мое в главе 3, включая в него не только атрибуты, характеризующие состоя­
ние объекта, но и связанные с ним действия. Объектно-ориентированной
модели посвящен целый раздел главы 11.

4.1.2. Модели данных на основе записей
В модели данных на основе записей база данных состоит из нескольких за­
писей фиксированного формата, которые могут иметь разные типы.
В большинстве коммерческих СУБД используются ставшие классическими
два типа такого рода моделей данных: теоретико-графовые (ТГ) и теорети­
ко-множественные (ТМ) модели данных.
К теоретико-графовым моделям относятся две разновидности:
□ сетевые модели;
□ иерархические модели.
В таких моделях данных предусматриваются характерные для подобного рода
структур операции навигации и манипулирования данными. Принципиальное

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

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

4.2. Сетевая модель
Сети — естественный способ представления отношений между объектами,
всевозможных их взаимосвязей. Сетевая модель опирается на математиче­
скую структуру, которая называется направленным графом. Направленный
граф состоит из узлов, соединенных ребрами. В контексте моделей данных
узлы представляют собой объекты в виде типов записей данных, а ребра —
связи между объектами со степенью кардинальности "один к одному" или
"один ко многим" Если говорить более точно, сетевая БД состоит из набора
экземпляров каждого типа из заданного в схеме БД набора типов записей и
набора экземпляров каждого типа из заданного набора типов связи.
Основное отличие графовых форм представления данных в сетевой структу­
ре данных от иерархической структуры данных состоит в том, что потомок
в графе может иметь любое число предков. Таким образом, сетевая модель
данных, снимая основное ограничение уже использующейся к тому времени
иерархической структуры данных, является результатом действий по обоб­
щению ситуаций моделирования существующих реалий и попыток установ­
ления подробных стандартов в этой области.
Хотя знакомство с теоретико-графовыми моделями начато с рассмотрения
сетевой модели данных, следует подчеркнуть, что ей предшествовала во
времени иерархическая модель данных. Первой же в книге сетевая модель
данных представляется потому, что, как будет показано позже, иерархиче­
ская модель данных является частным случаем сетевой и основные ее поло­
жения проще объяснить с точки зрения общего представления.
Сетевая модель имеет богатую историю и является основой нескольких
удачных СУБД. Если говорить о практической реализации сетевой модели
данных, то в первую очередь необходимо упомянуть одну из самых первых
СУБД — Integrated Data Store (IDS), созданную компанией General Electric.
Именно архитектура этой СУБД легла в основу деятельности группы Data­
base Task Group (DTBG), которой конференция по языкам систем данных
(CODASYL) в конце 60-х годов поручила разработать стандарты систем
управления базами данных. Отчет по этой работе, рекомендовавший к ис­
пользованию сетевую модель данных, был представлен в Американский на­
циональный институт стандартов в 1971 году для возможного принятия
в качестве национального стандарта СУБД. Этот документ в дальнейшем
послужил основой при разработке других сетевых систем управления базами
данных и сейчас остается главной формулировкой сетевой модели.
Разработанная сетевая модель DTBG имеет трехуровневую архитектуру, со­
ответствующую рекомендациям ANSI/SPARC следующим образом. Концеп­
туальный уровень, определяющий глобальную структуру базы данных, назы­
вается схемой. Конечные пользователи на внешнем уровне осуществляют
доступ к базе данных посредством прикладной программы на базовом языке,

использующей только одну некоторую подсхему БД. Подсхема — это под­
множество схемы, которое определяется пользовательским представлением
данных БД. Внутренний уровень (физические подробности хранения дан­
ных) явно содержится в реализации.
Несколько программ могут параллельно использовать одну и ту же подсхе­
му. СУБД может поддерживать несколько различных баз данных. Рассмот­
рим основные концепции CODASYL-совместимых СУБД.

4.2.1. Структуры данных сетевой модели
В технологии, разработанной CODASYL, используются несколько различ­
ных типовых структур данных, главными из которых являются типы записей
и наборы. Для построения этих структур применяются такие конструктив­
ные элементы, как элемент данных и агрегат (рис. 4.1).
Эл-т
данных ->

Агрегат
данных ...-*

Запись

к

Набор

База
данных

Î
Рис. 4.1. Основные структуры сетевой модели данных

Структуризация данных базируется на концепциях агрегации и обобщения.
Агрегация используется для композиции элементов данных в запись. Обоб­
щение используется для объединения однотипных записей файлов. Рассмот­
рим основные элементы сетевой модели данных.
Элемент данных — это наименьшая поименованная информационная еди­
ница данных, доступная пользователю (аналог — поле в файловой системе).
Элемент данных должен иметь свой тип (не структурный, простой).
Агрегат данных соответствует следующему уровню обобщения — поимено­
ванная совокупность элементов данных внутри записи или другого агрегата
(рис. 4.2).
Дата
День

Месяц

Год

Рис. 4.2. Агрегат Дата

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

Сотрудник
Табельный номер

ФИО

Дата
День

Месяц

Адрес
Год

Рис. 4 .3 . Запись Сотрудник

Тип записей — это совокупность логически связанных экземпляров записей.
Тип записей моделирует некоторый класс объектов реального мира.
В качестве элемента данных могут быть использованы только простые типы,
а в качестве агрегатов могут быть использованы сложные типы: вектор и
повторяющаяся группа.
Агрегат типа вектор соответствует линейному набору элементов данных
(рис. 4.2). Агрегат типа повторяющаяся группа соответствует совокупности
векторов данных. Так, например, в заказе может быть указано несколько
видов товаров с числом повторений 10 (рис. 4.4).
Заказ
Номер
заказа

Товар

Дата заказа
День

Месяц

Год

Шифр товараКоличество Наименован*
ФР
р
товара
товара
^
1
Повторяющаяся группа

Рис. 4 .4 . Запись Заказ

Набор — это поименованная двухуровневая иерархическая структура, кото­
рая содержит запись владельца и записи членов. Наборы выражают связи
"один ко многим" или "один к одному" между двумя типами записей. Тип
набора поддерживает работу с внутренними структурами типов записей.
Тип набора — это не аналог файла, он определяет связь между типами запи­
сей. Каждый экземпляр типа набора может содержать только один экземп­
ляр записи владельца и сколько угодно экземпляров записей членов. Набор
может быть пустым, т. е. в нем может находиться только одна записьвладелец. Тип набора является основным композиционным элементом,
с помощью которого по технологии CODASYL строится в сетевой модели
структура всей БД.
Набор, приведенный на рис. 4.5, определяет тип записи-владельца Отдел и
тип записи-члена набора Сотрудник, а также тип связи между ними "один
ко многим" — с именем Работает. Имя набора — это метка, присвоенная
стрелке. Связь типа "один ко многим" допускает возможность того, что
с данным экземпляром записи-владельца может быть связан ноль, один, или
несколько экземпляров записи-члена.

Рис. 4 .5 . Диаграмма тира набора Работает

ОТДЕЛ
Код

Название

Номер комнаты
Тип записи владельца

Работает

Тип записи члена
СОТРУДНИК
►*; Табел__ном ер

ФИО

Должность

Образование

Рис. 4.6. Набор Работает между двумя типами записей Отдел и Сотрудник

Используя понятия сетевой модели данных, можно получить другое изобра­
жение такого набора (рис. 4.6), где представлены логические типы записей
Отдел и Сотрудник, их структура и связь между типами записей Работает.
Для обозначения связи в направлении ’’много" можно использовать альтер­
нативное обозначение показателя кардинальности — двойные стрелки,
опуская буквенное.
Типы записей и наборы используются для построения на концептуальном
уровне сетевого графа, отражающего глобальную структуру базы данных.
Учитывая все вышесказанное, уточним понятие база данных в сетевой моде­
ли данных.
База данных в сетевой модели данных — это поименованная совокупность
экземпляров записей различного типа и экземпляров наборов, содержащих
связи между ними.

4.2.2. Сетевой граф БД
Сетевой граф строится по определенным правилам:
□ БД может содержать любое количество наборов и записей;
П между двумя типами записей может быть любое количество наборов; на­
пример, преподаватель может не только заниматься с группой, но и быть
куратором этой группы (рис. 4.7);
□ тип записи может быть владельцем в одних типах наборов и членом
в других типах наборов;

□ только один тип записи может быть владельцем в каждом наборе;
□ типы наборов могут быть определены так, что в результате они образуют
циклическую структуру;
□ тип записи не обязательно должен быть членом какого-либо типа набора;
□ один и тот же тип записи может быть владельцем нескольких типов на­
боров и одновременно может быть членом нескольких типов наборов.
Преподаватель
Таб_н, ФИО, должность
Преподает
Куратор

Группа
^ Код_гр, староста, кол_студ

Рис. 4.7. Наборы между двумя типами записей

4.2.3. Преобразование концептуальной модели
в сетевую
Сетевая модель данных может быть без осложнений получена из концепту­
альной модели. Для этого надо предположить, что в последней используют­
ся только бинарные связи. Причем они должны принадлежать к типам
"один к одному" или "один ко многим" При этом вместо объектов концеп­
туальной модели необходимо использовать типы записей сетевой модели,
где имена объектов становятся именами типов записей, атрибуты объектов
становятся полями записей, связь между объектами превращается в связь
между типами записей.
Бинарные связи, принадлежащие к типу "один ко многим", переносятся
в сетевую модель следующим образом: тип записи со стороны "один" стано­
вится владельцем, а тип записи со стороны "много" становится типом запи­
си-члена. Для связи типа "один к одному" выбор типа записи-владельца и
типа записи-члена может быть осуществлен произвольно.
На рис. 4.8 представлена схема базы данных Факультет, которая содержит
ряд типов записей и ряд типов наборов.
Присущие сетевым моделям внутренние ограничения не позволяют напрямую
моделировать некоторые реально существующие в предметной области типы
связей. К таким типам связей относятся рекурсивные связи и связи типа M:N.
Для того чтобы их отразить в сетевой модели, применяют различные подходы,
которые приводят к определенным преобразованиям графа.
Рекурсивная связь возникает тогда, когда экземпляр типа записи участвует
в связи с другим экземпляром того же типа записи, например один из

сотрудников подразделения является его руководителем. Рекурсивные связи
могут иметь тип 1:1, 1:М, M:N. Рекурсивная связь представляется с помо­
щью диаграммы Бахмана так, как это показано на рис. 4.9.
Кафедра

Имеет

Факультет

Рис. 4 .8. Схема базы данных Факультет

Рис. 4 .9. Рекурсивная связь Руководит

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

Рис. 4 .1 0 . Рекурсивная связь Сотрудник — Руководитель

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

модели не существует прямого способа представления связи типа M:N.
И в этом случае также необходимо что-то изменить, чтобы можно было по­
лученную структуру вписать в те рамки, которые определяет сетевая модель.
Изделие
Код_иэд J

Содержит

Назв_изд

Содержит

/ / Ç

Код_дет

Код_изд, Назв_изд

j

Вес_дет

Деталь .... {^Назв_дет '^;
Деталь
Рис. 4.11. Диаграмма представления связи типа M:N

Проводимые в таких случаях преобразования приводят к увеличению коли­
чества типов записей, так как в подобных моделях связь должна быть пред­
ставлена самостоятельным типом записи. В результате вместо одной недо­
пустимой для сетевой модели связи типа M:N появятся две связи типа 1:N,
с помощью которых можно будет легко управлять типами наборов. Графи­
ческие диаграммы, приведенные на рис. 4.11, иллюстрируют эти преобра­
зования.
Рассмотрим пример сетевой модели данных небольшой локальной ПрО,
включающей шесть объектов Факультет, Кафедра, Преподаватель, Предмет,
Группа, Студент.
Указанные объекты могут быть использованы для формирования ряда набо­
ров данных, часть которых ниже перечислена и показана на рис. 4.12:
□ Факультет — Кафедра (Фак_Каф);
□ Кафедра — Преподаватель (Каф_Преп);
□ Кафедра — Предмет (Каф_Предм);
□ Кафедра — Группа (Каф_Гр);
□ Группа — Студент (Гр_Ст);
□ Преподаватель — Группа (Куратор).
Все представленные наборы содержат разрешенные для сетевой модели свя­
зи типа "один ко многим" или "один к одному" Все вместе данные наборы
представляют собой простую сеть. В отличие от простых сетей сложные се­
ти, включающие одну или несколько связей типа "много ко многим", нуж­
даются в дополнительных преобразованиях, осуществляющих замену связи
"много ко многим" на более простые разрешенные связи!

Рис. 4.12. Подсхема сетевой модели ПрО Учебный процесс

Тип записи Группа включен в два набора Кафедра-Группа (Каф_Гр) и
Преподаватель — Группа (Куратор). Причем в обоих наборах ему отведена
роль члена набора. Таким образом, тип записи Группа имеет двоих владель­
цев, что также разрешено к использованию в сетевой модели данных.
Подводя итоги проблемам преобразования концептуальной модели в сете­
вую модель данных, следует обратить внимание и на следующий факт.
Некоторые концептуальные модели содержат не только бинарные связи, но
и связи более высоких порядков. Преобразование таких связей в сетевую
модель данных требует создание нового типа записи — записи связи, со­
стоящей из ключевых полей каждого объекта. Причем тип связи между су­
ществующими записями и записью связи всегда имеет показатель карди­
нальности "один ко многим" и запись связи всегда является записью-членом
набора.

4.2.4. Реализация наборов
Экземпляр набора обычно реализуется с помощью указателей в виде коль­
цевого списка, в котором головным элементом является экземпляр записивладельца. Установленные таким образом связи позволяют последовательно
совершать переходы между всеми записями набора с возвратом к исходной
записи-владельцу.
Списки могут быть как однонаправленные, так и двунаправленные. Двуна­
правленные связанные списки позволяют производить обход записей в обо­
их направлениях. Кроме этого, могут иметься ссылки в элементах списка на
запись владельца (для этого предусмотрены специальные поля).

Наборы делятся на одночленные, многочленные и сингулярные.
Одночленный набор состоит из одного типа записи-владельца и одного типа
записи-члена. В то же время конкретный экземпляр одночленного набора
может состоять из одного экземпляра записи-владельца и любого количест­
ва экземпляров записи-члена.
Многочленный набор состоит из одного типа записи-владельца и двух или
более типов записей-членов.
Сингулярный набор не имеет записи-владельца, в этом случае владельцем набора
является система. Сингулярный набор является средством обеспечения доступа
к экземплярам отдельных типов записей и представляет собой очень полезную
структуру при реализации алгоритмов обработки информации, предполагающих
обеспечение произвольного доступа к некоторому типу записи.
Есть три способа формирования имен для набора:
□ имя набора формируется из первых трех букв записи владельца и записи
членов;
□ имя набора связывается со смысловым содержанием;
П набор обозначается каким-либо символом; например: X, Y, Z. В этом
случае строится таблица для пояснения этих обозначений (таблица коди­
рования смыслового содержания).
Для описания фундаментальных структур схемы базы данных в CODASYLсовместимых СУБД используется язык описания данных (ЯОД). Язык опре­
деления схемы описывает концептуальную модель предметной области,
представленную в виде сетевого графа. Это описание должно включать:
□ описание схемы, задающей имя схемы;
□ описание записей, определяющее структуру каждой записи (элементов и
агрегатов);
□ описание наборов, определяющее все наборы (каждый в отдельности),
включая типы записей владельцев и членов.
Внешняя (пользовательская модель) при сетевой организации данных под­
держивается путем описания в основном части общего связного графа
(пользовательского представления), для чего применяется другой язык опи­
сания — язык определения подсхем. Однако если это требуется пользовате­
лю, в подсхеме могут быть сгруппированы новые данные, записи и наборы
могут быть переименованы, порядок описания может быть изменен.

4.2.5. Управляющая часть сетевой модели
Гибкость управления БД определяется множеством операций, разрешенных
над данными. С помощью этих операций БД переводится из одного состоя­
ния в другое. Реализуется такой переход с помощью языка манипулирова­
ния данными (ЯМД).
5 Зак. 3303

Из множества операций над данными можно выделить следующие группы:
□ операции селекции;
□ действия над данными.
Селекция — это поиск некоторого данного по заданному условию. После
осуществления селекции это данное становится текущим.
Действия над данными:
□ выборка — чтение экземпляра записи из БД;
□ включение — ввод экземпляра записи в БД с установкой соответствую­
щих связей;
□ удаление — исключение экземпляра записи из БД с установкой новых
связей;
□ модификация — изменение содержимого экземпляра записи и коррекция
связей при необходимости.
Для манипулирования данными в сетевой модели данных определен ряд
типичных операций, которые можно подразделить на две группы: навигаци­
онные операции и операции модификации.
Навигационные операции осуществляют перемещение по БД путем прохож­
дения по связям, определенным в схеме БД. В результате таких операций
определяется запись, которая называется текущей. К подобным операциям
относятся:
□ найти конкретную запись в наборе однотипных записей и сделать ее те­
кущей;
□ перейти от записи-владельца к записи-члену в некотором наборе;
□ перейти к следующей записи в некоторой связи;
□ перейти от записи-члена к владельцу по некоторой связи.
Операции модификации осуществляют как добавление новых экземпляров
отдельных типов записей, так и экземпляров новых наборов, удаление эк­
земпляров записей и наборов, модификацию отдельных компонентов самой
записи. Для реализации этих операций в системе текущее состояние детали­
зируется путем запоминания трех его составляющих: текущего набора, те­
кущего типа записи, текущего экземпляра типа записи. В такой ситуации
возможны следующие операции:
□ извлечь текущую запись в буфер прикладной программы для обработки;
□ заменить в извлеченной записи значения указанных элементов данных
на заданные новые их значения;
□ запомнить запись из буфера в БД;
□ создать новую запись;
□ уничтожить запись;

□ включить текущую запись в текущий экземпляр набора;
□ исключить текущую запись из текущего экземпляра набора.
В сетевой модели имеют большое значение средства автоматики для много­
шаговой навигации и распространения изменений по структуре данных. Се­
тевые модели обладают тем неоценимым достоинством, что они могут со­
держать любые петли; это означает, что возможно без проблем отобразить
любую концептуальную модель в датологическую модель. Недостатком этой
модели является сложность реализации.
Поддержание ограничений целостности в сетевых моделях в принципе не
требуется.
Типичным представителем СУБД, использующих сетевую модель данных,
является Integrated Database Management System (1DMS) компании Cuüinet
Software, Inc., предназначенная для использования на машинах основного
класса фирмы IBM под управлением большинства операционных систем.

4.3. Иерархическая модель данных
Первые системы управления базами данных использовали иерархическую
модель данных, и во времени их появление предшествует появлению сете­
вой модели. Для иерархической модели данных стандарты не разрабатыва­
лись, и ее изучение может быть осуществлено путем рассмотрения реально
существующих СУБД. Самой известной СУБД, использующей модель дан­
ных этого типа, является система фирмы IBM — Information Management
System (IMS). Именно эта система зарегистрирована как первая промышлен­
ная СУБД. Она была создана для поддержки лунного проекта "Аполлон" и
призвана была управлять огромным количеством деталей, иерархически свя­
занным между собой — из деталей собирались узлы, которые входили в еще
более крупные модули и так далее. Поскольку структур данных с такой орга­
низацией существует достаточно много, а системы с иерархической моделью
данных работают достаточно эффективно и проще в реализации, чем сетевые,
то нетрудно понять истоки популярности в свое время подобных систем.

4.3.1. Структурная часть иерархической модели
Основными информационными единицами в иерархической модели данных
являются сегмент и поле. Поле данных определяется как наименьшая неде­
лимая единица данных, доступная пользователю. Для сегмента определяют­
ся тип сегмента и экземпляр сегмента. Экземпляр сегмента образуется из
конкретных значений полей данных. Тип сегмента — это поименованная
совокупность входящих в него типов полей данных.
Как и сетевая, иерархическая модель данных базируется на графовой форме
построения данных, и на концептуальном уровне она является просто частным

случаем сетевой модели данных. Между конструктивными элементами этих
моделей существуют определенные аналогии. В сетевой модели вершины
графов отображают типы записей, дуги — типы связей. В иерархической
модели данных вершине графа соответствует тип сегмента или просто сег­
мент, а дугам — типы связей предок — потомок. В иерархических структу­
рах сегмент — потомок должен иметь в точности одного предка. В СУБД,
базирующихся на иерархической модели данных, используются такие струк­
туры и способы их реализации, которые позволяют отнести системы такого
типа, также как и сетевые, к классу "навигационных"
Иерархическая модель представляет собой связный неориентированный граф
древовидной структуры, объединяющий сегменты. Иерархическая БД состоит
из упорядоченного набора деревьев; более точно, из упорядоченного набора
нескольких экземпляров одного типа дерева, а не произвольных графов. При
этом граф — дерево обладает следующими свойствами (рис. 4.13):
□ имеется только одна вершина графа — корень, в которую не заходит ни
одно ребро;
□ имеются вершины графа л-го уровня, называемые исходными, куда захо­
дит одно ребро (л — 1) уровня; исходит из этого узла ноль, один или
несколько порожденных узлов, которые называются потомками;
□ единственный проход к порожденному узлу лежит через его исходный
узел;
□ каждый потомок может иметь только одного предка;
□ нет замкнутых петель или циклов;
□ сегмент, у которого нет потомков, называется

л и с т о в ы м с е гм е н т о м .

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

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

4.3.2. Преобразование концептуальной модели
в иерархическую модель данных
Преобразование концептуальной модели в иерархическую структуру данных
во многом схоже с преобразованием ее в сетевую модель, но и имеет неко­
торые отличия в связи с тем, что иерархическая модель требует организации
всех данных в виде дерева.
Преобразование связи типа "один ко многим" между предком и потомком
осуществляется практически автоматически в том случае, если потомок
имеет одного предка, и происходит это следующим образом. Каждый объект
с его атрибутами, участвующий в такой связи, становится логическим
сегментом. Между двумя логическими сегментами устанавливается связь
типа "один ко многим" Сегмент со стороны "много” становится потомком,
а сегмент со стороны "один" становится предком.
Ситуация значительно усложняется, если потомок в связи имеет не одного,
а двух и более предков. Так как подобное положение является невозможным
для иерархической модели, то отражаемая структура данных нуждается
в преобразованиях, которые сводятся к замене одного дерева, например,
двумя (если имеется два предка). В результате такого преобразования в базе
данных появляется избыточность, так как единственно возможный выход из
этой ситуации — дублирование данных.
Пусть концептуальная модель имеет вид, как на рис. 4.14, а. Тогда соответ­
ствующая ей иерархическая структура должна содержать два дерева, как по­
казано на рис. 4.14, б. Реализация подобной структуры напрямую требует
дублирования информации. В приведенном примере это касается информа­
ции о группах. Но дублирование информации — это нежелательное явление
в информационных системах. Из-за его присутствия возникает возможность
нарушения непротиворечивости данных, при этом и объем памяти расходу­
ется неэффективно, а значит, оно должно быть минимизировано.

СПЕЦИАЛЬНОСТЬ

Дерево 1

ПРЕПОДАВАТЕЛЬ

Дерево 2

Рис. 4 .1 4 . Преобразование связи с двумя предками
(а — концептуальная модель; б — иерархическая модель)

Вносимая полученной структурой избыточность данных может быть ограни­
чена при помощи виртуальных сегментов и указателей следующим образом.
Сегмент запоминается полностью только один раз. Когда сегмент должен
дублироваться в двух или более деревьях все последующие вхождения сег­
мента запоминаются как указатели на место хранения данного сегмента.
Такие вхождения называются виртуальными сегментами. При их использо­
вании избыточности данных не возникает, а требуется лишь дополнительная
память для хранения указателей.
Преобразование бинарной связи типа "многие ко многим" осуществляется по
следующему правилу. Каждый объект, участвующий в такой связи, с его ат­
рибутами становится логическим сегментом. Пусть это сегменты С1 и С2.
В отражаемой структуре данных производят преобразования, которые сво­
дятся к замене одного дерева двумя деревьями. Первое дерево включает оба
сегмента, между которыми устанавливается связь типа "один ко многим",

где С1 — предок, а С2 — потомок. Второе дерево включает опять оба этих
сегмента, между которыми устанавливается связь типа "один ко многим", но
только в этом случае С2 — предок, а С1 — потомок.
Описанная ситуация хорошо просматривается на приведенном примере
(рис. 4.15), где каждый преподаватель может работать в разных группах, а
одна и та же группа занимается с разными преподавателями. Здесь для ис­
ходной концептуальной модели (рис. 4.15, ) приведена соответствующая ей
иерархическая структура (рис. 4.15, б).

ПРЕПОДАВАТЕЛЬ

Дерево 1

ПРЕПОДАВАТЕЛЬ

Дерево 2

Рис. 4 .1 5 . Преобразование типа связи "многие ко многим"
(а — концептуальная модель; б — иерархическая модель)

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

ПРЕПОДАВАТЕЛЬ
Таб ном,ФИО, Долж
Аудитория t
Корпус, Ауд
ГРУППА

1Г
Код_груп, Кол_студ
Дерево 1

ПРЕПОДАВАТЕЛЬ
Таб ном,ФИО, Долж
Аудитория f
Корпус, Ауд
ГРУППА

i

Код_ФУп. Кол_студ
Дерево 2

Рис. 4.16. Иерархическая структура представления связи "многие ко многим"
с атрибутами

Пример более сложной иерархической модели данных некоторой предмет­
ной области приведен на рис. 4.17. Этот пример содержит только разрешен­
ные иерархические структуры, включающие в себя ряд типов сегментов и
существующие между ними связи типа "один ко многим", которые не нуж­
даются в дополнительных преобразованиях.
Перечислим их.
Типы сегментов: Факультет, Курс, Кафедра, Группа, Преподаватель, Дисциплина,
Студент.
Типы связей: Факультет/Курс, Курс/Группа, Группа/Студент, Факультет/Кафедра,
Кафедра/ Преподаватель, Кафедра/Дисциплина.
Факультет

Рис. 4.17. Иерархическая модель Факультет

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

4.3.3. Управляющая часть
иерархической модели
В рамках иерархической модели выделяют языковые средства описания
данных (ЯОД) и средства манипулирования данными (ЯМД).
Описание данных

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

Для доступа к БД у пользователя должна быть сформирована специальная
среда окружения, поддерживающая в явном виде навигационные опера­
ции, которые связаны с перемещением указателя, определяющего текущий
экземпляр конкретного сегмента. Для этого в среде окружения должны
храниться:
□ шаблоны всех записей логических БД, доступных пользователю;
□ указатели на текущий экземпляр сегмента данного типа — для всех типов
сегментов.
Среди операторов манипулирования данными можно выделить операторы
поиска данных, операторы поиска данных с возможностью модификации,
операторы модификации данных. Набор операций манипулирования дан­
ными в иерархической БД невелик, но вполне достаточен.

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

4.3.4. Ограничения целостности
Автоматически поддерживается целостность ссылок между предками и по­
томками. Основное правило: никакой потомок не может существовать без
своего родителя. Заметим, что целостность по ссылкам между сегментами,
не входящими в одну иерархию, не поддерживается.
Как уже упоминалось, типичным представителем (наиболее известным и
распространенным), использующим указанную модель данных, является
Information Management System (IMS) фирмы IBM. Первая версия появилась
в 1968 г. До сих пор поддерживается много баз данных, использующих ие­
рархическую модель данных, что создает существенные проблемы с перехо­
дом как на новую технологию БД, так и на новую технику.
В заключение обзора ранних СУБД необходимо дать оценку их сильных и
слабых сторон.

4.4. Достоинства и недостатки
ранних СУБД
Достоинства ранних СУБД:
□ развитые средства управления данными во внешней памяти на низком
уровне;
□ возможность построения вручную эффективных прикладных систем;
П возможность экономии памяти за счет разделения подобъектов (в сете­
вых системах).
Недостатки ранних СУБД:
□ сложность использования;
□ высокий уровень требований к знаниям о физической организации БД;
□ зависимость прикладных систем от физической организации БД;
□ перегруженность логики прикладных систем деталями организации дос­
тупа к БД.
Как иерархическая, так и сетевая модель данных предполагает наличие вы­
сококвалифицированных программистов. И даже в таких случаях реализа­
ция пользовательских запросов часто затягивается на длительный срок.

Вопросы и упражнения
1. Что собой представляет модель данных? Какие составляющие в ней раз­
личают?
2. Приведите классификацию моделей данных.
3. Опишите сетевую модель данных, ее структурные элементы.
4. По каким правилам строится сетевой граф?
5. Поясните методику преобразования концептуальной модели в сетевую.
6. Как осуществляется реализация наборов в сетевой модели данных?
7. Дайте характеристику иерархической модели данных.
8. Осветите структурную часть иерархической модели.
9. Изложите правила преобразования концептуальной модели в иерархи­
ческую модель данных.
10. Что собой представляет управляющая часть иерархической модели?
11. Какие ограничения целостности хранимых данных должны поддержи­
ваться в сетевой и иерархической модели данных?

SSiSS^

Глава 5

ЯВИ

888835

Реляционная
модель данных
Поскольку в вопросах обработки данных в информационных системах на
сегодняшний день реляционные базы данных занимают доминирующее по­
ложение, далее в книге им уделяется большое внимание. Эта и ряд после­
дующих глав посвящены рассмотрению целого ряда положений, касающих­
ся теоретических основ, вопросов создания реляционных баз данных и
управления ими.
Естественно, что при изложении материала будет использована и соответст­
вующая теме терминология. При этом придется иногда повторно касаться
некоторых уже рассмотренных при обсуждении методов концептуального
проектирования вопросов. Дело в том, что многие распространенные тер­
мины, применяемые в смежных областях технологий обработки данных, от­
личаются значительной размытостью и неточностью. Чтобы избежать неод­
нозначного толкования тех или иных терминов, требуется более четко
обозначить необходимые для такой формальной теории, как реляционная
теория, понятия. К тому же широкое внедрение за последние годы объект­
но-ориентированного подхода в методику построения БД придало ряду по­
нятий несколько другую окраску.

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

данных в памяти ЭВМ, что значительно упрощает взаимодействие пользова­
теля с банком данных и существенно повышает производительность его
труда.
Во-вторых, манипулирование данными реляционной базы данных, которая
с математической точки зрения представляет собой конечный набор конеч­
ных отношений различной арности между заранее определенным множест­
вом элементарных данных, осуществляется в соответствии со специально
разработанной для этой цели реляционной теорией. Над отношениями мо­
дели можно осуществлять различные алгебраические операции. Теория РБД
как раз и определяет, какие операции и каким образом необходимо выпол­
нять над отношениями, чтобы достичь заданной цели.
Создателем реляционной модели является сотрудник фирмы IBM доктор
Э. Ф. Кодц. Будучи по образованию математиком, Э. Кода предложил
использовать для обработки данных аппарат теории множеств. В статье
"A Relational Model of Data for Large Shared Data Banks", вышедшей в свет
в 1970 году, он показал, что любое представление данных сводится к сово­
купности двумерных таблиц особого вида, известного в математике как от­
ношение (relation).
Положив теорию отношений в основу реляционной модели, Э. Кодд обос­
новал реляционную замкнутость отношений и ряда некоторых специальных
операций, которые применяются сразу ко всему множеству строк отноше­
ния, а не к отдельной строке. Указанная реляционная замкнутость означает,
что результатом выполнения операций над отношениями является также
отношение, над которым в свою очередь можно осуществить некоторую
операцию. Из этого следует, что в данной модели можно оперировать реля­
ционными выражениями, а не только отдельными операндами в виде про­
стых имен таблиц.
Опираясь на абстрактную алгебру, которую образуют отношения совместно
с определенными над ними операциями, Э. Кода смог предложить такую
формальную теорию реляционной модели данных, которую отличают стро­
гие принципы математики и ее точность. Одним из основных преимуществ
реляционной модели является ее однородность. Все данные рассматривают­
ся как хранимые в таблицах и только в таблицах. Каждая строка такой таб­
лицы имеет один и тот же формат.
Кодд ввел два языка манипулирования данными, предлагающие более эф­
фективные средства доступа к данным и их обработки. Сегодня они являют­
ся основой коммерческих реляционных языков баз данных, используемых
в большинстве наиболее популярных коммерческих СУБД. Среди них наи­
более распространены SQL (Structured Query Language — структуризованный
язык запросов) и QBE (Quere-By-Example —запросы по образцу).
Созданные языки манипулирования данными позволяют реализовать все
операции реляционной алгебры и практически любые их сочетания.

Оба относятся к языкам очень высокого уровня, с помощью которых пользова­
тель указывает, какие данные необходимо получить, не уточняя процедуру
их формирования. С помощью единственного запроса на любом из этих
языков можно соединить несколько таблиц во временную таблицу и выре­
зать из нее требуемые строки и столбцы.
В настоящее время реляционный подход к построению информационных
систем является наиболее распространенным. К числу достоинств реляци­
онного подхода можно отнести:
□ наличие небольшого набора абстракций, которые позволяют сравнитель­
но просто моделировать большую часть распространенных предметных
областей и допускают точные формальные определения, оставаясь интуи­
тивно понятными;
□ наличие простого и в то же время мощного математического аппарата,
опирающегося главным образом на теорию множеств и математическую
логику и обеспечивающего теоретический базис реляционного подхода
к организации БД;
□ возможность ненавигационного манипулирования данными без необхо­
димости знания конкретной физической организации баз данных во
внешней памяти.
Вклад, который Э. Кодц внес в развитие реляционной алгебры, реляцион­
ного исчисления и нормализации отношений, трудно переоценить. За "про­
должительный фундаментальный вклад в теорию и практику развития
СУБД" Генеральным комитетом Ассоциации вычислительных машин (ACM)
в 1981 году Кодду была вручена премия Тьюринга. В докладе на присужде­
нии премии Кодд говорил:
"Основной побудительной причиной исследований, результатом которых
стало создание реляционной модели данных, было желание четко разграни­
чить логический и физический аспекты управления базами данных (прини­
мая во внимание проблемы создания БД, поиска и обработки информации).
Мы назвали это стремлением к независимости данных.
Вторым нашим желанием было создать структурно простую модель, так
чтобы пользователи и программисты любой квалификации одинаково
могли бы понимать содержащуюся в ней информацию и общаться друг
с другом с помощью базы данных. Мы назвали это стремлением к комму­
никабельности.
В-третьих, мы хотели использовать концепции языка высокого уровня (но
не специфический синтаксис), чтобы пользователи имели возможность опи­
сывать операции сразу над большими порциями информации. Это является
основой для способов обработки информации, ориентированных на множе­
ства (т. е. возможности при помощи одного оператора задать операцию над

несколькими множествами записей одновременно). Мы назвали это стрем­
лением к обработке множеств".
Среди других целей создания РМ Кода называл также разработку теоретиче­
ских основ организации управления базами данных.
В своей статье, опубликованной в журнале "Computer Word”, Кода сформу­
лировал двенадцать приведенных ниже правил, которым должна соответст­
вовать настоящая реляционная база данных.
□ Правило информации. Вся информация в базе данных должна быть пред­
ставлена исключительно на логическом уровне и только одним способом —
в виде значений, содержащихся в таблицах.
□ Правило гарантированного доступа. Логический доступ ко всем и каждому
элементу данных (атомарному значению) в реляционной базе данных
должен обеспечиваться путем использования комбинации имени табли­
цы, первичного ключа и имени столбца.
□ Правило поддержки недействительных значений. В настоящей реляцион­
ной базе данных должна быть реализована поддержка недействительных
значений, которые отличаются от строки символов нулевой длины, стро­
ки пробельных символов и от нуля или любого другого числа и исполь­
зуются для представления отсутствующих данных независимо от типа
этих данных.
□ Правило динамического каталога, основанного на реляционной модели. Опи­
сание базы данных на логическом уровне должно быть представлено
в том же виде, что и основные данные, чтобы пользователи, обладающие
соответствующими правами, могли работать с ним с помощью того же
реляционного языка, который они применяют для работы с основными
данными.
□ Правило исчерпывающего подъязыка данных. Реляционная система может
поддерживать различные языки и режимы взаимодействия с пользователем
(например, режим вопросов и ответов). Однако должен существовать по
крайней мере один язык, операторы которого можно представить в виде
строк символов в соответствии с некоторым четко определенным синтак­
сисом и который в полной мере поддерживает следующие элементы:
• определение данных;
• определение представлений;
• обработку данных (интерактивную и программную);
• условия целостности;
• идентификацию прав доступа;
• границы транзакций (начало, завершение и отмена).
□ Правило обновления представлений. Все представления, которые теорети­
чески можно обновить, должны быть доступны для обновления.

□ Правило добавления, обновления и удаления. Возможность работать с отно­
шением как с одним операндом должна существовать не только при чте­
нии данных, но и при добавлении, обновлении и удалении данных.
□ Правило независимости физических данных. ПрикладньЛ программы и ути­
литы для работы с данными должны на логическом уровне оставаться не­
тронутыми при любых изменениях способов хранения данных или мето­
дов доступа к ним.
□ Правило независимости логических данных. Прикладные программы и ути­
литы для работы с данными должны на логическом уровне оставаться не­
тронутыми при внесении в базовые таблицы любых изменений, которые
теоретически позволяют сохранить нетронутыми содержащиеся в этих
таблицах данные.
□ Правило независимости условий целостности. Должна существовать воз­
можность определять условия целостности, специфические для конкрет­
ной реляционной базы данных, на подъязыке реляционной базы данных
и хранить их в каталоге, а не в прикладной программе.
□ Правило независимости распространения. Реляционная СУБД не должна
зависеть от потребностей конкретного клиента.
□ Правило единственности. Если в реляционной системе есть низкоуровне­
вый язык (обрабатывающий одну запись за один раз), то должна отсутст­
вовать возможность использования его для того, чтобы обойти правила и
условия целостности, выраженные на реляционном языке высокого
уровня (обрабатывающем несколько записей за один раз).
Формулируя эти правила, Кодд тем самым стремился заложить фундамент
для построения эффективных систем. Тем не менее следует отметить, что
реляционные системы далеко не сразу получили широкое распространение.
В то время как основные теоретические результаты в этой области были по­
лучены еще в 70-х, и тогда же появились первые прототипы реляционных
СУБД, долгое время считалось невозможным добиться эффективной реали­
зации таких систем. Сейчас же, благодаря популярности реляционной моде­
ли, многие нереляционные системы, независимо от используемой модели,
стараются обеспечить реляционным пользовательским интерфейсом.
Однако действительность такова, что не все детали реляционной теории
нашли широкое признание и применение. Некоторые аспекты этой теории
до сих пор являются предметом разногласий, и на рынке в настоящее время
не существует продукта, который поддерживал бы все до единой возможно­
сти реляционной технологии, а пользователей и разработчиков продолжают
беспокоить ее узкие места. В настоящее время основным предметом крити­
ки реляционных СУБД являются:
□ присущая этим системам некоторая ограниченность при использовании
в так называемых нетрадиционных областях (наиболее распространен­

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

5.2. Структурная часть
реляционной модели
В главе 4 было сказано о том, что любая модель данных может рассматри­
ваться как сочетание трех компонентов, которыми являются: определение
структур модели, управление структурами модели, поддержка целостности
данных модели. Все перечисленное относится и к реляционной модели.
В этом разделе рассматриваются первый и третий ее компоненты: структур­
ная часть реляционной модели и набор ограничений целостности, которые
гарантируют корректность данных. Управляющей же части — реляционным
операциям управления данными — посвящена глава 7.

5.2.1. Реляционное отношение
Итак, как уже упоминалось, реляционная база данных — это конечный (огра­
ниченный) набор отношений. Отношения используются для представления
объектов, а также для представления связей между объектами. Отношение —
это двумерная таблица, имеющая уникальное имя и состоящая из строк и
столбцов, где строки соответствуют записям, а столбцы — атрибутам. Каж­
дая строка в таблице представляет некоторый объект реального мира или
соотношения между объектами.
Атрибут — это поименованный столбец отношения. Свойства объекта, его
характеристики определяются значениями атрибутов. Порядок следования
атрибутов не влияет на само отношение, оно имеет один и тот же смысл
при любом порядке их следования.
Хотя в литературе по базам данных понятия "отношение" и "таблица" иногда
рассматриваются как синонимы, их следует различать: отношением является
не любая таблица, а таблица, обладающая определенными свойствами.
Пусть имеется отношение г. Схемой отношения г называется конечное множе­
ство имен атрибутов {Л|, À2, Ап}. Заголовки столбцов отношения содержат
имена его атрибутов и, следовательно, все вместе отражают его схему.
Схема отношения ПРЕПОДАВАТЕЛЬ может быть представлена следующим
образом:
<Таб ном преп. Фамилия, Должность}

или:
ПРЕПОДАВАТЕЛЬ

Таб ном преп_____
Фамилия__________
Должность________

Тогда заголовок отношения ПРЕПОДАВАТЕЛЬ примет вид
Таб ном преп | Фамилия | Должность
Отношение строится с учетом ряда факторов. Каждому имени атрибута А,-,
1 <= / <= п ставится в соответствие множество допустимых для соответст­
вующего столбца значений. Это множество
называется доменом данного
имени атрибута. В самом общем виде домен определяется заданием некото­
рого базового типа данных, к которому относятся элементы домена, и про­
извольного логического выражения, применяемого к элементу типа данных.
Если вычисление этого логического выражения дает результат "истина", то
элемент данных является элементом домена.
Домены весьма важный компонент реляционной модели. Домены могут от­
личаться для каждого из атрибутов, но в то же время несколько атрибутов
могут определяться на одном и том же домене.
В семантическом плане понятие домена отражает тот факт, что данные счи­
таются сравнимыми только в том случае, когда они относятся к одному до­
мену. Например, значения доменов Номер пропуска и Номер паспорта отно­
сятся к типу целых чисел, но не являются сравнимыми. Для сравнимых же
данных могут быть определены и разного рода операции, например: соеди­
нение, пересечение и другие. Преимущество системы поддержки доменов
заключается в том, что такой системе доступно больше информации. Эту
информацию она может использовать с определенной целью: более точно
отражать семантику предметной области и предотвращать грубые ошибки.
Заметим, что домены по своей природе являются в большей степени поня­
тиями концептуальными. В большинстве реляционных СУБД понятие домена
в полной мере не используется, но при определении базы данных специфика­
ция каждого атрибута должна содержать ссылку на соответствующий домен.
В современных СУБД поддержка доменов осуществляется на примитивном
уровне и так, как это обеспечивается в реализациях языков программирова­
ния, которые предоставляют определенные встроенные типы данных. Под­
держка доменов в контексте реляционных же систем предполагает нечто
большее. Например, пользователь должен иметь возможность конструиро­
вать требуемые ему сложные типы данных, а система должна быть способ­
ной обеспечить все аспекты работы с ними.
Как уже отмечалось, отношения изображаются в виде таблиц, где имена ат­
рибутов выносятся в шапку таблицы. Каждая строка отношения является

множеством значений, взятых по одному из домена каждого имени атрибу­
та. Домены являются произвольными непустыми конечными или счетными
множествами и образуют множество:
D = D[ u D2 и ... u Dn.
Отношение г со схемой R — это конечное множество отображений {/|, /2, /р}
из R в D. Причем каждое отображение t e r должно удовлетворять следую­
щему ограничению:
tiAj) принадлежит Dh где 1 <= / <= п.
Эти отображения называются кортежами. Каждый кортеж отношения ото­
бражает экземпляр объекта, а атрибут отношения отображает атрибут объек­
та. Кортежи могут располагаться в любом порядке, при этом отношение бу­
дет оставаться тем же самым, а значит иметь тот же самый смысл.
Множество кортежей называются телом отношения. Тело отношения отра­
жает состояние объекта, поэтому во времени оно постоянно меняется. Тело
отношения характеризуется кардинальным числом, которое равно количеству
содержащихся в нем кортежей.
Первичный
ключ
ФИО

СОТРУДНИК

г

ЕЙ
ФИО
Р1 Иванов С.И.
Петров М.Т.
Отношение < Р2
Р3 С и д о р о в Р.А.
Р4 Чистов К.Л.

Должность

Стаж

Должность
Стаж
Заведующий ~2S---Инженер
5
Инженер
7
Лаборант
1

/у'

4 ....

Атрибуты
----- Степень

Домены

~к

Кортежи

Кардинальное
число
—►

Рис. 5 .1 . Отношение СОТРУДНИК

Одной из главных характеристик отношения является его степень. Степень
отношения определяется количеством атрибутов, которое в нем присутству­
ет. Эта характеристика отношения имеет еще названия: ранг и арность. От­
ношение с одним атрибутом называется унарным, с двумя атрибутами —
бинарным, с тремя — тернарным, с п атрибутами я-арным. Определение
степени отношения осуществляется по заголовку отношения.
Все названные характеристики отношения обозначены на рис. 5.1, где при­
ведено отношение СОТРУДНИК. В данном отношении есть строка заголов­
ков столбцов и тело отношения. В строке заголовков определены четыре

атрибута, следовательно, степень отношения равна 4. Атрибуты имеют свои
уникальные имена: Р#, ФИО, Должность, Стаж. Каждый атрибут определен
на своем домене.
Тело отношения содержит ряд строк — кортежей, где каждый кортеж пред­
ставляет одного сотрудника, а поэтому в данном отношении все строки раз­
личны. Количество кортежей определяет кардинальное число отношения.
В каждом кортеже представлены значения атрибутов, соответствующие дан­
ному сотруднику. Значения атрибутов берутся из множества допустимых
значений соответствующего домена, на котором определен каждый атрибут.
Элементы домена имеют атомарные значения, любое из которых предпола­
гается использовать единым элементом, не разбивая на части. Это утвер­
ждение, безусловно, относится и к значениям атрибута ФИО. Таким обра­
зом, приведенное отношение является нормализованным или, как будет
показано дальше, можно утверждать, что оно находится в первой нормаль­
ной форме, форме, которая накладывает на отношение самые минимальные
ограничения.

5.2.2. Свойства и виды отношений
Ранее было отмечено, что отношение по структуре подобно таблице, но таб­
лице, обладающей определенными свойствами, о каждом из которых говори­
лось в предыдущем подразделе. Сведем воедино все свойства отношения.
□ Отношение имеет имя, которое отличается от имен всех других отношений.
□ Отношение представляется в виде табличной структуры. Имя таблицы
соответствует имени отношения, имена столбцов — именам атрибутов,
а строки таблицы — кортежам.
□ Каждый атрибут имеет уникальное имя, его значения берутся из одного и
того же домена.
□ Каждый компонент кортежа является простым, атомарным значением, не
состоящим из группы значений. Это не позволяет заменять значение ат­
рибута другим отношением, что привело бы к сетевому или иерархиче­
скому отношению.
□ Упорядочение атрибутов теоретически несущественно, однако оно может
влиять на эффективность доступа к кортежам.
□ Все строки (кортежи) должны быть различны.
□ Теоретически порядок следования кортежей не имеет значения, но этот
порядок влияет на эффективность доступа к кортежам.
Большая часть свойств отношения проистекает из того факта, что оно рас­
сматривается как множество. Отсюда и несущественность упорядочения ат­
рибутов и кортежей, и отсутствие дубликатов кортежей.

Особое место в ряду свойств занимает требование того, чтобы каждый атри­
бут имел только простые, атомарные значения. Иными словами, необходи­
мо строить такие отношения, у которых в каждом кортеже каждый атрибут
может иметь только единственное значение. Отношение, удовлетворяющее
этому условию, называется нормализованным. Таким образом, с точки зрения
реляционной модели отношение всегда нормализовано. Этим оно отличает­
ся от математического отношения, которое вовсе не обязано быть нормали­
зованным.
Данный факт определяет более строгое ограничение в реляционной модели
в этой сфере, чем в сетевой модели данных, где разрешено использование
повторяющихся групп. Кода сознательно пошел на такое ограничение с це­
лью упрощения реляционной модели данных, но это упрощение является
одним из узких ее мест. Стремление устранить его наряду с другими факто­
рами вызвало к жизни постреляционные СУБД.
В реляционной теории встречается несколько видов отношений, но не все
они поддерживаются реальными системами.
Различают:
□ именованное отношение — это переменная отношения, определенная
в СУБД посредством специальных операторов;
□ базовое отношение — это именованное отношение, являющееся частью
базы данных;
□ производное отношение — это отношение, определенное посредством ре­
ляционного выражения через базовые отношения;
□ представление — это именованное виртуальное производное отношение,
представленное в системе исключительно через определение в терминах
других именованных отношений;
□ снимки — это отношения, подобные представлениям, но они сохраняют­
ся, доступны для чтения и периодически обновляются;
□ результат запроса — это неименованное производное отношение, полу­
чаемое в результате запроса, которое для сохранения необходимо преоб­
разовать в именованное отношение;
□ хранимое отношение — это отношение, которое поддерживается в физи­
ческой памяти.

5.2.3. Реляционные ключи
В отношении могут существовать несколько одиночных или составных ат­
рибутов, которые однозначно идентифицируют кортеж отношения. Это —
суперключи.
В особую категорию необходимо выделить потенциальные ключи. Говорят,
что множество атрибутов К = (Ai, Aj, ..., Ak) отношения R является потенци­

альным ключом R тогда и только тогда, когда удовлетворяются два незави­
симых от времени условия:
□ уникальность: в произвольный заданный момент времени никакие два раз­
личных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak;
□ минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исклю­
чен из К без нарушения уникальности.
Отношение может иметь несколько потенциальных ключей. Ключ, содер­
жащий два и более атрибута, называется составным ключом. Каждое отно­
шение обладает хотя бы одним возможным ключом, поскольку в отношении
не может быть одинаковых кортежей, а это значит, что, по меньшей мере,
комбинация всех его атрибутов удовлетворяет условию уникальности. По­
тенциальные ключи, позволяя гарантированно выделить точно один кортеж,
обеспечивают основной механизм адресации на уровне кортежей реляцион­
ной модели, а следовательно, имеют фундаментальное значение для ее ус­
пешной работы.
Один из возможных ключей (выбранный произвольным образом) принима­
ется за его первичный ключ. Обычно первичным ключом назначается тот
возможный ключ, которым проще всего пользоваться при повседневной ра­
боте. Остальные возможные ключи, если они есть, называются альтерна­
тивными ключами. Для индикации связи между отношениями используются
внешние ключи.
Внешний ключ — это набор атрибутов одного отношения, являющийся по­
тенциальным ключом другого отношения. Причем атрибуты внешнего клю­
ча не обязательно должны иметь те же имена, что и атрибуты ключа, кото­
рым они соответствуют. Часто в теории реляционных БД рассматривается
более жесткая позиция, которая требует, чтобы внешние ключи в точности
соответствовали первичным ключам, а не просто потенциальным ключам,
что справедливо в большинстве случаев.
Благодаря наличию связок между потенциальными и внешними ключами
обеспечивается взаимосвязь кортежей определенных отношений, которая
тем самым способствует удержанию базы данных в таком состоянии, что ее
можно рассматривать как единое целое. Отношение, содержащее внешний
ключ, называется дочерним или ссылающимся отношением. А отношение,
содержащее связанный с внешним ключом потенциальный ключ, — роди­
тельским или целевым отношением.
Стоит остановиться на некоторых аспектах существования внешних ключей.
Внешний и соответствующий ему потенциальный ключи должны быть оп­
ределены на одном домене. Для внешнего ключа вовсе не требуется, чтобы
он был компонентом какого-то потенциального ключа в содержащем его
отношении. В действительности внешним ключом может быть любой атри­
бут или какое-либо сочетание атрибутов отношения.

Далее, по определению: каждое значение данного внешнего ключа должно
являться значением соответствующего ему потенциального ключа. Обратное
же совсем не требуется. Потенциальный ключ родительского отношения мо­
жет иметь такие значения, которые еще не являются значениями внешнего
ключа в дочернем отношении. Например, преподаватель зачислен в штат не­
которой кафедры, а значит, в отношении ПРЕПОДАВАТЕЛЬ появился соот­
ветствующий ему кортеж, но ему еще не поручено ведение ни одной дисцип­
лины. Тогда в отношении ДИСЦИПЛИНА будут отсутствовать кортежи,
имеющие во внешнем ключе значения, соответствующие потенциальному
ключу данного преподавателя в отношении ПРЕПОДАВАТЕЛЬ.
Пояснить структуру базы данных можно путем построения ссылочных диа­
грамм. Элементами такой диаграммы являются имена родительского и до­
чернего отношений и помещенная между ними стрелка, острие которой на­
правлено на имя родительского отношения. Например: ДИСЦИПЛИНА =>
ПРЕПОДАВАТЕЛЬ.
Одно и то же отношение может быть в одной связи родительским, а в другой —
дочерним. Удобно использовать так называемый ссылочный путь, представ­
ляющий собой цепочки связанных стрелками отношений. Например:
ДИСЦИПЛИНА => ПРЕПОДАВАТЕЛЬ => КАФЕДРА => ФАКУЛЬТЕТ.
Более сложные варианты ссылок могут образовывать ссылочные циклы, где
в ссылочной диаграмме в начале и в ,конце ссылочного пути находится имя
одного и того же отношения.
Отношения не могут рассматриваться как статические объекты, так как они
предназначены для отражения некоторой части реального мира, а эта часть
реального мира может изменяться во времени. Поэтому и отношения изме­
няются во времени: кортежи могут добавляться, удаляться или модифициро­
ваться. Тем не менее предполагается, что сама схема отношения инвари­
антна во времени. Отношение должно восприниматься как множество
возможных состояний, которые может принимать отношение.
Для закрепления сказанного рассмотрим ряд моделей некоторых локальных
предметных областей.
Пример 1

Пусть рассматривается концептуальная модель, приведенная на рис. 5.2.
Пример относится к предметной области, которую можно назвать "Препо­
давательская деятельность” Данная модель содержит два объекта: ЛЕКТОР
и ПРЕДМЕТ, между которыми установлена связь ЧИТАЕТ типа "много ко
многим" Характеристики объектов представлены изображенными на рисун­
ке атрибутами. Связь ЧИТАЕТ не имеет собственных атрибутов.
Для преобразования концептуальной модели в реляционную модель разра­
ботан ряд технологий, знакомство с которыми состоится несколько позже

в разделе 6.2. В данный момент, не вдаваясь в подробности причин приня­
того решения, просто приведем реляционную схему, соответствующую ука­
занной концептуальной модели. Она включает в себя три отношения:
ЛЕКТОР, ПРЕДМЕТ, ЧИТАЕТ. Схемы отношений и связи между ними
изображены на рис. 5.3.

Рис. 5.2. Концептуальная модель для примера 1

Рис. 5.3. Реляционная схема базы данных для примера 1

На рис. 5.4 даны соответствующие отношения, заполненные кортежами.
Эти отношения имеют следующие характеристики:
□ ЛЕКТОР — 4-арное отношение с первичным ключом Код лек, с карди­
нальным числом, равным четырем; атрибуты определены на следующих
доменах: Код лек — {целые: 01...04}, ФИО — {возможные фамилии и
инициалы}, Уч_степень — {Канд_техн_наук, Докт_техн_наук, Не_имеет_
степени}, Уч_звание — {Доцент, Профессор, Не_имеет_звания};
□ ПРЕДМЕТ — тернарное отношение с первичным ключом Код предм.
с кардинальным числом, равным шести; атрибуты определены на сле­
дующих доменах: Код предм — {символьный}, Назв_предм — {Информа­
тика, Программирование, Дискретная математика, ООП, Базы данных,
Структуры и алгоритмы}, Кол_во_час — {целые: 54, 102, 36};
□ ЧИТАЕТ — бинарное отношение с составным первичным ключом
Код лек. Код предм. с кардинальным числом, равным шести, в котором

присутствуют первичные ключи только читающих лекторов и первичные
ключи только читаемых предметов.
ЛЕКТОР
Кодлек

ФИО

Уч_степень

Уч_звание

Канд_техн_наук Доцент

01

Иванов Т.Т.

02

Сидоров П.П.

Канд_техн_наук Доцент

03

Мухин И.И.

Докт_техн_наук Профессор

04

Борисов Г. Г

Канд_техн_наук Доцент

ПРЕДМЕТ

ЧИТАЕТ

Крд прздм

Назв_предм

Кол_во_час

Код поедм

код пак

01

Информатика

54

01

02

02

Программирование

102

02

02

03

Дискретная
математика

36

03

04

54

04

01

102

05

03

54

06

01

04

ООП

05

Базы данных

06

Структуры и
алгоритмы

Рис. 5.4. Реляционные отношения модели для примера 1

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

Рассмотрим концептуальную модель предметной области, состоящей из трех
объектов: РАБОЧИЙ, ДЕТАЛЬ, ИЗДЕЛИЕ (рис. 5.5). Между объектами оп­
ределены следующие связи:
□ между объектами РАБОЧИЙ и ДЕТАЛЬ — связь ИЗГОТАВЛИВАЕТ типа
"много ко многим”;
□ между объектами ДЕТАЛЬ и ИЗДЕЛИЕ — связь ВХОДИТ типа "много
ко многим"
Характеристики объектов представлены изображенными на рисунке атрибу­
тами. Связи ИЗГОТАВЛИВАЕТ и ВХОДИТ не имеют собственных атрибутов.
Также как и в предыдущем примере, без обсуждения методики преобразова­
ния концептуальной модели в реляционную приведем сразу результирующую

реляционную схему базы данных, соответствующую указанной концепту­
альной модели. Данная модель включает в себя уже пять отношений:
РАБОЧИЙ, ИЗГОТАВЛИВАЕТ, ДЕТАЛЬ, ВХОДИТ, ИЗДЕЛИЕ (рис. 5.6) по одному отношению для каждого объекта и по одному отношению на ка­
ждую связь, определенную в модели.

Рис.5.5. Концептуальная модель для примера 2

Рис. 5.6. Реляционная схема базы данных для примера 2

Отношения имеют следующие характеристики:
□ РАБОЧИЙ — тернарное отношение с первичным ключом Таб ном,
с кардинальным числом, равным четырем; атрибуты определены на еле-

дующих доменах: Таб ном — {целые: 01...04}, ФИО — {возможные фами­
лии и инициалы}, Квалификация — {целые: 1...3};
□ ИЗДЕЛИЕ — бинарное отношение с первичным ключом Код изд.
с кардинальным числом, равным четырем; атрибуты определены на сле­
дующих доменах: Код изд — {символьные: И1...И4}, Назван_изд — {Иа,
Ив, Ис, Ид};
□ ИЗГОТАВЛИВАЕТ — бинарное отношение с составным первичным
ключом Таб ном. Код изд. с кардинальным числом, равным четырем,
в котором присутствуют первичные ключи только рабочих, участвующих
в изготовлении деталей, и первичные ключи только изготавливаемых
деталей;
□ ДЕТАЛЬ — бинарное отношение с первичным ключом Код дет, с карди­
нальным числом, равным трем; атрибуты определены на следующих до­
менах: Код дет — {символьные: Д1...ДЗ}, Назван_дет — {Да, Дв, Дс};
□ ВХОДИТ — бинарное отношение с составным первичным ключом
Код изд. Код дет, с кардинальным числом, равным пяти, в котором при­
сутствуют первичные ключи только выпускаемых изделий, и первичные
ключи только тех деталей, которые входят в состав выпускаемых изделий.
РАБОЧИЙ

ИЗГОТАВЛИВАЕТ

Таб ном

ФИО

Квалифик

Таб ном

KsMjae.T

01

Иванов В.И.

1

01

Д1

02

Цей Т.Т.

2

02

Д2

03

Гром Б.Ю.

2

03

ДЗ

04

Ли Ю.Ю.

3

04

ДЗ

ИЗДЕЛИЕ
Кед-изд

ДЕТАЛЬ
Код дет Назв
Д1

Да

Д2

Дв

ДЗ

Дс

ВХОДИТ
Назв

И1

Иа

И2

Ив

ИЗ

Ис

И4

Ид

Рис. 5 .7 . Реляционные отношения модели для примера 2

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

5.2.4. Обновление отношений
Для обновления отношений необходимо иметь возможность выполнять сле­
дующие операции:
□ добавление кортежа;
□ удаление кортежа;
□ изменение кортежа.
Рассмотрим их по порядку.
Операция добавления для отношения г (Ai, А2, ... А„) имеет вид:
ADD

(г;

A l= d l, A2=d2,

An=dn)

Если порядок атрибутов фиксирован, возможна более короткая запись:
ADD

(г;

d l,

d2,

d n ).

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

(г;

A l= d l,

A 2=d2,

A n = d n ),

или для упорядоченных атрибутов:
DEL

(г;

d l,

d2,

d n ).

Для удаления некоторого кортежа часто достаточно указать значение неко­
торого ключа:
DEL

( г ; кл ю ч).

Если указанный кортеж в отношении отсутствует, то отношение остается
неизменным.
Операция изменения предназначена для модификации части кортежа. Для
отношения гее можно при {с1; с2, ср\ е {А\, А%, ... Ап) определить так:
CH

(г;

c l= e l,

A l= d l, A 2=d2,
c2=e2,

An=dn;

cp=ep)

Если К = {B\, Bi,
быть сокращена:

Bm) является ключом, то запись данной операции может

CH ( г ;

B l= d l,

B 2 = d 2 , Bm=dm;

c l= e l,

с2=е2,

ср=ер)

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

5.3. Целостность базы данных
Данный раздел посвящен рассмотрению вопросов, связанных с поддержкой
данных базы в целостном непротиворечивом состоянии. Именно такое со­
стояние базы данных гарантирует корректность данных. Поддержка целост­
ности базы данных реализуется посредством ряда ограничений, наклады­
ваемых на данные.
Первый тип ограничений проистекает из того факта, что каждый атрибут оп­
ределяется на своем домене, или наоборот: домен атрибута задает множество
значений, которые может принимать атрибут. Указанное ограничение назы­
вается ограничением домена.
Если значение атрибута в настоящий момент неизвестно или неприемлемо
для данного кортежа, то в этом случае в реляционной теории Кодца реко­
мендуется использовать понятие NULL, которое он рассматривал как не­
отъемлемую его часть. Следует помнить, что NULL — это не значение атри­
бута. Это понятие призвано обозначать отсутствие какого-либо значения
атрибута. Например, фирма выпускает изделие, но стоимость его еще уточ­
няется, преподаватель оформлен на работу, но состав его нагрузки еще не
определен.
В системе для атрибута может быть разрешено или запрещено иметь значе­
ния NULL. В том случае, когда атрибуту запрещается иметь такие значения,
система должна отвергать любые попытки ввода значения NULL.
Поскольку использование данного понятия значительно усложняет пробле­
мы реализации модели, так как требует использования логики более высо­
кого порядка, чем двузначная, поддержка с определителем NULL обеспечи­
вается не каждой реляционной системой. К тому же ряд специалистов
считают, "что NULL значения — и целая теория трехзначной логики, на ко­
торой они базируются, — являются фундаментальным заблуждением, и не
должны иметь места в чистой формальной системе, такой, какой подразуме­
вается реляционная модель", поскольку в нынешнем виде они разрушает
логические основы реляционной модели. Их точка зрения такова, что про­
блема отсутствия значений еще не до конца осмыслена, в настоящее время
не известно Ни одного полного удовлетворительного решения проблемы и
включать ее в реляционную модель преждевременно.
Весьма важными понятиями в теории реляционных баз данных являются
категорная целостность и целостность на уровне ссылок.

Категорная целостность ограничивает набор значений первичных ключей
базовых отношений. Такого рода целостность заключается в следующем:
кортеж не может записываться в БД до тех пор, пока значения его ключе­
вых атрибутов не будут полностью определены. Иными словами: никакой
ключевой атрибут любого кортежа отношения не может содержать отсутст­
вующего значения, обозначаемого определителем NULL.
Суть этого ограничения довольно легко уяснить, если вспомнить то, что
первичный ключ К должен обладать минимальностью: ни один из его атри­
бутов Ai, Aj, ..., Ak не может быть исключен из К без нарушения его уни­
кальности. В том же случае, когда один из его атрибутов не определен, как
раз и происходит нарушение его уникальности — он перестает быть иден­
тифицирующим атрибутом, а весь объект становится не идентифицируемым.
Поскольку в базу данных не должна записываться информация о чем-то,
что невозможно идентифицировать, то подобный объект не имеет права
быть включенным в базу данных.
Для не базовых отношений в реляционной модели допускается присутствие
определителя NULL в его первичном ключе.
Целостность на уровне ссылок. При построении отношений для связывания
строк одной таблицы со строками другой таблицы используются внешние
ключи. База данных, в которой все непустые внешние ключи ссылаются на
текущие значения ключей другого отношения, обладает целостностью на
уровне ссылок. Добавим, что из этого утверждения вытекает и другое:
внешние ключи также не должны содержать NULL значений.
Суть вопроса можно пояснить на примере. Пусть есть два отношения:
STUD (Ном зач кн. ФИО, Адрес);
SES (Ном зач кн. Оценка1, Оценка2, ОценкаЗ).
При удалении записи, содержащей сведения о студенте из отношения
STUD, в отношении SES появятся записи, не связанные ни с одним студен­
том — происходит нарушение целостности базы данных. Поддержка ссы­
лочной целостности также требует, чтобы система предотвращала любые
попытки создать кортеж в отношении SES, содержащий сведения о сдаче
сессии студентом с атрибутом Ном_зач_кн_до тех пор, пока в отношении
STUD не будет создан кортеж, содержащий сведения об этом студенте. От­
ношение же STUD может содержать кортежи со сведениями о студентах,
информация о сдаче сессии которыми еще не внесена в отношение SES.
Не все СУБД своими средствами автоматически поддерживают целостность
БД. В этом случае пользователь должен сам заботиться об обеспечении це­
лостности БД при удалении и модификации данных. Проверка целостности
данных может осуществляться программными средствами. Однако более
правильным является определение условия целостности данных на уровне
базы данных, так как в этом случае ни одно приложение не может нарушить
целостность данных.

Исходя из сказанного, для обеспечения целостности данных необходимо
выполнить следующие действия.
□ При удалении из отношения записи нужно проверить отсутствие ссылок
на удаляемую запись во всех связанных,с ним отношениях. Причем
прежде всего необходимо удалить в связанных отношениях все записи,
которые ссылаются на удаляемую запись, и только после этого — саму
запись.
□ Необходимо внимательно относиться к изменению значений связующих
полей. Например, при выдаче новой зачетной книжки взамен утерянной.
□ При добавлении новой записи в отношение, в котором осуществляется
ссылка на значение в другом отношении, необходимо проверить наличие
связующих полей в отношении, на которое осуществляется ссылка.
Как правило, определение условия целостности данных осуществляется при
установлении взаимосвязи между родительским и дочерним отношениями;
при этом пользователю часто предоставляется возможность самому решить,
каким путем сохранять целостность базы данных и насколько жестко долж­
но соблюдаться условие целостности при различных операциях изменения
данных.
Так, например, при изменении значения первичного ключа в родительском
отношении часто разрешены следующие варианты действий, из которых два
первых — обеспечивают нахождение базы данных в целостном непротиво­
речивом состоянии.
О При изменении значений полей первичного ключа в родительском от­
ношении автоматически осуществляется каскадное изменение всех соот­
ветствующих значений в дочернем отношении.
□ Не позволяется изменять значения полей первичного ключа в родитель­
ском отношении, если в дочернем отношении имеется хотя бы одна за­
пись, содержащая ссылку на изменяемую запись.
□ Позволяется изменять значения полей первичного ключа в родительском
отношении, независимо от существования связанных записей в дочернем
отношении. Целостность данных при этом не поддерживается.
При удалении записи в родительском отношении также возможны несколь­
ко вариантов действий.
□ При удалении записи в родительском отношении автоматически осуще­
ствляется каскадное удаление всех записей из дочернего отношения, свя­
занных с удаляемой записью:
□ Не позволяется удалять записи в родительском отношении, если в дочер­
нем отношении имеется хотя бы одна запись, содержащая ссылку на уда­
ляемую запись. При попытке удаления записи возникает ошибка, кото­
рую можно обработать программно.

□ Позволяется удалять записи в родительском отношении независимо от
существования связанных записей в дочернем отношении. Очевидно, что
целостность данных при этом не поддерживается.
При добавлении новой записи в дочернее отношение или редактировании
в нем существующей записи возможно выбрать один из вариантов:
□ не позволяется вводить запись, если значение индексного выражения
дочернего отношения не соответствует одной из записей в родительском
отношении;
□ при вводе данных в дочернее отношение не анализируется значение ин­
дексного выражения. Целостность данных при этом не поддерживается.
Еще один вид ограничений, накладываемый на информацию, содержащую­
ся в отношениях, связан с теми бизнес-правилами, которые существуют
в данной организации или в моделируемой предметной области. Это так
называемые дополнительные правила поддержки целостности данных, оп­
ределяемые пользователем или администратором данных, которые называ­
ются корпоративными ограничениями целостности.
Приведем примеры таких правил:
□ студентам нельзя планировать занятия продолжительностью более восьми
часов в день;
□ студенты весь день должны заниматься в одном корпусе вуза, чтобы не
требовалось дополнительное время на переходы из одного здания в другое.

Итоги
□ Реляционная база данных является совокупностью изменяющихся во
времени нормализованных отношений различных степеней арности, ко­
торые могут быть связаны друг с другом через общие домены.
□ Степень отношения — число его атрибутов. Отношение степени один
называют унарным, степени два — бинарным, степени три — тернар­
ным, а степени п — л-арным.
□ Кардинальное число или мощность отношения — это число его корте­
жей. Кардинальное число отношения изменяется во времени в отличие
от его степени.
□ Если атрибут неприменим или его значение неизвестно, то для отраже­
ния этого факта необходимо использовать определитель NULL.
□ Реляционная схема базы данных содержит имена реляционных таблиц,
имена атрибутов, ключевые атрибуты, внешние ключи.
□ В реляционной базе данных должна обеспечиваться поддержка ограниче­
ний доменной, категорией, ссылочной и корпоративной целостности,
которым должны удовлетворять данные.

Вопросы и упражнения
1. Осветите исторические аспекты появления реляционного подхода соз­
дания баз данных и его содержание.
2. Объясните своими словами смысл терминов:
• реляционная модель данных;
• реляционная схема базы данных.
3. Охарактеризуйте реляционную модель данных.
4. Дайте развернутое пояснение структурной части реляционной модели
данных.
5. Объясните термины:
• отношение;
• кортеж;
• атрибут и степень отношения;
• первичный и внешний ключи;
• домен;
• кардинальное число.
6. Поясните свойства и виды отношений.
7. Объясните смысл использования потенциальных и первичных ключей
отношений. Как использовать ключи для связи отношений?
8. Поясните операции обновления отношений.
9. Каким образом реализуется поддержка целостности базы данных?
10. Дайте определение двух основных правил целостности базы данных.
11. Какие существуют пути сохранения целостности базы данных при раз­
личных операциях изменения данных?

яяяяяя
Глава 6

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

с требуемыми свойствами. Иначе, как было отмечено в первой главе книги,
скорее всего, будет повторяться то, что мы уже проходили: в результате боль­
ших усилий и затрат появляются ненадежные, сложные в сопровождении,
неэффективные программные продукты.
Можно выделить два подхода к проектированию реляционной базы данных.
Первый, более традиционный предложенный Коддом подход, предполагает
создание на этапе концептуального проектирования не концептуальной мо­
дели данных, а непосредственно реляционной схемы базы данных, состоя­
щей из определений реляционных отношений. Собственно проектирование
реляционной базы данных заключается в нормализации определений этих
отношений. Нормализация представляет собой вариант восходящего подхо­
да к проектированию базы данных, который заключается в постепенном
выявлении различного рода зависимостей между атрибутами и устранении
нежелательных из них.
Второй подход основан на концептуальной модели данных, создаваемой на
этапе концептуального проектирования. Затем эта модель механически пре­
образуется в реляционную модель. Процесс преобразования автоматически
гарантирует получение нормализованной реляционной модели. Данный
подход можно отнести к категории нисходящих, поскольку он начинается
с построения концептуальной модели, где усилия концентрируются, прежде
всего, на выявлении важных для организации объектов и их связей. К полу­
ченной таким путем реляционной схеме базы данных для проверки ее кор­
ректности применяется процесс нормализации, но уже в упрощенном виде,
поскольку, как правило, он уже не приводит к перестройке отношений, так
как в схеме реляционной базы данных отсутствуют нежелательные зависи­
мости между атрибутами отношений.
До широкого распространения и признания концептуальных моделей тра­
диционно использовался первый подход. Он все еще полезен в ситуациях,
когда требуется достаточно простая схема базы данных. В таких случаях
программист может выбрать то, что для него проще. Второй подход с ис­
пользованием концептуальных моделей имеет высокую ценность при проек­
тировании больших, сложных схем баз данных, необходимых для корпора­
тивных ИС.
В данной книге рассматриваются оба указанных подхода.

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

ясняется разными причинами. Одни функциональные зависимости отража­
ют взаимосвязи в исследуемой предметной области, источник других же
кроется в структуре сформированных отношений. При неправильно сгруп­
пированных отношениях некоторые функциональные зависимости могут
оказаться нежелательными из-за побочных эффектов или аномалий, кото­
рые они вызывают при обновлении БД. В связи с этим возникает вопрос
о корректности представленной схемы. Корректной считается схема, в ко­
торой отсутствуют нежелательные функциональные зависимости между ат­
рибутами.
Для приведения реляционной базы данных к корректному состоянию Кода
предложил использовать разработанный им процесс нормализации, который
представляет собой метод создания набора отношений с заданными свой­
ствами на основе требований к данным, установленным в некоторой орга­
низации.
Хотя процесс нормализации и является формальным общепризнанным
методом, но в литературе бытует много различных его определений. Выше
приведено одно из них. Процесс нормализации часто выполняется в виде
последовательности тестов для некоторого отношения с целью проверки его
соответствия определенным требованиям некоторой нормальной формы.
В случае отсутствия такого соответствия приходится прибегать к процедуре,
называемой декомпозицией (разложением), при которой данное множество
отношений заменяется другим множеством отношений (при этом число их
возрастает), являющихся проекциями первых. Цель этой процедуры — уст­
ранить нежелательные функциональные зависимости (а следовательно,
и аномалии), что составляет суть процесса нормализации.
Другими словами, нормализация — это пошаговый, обратимый процесс за­
мены данной схемы (или совокупности отношений) другой схемой, в кото­
рой отношения имеют более простую и регулярную структуру.

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

Вот характерный пример отношения (табл. 6.1), содержащего нежелатель­
ную избыточность:
Таблица

6.1. Отношение СТУДЕНТ

Ном_зач_кн ФИО_студента

Код_группы ФИО_старосты

Куратор

20-Т-201

Иванов С.И.

20-Т-11

Рябов В.С

Доц. Фок И.И.

20-Т-215

Петров Я.Р.

20-Т-12

Сизов М.М.

Доц. Докин С.С.

20-Т-217

Рябов В.С

20-Т-11

Рябов В.С

Доц. Фок И.И.

20-Т-211

Сенова А.Л.

20-Т-11

Рябов В.С

Доц. Фок И.И.

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

6.1.2. Аномалии обновления в базе данных
Выше не один раз упоминалось о том, что процесс нормализации позволяет
проектировщику базы данных избавиться от присутствия в ней различного
рода аномалий.
Различают три вида аномалий в базе данных:
□ аномалии включения;
□ аномалии удаления;
□ аномалии модификации.
Аномалии включения

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

цо только что обсуждавшееся дублирование данных, при котором любая
неточность ввода данных о новом студенте переведет базу данных в несогла­
сованное состояние.
Таблица 6.2. Отношение СТУДЕНТ
Ном зач кн

ФИО_
студента

Код_
группы

Таблица 6.3. Отношение ГРУППА

ГРУППЫ

ФИО_
старосты

Код

Куратор

20-Т-201

Иванов С.И.

20-Т-11

20-Т-11

Рябов В.С

Доц. Фок И.И.

20-Т-215

Петров Я.Р.

20-Т-12

20-Т-12

Сизов М.М.

Доц. Докин С.С.

20-Т-217

Рябов В.С

20-Т-11

20-Т-13

NULL

NULL

20-Т-211

Сенова А.Л.

20-Т-11

Второй вид аномалии включения в такой ситуации возникает при попытке
создать новую группу и ввести ее в отношение при том условии, что в нее
еще не зачислен ни один студент. Ввод такой информации в подобной си­
туации требует присвоения значения NULL всем атрибутам описания сту­
дента, в том числе и атрибуту Ном_зач_кн, который является первичным
ключом данного отношения. Но реализация такой попытки приведет к на­
рушению категорной целостности, а значит, система ее обязана отклонить.
Результатом анализа является вывод о том, что в отношении табл. 6.1 при­
сутствуют аномалии включения, а следовательно, это отношение должно
быть преобразовано таким образом, чтобы от них избавиться.
Структура отношений, содержащая ту же информацию, что и отношение
СТУДЕНТ, но лишенная аномалий включения, представлена в табл. 6.2 и 6.3.
Для того чтобы добиться указанной цели, потребовалось вместо одного от­
ношения сформировать два отношения с меньшими степенями, чем исход­
ное, но эти отношения уже лишены аномалий включения. В отношении
СТУДЕНТ для каждого студента помимо описывающих его атрибутов при­
сутствует только атрибут, относящий его к определенной группе и связы­
вающий оба отношения, а отношение ГРУППА содержит перечень всех
групп, куда очень просто внести дополнительную группу, пометив неопре­
деленные значения описательных атрибутов NULL-значениями.
Аномалии удаления

Вернемся к анализу отношения, представленного в табл. 6.1. Напомним, что
это отношение содержит сведения о студентах, и каждый его кортеж вклю­
чает значения атрибутов, относящиеся к нему и к группе, в которой он обу­
чается. Причем при удалении из этого отношения кортежа:
20-Т-215

Петров Я.Р.

20-Т-12

Сизов М.М.

Доц. Докин С.С.

из базы данных будут удалены все сведения о группе 20-Т-12. Такая ситуа­
ция представляет собой аномалию удаления.

Для исключения из базы данных аномалии удаления это отношение должно
быть преобразовано. Причем оказывается, что преобразования должны быть
проведены точно такие же, какие были проведены для исключения анома­
лии включения.
Рассмотрим отношения, представленные в табл. 6.2 и 6.3. При удалении
кортежа
20-Т-215

Петров Я.Р.

20-Т-12

из отношения СТУДЕНТ сведения о группе 20-Т-12 не исчезнут из базы
данных, поскольку они содержатся в отношении ГРУППА и их присутствие
не зависит от того факта, есть ли в отношении СТУДЕНТ кортежи, относя­
щиеся к этой группе, или нет.
Аномалии модификации

В исходном отношении, представленном в табл. 6.1, помимо аномалий вклю­
чения и удаления, присутствует еще одна аномалия, которая называется ано­
малией модификации. Такая аномалия возникает при попытке изменить чтолибо касающееся сведений о группе обучения студента. Допустим, что
в группе 20-Т-11 решили назначить нового старосту, например Сенову А. Л.
В такой ситуации необходимо просмотреть все кортежи отношения и в каж­
дом кортеже значение атрибута ФИО_старосты заменить Рябов В. С. на Сенова А. Л. При наличии большого количества кортежей в рассматриваемом
отношении очень просто в процессе замены пропустить какой-либо кортеж
или допустить ошибку при вводе новой информации. Помимо больших
временных затрат, требуемых для выполнения этой работы, результатом
таких промахов будет являться перевод базы данных в противоречивое
состояние. Естественно, нельзя надеяться на то, что подобная база всегда
будет выдавать корректную информацию.
Появление аномалии модификации можно заблокировать, если опять же
прибегнуть к преобразованию отношения из табл. 6.1. И не случайно оказы­
вается, что эти преобразования точно такие же, которые были исполь­
зованы для исключения аномалий включения и удаления. Действи­
тельно: смена старосты группы требует изменения значения атрибута
ФИО_старосты только в одном кортеже отношения табл. 6.3, что совершен­
но нетрудно сделать.
Подведем итоги: задача группировки отношений может быть решена мно­
жеством способов, но требуется найти такой состав отношений, который
удовлетворял бы, по крайней мере, следующим требованиям:
О множество отношений должно обеспечивать минимизацию избыточности
представления информации;
□ назначенные для отношения ключи должны быть минимальными;

□ при выполнении операций удаления, включения, модификации в БД не
должно быть аномалий.
К перечисленным требованиям необходимо добавить еще два, смысл кото­
рых очевиден и не нуждается в дополнительных пояснениях:
□ перестройка набора отношений при изменении структуры какого-либо
отношения (добавление атрибутов в отношение, удаление, изменение
имеющихся) должна быть минимальной;
□ разброс времени выполнения запросов в БД должен быть небольшим.
Например, отношение ПОСТАВКА содержит следующие атрибуты:
ПОСТАВКА (Дата поставки. Назв поставщика. Товар.
Адрес_поставщика, Количество_товара, Цена_ ед_товара)
Такое отношение имеет следующие нежелательные свойства:
□ избыточность информации (Адрес_ поставщика);
□ первичный ключ не минимален;
□ аномалия модификации: при изменении Адрес_поставщика он не изменяется
в других записях, в результате возникает нарушение целостности БД;
□ аномалия включения: если с поставщиком заключен договор, но товар не
поставлен, его нельзя включить в БД;
□ аномалия удаления: если удалили все поставки некоторого поставщика,
то теряются вообще все сведения о нем.
Проблема обратимости

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

При этом в результирующем отношении не должны появляться ранее отсут­
ствующие кортежи, являющиеся следствием ошибочного соединения.
Такая декомпозиция обеспечивает обратимость, то есть получение исход­
ного множества отношений путем применения естественных соединений
над их проекциями, а раз это так, то отпадает необходимость выполнения
соединений результирующих отношений для проверки того, не нарушаются
ли исходные ограничения.
Существуют ли формальные правила, обеспечивающие проведение коррект­
ной в указанном смысле декомпозиции? Забегая вперед, можно определить
некоторые условия ее проведения. Например, отсутствие потерь при декомпо­
зиции отношения г{Х, У, Z) на r\(X, У) и г2( У, Z) гарантируется при следую­
щем условии: если от общего атрибута двух получаемых отношений (в данном
случае атрибута У) зависит хотя бы один атрибут из двух оставшихся. Иными
словами, если Y —>X (если У определяет X) или Y Z (если У определяет Z),
то декомпозиция осуществляется без потерь. Обеспечение отсутствия потерь и
сохранения зависимостей при декомпозиции требуют знания всех возможных
функциональных зависимостей, имеющихся в данной схеме. Вначале известно
лишь их подмножество, но можно получить все остальные.

6.1.3. Процесс нормализации
Для устранения рассмотренных выше недостатков и применяется процесс
нормализация отношений. Данный процесс — это формальный метод ана­
лиза отношений на основе их первичных или потенциальных ключей и су­
ществующих функциональных зависимостей, являющийся одним из наибо­
лее строгих способов улучшения характеристик БД. Он включает ряд
формальных правил, используемых для проверки всех отношений базы дан­
ных. Различают:
□ 1НФ — первую нормальную форму;
□ 2НФ — вторую нормальную форму;
□ ЗНФ — третью нормальную форму;
□ НФБК — нормальную форму Бойса — Кодда;
□ 4НФ — четвертую нормальную форму;
□ 5НФ — пятую нормальную форму.
Каждая нормальная форма налагает определенные ограничения на данные.
Эти ограничения вводятся в каждом конкретном отношении, и соблюдение
этих ограничений в отношении связано уже с наличием нормальной формы.
О 1НФ, 2НФ, ЗНФ — ограничивают зависимость непервичных атрибутов
от ключей.
□ НФБК — ограничивает зависимость первичных атрибутов.

□ 4НФ — формулирует ограничения на виды многозначных зависимостей.
□ 5НФ — вводит другие типы зависимостей: зависимости соединений.
Каждая нормальная форма более высокого уровня предполагает, что анали­
зируемое отношение уже находится в нормальной форме на уровень ниже
рассматриваемой. Чем выше уровень нормальной формы, тем жестче накла­
дываемые на отношения ограничения. В ходе нормализации схема базы
данных становится все более строгой, а ее отношения все менее подвержены
различного рода аномалиям. Сам процесс перехода от нормальной формы
более низкого уровня к нормальной форме более высокого уровня и назы­
вается нормализацией отношений (НО).
Для реляционных баз данных необходимо, чтобы все отношения базы дан­
ных обязательно находились в 1НФ. Нормальные формы более высокого
порядка могут использоваться разработчиками по своему усмотрению. Од­
нако грамотный специалист стремится к тому, чтобы довести уровень нор­
мализации базы данных хотя бы до ЗНФ, тем самым исключив из базы дан­
ных избыточность данных и аномалии обновления. В процессе
нормализации на каждом егр этапе производится анализ первоначальных
отношений, в результате которого выявляются зависимости между данными
и в соответствии с ними осуществляется их перегруппировка.
Переходя к знакомству с нормальными формами, подчеркнем тот факт, что
процесс нормализации не использует концепции ER-моделирования и на­
чинается с некоторых табличных структур, которые проектировщик намерен
использовать в качестве исходных. Какие это будут отношения, зависит от
знаний, опыта и интуиции проектировщика. Удачный выбор первоначаль­
ных отношений может существенно сократить объем работ процесса норма­
лизации и свести его только к доказательству правильности выбора.
Функциональные зависимости и ключи

Функциональная зависимость определяется для атрибутов, находящихся
в одном и том же отношении в 1НФ. Функциональная зависимость является
семантическим свойством атрибутов отношения. Часто рассматриваются
функциональные зависимости между двумя атрибутами.
Пусть дана схема отношения
R(au a2, ..., a„).
Атрибут a2 функционально зависит от атрибута а\, если каждому значению
ai соответствует единственное значение а2 (т. е. каждый кортеж, имеющий
одно и то же значение а\, должен иметь одно и то же значение а2).
Обозначается подобная ситуация так: а\ -> а2. Левая часть функциональной
зависимости называется детерминантом, а правая часть — зависимой частью.
Отсутствие функциональной зависимости обозначается а-/-> Ь.

Неоднократно упоминалось о том, что создание баз данных преследует две
основные цели: понизить избыточность данных и повысить их надежность.
Любое априорное знание об ограничениях, накладываемых на данные, мо­
жет принести большую пользу в этом направлении. Установление функцио­
нальных зависимостей — один из способов формализации этих знаний. Рас­
смотренная выше функциональная зависимость — это / ’-зависимость.
Дадим более общее формальное определение функциональных зависимостей
с использованием реляционных операторов.
Пусть /--отношение со схемой
R,а
удовлетворяет функциональной зависимости -»
если Ру(&х=х(г)) (проек­
ция на У) имеет не более чем один кортеж для каждого Л'-значения х. Один
из способов интерпретировать это выражение — рассмотреть два кортежа /)
и /2 в г. Если tx(X) = t2(X) , то /ДУ) = /2(>0Такая интерпретация функциональной зависимости приводит к следующему
алгоритму выявления ее наличия.
Вход: отношение г и /"-зависимость
Выход: истина, если г удовлетворяет

Х —ложь —

Тело алгоритма.
1. Пересортируем отношение г по Л'-столбцам так, чтобы собрать кортежи
с равными Л'-значениями вместе.
2. Если каждая совокупность кортежей с равными Л’-значениями имеет
также равные /-значения, то на выходе получаем истину, в противном
случае — ложь.
Этот алгоритм проверяет, удовлетворяет ли отношение / ’-зависимости -»
Применим этот алгоритм к отношению г и проверим наличие в нем зависи­
мости
А»
В:
г
в

С

D

al

ы

cl

dl

а2

Ь2

cl

dl

al

ы

с2

d2

с2

d3

А

ы

аЗ
а2

Ь2

сЗ

d2

al

Ы

сЗ

d4

а4

ЬЗ

с4

d2

Отсортируем его кортежй по атрибуту А, получим:
А

в

С

D

al

ы

с1

ai

al

ы

с2

d2

al

ы

сЗ

d4

а2

Ь2

сЗ

d2

а2

Ь2

cl

dl

аЗ

Ы

с2

d3

а4

ЬЗ

с4

d2

Здесь таблица разбита на подмножества кортежей с равными значениями
атрибута А. Значения атрибута
Вв каждом подмнож
довательно, указанная / ’-зависимость удовлетворяется. Для того чтобы про­
верить наличие обратной зависимости В -> А требуется пересортировать это
отношение по атрибуту В. В результате такой пересортировки получим:
B

c

D

al

Ы

cl

dl

al

bl

c2

d2

al

Ы

c3

d4

a3

bl

c2

d3

a2

b2

cl

dl

a2

b2

c3

d2

a4

b3

c4

d2

A

Существует первое подмножество кортежей с равными значениями атрибута
но с разными значениями атрибута А, следовательно, эта / ’-зависимость
в рассматриваемом отношении не выполняется.
Необходимо сказать, что существует еще два экстремальных случая, а имен­
но 1 - » 0 и 0 - 4 К / ’-зависимость
X» 0 триви
отношением, / ’-зависимость 0 -»
Уудовлетворяется т
которых К-значения всех кортежей совпадают. В дальнейшем / ’-зависимости
такого вида рассматриваться не будут.

Аксиомы вывода

Для отношения r(R) в любой момент существует некоторое семейство
/ ’-зависимостей, которым это отношение удовлетворяет. Причем одно со­
стояние отношения может удовлетворять / ’-зависимости, а другое — нет.
Требуется выявить семейство / ’-зависимостей / , которому удовлетворяют
все допустимые состояния г. Чтобы найти F, необходимы семантические
знания об отношении г. Можно считать семейство / ’-зависимостей задан­
ным в схеме отношения R, и задача состоит в том, чтобы их выявить. В этом
случае любое отношение r(R) должно удовлетворять всем / ’-зависимостям из F
Не всегда ясно, что является первичным: множество допустимых состояний
отношения, которые определяет / ’-зависимости, или / ’-зависимости накла­
дывают ограничения на схему отношения.
Множество функциональных зависимостей, применимых к отношению
r(R), конечно, так как существует только конечное число подмножеств
множества R. Таким образом, можно найти все / ’-зависимости, которым
удовлетворяет г, перебрав все возможности с помощью описанного выше
алгоритма. Стоит обратить внимание на то, что этот подход, если его ис­
пользовать напрямую, требует большого количества времени. Общее время
поиска можно сократить в том случае, если известны некоторые / ’-зави­
симости из F. В подобной ситуации сокращение времени поиска происхо­
дит часто из-за того, что остальные /-зависимости можно получить, исполь­
зую аксиомы вывода.
Множество /-зависимостей /влечет за собой /-зависимость Л’-» Y (говорят
также, что Х -* Y является логическим следствием /, или что X -» Y следует из
/), если каждое отношение, удовлетворяющее всем зависимостям в /,
удовлетворяет также зависимости Х-> Y
Аксиома вывода — это правило, устанавливающее, что если отношение
удовлетворяет определенным /-зависимостям, то оно должно удовлетворять
и некоторым другим /-зависимостям.
Ниже рассмотрены шесть аксиом вывода для /-зависимостей. В их форму­
лировках используется обозначение г для отношения на R, и W, X, Y, Z для
подмножеств R.
□ / / . Рефлексивность. Отношение Р^ах=х(д) всегда имеет не более од­
ного кортежа, следовательно, X -» X всегда имеет место в г.
□ / 2 Пополнение. Эта аксиома имеет дело с расширением левой части
/-зависимости. Если г удовлетворяет Х-* Y, то Ру(ох=^г)) всегда имеет не бо­
лее одного кортежа для любого Х-значения х. Если Z является любым под­
множеством R, то axz=x£d и, следовательно, Py(csxz^r)) - Ryi^x^r)).
Таким образом, Py(oxz=xz(r)) имеет самое большее один кортеж, и г
должно удовлетворять /-зависимости XZ —> К

Пример. Пусть дано отношение

Это отношение удовлетворяет /'-зависимости
/■-зависимостям:
АВ
ABCD

В, А С В , AD-»

—»

и, следовательно,

В,АВС^> В, ABD

Вв силу аксиомы /2.

□ /3. Аддитивность (объединение). Эта аксиома позволяет объединить две
/ ’-зависимости с одинаковыми левыми частями. Если отношение г удов­
летворяет Х->
Yи
Z, то обе проекции / ’zfajr-wO)) и
име­
ют не более одного кортежа для любого ^-значения х. Если бы отноше­
ние Pyz(ox=x(r)) имело бы более одного кортежа, то по крайней мере
одно из отношений Pyipx^rfj)) или Pz(ax=x(r)) имело бы более одного
кортежа. Таким образом,
гудовлетворяет / ’-зависимос
Пример. Отношение /-, рассмотренное выше, удовлетворяет —» и
По аксиоме /3 отношение г должно также удовлетворять А —>ВС.

—» С.

□ /4. Проективность (декомпозиция). Эта аксиома в некоторой степени
обратна аксиоме аддитивности. Если г удовлетворяет
->
то
Pyz(c>x=x(r)) имеет не более одного кортежа для любого Т-значения х. Так
как Ру(РуАах=х(г))) = Ру(°х=Аг)), то Ру(ох=х(г)) также может иметь не
более одного кортежа. Следовательно, г удовлетворяет Л'-» К
Пример. Рассмотренное выше отношение удовлетворяет А —> ВС. Согласно
аксиоме /4, отношение г должно также удовлетворять А -» и —> С.
□ /5. Транзитивность. Эта и следующая аксиомы являются наиболее мощ­
ными из аксиом вывода. Пусть г удовлетворяет /"-зависимостям
и
К-» Z. Рассмотрим кортежи /1 и /2 в Если /10) = 2(х), то /10) = t2(y),
а из /10) = /2(у) следует /10) = /20). Таким образом, если /10) = /2 0 ),
то /10) = /20), т.е. г удовлетворяет

Пример. Пусть дано отношение г.
г
С

D

А

в

al

b1

c2

dl

а2

b2

cl

d2

аЗ

b1

c2

dl

а4

b1

c2

d3

В этом отношении
А—»
Ви
удовлетворяет
А -» С.
□
PS.Псевдотранзитивность. Пусть г удовлетворяет /"-зависимостям —» У
и JZ-»
W
,а /1 и
f l являются кортежами в г. По условию, если Л(х) = /2(х),
то t\(y) =
и аналогично, если
—
то /l(w) = (w). Из
/1(xz) =
(2 п
(xz) олучаем, что
tl(x)= (2(x);
дущему /10) = (2(y) и, кроме того, tl(yz) =
откуда следует, что
/l(w) = (2(w). Таким образом, г удовлетворяет XZ-> W.
Итак, запишем кратко все аксиомы.
□ /1. Рефлексивность: Х-> X.
□ F1. Пополнение: Х-> Увлечет за собой AZ-» У.
□ /3. Аддитивность: X —>Y h X —>Zвлечет за собой
□ F4. Проективность: X ->
□ /5. Транзитивность: X —»
□ /б. Псевдотранзитивность: X —> У и У?-»
Применение аксиом вывода
Используя аксиомы / 1 зависимостей.

Zлвечет за собой
Y
Уи У-» Z влечет за собой
влечет за собой XZ-*

S,можно получить правила вывода
P

Пример 1. Пусть /--отношение со схемой
а и У подмножества R. Аксио­
ма /1 утверждает, что г удовлетворяет У -» У. Применяя аксиому /2, полу­
чим, что г удовлетворяет ХУ—> У.
Некоторые аксиомы вывода могут быть получены из других аксиом. На­
пример, транзитивность /5 является частным случаем псевдотранзитивно­
сти PS при Z = 0 . Аксиома PS следует из /1, /2, /3, /5: если —> У и
YZ-* JV,то, как следствие FI, имеем Z -» Z. Согласно /2, имеем X Z —> У и
AZ->Z. Используя /3, получаем XZ-> YZ. Применяя /5, получаем ZZ-»

Необходимо отметить, что из аксиом Fl, F2 и F6 можно вывести все ос­
тальные аксиомы. Они составляют полное подмножество для F I—F6. Они
являются независимыми: ни одна из этих аксиом не может быть получена
из двух других. Эти три аксиомы еще называют аксиомами Армстронга.
Пусть F — множество всех / ’-зависимостей для отношения r(R). Замыкание
F, обозначаемое F +, — это наименьшее, содержащее F множество, такое,
что, при применении к нему аксиом Армстронга нельзя получить ни одной
/■-зависимости, не принадлежащей F. Так как Z4- должно быть конечно, то
можно вычислить его, начиная с / ’применением Fl, F2 и F6 и добавлени­
ем полученных / ’-зависимостей к F до тех пор, пока не перестанут получать­
ся новые / ’-зависимости. Замыкание / ’зависит от схемы R. Если R = АВ, то
всегда будет содержать В-* В.
Из множества F можно вывести / ’-зависимости X -» У, если X —> Y принад­
лежит F + Так как аксиомы вывода порождают только функциональные за­
висимости, то / ’влечет за собой Х -* Y, если Х —>Y выводится из F. Заметим,
что F + = ( / ’+)+

Полнота системы аксиом вывода

Система аксиом вывода F I—F6 является полной. Это означает, что каждая
/-зависимость, которая следует из множества F, может быть выведена путем
одно- или многократного применения к F этих аксиом. Действительно, вы­
ше было показано, что каждая аксиома выполняется в любом отношении.
Поэтому применение аксиом к / ’-зависимостям из множества F может дать
в результате только / ’-зависимости, которые следуют из F.

Первая нормальная форма

Отношение находится в первой нормальной форме, если все его атрибуты имеют
простые (атомарные) значения. Другими словами, значения в домене каждого
атрибута отношения не являются ни списками, ни множествами простых или
сложных значений. Одним словом, в отношении не должно быть повторяю­
щихся групп. В противном случае отношение считается ненормализованным
и ему соответствует многоуровневая таблица (иерархия) в отличие от одно­
родной табличной структуры нормализованного отношения.
Определить понятия атомарности трудно. Значение, атомарное в одном
приложении, может быть неатомарным в другом. Можно руководствоваться
общим принципом, что значение не атомарно, если в приложении оно ис­
пользуется по частям. Рассмотрим пример отношения, представленного
в табл. 6.4.

Таблица 6.4. Отношение РОЖДЕНИЕ
Имя

Дата рождения

Аня

5 марта 1976

Саша

25 января 1977

Ольга

1 ноября 1977

Федор

14 сентября 1976

Если значение атрибута Дата рождения предполагается использовать цели­
ком, то в этом случае данное отношение находится в 1НФ. Если бы потре­
бовалось выделить и отдельно использовать, скажем, год, число, месяц, то
это отношение не находилось бы в 1НФ, так как требуемые данные являют­
ся только частями значения атрибута Дата рождения. Чтобы перевести такое
отношение в 1НФ, атрибут Дата рождения должен быть разбит на части так,
как показано в табл. 6.5.
Таблица 6.5. Отношение РОЖДЕНИЕ
Имя
Аня

День рождения
5

Месяц рождения

Год рождения

Март

1976

Саша

25

Январь

1977

Ольга

1

Ноябрь

1977

Сентябрь

1976

Федор

14

Таким образом, в отношении данные можно представлять с той степенью
детализации, которая требуется в информационной системе. Предположим,
что нужно добавить атрибут Знак, являющийся знаком зодиака человека,
в первое отношение РОЖДЕНИЕ (табл. 6.4). Известно, что знак зодиака
определяется по месяцу и дню рождения человека, а от года рождения не
зависит. Используя табл. 6.4, в этой ситуации можно только установить за­
висимость Дата рождения —»Знак, которая позволит двум лицам, родившим­
ся в один и тот же день, но в разные годы, иметь различные знаки, что не
соответствует действительности.
Во втором отношении РОЖДЕНИЕ (табл. 6.5) таких трудностей не возни­
кает, так как можно записать зависимость:
(День рождения, Месяц рождения) -> Знак.
Или, например, табл. 6.6 является ненормализованной, и она не находится
в 1НФ потому, что включает величины, являющиеся совокупностью ато­
марных значений. Чтобы получить отношение РОД, находящееся в 1НФ,
необходимо его представить так, как это сделано в табл. 6.7.

Таблица 6.6. Ненормализованная таблица РОД
Имя

Пол

(Саша, Федор)

Мужской

Ольга

Женский
Таблица 6.7. Отношение РОД
Имя

Пол

Саша

Мужской

Федор

Мужской

Ольга

Женский

Если отношение не находится в 1НФ, то и с обновлением данных могут
быть трудности. Допустим, выяснилось, что женское имя Саша в табл. 6.6
было ошибочно помешено в кортеж, где определен мужской пол. Измене­
ние данных в этом случае связано с тем, что имя Саша нужно убрать из од­
ного множества и поместить в другое. А во втором отношении РОД
(табл. 6.7) в подобной ситуации в кортеже необходимо только изменить
Мужской пол на Женский.
Таким образом, если отношение является ненормализованным, его нужно
привести к первой нормальной форме. Один из распространенных подходов
приведения к 1НФ заключается в том, что в процессе преобразования, ко­
торое называется выравниванием таблицы, повторяющиеся группы устра­
няются путем организации дополнительных кортежей по одному на каждый
элемент повторяющейся группы. При этом в каждом кортеже необходимо
продублировать неповторяющиеся данные. Полученная подобным путем
таблица содержит только атомарные значения, поэтому ее можно назвать
отношением. Однако этим преобразованием в отношение вносится некото­
рая избыточность данных, которая, как было отмечено выше, является ис­
точником ряда аномалий и в дальнейшем должна быть устранена.
Поясним сказанное на примере. Представим себе отношение, в котором
должна присутствовать информация о дисциплинах кафедры и о лекторах,
которые могут участвовать в учебном процессе по их ведению. Допустим,
что один и тот же лектор может участвовать в ведении нескольких дисцип­
лин. Указанные сведения можно представить в нормализованном отноше­
нии так, как показано в табл. 6.8. Поскольку лекции по дисциплине
Информатика могут читать два преподавателя, то для каждого из них при­
шлось организовать кортеж с относящимися к ним сведениями, и в каждом
кортеже повторить описание дисциплины Информатика. Аналогично при­
шлось поступить и с дисциплиной ОС (операционные системы), с той лишь
разницей, что на чтение лекций по этой дисциплине претендуют сразу три
преподавателя, а следовательно, пришлось создать три кортежа (табл. 6.8).

Таблица 6.8. Отношение ПРЕПОДАВАНИЕ ДИСЦИПЛИН
Индекс.
дисц

Назв.предм

Кол_во_
час

Код.
лек

Ф ИО .лек

Должность

ЕНФ02

Информатика

54

001

Иванов И.И.

Доцент

ЕНФ02

Информатика

54

002

Петров Т.Т.

Старший пре­
подаватель

ОПДФ08

ОС

102

003

Сур М.И.

Доцент

ОПДФ08

ОС

102

001

Иванов И.И.

Доцент

ОПДФ08

ОС

102

002

Петров Т.Т.

Старший пре­
подаватель

СДОЗ

ООП

54

001

Иванов И.И.

Доцент

СДОЗ

ООП

54

002

Петров Т.Т.

Старший пре­
подаватель

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

Вторая и третья нормальные формы возникли в результате стремления избе­
жать аномалий обновления данных при работе с БД и избавиться от инфор­
мационной избыточности в отношениях. Аномалии обновления являются не­
желательным побочным эффектом, обусловленным изменением отношения.
Вторая нормальная форма применяется к отношениям с составными клю­
чами, т. е. к таким отношениям, первичный ключ которых состоит из двух
или более атрибутов. Отношение, у которого первичный ключ включает
только один атрибут, всегда находится во 2НФ.
Описание процесса приведения отношения ко 2НФ требует использования
ряда не встречаемых до сих пор понятий. Рассмотрим их.
Определения

1. Атрибут называется посторонним для функциональной зависимости X —>
У, если он может быть удален из правой или левой части функциональ­
ной зависимости без изменений транзитивного замыкания F+ множества
F.
2. Функциональная зависимость X -> Y называется редуцированной слева
(справа), если X(Y) не содержит атрибута Z, постороннего для функцио­

нальной зависимости Х - * Y. Зависимость, редуцированная слева и спра­
ва, называется просто редуцированной. Если функциональная зависи­
мость Х —> У редуцирована слева, то Y является полностью зависящим от
X. В противном случае Y частично зависит от X. Удаление посторонних
атрибутов в начале производят слева, а потом справа. Если после этого
исключить зависимости вида X —> 0 , то посторонних атрибутов вообще
больше не останется.
3. Для данной схемы отношения R атрибут А в R и множество функцио­
нальных зависимостей F на R атрибута А называется первичным в R от­
носительно F, если А содержится в каком-нибудь ключе схемы R. В про­
тивном случае А называется непервичным в R.
Итак, схема отношения R находится во 2НФ относительно F, если она на­
ходится в 1НФ, и каждый непервичный атрибут функционально полно за­
висит от первичного ключа.
Наоборот, если имеются неключевые атрибуты, зависящие от части первич­
ного ключа, то отношение не находится во 2НФ. Такое отношение может
страдать от аномалий обновления.
Пример 1

Пусть имеется отношение:
ПОСТАВКИ (Ном поставщика. Товар. Цена).
Предположим, что поставщик может поставлять различные товары, а один и
тот же товар могут поставлять разные поставщики. Ключ отношения опре­
делен как (Ном поставщика. Товар). При условии, что цена любого товара
зафиксирована, семантика отношения включает следующие зависимости:
(Ном поставщика. Товар —»Цена) (по определению ключа);
(Товар -» Цена).
Наличие в данном случае неполной функциональной зависимости атрибута
Цена от ключа приводит к ряду аномалий.
Аномалия включения. Если у поставщика появляется новый товар, информа­
ция о товаре и его цене не сможет храниться в базе данных до тех пор, пока
поставщик не начнет поставлять его.
Аномалия удаления. Если поставки некоторого товара прекращаются, из базы
данных придется удалить сведения о товаре и его цене, даже если он имеет­
ся в наличии у поставщиков.
Аномалия модификации. При изменении цены товара необходим полный
просмотр отношения с целью найти все поставки товара, чтобы изменения
цены было отражено для всех поставщиков. Таким образом, изменения зна­
чений атрибута одного объекта влечет необходимость изменений в несколь­

ких кортежах отношения: в противном случае база данных окажется несо­
гласованной.
Причиной этих аномалий является неполная функциональная зависимость
атрибута Цена от ключа, что обусловлено объединением в отношении
ПОСТАВКИ двух семантических фактов. Разложение исходного отношения
на два отношения:
ПОСТАВКИ (Ном Поставщика. Товар):
ЦЕНА_ТОВАР (Товар. Цена)
устраняет указанную выше неполную функциональную зависимость.
Цену товара конкретной поставки можно определить путем соединения двух
отношений по атрибуту Товар. В полученной схеме реляционной базы дан­
ных, состоящей из двух отношений, изменение цены товара вызовет моди­
фикацию одного лишь кортежа второго отношения, потому что в данных
отношениях аномалия обновления уже отсутствует. Чтобы изменить цену
товара, достаточно изменить его в одном кортеже. Изменения в первое от­
ношение вносить не придется, поскольку в нем цена товара отсутствует. Та­
кое разбиение исходного отношения позволило попутно избавиться также и
от некоторой избыточности данных. Произошло все это потому, что схема
отношения была приведена ко второй нормальной форме.
Пример 2

Пусть есть отношение со схемой:
(Ном врача, Цом паи. Дата. ФИО_ паи, Адрес_пац, ФИО_врача, Лечение,
Лекарство, Побочный_эффект).
В данном отношении определен первичный составной ключ:
(Ном_врача, Ном_пац, Дата).
Исследование этого отношения на принадлежность ко 2НФ приводит
к следующим результатам.
□ Непервичный атрибут ФИО_врача не зависит функционально полно от
всего первичного ключа, а зависит только от его части Ном_врача.
□ Непервичные атрибуты ФИО_пац и Адрес_пац не зависят функционально
полно от всего первичного ключа, а зависят только от его части Ном_пац.
Результаты исследования показывают, что данное отношение не находится
во 2НФ, а следовательно может быть подвержено всем негативным послед­
ствиям такого состояния. Для приведения исходного отношения ко 2НФ
необходимо его разбить на три отношения, находящихся во 2НФ, поскольку
каждый атрибут каждого отношения, не входящий в свой первичный ключ,
функционально полно зависит от первичного ключа отношения:
ВРАЧ (Ном врача, ФИО_врача);
ПАЦИЕНТ (Ном паи. ФИО_ пац, Адрес_пац );
ЛЕЧЕНИЕ 0 ïom врача. Ном паи. Дата. Лечение, Лекарство, Побоч_эффект).

При анализе отношений этого примера, если рассматривать информацион­
ную ценность используемых атрибутов, может возникнуть вопрос об избы­
точности атрибутов Ном_врача, Ном_пац. Действительно, в качестве ключей
в отношениях могут использоваться атрибуты ФИО_врача и ФИО_пац
(в пределах одной больницы навряд ли возможно полное их дублирование),
но на практике из-за их большого объема (длины) для связывания отноше­
ний выгоднее ввести численные поля меньшей длины. Это приводит к не­
которому уменьшению объема данных и к большему быстродействию при
связывании, индексировании и выполнении других операций над отноше­
ниями.
Схема всей БД имеет 2НФ относительно F, если каждая ее схема отношения
находится относительно F во 2НФ.
Пример 3

Рассмотрим отношение КОНСУЛЬТАЦИИ_ДИПЛОМНИКОВ со схемой:
(Таб Ном преп. Ном зам кн. Дата. ФИО_преп, Должность, ФИО_студ,
Тема.диплома, Время, Аудитория, Вместимость).
Это отношение содержит информацию о том, какой преподаватель консуль­
тирует определенного дипломника, а также дату, время консультации и ауди­
торию с ее вместимостью, где она должна проводиться. Обозначим основные
зависимости этого отношения.
□ Первичный ключ данного отношения является составным и по опреде­
лению однозначно идентифицирует каждый кортеж отношения:
□ (Таб Ном преп. Ном зач кн. Дата) -» (ФИО_ преп, Должность,
ФИО.студ, Тема.диплома, Время, Аудитория, Вместимость).
□ Описательные атрибуты преподавателя ФИО_ преп, Должность зависят
только от части первичного ключа. Данную ситуацию определяет зависи­
мость:
□ Таб Ном преп —>(ФИО_ преп, Должность).
□ Описательные атрибуты студента ФИО_студ, Тема.диплома также зави­
сят только от части первичного ключа и не зависят от остальных атрибу­
тов ключа, то есть имеется зависимость вида:
□ Ном зач кн —>(ФИО студ. Темадиплома).
Отсутствие полной функциональной зависимости каждого непервичного
атрибута отношения от первичного ключа, как и в других рассмотренных
здесь примерах, является источником аномалий обновления и вносит свою
долю избыточности в базу данных. Устранение данных отрицательных явле­
ний осуществляется путем декомпозиции исходного отношения на три со
следующими схемами:
ПРЕПОДАВАТЕЛЬ (Таб Ном преп. ФИО_ преп, Должность);

СТУДЕНТ (Ном зач кн. ФИО_студ, Тема„диплома);
КОНСУЛЬТАЦИИ (Таб Ном преп. Ном зач кн. Дата. Время, Аудитория,
Вместимость).
Полученная схема базы данных содержит три отношения: первое содержит
сведения обо всех преподавателях, второе содержит сведения обо всех ди­
пломниках, а последнее отношение КОНСУЛЬТАЦИИ связывает воедино
базу данных, так как в него включены первичные атрибуты первых двух от­
ношений. Поскольку в базе данных теперь отсутствуют повторяющиеся
данные, то отсутствует и возможность привести ее в несогласованное со­
стояние.
Третья нормальная форма

Рассмотрим транзитивную зависимость следующего типа:
если А —у В, В-/ -+А (В не является ключом), В - у С,
то А - у С.
В этом случае считается, что С транзитивно зависит от А.
Проанализируем БД примера 2 предыдущего раздела, а в ней последнее от­
ношение ЛЕЧЕНИЕ. В указанном отношении существуют зависимости:
(Ном_ врача, Ном_пац, Дата) —у Лекарство;
Лекарство -» Побоч_эффект.
Последняя зависимость определена между описательными атрибутами дан­
ного отношения: атрибут Побоч_эффект зависит от атрибута Лекарство,
который в свою очередь зависит от первичного ключа, то есть атрибут
Побоч_эффект транзитивно зависит от первичного ключа отношения. Нали­
чие данной зависимости в одном отношении приводит к ряду негативных
последствий:
□ нельзя включить в БД сведения о лекарстве, не назначенном ни одному
больному;
□ при изменении сведений о побочном эффекте лекарства требуется про­
смотреть всю БД для корректного изменения данных.
Транзитивная зависимость вызвана наличием в отношении двух семантиче­
ских различных типов. Преобразование отношения в ЗНФ устраняет рас­
смотренные аномалии.
Схема отношения находится в третьей нормальной форме относительно
множества функциональных зависимостей F, если она находится в 1НФ и
ни один из непервичных атрибутов в Л не является транзитивно зависимым
от ключа для R.
Схема всей БД находится в ЗНФ относительно F, если каждая схема отно­
шения находится в ЗНФ относительно F.

Нормализованная БД рассматриваемого примера имеет вид:
ВРАЧ (Ном врача. ФИО_ врача);
ПАЦИЕНТ (Ном паи. ФИО_пац, Адрес_пац);
ЛЕЧЕНИЕ (Ном врача. Ном паи. Дата. Лечение, Лекарство);
ЛЕКАРСТВО (Лекарство. Побоч_эффект).
Рассмотрим схему базы данных примера 3 предыдущего раздела.
ПРЕПОДАВАТЕЛЬ (Таб Ном преп. ФИО_ прел, Должность);
СТУДЕНТ (Ном зач кн. ФИО_студ, Тема_диплома);
КОНСУЛЬТАЦИИ (Таб Ном преп. Ном зач кн. Дата. Время, Аудитория,
Вместимость).
Последнее отношение содержит транзитивную зависимость:
(Таб Ном преп. Ном зач кн. Дата} —>Аудитория -> Вместимость.
Следовательно это отношение не находится в ЗНФ со всеми вытекающими
из этого последствиями, и прежде всего следующими:
□ если аудитория исключается из расписания консультаций, то о ней во­
обще теряются сведения;
□ если аудитория перестроена и в результате изменилась ее вместимость, то
придется просмотреть все кортежи и провести модификацию значений
атрибута.
Для устранения транзитивной зависимости необходимо провести декомпо­
зицию последнего отношения, удалив из него транзитивно-зависимый атри­
бут и поместив его в новое отношение вместе с копией того атрибута, от
которого он зависит.
Таким образом, база данных этого примера, лишенная транзитивных зави­
симостей, в ЗНФ будет выглядеть так:
ПРЕПОДАВАТЕЛЬ (Таб Ном преп. ФИО_ преп, Должность);
СТУДЕНТ (Ном зач кн. ФИО_студ, Тема^диплома);
КОНСУЛЬТАЦИИ (Таб Ном преп. Ном зач кн. Дата. Время, Аудитория);
АУДИТОРИЯ (Аудитория, Вместимость).
При проектировании структуры реляционной базы данных считается кор­
ректной следующая установка, что любая БД должна находиться как мини­
мум в ЗНФ. На практике третья нормальная форма схем отношений доста­
точна в большинстве случаев, и приведением к третьей нормальной форме
процесс проектирования реляционной базы данных обычно заканчивается.
Однако иногда полезно продолжить процесс нормализации.
Справедливо и следующее замечание.
Любая схема отношения, находящаяся в ЗНФ относительно F, находится во
2НФ относительно F.

Действительно, частичная зависимость означает транзитивную зависимость.
Для доказательства этого положения предположим, что непервичный атри­
бут А в R является частично зависимым от ключа ç
Тогда существует
собственное подмножество К' множества К, такое что К' —> А. Здесь
—>
К, так как тогда К' должно было быть ключом для
а ключи не могут со­
держать в себе ключи в качестве собственного подмножества. В этом случае
также имеем
А еК
,так как К является ключом, а атрибут А — неперв
ный. Следовательно,
К->
К',К'^
,К К'^>A, A i К,
то есть А транзитивно зависит от К.
Нормализация на основе декомпозиции

Итак, схему отношения БД, не находящуюся в ЗНФ, необходимо к ней при­
вести. Приведение осуществляется через разбиение схемы отношения на
пару схем отношений R\ и /?2 так, чтобы любое отношение r(R), удовлетво­
ряющее F, разлагалось на R\ и
Rj.Если какое-то от
окажется в ЗНФ, то процесс декомпозиции придется повторить. Этот про­
цесс продолжается до тех пор, пока все полученные отношения не окажутся
в ЗНФ относительно F.
Процесс декомпозиции схемы не бесконечен. Каждый раз обе получившие­
ся в результате декомпозиции схемы отношений становятся меньше исход­
ной, а в схеме отношения, содержащей только два атрибута, не может быть
никакой транзитивной зависимости.
Недостатки д ан н о й но рм ализац ии

Необходимо обратить внимание на то, что в этом подразделе и ранее для.
пояснения материала приходится упоминать некоторые операции реляци­
онной алгебры. Если читателю смысл этих операций покажется непонят­
ным, то необходимо обратиться к главе 8, где все операции такого рода рас­
сматриваются достаточно подробно.
До сих пор при рассмотрении конкретных ситуаций отношения разделялись
на проекции без проверки сохранности данных. Однако можно привести ни
один случай, когда декомпозиция отношения дает набор отношений, не эк­
вивалентный исходному отношению. Например, из исходного отношения:
R

А

в

с

щ

ь,

Cl

ai

Ь2

с2

а2

Ьз

Cl

а2

ь2

с2

в соответствии с некоторой декомпозицией можно получить две проекции,
которые будут выглядеть следующим образом:
Рас (Я)__________________

А

Р

(Я)___________________

С

В

С
Ci
с2
с!

al

с!

ь,

al

с2

Ь2

а2

cl

Ьз

а2'

с2

Соединение же этих проекций даст следующее отношение:
Рас (R)
Р Ьс (Я)
А

в

с

ai

bi

Cl

щ

к

Si

ai

ь2

С2

02

h

Су

а2

Ьз

Cl

а2

ь2

С2

Данная декомпозиция не является полной, так как при соединении ее про­
екций появляются кортежи, отсутствовавшие в исходном отношении
(в примере они выделены курсивом и подчеркнуты). В рассматриваемом
примере ни зависимость С -> А, ни зависимость -» не являются коррект­
ными, поэтому естественное соединение проекций порождает два новых
кортежа.
Полная декомпозиция отношения есть набор его проекций, соединение кото­
рых эквивалентно исходному отношению. Существует теорема Хита, кото­
рая устанавливает связь между функциональными зависимостями и полной
декомпозицией.
Пусть имеется отношение r(S, К), где S — атрибуты, К — ключи, и выделе­
ны три подмножества атрибутов А, 3 и С такие, что
А
п В= 0 ,
С пВ=0,
А и
В uС =
S.
Если существует функциональная зависимость —» С, то Р а с ( Я ) и Р вс ( Я )
образуют полную декомпозицию отношения г.

При нормализации схемы отношения посредством декомпозиции возникает
еще ряд проблем, которые кратко можно обозначить следующим образом:
□ DI — временная сложность процесса;
□ Ш — число порожденных процессом схем отношения может оказаться
большим, чем в действительности необходимо для ЗНФ;
□ D3 — при декомпозиции могут возникнуть частичные зависимости, кото­
рые также могут породить избыток схем;
□ D4 — для построенной схемы БД заданное множество / ’-зависимостей
может оказаться ненавязанным;
О D5 — с помощью декомпозиции можно породить схемы со скрытыми
транзитивными зависимостями.
Контроль всех этих проблем требует значительного внимания.
Нормализация посредством синтеза

Нормализация посредствам синтеза это еще один метод получения ЗНФ,
который, кстати, не порождает упомянутые проблемы декомпозиции. Ос­
новная задача сводится к нахождению схемы БД в ЗНФ, представляющей
схему отношения, не находящуюся в ЗНФ. Предположим, что на входе за­
дана схема отношения R и множество / ’-зависимостей F над R. С помощью
множества / ’-зависимостей F над R требуется создать схему базы данных
R = {Л/, ..., Rp} над R, удовлетворяющую следующим четырем требованиям:
□ С1 — множество F полностью характеризуется с помощью Л;
□ С2 — каждая схема отношения R, из R находится в ЗНФ;
□ СЗ — не существует схемы БД с меньшим числом атрибутов, чем R,
удовлетворяющей свойствам С1 и С2;
□ С4 — для любого отношения r(R), удовлетворяющего F,
G Г = PRl(r) =® Рю,{г) =® ... =® Кр{г).

Схема БД, удовлетворяющая первым трем требованиям, называется полной
схемой БД для F.
Пояснение. Свойство С1 обеспечивает навязанность / в R, которая может
быть проверена без вычисления F + Это же свойство гарантирует, что един­
ственными /-зависимостями, которые должны быть навязаны для выполне­
ния / в R, являются те, которые выводятся из выделенных ключей. Свойст­
во СЗ — защищает от избыточности. Свойство С4 — позволяет правильно
представить отношение со схемой R своими проекциями. Свойство С2 не
требует пояснений, так как его ценность уже обсуждалась.
Построение алгоритма сводится к построению редуцированного мини­
мального кольцевого покрытия, порождающего для F полную схему БД.

Поскольку алгоритм строит схему БД непосредственно из / ’-зависимостей F,
он называется алгоритмом синтеза.
Построенный таким образом алгоритм устраняет проблему временной
сложности, а также и прочие проблемы декомпозиции.
Алгоритм синтеза
Вход: множество /'-зависимости F над U.
Выход: полная схема БД для F.
Синтез (/).
1. Найти для F редуцированное минимальное кольцевое покрытие G.
2. Для каждой GF-зависимости (xl, х2, ..., хк) -» у из G построить схему
отношения R = xl, х2, ..., хк у с выделенными ключами К = {xl, х2,
- , х£}.
3. Вернуться к множеству схем п. 2.
Показано, что алгоритм синтеза порождает схемы отношений, которые на­
ходятся в несколько более сильной форме, чем ЗНФ в том смысле, что ни
один из выделенных ключей не зависит транзитивно ни от одного ключа.
Это состояние отношения называется: нормальная форма Бойса — Кодда
(НФБК).
Нормальная форма Бойса — Кодда

Следует отметить, что определение для ЗНФ было дано Коддом для ситуа­
ций с упрощающим картину допущением того, что отношение имеет только
один потенциальный ключ, который, естественно, и является первичным
ключом. Естественно, что не все отношения могут быть уложены в данные
довольно жесткие рамки. Более обобщающими являются случаи, когда в на­
личии имеются следующие условия:
1. Отношение имеет два (или более) потенциальных ключа.
2. Два потенциальных ключа являются составными.
3. Два потенциальных ключа перекрываются, т. е. имеют, по крайней мере
один общий атрибут.
Следует подчеркнуть, что комбинация указанных трех условий не часто
встречается на практике, и для отношения, в котором они не наблюдаются,
ЗНФ и НФБК эквивалентны.
Для объяснения понятия НФБК потребуется использовать понятие детер­
минанта и тривиальной функциональной зависимости, т. е. такой зависимо­
сти, в которой левая часть является супермножеством правой части. Дадим
одно из возможных определение НФБК, которое, на взгляд автора, выделя­
ется своей простотой.

Схема отношения R находится в НФБК относительно множества F-зависимостей тогда и только тогда, когда детерминанты являются потенциальными
ключами.
Допустим, что при проектировании базы данных ПОСТАВКИ_ТОВАРОВ
рассматривается отношение:
ПОСТАВКА (Индекс поставщ, Имяпоставщ, Индекс_товара, Колич товара).
Допустим также, что значения атрибута Имя_поставщ уникальны и могут
быть использованы наряду с атрибутом Индекс_поставщ для идентификации
поставщика. В такой ситуации можно выделить два составных потенциаль­
ных ключа:
(Ивдекс_поставщ, Индекс_товара);
(Имя_поставщ, Индекс_товара).
В рассматриваемом отношении есть два атрибута Индекс_поставщ и
Имя_поставщ, которые идентифицируют один и тот же объект, а, значит,
они определяют друг друга. В таком случае отношение содержит два детер­
минанта, но эти детерминанты не являются потенциальными ключами от­
ношения. Сложившаяся картина противоречит данному выше определению
НФБК, и следовательно, данное отношение не находится в НФБК со всеми
вытекающими из этой ситуации негативными последствиями: избыточно­
стью данных и аномалиями обновления. Поскольку поставщик осуществля­
ет неоднократные поставки, то изменение его имени приведет к необходи­
мости во избежание несогласованности базы данных отыскать все кортежи,
к нему относящиеся, и внести в них изменения.
Для схемы отношения, не находящейся в НФБК, можно провести декомпо­
зицию в схему БД в НФБК. Если для схемы R имеет место Y -» A, YçR и
А е R — Y, и если Y не является ключом R, то можно разложить R на
Ri = R —А и Ri = (Y, А). Выделенные ключи для /?|И Ri находятся так же,
как и в случае схем базы данных в ЗНФ. Иными словами, из исходного от­
ношения убирается и переносится в новое отношение зависимая часть вме­
сте с копией детерминанта.
Для рассматриваемого примера решение проблемы можно осуществить, раз­
бив исходное отношение на два. Причем поскольку два детерминанта
Индекс_поставщ и Имя_поставщ определяют друг друга, то возможны два
равносильных варианта декомпозиции, приводящей к НФБК.
Первый вариант получается, если учитывается зависимость
Индекс_поставщ —> Имя_поставщ,
в результате чего имеем следующих два отношения:
ПОСТАВКА (Индекс_поставщ, Индекс_товара, Колич_товара);
ПОСТАВЩИК (Индекс_поставщ, Имя_поставщ).

Второй вариант исходит из зависимости
Имя_поставщ —>Индекс_поставщ,
в результате чего получаем альтернативную группу отношений:
ПОСТАВКА (Имя_поставщ, Индекс_товара, Колич_товара);
ПОСТАВЩИК (Индекс_поставщ, Имя_поставщ).
В обоих вариантах в отношении ПОСТАВКА остался один составной потен­
циальный ключ, который может быть использован в качестве первичного
ключа. В обоих вариантах исключены возможности возникновения анома­
лий обновления, и обновление их может проходить независимо друг от
друга. Если добавляется некоторый поставщик, он будет помещен в отно­
шение ПОСТАВЩИК и информация о нем будет храниться там даже в том
случае, если он пока не осуществляет поставки. Отношение же ПОСТАВКА
будет содержать сведения о реальных выполненных поставках товаров.
Несложно проверить и тот факт, что данная декомпозиция осуществляется
без потерь и с сохранением функциональных зависимостей.
Следует отметить, что хотя данное выше определение предполагает реализа­
цию довольно простого алгоритма приведения отношения к НФБК, сам ре­
зультат этого приведения таит в себе некоторые подводные камни, что тре­
бует повышенной осторожности на этом этапе нормализации отношений.
Так, при заданном множестве F-зависимостей над R, можно найти схему
базы данных в ЗНФ, полностью характеризующую F. Для НФБК это не
всегда верно, поскольку в результате декомпозиции некоторые функцио­
нальные зависимости могут быть потеряны.
Рассмотрим отношение:
Ф
П
О
ГАРАНТ_ОБСЛУЖИВАНИЕ (Фирма, Поставщик, Отделение)
Содержание такого отношения мотивируется следующими соображениями.
Если некоторая организация (П) поставила фирме (Ф) оборудование, то га­
рантийное обслуживание этого оборудования должно осуществляться неко­
торым отделением (О) поставщика (П). Следовательно, имеется в наличии
две зависимости:
(Ф,П) -» О;
0 -> П .
Множество (Ф, О) является ключом схемы отношения, а (П) — частично,
следовательно, транзитивно зависит от (Ф, О). Несмотря на то, что (П) яв­
ляется первичным атрибутом, его желательно удалить из схемы, поскольку
существует дублирование пар (П-О).
Схема отношения:
ГАРАНТ_ОБСЛУЖИВАНИЕ (Фирма , Поставщик, Отделение)

не находится в НФБК. Используя /-зависимость О —» П, разложим исход­
ное отношение на два:
/?1 (Фирма, Отделение) с выделенным ключом:
К\ {Фирма, Отделение};
Kl (Поставщик, Отделение) с выделенным ключом:
Kl {Отделение}.
Полученная схема базы данных удовлетворяет одной функциональной зави­
симости, вторая же зависимость оказалась этой схеме не навязанной. По­
добная ситуация характеризуется тем, что оба эти отношения не могут быть
обновлены независимо друг от друга, а, следовательно, налицо аномалия
обновления. Изучение данного примера показывает, что для него вообще не
существует схемы БД в НФБК, полностью характеризующей заданное мно­
жество / ’-зависимостей.
Схема БД находится в НФБК относительно множества / ’-зависимостей F,
если каждая схема отношения находится в НФБК относительно F.
В заключение стоит обратить внимание на то, что, как уже упоминалось,
определение НФБК является более строгим, чем определение ЗНФ, а также
на то, что оно концептуально проще, поскольку в нем нет ссылок на 1НФ,
2НФ и не используется понятие транзитивной зависимости.
Четвертая нормальная форма

Итак, НФБК позволяет устранить любые аномалии обновления, вызванные
функциональными зависимостями. Собственно, Кодд и стремился к устра­
нению аномалий именно такого рода, разработав процесс нормализации
вначале до ЗНФ, а затем, вместе с Бойсом, предложил и НФБК.
Однако в ходе дальнейших исследований был выявлен еще один тип зави­
симостей — многозначная зависимость. Возможность существования в от­
ношении многозначных зависимостей возникает в процессе приведения ис­
ходных таблиц к 1НФ. Вспомним, что первая нормальная форма запрещает
отношениям иметь неатомарные, многозначные атрибуты. Однако сущест­
вует множество ситуаций моделирования, требующих многозначных атрибу­
тов. Например, в университете преподаватель факультета отвечает за препо­
давание нескольких предметов, или отдел некоторой фирмы выполняет ряд
проектов. То есть многозначность присутствует в тех отношениях, где моде­
лируется связи типа 1 М. Если в отношении моделируется одна связь та­
кого рода, то такая многозначность называется тривиальной.
Совсем другая, картина создается, если в отношении представлены две связи
типа 1 М. Рассмотрим следующую схему отношения: НИР (Номер_НИР,
Сотр, Задан_НИР).
Отношение НИР содержит номера тем научно-исследовательских работ,
для каждой темы — список сотрудников, которые могут выполнять работы

по теме, и список заданий темы. Сотрудники могут участвовать в несколь­
ких темах, и разные темы могут включать одинаковые задания. В такой
ситуации единственно возможным ключом отношения является составной
атрибут:
(Номер НИР. Сотр. Задан НИР).
Каждый кортеж отношения связывает некоторую тему с сотрудником, уча­
ствующим в этой теме, и заданием, которое сотрудник выполняет в рамках
данной темы (мы предполагаем, что любой сотрудник, участвующий в НИР,
может выполнять все задания, предусмотренные этой темой).
Если между сотрудниками и заданиями НИР нет никакой прямой связи
(хотя это и не совсем реалистическое утверждение), то необходимо создать
кортеж для каждой комбинации сотрудника и задания — только это позво­
лит иметь гарантии того, что отношение находится в непротиворечивом со­
стоянии. Иными словами, связи между независимыми атрибутами можно
исключить, потребовав, чтобы каждое значение атрибута сочеталось с каж­
дым значением другого атрибута как минимум в одной строке.
Полученное в результате отношение характеризуется значительной избы­
точностью и приводит к возникновению аномалий обновления. Так, напри­
мер, если некоторый сотрудник присоединяется к данной теме, необходимо
вставить в отношение НИР столько кортежей, сколько заданий в нем пре­
дусмотрено. Такой подход имеет определенные недостатки, поскольку те
кортежи, в которых есть пустые значения, нарушают категорную целост­
ность, так как все атрибуты вместе составляют ключ отношения. А следова­
тельно, в подобных ситуациях требуется лишнее место либо из-за наличия
пустых значений, либо из-за необходимости вводить избыточные данные.
Таким образом, не вызывает сомнения тот факт, что данное отношение
должно быть нормализовано, но как? Отношение является полностью клю­
чевым, а следовательно, находится в НФБК. Поэтому все рассмотренные до
сих пор приемы нормализации, опирающиеся на функциональные зависи­
мости, оказываются неприменимыми, поскольку этих зависимостей в отно­
шении вовсе нет.
В 1971 году Фейгин предложил строго теоретически обоснованный выход из
этой ситуации с помощью понятия многозначной зависимости.
Условие, обеспечивающее независимость атрибутов путем обязательного
повторения значений, называется многозначной зависимостью (М3). Опреде­
лим формально условие существования многозначной зависимости: много­
значная зависимость имеет место в том отношении, в котором содержится
две независимые связи типа 1 : М. И все проблемы данной ситуации вызваны
именно этой независимостью связей.
Многозначные зависимости являются такими же ограничительными усло­
виями, как и функциональные зависимости. Очевидно, что поскольку они

требуют огромного числа повторений значений данных, важный этап про­
цесса нормализации состоит в избавлении от многозначных зависимостей.
В отношении R(A, В, Q существует многозначная зависимость А - » В в том
и только в том случае, если множество значений В, соответствующее паре
значений А и С, зависит только от А и не зависит от С.
Многозначные зависимости можно считать обобщением функциональных
зависимостей в том смысле, что каждая функциональная зависимость явля­
ется многозначной, где множество зависимых значений является одноэле­
ментным множеством. Однако обратное утверждение неверно, поскольку
существуют многозначные зависимости, которые не являются функцио­
нальными. Такие многозначные зависимости и являются предметом рас­
смотрения в этом подразделе.
В отношении НИР существуют следующие две многозначные зависимости:
Номер_НИР -> > Сотр;
Номер_НИР -> -> Задан_НЙР.
Легко показать, что в общем случае в отношении R (А, В, Q существует
многозначная зависимость А - » В в том и только в том случае, когда суще­
ствует многозначная зависимость А - » С. Еще раз подчеркнем тот факт,
что атрибуты В и С между собой не связаны. Таким образом, многозначные
зависимости всегда образуют связанные пары и поэтому их обычно пред­
ставляют вместе в символьном виде так: А - » В \ С.
Дальнейшая нормализация таких отношений должна проходить по пути
разделения двух независимых повторяющихся групп. Это разделение осно­
вывается на следующей теореме Фейгина.
Отношение R (А, В, Q можно спроецировать без потерь в отношения RI (А, В)
и R2 (А, С) тогда и только тогда, когда для отношения R выполняется МЗзависимость: А - » В | С. Такая зависимость называется нетривиальной
МЗ-зависимостью.
Отношение находится в четвертой нормальной форме (4НФ) тогда и только
тогда, когда существуют такие подмножества А и В атрибутов отношения R,
что выполняется нетривиальная многозначная зависимость А - » В. Тогда
все атрибуты отношения R также функционально зависят от атрибута А.
Итак, поскольку проблема многозначных зависимостей возникает в связи
с многозначными атрибутами, то решить проблему можно, поместив каж­
дый многозначный атрибут в свою собственную таблицу вместе с ключом,
от которого атрибут зависит.
В рассматриваемом примере можно произвести декомпозицию отношения
НИР в два отношения НИР-СОТРУДНИКИ и НИР-ЗАДАНИЯ:
НИР-СОТРУДНИКИ (Номер НИР. Сотр);
НИР-ЗАДАНИЯ (Номер НИР. Задан_НИР).

Оба эти отношения находятся в 4НФ и свободны от отмеченных аномалий,
хотя в них для каждой НИР определено столько кортежей, сколько сотруд­
ников занято в ее выполнении (отношение НИР-СОТРУДНИКИ) или зада­
ний в ней предусмотрено (отношение НИР-ЗАДАНИЯ). Такая многознач­
ность, не накладывающая на отношения ограничений и не вызывающая
аномалий, называется, как было сказано ранее, тривиальной М3.
Пятая нормальная форма

Во всех рассмотренных до этого момента ситуациях нормализация отноше­
ний производилась декомпозицией одного отношения на два. Иногда нор­
мализовать отношение путем декомпозиции на два отношения без потерь не
удается, но просматривается возможность декомпозиции исходного отноше­
ния без потерь на большее число отношений, каждое из которых обладает
лучшими свойствами. Такое отношение называется термином "я-декомпозитируемое отношение" для некоторого я > 2. Это значит, что для данного от­
ношения возможна декомпозиция без потерь на я проекций, а на меньшее
число проекций декомпозиция без потерь невозможна.
Если в процессе естественного соединения декомпозированных отношений
в сравнении с первоначальным отношением генерируются ложные кортежи,
то такая декомпозиция характеризуется зависимостью соединения.
В отношении R (X,, Y, ..., 2) отсутствует зависимость соединения *{Х, Y, ..., Z)
в том и только в том случае, когда R восстанавливается без потерь путем
соединения своих проекций на X, Y, ..., Z
Отношение находится в пятой нормальной форме, если оно не содержит
зависимостей соединения.
Пятая нормальная форма — это последняя нормальная форма, которую
можно получить путем декомпозиции, и на практике 5НФ почти не исполь­
зуется. Заметим, что зависимость соединения является обобщением как
многозначной зависимости, так и функциональной зависимости.

6.2. Проектирование
реляционной базы данных
Рассмотренный выше декомпозиционный подход к проектированию схемы
реляционной базы данных путем последовательной нормализации первона­
чальных отношений, предложенный Коддом, является вполне пригодным
при условии небольшого числа задействованных атрибутов. Большинство
специалистов полагают, что, когда число атрибутов превышает 20, метод,
основанный на декомпозиции, становится излишне громоздким.
В то же время в разд. 3.1 при обсуждении жизненного цикла базы данных
было показано, что одним из важнейших его этапов является этап проекта-

рования базы данных, который начинается после создания плана разработки
БД, сбора и анализа требований пользователей и включает в себя три фазы
проектирования:
□ концептуальное проектирование, в результате которого создается семан­
тическая модель предметной области, не зависящая от каких-либо физи­
ческих условий реализации;
□ логическое проектирование, в результате которого концептуальная мо­
дель предметной области претерпевает изменения, вызванные учетом вы­
бранной модели данных;
□ физическое проектирование, рассматривающее вопросы физической реа­
лизации полученной логической модели посредством выбранной СУБД.
Первая фаза проектирования — создание концептуальной модели ИС, обес­
печивающей точное и наглядное представление сложных аспектов приклад­
ной проблемы, была рассмотрена в разд. 3.2. Основой методики построения
концептуальной модели ИС служит процесс создания ER-модели, предло­
женный Ченом шестью годами позже опубликования Коддом реляционной
модели данных, и дополненный рядом весьма полезных концепций (EERмодель) за последующий период его использования. Поскольку процесс по­
строения концептуальной модели ИС в главе 3 был рассмотрен достаточно
подробно, на данном этапе изложения будем исходить из того факта, что
фаза концептуального проектирования завершена, и в ее ходе для данной
предметной области определены и документированы следующие основопо­
лагающие моменты модели:
□ типы объектов;
□ типы связей;
□ атрибуты типов объектов;
□ домены атрибутов;
□ потенциальные и первичные ключи объектов;
□ EER-диаграмма предметной области.
Данный раздел посвящен второй фазе процесса проектирования БД — логи­
ческому проектированию базы данных, для которой уже определена модель
данных — реляционная модель данных. Иными словами, раздел посвящен
проектированию реляционной базы данных, где концептуальная модель
используется в качестве промежуточной модели, которая впоследствии
посредством применения некоторой методологии преобразуется в реля­
ционную.
Такой подход, помимо всего прочего, отличается от метода декомпозиции
еще и тем, что функциональные зависимости привлекаются не на началь­
ном, а на конечном этапе проектирования. Поэтому важной характеристи­
кой указанного процесса является тот факт, что все полученные в результате

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

6.2.1. Логическое проектирование
реляционной БД
Напомним, что концептуальная модель данных состоит из ряда компонен­
тов: объектов (простых или составных), связей, атрибутов, специализаций
или генерализаций. При переходе к реляционной схеме базы данных каж­
дый из этих компонентов должен быть проанализирован и, если это окажет­
ся необходимым, то даже и преобразован. Изменения, вносимые в процессе
преобразования, должны быть такими, чтобы их результат полностью отве­
чал требованиям, выдвигаемым реляционной моделью данных.
Созданная логическая модель базы данных далее должна пройти проверку
с использованием процедуры последовательной нормализации, а также
должна пройти контроль на возможность выполнения всех необходимых
пользователю транзакций.
Таким образом, данная фаза логического проектирования предполагает сле­
дующие действия:
□ преобразование концептуальной модели данных в логическую модель,
в результате которого будет определена схема реляционной модели
данных;
□ проверка
ции;
□ проверка
□ проверка
Рассмотрим

модели с помощью концепций последовательной нормализа­
модели в отношении транзакций пользователей;
поддержки целостности данных.
последовательно каждое действие.

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

ванию. В этом случае ему придется столкнуться с необходимостью преобра­
зования разнообразных структур данных, причем на пути преобразования
некоторых из них он может встретить ряд трудностей.
Второй же подход состоит в том, что проектировщик, прежде чем присту­
пить к процессу перехода от концептуальной модели к логической модели,
стремится вначале данный переход максимально упростить, проведя предва­
рительные преобразования концептуальной модели, преобразования неко­
торых ее, не подходящих для реляционных СУБД, структур данных. К таким
структурам данных относятся:
□ связи типа "многие ко многим";
□ сложные связи;
□ рекурсивные связи;
□ связи с атрибутами;
□ множественные атрибуты;
□ избыточные связи.
Точка зрения второго подхода на процесс преобразования концептуальной
модели такова: если в модели присутствуют перечисленные нежелательные
структуры, то они должны быть исключены путем тождественной их замены
на структуры данных, допустимые для логической модели.
В данном подразделе рассматривается второй подход, который предполагает
наличие промежуточного этапа на пути получения логической модели БД,
этапа получения упрощенной концептуальной модели.
Прямое преобразование нежелательных с точки зрения реляционной модели
данных концептуальных структур будет рассмотрено в конце этой главы.
Исключение связи типа "многие ко многим"

Преобразование связи типа "многие ко многим" осуществляется путем введе­
ния некоторого промежуточного объекта с заменой одной связи двумя связя­
ми типа "один ко многим" с вновь созданным объектом. При организации
новых связей необходимо следить за тем, чтобы максимальная мощность свя­
зи "один" была направлена к исходному объекту, а максимальная мощность
связи "много" — к вновь созданному объекту. Например, допустим ситуацию
(рис. 6.1), когда один и тот же преподаватель может читать несколько курсов,
и один и тот же курс может читаться несколькими преподавателями.

Рис. 6.1. Диаграмма связи типа "многие ко многим’

Введем дополнительный объект ЧТЕНИЕ и определим новые две связи
(рис. 6.2):
□ ПР_ЧИТАЕТ типа 1 N между объектами ПРЕПОДАВАТЕЛЬ и ЧТЕНИЕ;
□ К_ЧИТАЕТСЯ типа 1 N между объектами КУРС и ЧТЕНИЕ.

Рис. 6.2. Преобразованная диаграмма связи типа "многие ко многим"

Исключение сложных связей

Хотя с помощью бинарных связей могут быть описаны многие ситуации
реального мира, тем не менее неизбежно возникновение и таких ситуаций,
в которых построение разумной модели организации не может быть сведено
к реализации только таких связей. Не так уж редко, например, возникает
потребность моделирования трехсторонних связей.
Напомним, что такая связь, в которой количество участников превышает
два, т. е. тернарные связи и связи более высокого порядка, называемые
jV-арными связями, считается сложной. Исключение такой связи из концеп­
туальной модели происходит по следующему сценарию:
□ в модель вводится новый объект;
□ сложная связь заменяется бинарными связями типа "один ко многим"
исходных объектов с вновь созданным объектом, причем количество би­
нарных связей равно степени сложной связи.
Например, пусть занятия по некоторому курсу ведутся некоторым препода­
вателем в некоторой лаборатории. Концептуальная модель в этой ситуации
может содержать структуру данных, изображенную на рис. 6.3.
Данная тернарная связь, отражающая отношения между преподавателем,
занятиями и лабораторией, должна быть заменена необходимым количест­
вом бинарных связей типа "один ко многим"
Введем дополнительный объект: ЛАБ_ЗАНЯТИЯ и определим для нею три би­
нарные связи типа "один ко многим" с каждым из исходных объектов (рис. 6.4):
П связь ПР_ВБДЕТ для объектов ПРЕПОДАВАТЕЛЬ, Л А Б З АНЯТИЯ;
□ связь В для объектов ЛАБОРАТОРИЯ, ЛАБ_ЗАНЯТИЯ;
□ связь ВЕДУТСЯ для объектов ЗАНЯТИЯ, ЛАБ_ЗАНЯТИЯ.

РИС.

6 .3 . Тернарная связь ПРЕПОДАВАТЕЛЬ - ЗАНЯТИЯ - ЛАБОРАТОРИЯ

Рис. 6.4. Представление тернарной связи бинарными связями

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

Рекурсивные связи с точки зрения их реализации в реляционных схемах БД
также относятся к нежелательным структурам. Как уже отмечалось в главе 3,
рекурсивная связь — это особый вид связи, в которой одни и те же экземп­
ляры объекта участвуют несколько раз в разных ролях. Если концептуальная
модель содержит такие связи, то перед переходом к реляционной схеме БД
они должны быть исключены из модели. Исключение осуществляется,
также как и в Предыдущих случаях, путем ввода в модель дополнительного
объекта и определения его связей.

Рис. 6.5. Рекурсивная связь

Вернемся к ситуации, уже рассмотренной в главе 3, где один из сотрудников
одновременно еще является и руководителем подразделения. Наличие
в концептуальной модели, полученной с учетом вышеописанных факторов
(рис. 6.5), рекурсивной связи типа "один ко многим” значительно усложняет
положение, так как подобные связи при их моделировании требуют к себе
особого подхода.
Проведя преобразование исходной модели путем исключения данной неже­
лательной связи, можно упростить ситуацию. Для этого введем дополни­
тельный объект РОЛЬ_СОТРУДНИКА и установим следующие его связи
(рис. 6.6):
□ РАБОТАЕТ — связь типа "один ко многим";
□ РУКОВОДИТ — связь типа "один к одному"

Рис. 6.6. Исключение рекурсивной связи

Исключение связей с атрибутами

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

Рис. 6.7. Связь с атрибутами

Рассмотрим ситуацию, изображенную на рис. 6.7, где связь ЧИТАЕТ имеет
свой атрибут Время. Для исключения из модели такой связи введем допол­
нительный объект ЛЕКЦИЯ и припишем ему атрибут Время (рис. 6.8).
Между исходными объектами и новым объектом установим следующие связи:
□ ЧИТАЕТ_В — связь типа 1 : N между объектами ПРЕПОДАВАТЕЛЬ и
ЛЕКЦИЯ;
□ ЧИТАЕТСЯ — связь типа 1 : N между объектами КУРС и ЛЕКЦИЯ.

Рис. 6 .8 . Исключение связи с атрибутами

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

Исключение множественных атрибутов

Поскольку в качестве логической модели данных здесь рассматривается ре­
ляционная модель данных, то необходимо не упускать из виду тот факт, что
1НФ для реляционного отношения требует, чтобы все его атрибуты имели
простые атомарные значения. Поэтому если какой-либо объект концепту­
альной модели имеет атрибут множественного типа, то эта модель должна
быть преобразована. Преобразование и в этом случае, также как и в преды­
дущих, осуществляется введением дополнительного объекта.
Допустим, что в концептуальной модели в качестве объекта присутствует
ОТДЕЛ организации, который имеет атрибут Номер_телефона. В том слу­
чае, если в некотором отделе установлен не один, а несколько контактных
телефонов, то данный атрибут имеет множественный тип. Для его исключе­
ния из модели введем дополнительный объект ТЕЛЕФОН и установим его
связь с объектом ОТДЕЛ так, как показано на рис. 6.9.

Исключение избыточных связей

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

6.2.3. Методика преобразования
концептуальных структур данных
в реляционные структуры
Созданием упрощенной концептуальной модели предметной области закла­
дывается основа для получения реляционной схемы базы данных. Посколь­
ку в такой модели присутствует очень узкий круг разрешенных структур,
преобразование каждой из которых имеет свои особенности, то методика
получения реляционной схемы базы данных представляет собой совокуп­
ность правил их преобразования в набор отношений.
Напомним, что в упрощенной концептуальной модели после исключения не­
желательных структур могут присутствовать следующие структуры данных:
□ объекты и атрибуты;
□ бинарные связи типа 1:1 и типа 1 : N;
□ связи типа суперкласс — подкласс.
Рассмотрим правила преобразования каждой из указанных структур.
Преобразование объектов и атрибутов

Пусть проектируется БД, предназначенная для хранения информации о
преподавателях факультета университета и о тех курсах, которые они чита­
ют. База данных, следовательно, включает объекты ПРЕПОДАВАТЕЛЬ и
КУРС (рис. 6.10).

КУРС

(Наименование_курта)

Рис. 6.10. Объекты и их атрибуты

Объект ПРЕПОДАВАТЕЛЬ имеет в данном случае два атрибута, один из
которых (Табельный_номер) может быть использован для идентификации
экземпляра преподавателя, т. е. быть первичным ключом. Таким образом,
левая диаграмма может быть преобразована в следующее отношение:
ПРЕПОДАВАТЕЛЬ (Табельный номер. Ф_И_0).

Объект КУРС имеет только один атрибут, который нельзя использовать в
качестве ключа, поскольку дисциплины с одинаковым названием могут
иметь различные рабочие программы для разных специальностей. Поэтому в
данной ситуации для идентификации экземпляра объекта необходимо доба­
вить еще один атрибут: Номер_курса (рис. 6.11).
В результате имеем следующее отношение:
КУРС (Номер курса. Наименование курса).
Итак, объект с атрибутами может быть преобразован в отношение с именем
объекта в качестве имени отношения и атрибутами объекта в качестве атрибу­
тов отношения. Если некоторый набор атрибутов может быть использован
в качестве ключа отношения, то он назначается ключом отношения. В против­
ном случае в отношение необходимо добавить идентифицирующий атрибут.
КУРС

Рис. 6.11. Диаграмма объекта КУРС с введением идентифицирующего атрибута

Общий подход к преобразованию объектов концептуальной модели ПрО
в отношения реляционной базы данных состоит в следующем:
□ построить набор предварительных отношений и указать первичные клю­
чи для каждого отношения;
□ подготовить список всех представляющих интерес атрибутов (тех из них,
которые не были перечислены в диаграмме в качестве первичных клю­
чей объектов) и назначить каждый из этих атрибутов одному из предва­
рительных отношений с тем условием, чтобы эти отношения находились
в НФБК. На этом шаге для каждого отношения должны быть определе­
ны межатрибутные функциональные зависимости, с помощью которых
проверяется соответствие отношений НФБК. Если полученные отноше­
ния в итоге не находятся в НФБК или если некоторым атрибутам не на­
ходится логически обоснованных мест в предварительных отношениях,
то в этих случаях диаграммы необходимо пересмотреть.
Преобразование бинарных связей

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

и связей типа "многие ко многим" весьма упрощает модель предметной об­
ласти, оставляя в ней только бинарные связи типа "один к одному" и "один
ко многим"
Напомним, что связи между отношениями в реляционной модели данных
реализуются посредством механизма первичных и внешних ключей. Чтобы
этот механизм действовал, необходимо в первую очередь определиться с
тем, которое из двух отношений является родительским, а которое — дочер­
ним. родительским считается такое отношение, которое передает копию на­
бора значений своего первичного ключа другому отношению, где этот набор
значений будет представлять внешний ключ. Последнее отношение в этом
случае будет являться дочерним отношением.
Рассмотрим бинарную связь ЧИТАЕТ между объектами ПРЕПОДАВАТЕЛЬ
и КУРС (рис. 6.12).

Как известно, эта связь может быть изображена с помощью диаграммы, ко­
торая содержит всю информацию, необходимую для генерации соответст­
вующих отношений РБД.
Объект ПРЕПОДАВАТЕЛЬ и КУРС однозначно идентифицируются с по­
мощью ТН — табельного номера преподавателя и НК — номера курса.
Напомним, что, если все элементы данного объекта должны участвовать
в связи, то такое участие называется обязательным. Например, если каждый
преподаватель должен читать один какой-либо курс, то класс принадлежно­
сти такого объекта — обязательный. Класс принадлежности объектов, а так­
же мощность связи между объектами являются факторами, определяющими
структуру проектируемой БД.
Предварительные отношения
для бинарных связей типа 1:1

Предварительные отношения для бинарных связей с показателем карди­
нальности, равным 1:1 могут быть получены вследствие просмотра не­
скольких логических альтернатив и выбора из них наиболее подходящей.
Рассмотрим процесс формирования отношений на ситуацию.
Пусть в проектируемой БД должна храниться следующая информация:
ТН — номер преподавателя;
Ф_И_0 — фамилия, имя, отчество преподавателя;

Тел_П — преподавателя;
НК — номер курса;
Назв_К — название курса.

Рис. 6.13. Диаграмма бинарной связи типа 1 1

Класс принадлежности для обоих объектов — обязательный. Считая, что
класс принадлежности является обязательным для обоих объектов, получаем
отношение:
ПРЕПОДАВАТЕЛЬ (ТН, Ф_И_0, Тел_П, НК, Назв_К).
В этом сводном отношении находится вся требуемая информация. Так как
показатель кардинальности связи равен 1:1 и класс принадлежности явля­
ется обязательным для обоих объектов, то гарантируется однократное появ­
ление каждого значения ТН и НК в любом экземпляре отношения. Это зна­
чит, что отношение никогда не будет содержать ни пустой информации, ни
повторяющихся групп избыточных данных. Первичным ключом этого от­
ношения может быть ключ любого из двух объектов. Существование еди­
ного отношения в данной ситуации тем более предпочтительно тогда, когда
исходные два объекта не принимают участия в других связях.
Если же по каким-то соображениям желательно для каждого объекта иметь
отдельное отношение, то выбор родительского и дочернего отношений вы­
полняется произвольно.
Класс принадлежности одного из объектов — обязательный. Ситуация
будет другая, если класс принадлежности одного из объектов
(ПРЕПОДАВАТЕЛЬ) — обязательный, второго (КУРС) — нет. В этом случае
одного отношения в БД недостаточно. Пробелы появляются в нем во всех
кортежах, содержащих информацию о курсах, не читаемых ни одним из
преподавателей.
Существует только один выход из такой ситуации — построение двух отно­
шений: по одному под каждый объект. При этом ключ каждого объекта
должен служить первичным ключом для соответствующего отношения. Объ­
ект, для которого класс принадлежности является необязательным, преобра­
зуется в родительское отношение, а объект, участвующий в связи с обяза­
тельным классом принадлежности, преобразуется в дочернее отношение.

Для связи полученных отношений ключ родительского отношения добавля­
ется в качестве атрибута (внешнего ключа) в дочернее отношение.
В результате получаем следующую реляционную схему:
ПРЕПОДАВАТЕЛЬ (Ш , Ф _И_0, Тел_П, НК);
КУРС (НК, Назв_К).
Класс принадлежности для обоих объектов — необязательный. В подобной
ситуации можно рассмотреть два альтернативных решения.
Первое решение предполагает существование двух отношений. Причем
в данном случае совершенно безразлично, которое из двух отношений будет
определено в качестве родительского отношения. Возможен такой вариант:
КУРС (НК, Назв_К);
ПРЕПОДАВАТЕЛЬ (Ш , Ф _И_0, Тел_П, НК).
Возможен и другой вариант:
ПРЕПОДАВАТЕЛЬ (IH , Ф _И_0, Тел_П);
КУРС (НК, Назв_К, ТН).
Но обоим этим вариантам свойственно появление пробелов во всех корте­
жах, содержащих информацию о курсах, не читаемых ни одним из препода­
вателей (первая схема), и во всех кортежах, содержащих информацию
о преподавателях, не ведущих ни один курс (вторая схема).
Лучшим решением при сложившихся обстоятельствах является определение
трех отношений — по одному для каждого объекта и одного для связи:
ПРЕПОДАВАТЕЛЬ (ТН, Ф _И_0, Тел_П),
КУРС (НК, Назв_К);
ЧИТАЕТ (Ш , НК).
В отношении ЧИТАЕТ любые значения ТН и НК могут появляться только
однажды, так как показатель кардинальности связи равен 1: 1, и в нем по­
являются только те преподаватели, которые и читают те курсы, которые чи­
таются. Отношение ПРЕПОДАВАТЕЛЬ содержит сведения обо всех препо­
давателях, а отношение КУРС — обо всех курсах.
Отношение для связи должно иметь среди своих атрибутов по одному ключу
от каждого объекта.
Предварительные отношения
для бинарных связей типа 1 : N

Пусть в рассмотренной выше концептуальной модели существует бинарная
связь типа 1 : N (рис. 6.14).
Для таких связей существует только два правила. Вариант определяется классом
принадлежности АГ-связного объекта, класс принадлежности 1-связного объекта
не влияет на конечный результат в обоих случаях.

Рис. 6.14. Диаграмма бинарной связи типа 1 : N

Первый вариант. ПРЕПОДАВАТЕЛЬ — класс принадлежности необязатель­
ный. КУРС — обязательный.
Если в такой ситуации всю информацию поместить в одно отношение, то в
нем будут присутствовать повторяющиеся сведения о преподавателях, чи­
тающих несколько курсов, и пробелы в полях атрибутов курса, который не
читается ни одним преподавателем. Если бы класс принадлежности объекта
ПРЕПОДАВАТЕЛЬ был обязателен, то исчезли бы пробелы, но повторяю­
щиеся данные остались бы.
Решение этой задачи становится возможным, если использовать два отно­
шения, по одному на каждый объект, при условии, что ключ каждого объек­
та служит в качестве первичного ключа для соответствующего отношения.
Для такой диаграммы существует только одно безальтернативное определе­
ние родительского и дочернего отношений. В качестве родительского
назначается отношение, соответствующее "единичной" стороне связи,
а в качестве дочернего назначается отношение, представляющее "множест­
венную" сторону связи. Для представления этой связи необходимо скопиро­
вать первичный ключ родительского отношения в дочернее отношение, где
данный ключ должен быть описан как внешний.
Окончательно в БД войдут два отношения:
ПРЕПОДАВАТЕЛЬ (Ш , Ф _И_0, Тел_П);
КУРС (НК, Назв_К, НП).
Второй вариант. Класс принадлежности для обоих объектов — необязатель­
ный. В одиночном отношении, моделирующем такую систему, появляется
ряд проблем:
□ возникают пробелы в атрибутах курса, где преподаватель не читает курс;
□ возникают пробелы в атрибутах преподавателя, где курс не читается ни
одним преподавателем;
□ повторяются сведения о преподавателях, читающих более одного курса.
Если воспользоваться предыдущим правилом, то исчезнут первая и третья
проблемы, но вторая останется. Решение второй проблемы — в формирова­
нии трех отношений: по одному на каждый объект (причем ключ каждого
объекта служит первичным ключом соответствующего отношения) и одного

отношения для связи. Отношение для связи должно иметь среди своих ат­
рибутов ключ каждого объекта:
КУРС (НК, Назв_К);
ПРЕПОДАВАТЕЛЬ (Ш , Ф_И_0, Тел_П);
ЧИТАЕТ (Ш , НК).
Вышеприведенные правила, лежащие в основе генерации предварительных
отношений для данной диаграммы, несколько отличаются от тех, которые
можно найти в ряде литературных источников. Некоторые авторы утвер­
ждают, что по одному предварительному отношению следует формировать
для каждого объекта и также по одному для каждой связи, вне зависимости
от ее степени и класса принадлежности. Результатом такого подхода
в большинстве случаев будет генерация большего числа отношений, чем это
необходимо.
Преобразование связи типа "суперкласс/подкласс"

Для каждой присутствующей в логической модели данных связи типа "су­
перкласс/подкласс" объект суперкласса необходимо определить как роди­
тельский, а объект подкласса — как дочерний. Существуют различные вари­
анты представления подобных связей в виде одного или нескольких
отношений. Выбор наиболее подходящего варианта зависит от ограничений
участия и пересечения, наложенных на участников связи типа "супер­
класс/подкласс"
Если суперкласс с его подклассами имеет тотальные и непересекающиеся
связи, где каждый экземпляр суперкласса обязательно должен быть членом
одного и только одного подкласса, то самым целесообразным решением яв­
ляется представление каждого из подклассов в виде отдельного отношения,
содержащего копию первичного ключа суперкласса.
Рассмотрим подклассы АССИСТЕНТ, СТАРШИЙ ПРЕПОДАВАТЕЛЬ,
ДОЦЕНТ, ПРОФЕССОР, которые являются членами суперкласса
ПРЕПОДАВАТЕЛЬ (рис. 6.15). Это означает, что каждый экземпляр под­
класса является в то же время и экземпляром суперкласса. Причем каждый
преподаватель обязательно принадлежит одному и только одному подклассу.
Подобная диаграмма преобразуется в следующую реляционную схему отно­
шений:
ПРЕПОДАВАТЕЛЬ (Табельный номер. Ф_И_0, Адрес, Педагог_стаж).
ПРОФЕССОР (Табельный номер. Номер_липлома_профессора);
ДОЦЕНТ (Табельный номер. Номер^диплома_доцента);
СТАРШИЙ_ПРЕПОДАВАТЕЛЬ (Табельный номер):

АССИСТЕНТ (Табельный номер).

ПРЕПОДАВАТЕЛЬ

ПРОФЕССОР

ДОЦЕНТ

СТАРШИЙ
ПРЕПОДАВАТЕЛЬ

АССИСТЕНТ

Рис. 6.15. Диаграмма связи "суперкласс/подкласс"

Представленный вариант преобразования концептуальной модели "супер­
класс/подкласс" в реляционную схему естественно нельзя рекомендовать
как единственно возможный, поскольку он подходит не ко всякой ситуа­
ции. Рассмотренный вариант предполагает организацию отношения для ка­
ждого подкласса. Количество отношений может быть и меньшим — вплоть
до одного для суперкласса и всех его подклассов. На окончательное реше­
ние могут повлиять факторы различной природы, например такой: включе­
ны или нет подклассы в отдельные связи. Диапазон возможных вариантов
довольно большой и всегда можно подобрать наиболее оптимальный.
В данный момент требуется подвести некоторые итоги. Материал этого раз­
дела посвящен вопросам создания логической модели предметной области,
которая учитывает тип модели данных. Поскольку речь идет о широко ис­
пользуемой реляционной модели данных, то в начале данного раздела была
освещена методика второго подхода к получению логической модели дан­
ных. Было показано, как необходимо упростить концептуальную модель,
исключив из нее нежелательные структуры данных, чтобы облегчить про­
цесс преобразования в реляционную схему данных. Действительно, исклю­
чив из концептуальной модели рекурсивные связи, связи типа "многие ко
многим", связи высокого порядка, мы ограничили число видов необходимых
преобразований и свели их к несложной последовательности вышеизложен­
ных действий.
При обосновании необходимости исключения структуры того или иного
типа из концептуальной модели было справедливо отмечено, что наличие ее
нежелательно, так как в процессе ее преобразования возникают определен­
ные трудности, а сам процесс исключения не нарушает общую структуру
модели и взаимосвязи ее объектов.
Тем не менее можно привести примеры, когда исключения такого рода
ухудшают восприятие модели. Например, бинарным связям, с помощью

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

При такой степени связи требуется три отношения вне зависимости от
класса принадлежности обоих объектов: по одному для каждого объекта,
причем ключ каждого объекта используется в качестве первичного ключа
соответствующего отношения, и одного отношения для связи. Последнее
должно иметь в числе своих атрибутов ключ каждого объекта. Единственно
допустимый вариант в сложившейся ситуации — представить БД тремя от­
ношениями:
КУРС (НК, Назв_К);
ПРЕПОДАВАТЕЛЬ (Ш , Ф _И_0, Тел_П);
ЧИТАЕТ (Ш , НК).
Вся информация о курсе будет содержаться в отношении КУРС, информация
о преподавателе — в отношении ПРЕПОДАВАТЕЛЬ, а отношение ЧИТАЕТ
будет содержать только экземпляры связи, имеющиеся в модели.
Использование прямого преобразования концептуальных связей в логиче­
ские структуры оказывается очень полезным при моделировании составных
объектов.
Преобразование составных объектов

Как было ранее показано, очень удобно при построении концептуальной
модели использовать составные объекты. Рассмотрим концептуальную мо­
дель, представленную на рис. 6.16.
Внутренний составной объект ВЫПОЛНЯЕТ имеет показатель кардиналь­
ности связи "многие ко многим" В соответствии с изложенными выше пра­
вилами преобразование этой модели в реляционную модель требует генера­
ции трех отношений:
СПЕЦИАЛИСТ (Таб номер. Ф_И_0, Должность);
ВИД_РАБОТЫ (Код вида. Характеристика);
ВЫПОЛНЯЕТ (Таб номер. Код вида).
Если бы первые два отношения имели только ключевые атрибуты, то эти
отношения можно было бы исключить, так как ключевые атрибуты уже со­
держатся в отношении ВЫПОЛНЯЕТ.

Рис. 6.16. Составной объект

Внутренний составной объект ВЫПОЛНЯЕТ вместе с объектом НИР обра­
зуют новый составной объект. Показатель кардинальности связи этих объек­
тов, также, как и первом случае, определен как "многие ко многим" Преоб­
разование подобной модели в реляционную модель требует генерации еще
двух дополнительных отношений: одного для объекта НИР, другого — для
связи ПО:
НИР (Индекс Нир. Название, Руководитель);
ПО (Таб номер. Код вида. Индекс Нир. Час_оплата, Кол_часов).
В последнее отношение помимо ключевых атрибутов первых двух отноше­
ний вошли атрибуты, относящиеся ко всему данному составному объекту
Час_оплата и Кол_часов.
Итак, в результате преобразования исходной концептуальной модели полу­
чена реляционная модель, содержащая пять отношений:
СПЕЦИАЛИСТ (Таб номер. Ф И О, Должность);
ВИД_РАБОТЫ (Код вида. Характеристика);
ВЫПОЛНЯЕТ (Таб номер. Код вида1):

НИР (Индекс Нир. Название, Руководитель);
ПО (Таб номер. Кол вида. Индекс Нир. Час_оплата, Кол_часов).
Однако следует обратить внимание на избыточность информации в данной
базе. Действительно, вся информация, содержащаяся в отношении
ВЫПОЛНЯЕТ, присутствует также в отношении ПО. Исключить указанную
избыточность можно удалением из схемы базы данных отношения
ВЫПОЛНЯЕТ, что нельзя было бы сделать, если бы отношение
ВЫПОЛНЯЕТ содержало неключевые атрибуты.
Конечный результат преобразования выглядит так:
СПЕЦИАЛИСТ (Таб номер. Ф_И_0, Должность);
ВИД_РАБОТЫ (Код вида. Характеристика);
НИР (Индекс Нирт Название, Руководитель);
ПО (Таб номер. Кол вида. Индекс Нир. Час_оплата, Кол_часов).
Нетрудно заметить, что данная модель представляет тернарную связь с соб­
ственными атрибутами.
Преобразование тернарных связей

Хотя с помощью бинарных связей могут быть описаны многие ситуации
реального мира, тем не менее неизбежно возникновение и таких ситуаций,
в которых построение разумной модели организации не может быть сведено
к реализации только таких связей.
Не так уж редко возникает потребность моделирования тернарных связей.
В подобных ситуациях необходимо использовать четыре предварительных
отношения, по одному для каждого объекта (причем ключ каждого объекта
должен служить в качестве первичного ключа для соответствующего отно­
шения) и одно для связи. Отношение, порождаемое связью, будет иметь
среди своих атрибутов ключи каждого объекта. Например, моделирование
связи между тремя объектами ПРЕПОДАВАТЕЛЬ, КУРС, СТУДЕНТ требу­
ет генерации четырех отношений:
ПРЕПОДАВАТЕЛЬ (Щ , Ф_И_0, Тел_П,...);
КУРС (НК, Назв_К,...);
СТУДЕНТ (НС, Фам_С,...);
ПК_С (ТН, НК, НС,...).
Аналогично, когда связь л-арная, требуется п + 1 предварительное отно­
шение.
Первичный ключ последнего отношения можно будет определить лишь то­
гда, когда будут распределены между отношениями все прочие, представ­
ляющие интерес атрибуты.

Преобразование рекурсивных связей

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

Рис. 6.17. Диаграмма связи РУКОВОДИТ

Ключом каждого объекта является табельный номер каждого служащего.
Предполагается, что ни один мастер не руководит другим мастером, ни один
мастер не является сборщиком, и ни один сборщик не является мастером.
Поскольку показатель кардинальности связи РУКОВОДИТ равен 1 : N и
класс принадлежности объектов для обеих сторон связи является обязатель­
ным, то в соответствии с общим правилом будут построены два предвари­
тельных отношения:
МАСТЕР (Ном мастера.............. ) ;
СБОРЩИК (Ном сборщика........... Ном_мастера).
Предположим, что другими представляющими интерес атрибутами являются:
ФамСл — фамилия (и имя) служащего;
РтелМ — номер служебного телефона мастера; сборщик служебного теле­
фона не имеет;
ДтелСл — номер домашнего телефона служащего;
АдресСл — домашний адрес служащего;
ТставкаСб — почасовая тарифная ставка сборщика;
ОкладМ — месячный оклад мастера.
Не возникает особых проблем при размещении в одном из двух отношений
следующих атрибутов: РтелМ, ТставкаСб, ОкладМ. После того как каждый
из этих атрибутов будет логичным образом помещен в одно из двух отноше­
ний, предварительные отношения примут вид:
МАСТЕР (Ном мастера. Оклад, РтелМ,...);
СБОРЩИК (Ном сборщика. ТставкаСб, ..., Ном_мастера).

Неразмещенными остались только атрибуты ФамСл, ДтелСл и АдресСл. Для
полноты представления следовало бы эти три атрибута поместить в оба от­
ношения. Однако в соответствии с общим правилом каждый неключевой ат­
рибут следует размещать только в одном отношении.
Может возникнуть необходимость переопределить три оставшихся атрибута
с целью получения из них следующих шести атрибутов:
Мфам — фамилия (и имя) мастера;
Сбфам — фамилия (и имя) сборщика;
Мдтел — номер домашнего телефона мастера;
Мадрес — домашний адрес мастера;
Сбдтел — номер домашнего телефона сборщика;
Сбадрес — домашний адрес сборщика.
Атрибуты Мфам, Мдтел и Мадрес могут быть помещены в отношение
МАСТЕР, а атрибуты Сбфам, Сбдтел и Сбадрес — в отношение СБОРЩИК.
Это неудачное решение, позволяющее уйти от проблемы отсутствия подхо­
дящего места для двух исходных атрибутов.
Если все же изменить предложенным образом названия атрибутов, то воз­
никнет следующая проблема. Предположим, что требуется найти номер до­
машнего телефона, например служащего Иванова. Поскольку неизвестно,
является Иванов мастером или сборщиком, то необходимо предварительно
просмотреть сначала одно отношение, затем другое с целью нахождения
фамилии — Иванов. Если существуют два служащих с фамилией Иванов —
один мастер, а другой — сборщик, результатом поиска, если выбрано не то
отношение, будет неправильный номер телефона.
Лучшее решение достигается путем рассмотрения всей проблемы с иной
точки зрения. Все мастера и сборщики рассматриваются в качестве супер­
класса СЛУЖАЩИЕ, а МАСТЕР и СБОРЩИК — это его подклассы, опре­
деляющие роли, которые данный служащий может играть: некоторые слу­
жащие являются мастерами, в то время как другие являются сборщиками
(рис. 6.18).
На рисунке СЛУЖАЩИЙ представляет собой объект, ключом которого яв­
ляется табельный номер. Элементы данного объекта могут играть роль либо
мастера, либо сборщика. Два подкласса — МАСТЕР и СБОРЩИК соеди­
няются связью РУКОВОДИТ.
При генерации предварительных отношений, исходя из представленной
выше диаграммы, можно руководствоваться следующим правилом.
Суперкласс служит источником генерации одного отношения, причем ключ
этого суперкласса служит в качестве ключа отношения. Подклассы и их свя­
зи порождают такое число отношений, которое определяется ранее описан­
ными правилами, причем каждый подкласс трактуется как обычный объект.

Рис. 6.18. Диаграмма с рекурсивной связью

При распределении всех других атрибутов между отношениями, входящими
в данный набор, выясняется, что каждому атрибуту находится естественное
место. Получаемый в результате окончательный набор отношений имеет вид:
СЛУЖАЩИЙ (Ном с л у ж . ..., ФамСл, ДтелСл, АдресСл);
МАСТЕР (Ном мастера. Оклад, РтелМ, ...);
СБОРЩИК (Ном сборщика. ТставкаСб, ..., Ном_мастера).
Отношение СЛУЖАЩИЙ содержит информацию, общую для всех служащих.
Отношения МАСТЕР и СБОРЩИК содержат специфическую для каждого
подкласса информацию. Каждое порождаемое подклассом отношение связано
с отношением, источником порождения которого послужил суперкласс, через
атрибут из общего домена (в данном примере — табельный номер).
В рассматриваемой диаграмме связь РУКОВОДИТ соединяет два подкласса
одного суперкласса. Такой тип связи называется р е к у р с и в н ы м . Эта связь ре­
курсивна в том смысле, что с точки зрения суперкласса служащие руководят
служащими.
Для увеличения скорости доступа при запросах проектировщик может рас­
смотреть возможность добавления в отношение СЛУЖАЩИЙ атрибута,
определяющего, кем конкретно является служащий — мастером или сбор­
щиком. Это позволит избежать необходимости организации поиска в отно­
шениях МАСТЕР и СБОРЩИК, цель которого состоит в определении типа
работы отдельного служащего, а возможность — обусловливается известным
табельным номером.
Итак, выше были рассмотрены способы преобразования конструкций кон­
цептуальной модели — объектов, атрибутов, связей и составных объектов —
в реляционные отношения. После того как преобразование всех конкретных
конструкций закончено, полученную реляционную схему необходимо еще
раз пересмотреть на предмет избавления от избыточности. Любые избыточные

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

6.2.4. Проверка модели с помощью концепций
последовательной нормализации
Созданный на предыдущем этапе предварительный набор отношений логи­
ческой модели данных должен обязательно быть подвергнут анализу на кор­
ректность объединения атрибутов в каждом из отношений. Проверка кор­
ректности состава каждого из отношений должна проводиться посредством
применения к ним процедуры последовательной нормализации. Целью
применения этой процедуры является получение гарантий того, что каждое
из отношений, полученных на основе концептуальной модели, находится,
по крайней мере, в НФБК.
Если в процессе анализа отношений модели будут найдены отношения, не
отвечающие требованиям НФБК, то это будет означать, что где-то на пре­
дыдущих этапах были допущены ошибки. Возможно, ошибки появились
при построении концептуальной модели, а возможно — в процессе ее пре­
образования в логическую модель. Для обеспечения корректности логиче­
ской модели в такой ситуации придется вернуться на ранние этапы проек­
тирования и перестроить ошибочно созданные фрагменты модели.
Правильно выполненные действия по проектированию модели предметной
области должны обязательно привести к созданию набора отношений в
НФБК. Функциональные зависимости, определенные для реляционной мо­
дели, являются атрибутами связей с показателями кардинальности "один к
одному" или "один ко многим" Описанный процесс преобразования каждой
из этих конструкций в атрибуты реляционных отношений гарантирует, что
они будут зависеть только от ключевых атрибутов. Таким образом, каждая
полученная реляционная таблица будет иметь НФБК.

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

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

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

Вопросы и упражнения
1. Объясните своими словами смысл терминов:
• избыточность данных;
• аномалии включения, обновления, удаления;
• нормализация отношений;

•
•
•
•
•
•

2.
3.
4.

5.
6.
7.
8.

9.

10.
11.

декомпозиция;
первая нормальная форма;
функциональные зависимости;
вторая нормальная форма;
посторонний атрибут;
третья нормальная форма;

• нормальная форма Бойса — Кодла;
• четвертая нормальная форма;
• пятая нормальная форма.
Приведите примеры отношений, не находящихся в первой нормальной
форме.
Рассмотрите отношение с навязанной функциональной зависимостью.
Продемонстрируйте алгоритм выявления функциональной зависимости.
Что такое транзитивная зависимость? К каким негативным последстви­
ям приводит наличие транзитивной зависимости? Какие меры помога­
ют избавиться от этих последствий?
Что служит альтернативой нормализации посредством декомпозиции?
Какие нежелательные функциональные зависимости устраняются по­
средством приведения отношения к нормальной форме Бойса — Кодда?
Охарактеризуйте многозначные зависимости. Приведите примеры от­
ношений, где они присутствуют.
Осветите процесс проектирования реляционной базы данных. Какие
действия предполагает фаза логического проектирования реляционной
БД?
Каким образом можно упростить концептуальную модель данных, чтобы
облегчить процесс перехода от концептуальной модели к логической мо­
дели?
Изложите правила методики преобразования концептуальных структур
данных в реляционные структуры.
Постройте концептуальную модель с ПрО Библиотека и с ее помощью
получите реляционную модель соответствующей базы данных.

Глава 7

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

Материал второй части этой главы содержит обзор технологий хранения
данных конкретной СУБД.

7.1. Технологии хранения данных
в СУБД
Любое упорядочение данных на диске называется структурой хранения.
К сожалению, до сих пор не создана такая идеальная структура хранения,
которую можно было бы использовать как оптимальную для любых задач.
Но зато можно организовать самые разные структуры хранения, обладаю­
щие различной производительностью, область применения которых опреде­
ляется тем, насколько они эффективны в том или ином случае.
В первых главах книги уже обращалось внимание на то, что организация об­
работки данных посредством реляционных СУБД имеет свою специфику.
Файловая структура и система управления файлами подчиняются законам
операционной системы. По отношению к базам данных эти принципы мо­
гут быть далеки от оптимальности, а потому СУБД подчиняется несколько
иным принципам и стратегиям управления внешней памятью.

Обозначим наиболее важные особенности, влияющие на организацию
внешней памяти.
□ Наличие двух уровней системы: уровня непосредственного управления
данными во внешней памяти и языкового уровня. При такой организа­
ции подсистема нижнего уровня должна поддерживать во внешней памя­
ти набор базовых структур, конкретная интерпретация которых входит
в число функций подсистемы верхнего уровня.
□ Необходимость организации отношений-каталогов с метаданными, под­
держиваемых подсистемой языкового уровня. С точки зрения структур
внешней памяти отношение-каталог ничем не отличается от обычного
отношения базы данных.
□ Регулярность структур данных обеспечивается тем, что основным объек­
том реляционной модели данных является плоская таблица.
□ Необходимость обеспечить возможность эффективного выполнения опе­
раторов языкового уровня как над одним отношением, так и над не­
сколькими отношениями. Для этого во внешней памяти должны поддер­
живаться дополнительные "управляющие" структуры — индексы.
□ Для выполнения требования надежного хранения баз данных необходимо
поддерживать избыточность хранения данных, что обычно реализуется
в виде журнала изменений базы данных.
Для функционирования СУБД во внешней памяти базы данных возникает
необходимость хранить следующие разновидности объектов:
□ строки отношений — основная часть базы данных, большей частью не­
посредственно видимая пользователям;
□ управляющие структуры — индексы, создаваемые по инициативе пользо­
вателя (администратора) или верхнего уровня системы из соображений
повышения эффективности выполнения запросов и обычно автоматиче­
ски поддерживаемые нижним уровнем системы;
□ журнальную информацию, поддерживаемую для удовлетворения потреб­
ности в надежном хранении данных;
□ служебную информацию, поддерживаемую для удовлетворения внутрен­
них потребностей нижнего уровня системы.
Поскольку СУБД в силу отмеченной выше специфики не может использо­
вать общесистемные механизмы буферизации и управления файловыми
структурами, то она вынуждена сама брать на себя полномочия по управле­
нию размещением данных и размещать их на своих внешних носителях, где про­
странство внешней памяти управляется непосредственно самой СУБД. Такие
системы организации данных во внешней памяти опираются на некоторые
механизмы, использующие страничный принцип организации.
Рассмотрим технологию доступа к базе данных.

7.1.1. Доступ к базе данных
Поиск и предоставление данных пользователю осуществляются с помощью
нескольких программ доступа данных и включают в себя три основных эта­
па (рис. 7.1).
□ Определяется искомая запись, для извлечения которой запрашивается
диспетчер файлов.
□ Диспетчер файлов определяет страницу, на которой находится искомая
запись, и для извлечения этой страницы запрашивает диспетчер дисков.
□ Диспетчер дисков определяет физическое положение искомой страницы
на диске и посылает соответствующий вопрос на ввод-вывод данных.
Запрос
записи

Запрос
Дисковая операция
страницы
ввода-вывода
- ........► Диспетчер ---------►
...........►
База
Диспетчер
СУБД
дисков
данных
файлов
4 --------< —....—
4 --------Чтение
Возвращение
Возвращение
данных
записи
страницы
с диска

Рис. 7 . 1 . Схема доступа к б а з е данных

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

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

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

Рис. 7 .2 . Классификация объектов ф изической м одели данных

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

Основными единицами осуществления операций обмена являются страницы
данных, управляемые диспетчером дисков. Все данные хранятся постранич­
но. Таким образом, с точки зрения СУБД база данных выглядит как набор
записей, которые просматриваются с помощью диспетчера файлов. С точки
зрения диспетчера файлов база данных выглядит как набор страниц, кото­
рые могут просматриваться с помощью диспетчера дисков.
На одной странице хранятся однородные данные, например, только данные
или только индексы. Все страницы данных имеют одинаковую структуру,
представленную на рис. 7.3.
Заголовок страницы используется для задания посредством указателей логи­
ческой последовательности страниц в данном наборе. Он также содержит
информацию о физическом дисковом адресе страницы, которая логически
следует за данной страницей (рис. 7.4 — правый верхний угол).
Заголовки страниц и указатели на следующие страницы обрабатываются
только диспетчером дисков и скрыты от диспетчера файлов. Для выполнения

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

С о д е р ж а н и е (строки)

Слоты

Рис. 7 . 3 . Структура страницы данных

Заголовок

5

Записи
Запись2
Свободное пространство

Рис. 7 . 4 . О п р едел ен и е логической последовательности страниц

С помощью диспетчера дисков удается решить и проблему сохранения ло­
гически связанных страниц в физически близко расположенных местах.
Так, вставка некоторой записи при наличии свободного пространства на
странице будет произведена на то место, которое эта запись занимает в ло­
гической последовательности записей, со сдвигом вниз записей, уже храни­
мых на странице, но логически следующих за ней. К тому же соответствие
физической и логической последовательности достигается также и за счет
того, что диспетчер дисков размещает или удаляет страницы в наборах не по
одной, а целыми экстентами.
Слоты характеризуют размещение строк данных на странице. На одной
странице хранится не более 255 строк.
Каждая запись обладает уникальным идентификатором, не изменяемым во
все время ее существования, он имеет определенную длину и состоит из
номера страницы, на которой данная запись находится, и байта смещения
слота от конца страницы, который в свою очередь содержит байт смещения
записи от начала страницы (рис. 7.5). Подобная схема идентификации запи­
си сочетает в себе быстроту непосредственной адресации и гибкость кос­
венной адресации, тем самым обеспечивая требуемую эффективность поис­
ка информации.
Обычно каждая запись хранится целиком в одной странице. Из этого следу­
ет, что максимальная длина записи любого отношения ограничена размера­
ми страницы.

Рис. 7 . 5 . Структура идентификационного ном ера записи

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

Как правило, на одной странице данных хранятся записи только одной таб­
лицы. Существуют, однако, варианты с возможностью хранения на одной
странице записей нескольких таблиц, что иногда позволяет резко сократить
число обменов с внешней памятью при выполнении соединений.
Таблица моделируется совокупностью экстентов. Для моделирования каж­
дой таблицы используется два типа экстентов: первый и последующие. Пер­
вый экстент задается при создании нового объекта типа таблица, его размер
8 Зак. 3303

задается при создании. Минимальный размер экстента в каждой системе
свой, но в большинстве случаев он равен 4 страницам, максимальный —
2 Гбайтам. Новый экстент создается после заполнения предыдущего и свя­
зывается с ним специальной ссылкой, которая располагается на последней
странице экстента. Внутри экстента идет учет свободных станиц.
Экстенты состоят из четырех типов страниц: страницы данных, страницы
индексов, битовые страницы и страницы Blob-объектов (Binary Large
Object), которые соответствуют неструктурированным данным. В современ­
ных СУБД к этому типу относятся неструктурированные текстовые данные,
картинки, просто наборы машинных кодов.
Изменение схемы хранимого отношения с добавлением нового столбца не
вызывает потребности в физической реорганизации отношения. Достаточно
лишь изменить информацию в описателе отношения и расширять записи
только при занесении информации в новый столбец.
Таким образом, подводя итоги рассмотрения общего подхода организации
хранения данных и доступа к ним на физическом уровне, следует отметить,
что эта организация направлена на то, чтобы обеспечить поддержку функ­
циональности СУБД с максимально возможной эффективностью, причем
так, чтобы пользователь не замечал всей сложности и многоступенчатости
данной проблемы. Диспетчер дисков скрывает все подробности физической
организации ввода-вывода от диспетчера файлов, который ведет работу
только на логическом уровне. На своем уровне СУБД уже имеет дело только
с хранимыми записями и файлами. С точки зрения СУБД хранимая запись
обладает определенной структурой, а с точки зрения диспетчера файлов —
это просто битовая строка.
Хотя, как только что было отмечено, описанная выше технология хранения
данных на физическом уровне и направлена на то, чтобы обеспечить как
можно более высокую эффективность операций ввода-вывода, все-таки од­
ной ее возможностей явно недостаточно. Производительность и иные пока­
затели современных СУБД опираются и на другие технологии, которые
предлагают способы доступа, отличающиеся от тех, которые опираются на
физическую последовательность данных.
Вернемся к файловым структурам баз данных.

7.1.3. Файловые структуры баз данных
Файлы и файловые структуры, широко применяемые практически во всех
СУБД для хранения информации во внешней памяти, можно классифици­
ровать следующим образом (рис. 7.6).
Так как файл — это линейная последовательность записей, то всегда в файле
можно определить текущую запись, предшествующую ей и следующую за ней.

Рис. 7 .6 . Классификация файлов, используемы х в систем ах б а з данных

Для каждого файла в системе хранится следующая информация:
□ имя файла;
□ тип файла (например, расширение или другие характеристики);
□ размер записи;
□ количество занятых физических блоков;
□ базовый начальный адрес;
□ ссылка на сегмент расширения;
□ способ доступа.
Известно, что в соответствии с методами управления доступом различают
устройства внешней памяти произвольного и последовательного доступа.
На устройствах последовательного доступа могут быть организованы файлы
только последовательного доступа.
Вообще файлы могут иметь постоянную или переменную длину записи.
Файлы с переменной длиной записи всегда являются файлами последова­
тельного доступа. Файлы с постоянной длиной записи, расположенные на
устройствах прямого доступа, являются файлами прямого доступа.
Наиболее перспективным в системах баз данных считается использование
файлов прямого доступа, поскольку посредством их обеспечивается наиболее
быстрый доступ к произвольным записям. Для файлов с постоянной длиной
записи физический адрес расположения нужной записи может быть вычислен
по номеру записи. Но доступ по номеру записи в базах данных весьма
неэффективен. Чаще всего в базах данных необходим поиск по ключу, для
которого необходимо определить соответствующий ему номер записи, а сле­
довательно, предпочтительнее связывать между собой не номер записи
и физический адрес, а значение ключа записи и номер записи файла.
При организации файлов прямого доступа в некоторых очень редких случаях
возможно построение линейной обеспечивающей однозначное соответствие
функции, которая по значению ключа однозначно вычисляет номер записи

файла. Однако чаще всего такой подход оказывается неприемлемым и тогда
приходится искать выход в привлечении других технологий.

7.1.4. Хеширование
Хешированием называется технология быстрого прямого доступа к хранимой
записи на основе заданного значения некоторого поля, которое может быть
даже не ключевым. Тем не менее в дальнейшем будем полагать, что речь
идет о ключевом поле.
Технология хеширования предполагает следующие моменты:
□ Каждая запись БД размещается по адресу, вычисляемому путем приме­
нения к значению ключа некоторой функции свертки (хеш-функции),
вырабатывающей значение меньшего размера. Свертка значения ключа
применяется для того, чтобы избежать неэффективного использования
дискового пространства. Достигается подобный эффект подбором специ­
альной функции. Указанная неэффективность обязательно возникнет,
если вместо свертки использовать значения непосредственно ключевого
поля, которые разбросаны по домену, а если диапазон значений ключе­
вого поля значительно шире диапазона имеющихся адресов, такой под­
ход вообще оказывается неприемлемым. Например, ключевое поле со­
держит 7 значений в диапазоне 0-1000. В результате использования
подходящей хеш-функции получим 7 ее значений в диапазоне 0-9.
□ Свертка значения ключа используется и для доступа к записи. Ее полу­
ченное значение берется в качестве адреса начала поиска, тем самым ог­
раничивается время поиска (количество дополнительных шагов) для
окончательного получения адреса. В самом простом, классическом слу­
чае, свертка ключа используется как адрес в таблице, содержащей ключи
и записи.
В файле может быть только одна структура хеширования или, -иначе говоря,
одно хеш-поле. Простейшим примером общего класса хеш-функций являет­
ся тип деление/остаток (на некоторое простое число, например 13).
Следует отметить, что при хешировании физическая последовательность
записей почти всегда отличается от последовательности ключевого поля.
Основным требованием к хеш-функции является равномерное распределе­
ние значения свертки, где одному значению хеш-функции может соответст­
вовать одно значение ключа. Однако часто приходится допускать обратное.
Если для нескольких значений ключа получается одна и та же свертка, то
образуются цепочки переполнения. Подобные ситуации называются колли­
зиями. Значения ключей, которые имеют одно и то же значение хешфункции, называются синонимами.
Главным ограничением этого метода является фиксированный размер таб­
лицы. Если таблица заполнена слишком сильно или переполнена, то возни­

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

Рассмотрим некоторые достаточно распространенные стратегии разрешения
коллизий.
Метод последовательного перебора

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

При выборе этой стратегии область хранения разбивается на две части:
□ основную область;
О область переполнения.
Для каждой новой записи вычисляется значение хеш-функции, которое оп­
ределяет адрес ее расположения, и запись заносится в основную область
в соответствии с полученным значением хеш-функции.
Если вновь заносимая запись имеет значение функции хеширования, такое
же, которое использовала другая запись, уже имеющаяся в БД, то новая
запись заносится в область переполнения на первое свободное место, а
в записи-синониме, которая находится в основной области, делается ссылка
на адрес вновь размещенной записи в области переполнения. Если же уже
существует ссылка в записи-синониме, которая расположена в основной об­
ласти, то тогда новая запись располагается всегда на втором месте в цепочке
синонимов, что существенно сокращает время размещения новой записи. При
таком алгоритме время размещения любой новой записи составляет не более
двух обращений к диску с учетом того, что номер первой свободной записи
в области переполнения хранится в виде системной переменной.

Рассмотрим теперь механизмы поиска произвольной записи и удаления за­
писи для этой стратегии хеширования.
При поиске записи также сначала вычисляется значение' ее хеш-функции и
считывается первая запись в цепочке синонимов, которая расположена в ос­
новной области. Если искомая запись не соответствует первой в цепочке си­
нонимов, то далее поиск происходит перемещением по цепочке синонимов,
пока не будет обнаружена требуемая запись. Скорость поиска зависит от
длины цепочки синонимов, поэтому качество хеш-функции определяется
максимальной длиной цепочки синонимов. Хорошим результатом может
считаться наличие не более 10 синонимов в цепочке.
При удалении произвольной записи сначала определяется ее место распо­
ложения. Если удаляемой является первая запись в цепочке синонимов, то
после удаления на ее место в основной области заносится вторая запись
в цепочке синонимов, при этом все ссылки на синонимы сохраняются.
Если же удаляемая запись находится в середине цепочки синонимов, то не­
обходимо провести корректировку указателей: в записи, предшествующей
удаляемой, в цепочке ставится указатель из удаляемой записи. Если это по­
следняя запись в цепочке, то все равно механизм изменения указателей та­
кой же, то есть в предшествующую запись заносится признак отсутствия
следующей записи в цепочке, который ранее хранился в последней записи.
Организация стратегии свободного замещения

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

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

7.1.5. Индексирование
Хотя технология хеширования и может дать высокую эффективность, но для
ее реализации не всегда удается найти соответствующую функцию, поэтому
при организации доступа к данным широко используются индексные файлы.
Основное назначение индексов состоит в обеспечении эффективного прямого
доступа к записи таблицы по ключу. Различают индексированный файл и ин­
дексный файл (рис. 7.7). Индексированный файл — это основной файл, со­
держащий данные отношения, для которого создан индексный файл.
Индекс
Английский
математика
математике
физика
физика

- ...►

1
2
3
4
5

Основной файл
математика
Иванов А.Л.
Андоеев С.И. английский
Сидоров П.А. физика
Тимофеев А.С математика
Лисов П.А.__ физика

. . .

Рис. 7 .7 . Индексированный и индексный файлы

Индексный файл — это файл особого типа, в котором каждая запись состоит
из двух значений: данных и указателя. Данные представляют поле, по кото­
рому производится индексирование, а указатель осуществляет связывание с
соответствующим кортежем индексированного файла. Если индексирование
осуществляется по ключевому полю, то индекс называется первичным. Такой
индекс к тому же обладает свойством уникальности, т. е. не содержит дуб­
ликатов ключа.
Обычно индекс определяется для одного отношения, и ключом является
значение простого или составного атрибута.
Основное преимущество использования индексов заключается в значитель­
ном ускорении процесса выборки данных, а основной недостаток — в за­
медлении процесса обновления данных. Действительно, при каждом добав­
лении новой записи в индексированный файл потребуется также добавить
новый индекс (а это дополнительное время) в индексный файл. Поэтому
при выборе поля индексирования всегда важно уточнить, который из двух
показателей важнее: скорость выборки или скорость обновления.

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

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

Операция добавления осуществляет запись в конец основной области. В ин­
дексной области при этом производится занесение информации так, чтобы
не нарушать упорядоченности. Поэтому вся индексная область файла разби­
вается на блоки и при начальном заполнении в каждом блоке остается сво­
бодная область (процент расширения) (рис. 7.8).
Индексная область
Ключ

Основная область

Ссылки на номер записи

02-КТ

4

1

07-КТ

Иванов АН.

0 3-К Г

11

2

10-К Г

Тарасов В.И.

04 - КТ

5

3

2 5 -КТ

Березин Ф.М.

->

4

02-КТ

Дубов Т.П.

->

5

04 - ЮГ

Петров С.К.

6

1 5 -КТ

Лескова К.Н.

7

20-КТ

Лукин СА

8

16-КТ

Егоров .Н.П.

9

08-КТ

Козлов В.О.

10

14-КТ

Степанов АВ.

11

03-КГ

Кустов В.Т.

12

0 5 -КТ

Коробков Ю.Т.

13

09 - КТ

Уварова М.С.

Блок 1 —

/ / / / / /
05-КТ

12

06-КТ

8

07-КТ

1

Свободна?

Блок 2 -

/ / / / / /
08-КТ

9

09-К Г

13

10-КТ

2

БлокЗ—

./// / / /

Свободная

Рис. 7.8. Организация индексно-прямой адресации

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

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

Если файлы поддерживаются в отсортированном состоянии с момента их
создания, то для работы с ними может быть использован другой подход
с технологией построения индексного файла, несколько отличной от выше­
рассмотренной. Принципы внутреннего упорядочения и блочности по­
строения таких файлов позволяют уменьшить количество хранимых индек­
сов за счет того, что в индексном файле не содержатся указатели на все
записи индексированного файла. Таким образом, в этом случае индекс по­
лучается неплотным или разреженным.
Одним из преимуществ неплотных индексов является их малый размер по
сравнению с плотными индексами, так как они содержат меньшее число
записей. Это позволяет просматривать содержимое базы данных с большей
скоростью.
Индексная запись для таких файлов должна содержать: значение ключа пер­
вой записи блока и номер блока с этой записью.
Теперь по заданному значению первичного ключа в индексной области тре­
буется отыскать уже нужный блок. Так как все записи упорядочены, то зна­
чение первой записи блока позволяет быстро определить, в каком блоке на­
ходится искомая запись. Все остальные действия происходят в основной
области (рис. 7.9). При переходе к неплотному индексу время доступа
уменьшается практически в полтора раза.
При таком подходе новая запись должна заноситься сразу в требуемый блок
на требуемое место. Данное занесение осуществляется в оперативной памя­
ти, куда считывается блок основной памяти, который вследствие упорядо­
ченности записей по значению ключа должен принять эту запись. Содержи­
мое считанного блока корректируется, и затем он снова записывается на
диск на старое место. Естественно, что для добавления записей уже блок
основной области должен иметь свободное место. При внесении новой
записи индексная область не корректируется.

Индексная область

Основная область

1ПП
Блок 1

7 /7 7 7 7 7 / / / / /
200

Свободное
пространство
Блок 2

J Свободное
/ / / / / / / У 7777 пространство
300

ZZZZ 7 7 7 7 / 7 / 7

БлокЗ
- Свободное
пространство

Рис. 7.9. Организация индексно-последовательной адресации

Уничтожение записи происходит путем ее физического удаления из основ­
ной области, при этом индексная область обычно не корректируется, даже
если удаляется первая запись блока.
Однако следует отметить:
□ с помощью одного неплотного индекса нельзя выполнить проверку на­
личия некоторого значения;
□ в данном хранимом файле может быть, по крайней мере, один неплот­
ный индекс, который организуется по полю, по которому этот файл от­
сортирован, а остальные индексы обязательно должны быть плотными.

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

Записи внутри индекса сгруппированы по страницам, а страницы связаны
в цепочку таким образом, чтобы логическое упорядочение на основе индек­
са осуществлялось внутри первой страницы, затем с помощью физической
последовательности записей внутри второй страницы этой последовательной
цепочки и т. д. Таким образом, с помощью набора последовательностей
можно организовать быстрый последовательный доступ к индексированным
данным.
Потом снова над новым индексом строится следующий неплотный индекс
и так до того момента, пока не останется всего один индексный блок. Эта
операция обычно применяется трижды, поскольку создание большого коли­
чества иерархических уровней индексирования требуется для очень больших
файлов. При этом индекс на каждом из уровней будет неплотным по отно­
шению к нижнему индексируемому уровню. Таким образом, на самом верх­
нем уровне такого индекса находится только один элемент структуры (стра­
ница, содержащая множество записей), который называется корневым.
Набор индексов обеспечивает быстрый непосредственный доступ к набору
последовательностей (а значит, и к данным).
В результате такого построения получится некоторое дерево (рис. 7.10), ка­
ждый родительский блок которого связан с одинаковым количеством под­
чиненных блоков, число которых равно числу индексных записей, разме­
щаемых в одном блоке. Количество обращений к диску при этом для поиска
любой записи одинаково и равно количеству уровней в построенном дереве.
Такие деревья называются сбалансированными потому, что путь от корня до
любого листа в этом древе одинаков.
4-й уровень
Неплотный
индекс
3:й уровень

--------1----------------------------------------- 1---------

—'

■

...........I.......

-

J -

r

г

Неплотный
индекс
2-й уровень

—
I-----------..................L............ ..............

■

L

(

Основной файл — 1-й уровень
Рис. 7.10. Б-дерево

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

Структуры типа Б-дерева позволяют, используя специальные, алгоритмы,
осуществлять сбалансированную вставку или удаление значений. К. Дж. Дейт
приводит такой краткий алгоритм вставки нового значения V в структуру
типа Б-дерева порядка п. Он рассчитан на вставку значения только лишь
в набор индексов, но может быть достаточно просто расширен для вставки
записи с данными в набор последовательностей.
□ На самом низком уровне набора индексов следует найти элемент (допус­
тим, что это элемент N), с которым логически связано вставляемое зна­
чение V. Если элемент N содержит свободное пространство, то значение
V вставляется в него, и на этом процесс завершается.
□ В противном случае (если свободного пространства нет, т. е. придется
создать еще один уровень) элемент N (допустим, что он содержит 2п ин­
дексных записей) разделяется на два элемента - М и N2. Обозначим
символом S множество из 2я + 1 значений, в котором 2л исходных зна­
чений и одно новое значение К Тогда п первых значений этой логиче­
ской (уже упорядоченной) последовательности необходимо поместить
в элемент N1, п последних — в элемент N2, а среднее между ними значе­
ние W — в родительский элемент Р на более высоком структурном уров­
не. Впоследствии, при осуществлении поиска значения U и достижении
элемента Р, поиск будет перенаправлен в сторону элемента М , если
U<W, либо в сторону элемента N2, если U> W.
□ Далее этот процесс следует повторить для вставки среднего значения W
в родительский элемент Р на более высоком структурном уровне.
В худшем случае процесс разделения элементов структуры может продлить­
ся вплоть до корневого элемента всей структуры с образованием нового ие­
рархического уровня.
Для удаления некоторого значения следует применить аналогичный алго­
ритм, но только в обратном порядке. А для изменения значения его можно
удалить, а затем вставить новое.

7.1.7. Моделирование отношений "один ко многим"
Как было показано в главе 6, при переходе к реляционной схеме базы дан­
ных каждый из компонентов ее концептуальной модели должен быть про­
анализирован и, если это окажется необходимым, то даже и преобразован.
Изменения, вносимые в процессе преобразования, должны быть такими,
чтобы их результат полностью отвечал требованиям, выдвигаемым реляци­
онной моделью данных. Если в модели присутствуют такие нежелательные
структуры, как связи типа "многие ко многим", сложные связи, рекурсивные
связи, связи с атрибутами, множественные атрибуты, избыточные связи, то
они должны быть исключены путем тождественной их замены на структуры
данных, допустимые для логической модели.

После подобных преобразований наиболее сложным для моделирования
компонентом остается структура 1 : М ("один ко многим"). Для моделирова­
ния такой структуры используется принцип организации цепочек записей
внутри файла и ссылки на номера записей для нескольких взаимосвязанных
файлов.
В этом случае из двух связываемых файлов один файл, например /1 (со сто­
роны связи "один") называется "основным", а файл F1 (со стороны "много”) —
"подчиненным" Каждая запись основного файла должна иметь следующую
структуру:
□ ключ;
□ запись;
□ ссылку-указатель на первую запись в "подчиненном" файле, с которой
начинается цепочка записей файла F1, связанных с данной записью
файла Я .
Каждая запись в подчиненном файле, помимо основной информации,
должна содержать специальный указатель, в котором хранится номер запи­
си, являющейся следующей в цепочке записей "подчиненного" файла, свя­
занной с одной записью "основного" файла.
Таким образом, каждая запись "подчиненного файла" делится на две облас­
ти: область указателя и область, содержащую собственно запись.
Поиск записи в "основном" файле осуществляется в соответствии с его орга­
низацией. Если указатель в основном файле пустой, то это означает, что для
этой записи нет ни одной связанной с ней записи в "подчиненном файле"
Если же указатель в найденной записи основного файла присутствует, то
производится переход прямым методом доступа по номеру записи на пер­
вую запись в цепочке "подчиненного" файла, а затем проход далее по це­
почке, пока искомая запись не будет найдена. Если конец цепочки достиг­
нут, а запись не найдена, то, следовательно, поиск прекращается.
Использование цепочек записей позволяет эффективно организовывать мо­
дификацию взаимосвязанных файлов.
Для удаления записи из цепочки "подчиненного" файла необходимо найти
удаляемую запись в соответствии с ранее рассмотренным алгоритмом. При
проходе по цепочке в специальных переменных обязательно сохраняются но­
мер предыдущей записи в цепочке (А) и указатель на следующую запись
в найденной записи (Б). Если запись найдена, то она помечается некоторым
символом, означающим, что запись отсутствует, а место в файле свободно и
может быть занято любой другой записью. При этом в записи, номер которой
хранится в переменной А, заменяется указатель на содержимое переменной В.
Для добавления новой записи в "подчиненный файл" требуется найти первое
свободное место, т. е. запись, помеченную специальным символом, и на ее
место занести новую запись, изменив значения соответствующих указателей.

7.1.8. Инвертированные списки
Базы данных должны предоставлять возможность проводить операции дос­
тупа к данным не только по первичным, но и по вторичным ключам. Для
обеспечения ускорения доступа по вторичным ключам используются струк­
туры, называемые инвертированными списками.
При организации инвертированного списка можно выделить три уровня
(рис. 7.11).
Уровень I

Уровень II

Рис.7.11. Уровни инвертированного списка

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

□ На втором уровне для каждого значения вторичного ключа строится це­
почка блоков, содержащих номера записей основного файла с этим зна­
чением вторичного ключа. Адрес первого блока такой цепочки и поме­
щается в поле ссылки первого уровня. При этом блоки второго уровня
также упорядочены по значёниям вторичного ключа.
Механизм доступа к записям по вторичному ключу при подобной организа­
ции записей состоит в следующем:
□ найти в области первого уровня заданное значение вторичного ключа;
□ по ссылке считать блоки второго уровня, содержащие номера записей
с заданным значением вторичного ключа;
□ прямым доступом загрузить в рабочую область пользователя содержимое
всех записей, содержащих заданное значение вторичного ключа.
Для одного основного файла может быть создано несколько инвертирован­
ных списков по разным вторичным ключам.
•Естественно, что описанная структура организации индекса по вторичным
ключам достаточно эффективна, но эффективность ее проявляется тогда,
когда не требуется осуществлять перестройку индексной структуры, напри­
мер при поиске информации в стабильной, мало подверженной изменениям
базе данных. Если же база данных постоянно изменяется, дополняется, мо­
дифицируется содержимое записей, то наличие большого количества инвер­
тированных списков или индексных файлов по вторичным ключам может
резко замедлить процесс обработки информации.
Действительно, модификация основного файла в такой ситуации требует:
□ изменить запись основного файла;
□ исключить старую ссылку на предыдущее значение вторичного ключа;
□ добавить новую ссылку на новое значение вторичного ключа.
Ясно, что такой процесс требует гораздо больше временных затрат, чем про­
сто изменение содержимого записи основного файла без поддержки всех
инвертированных списков.
Таким образом, можно придерживаться следующей позиции: если база дан­
ных достаточно стабильна и ее содержимое практически не меняется, то
построение вторичных индексов действительно может ускорить процесс об­
работки информации.

7.2. Технологии хранения данных
в MS SQL Server
Фундаментальной единицей хранения данных в Microsoft SQL Server являет­
ся страница. Страница в виртуальной системе хранения данных — блок
фиксированного объема, содержащий виртуальные адреса, копируемые как

целое из оперативной памяти на диск и обратно во время работы. Базы дан­
ных SQL Server физически располагаются в страницах. Размер страницы
данных SQL Server — 8 Кбайт. Это означает, что на 1 Мбайт дискового про­
странства приходится 128 страниц.

7.2.1. Формат страницы SQL Server
Началом страницы является заголовок длиной 96 байт, в котором хранится
системная информация, такая как тип страницы, количество свободного
места на странице, и идентификатор объекта (ID), которому принадлежит
эта страница.
Существует несколько типов страниц файлов данных баз SQL Server (табл. 7.1).
Таблица 7.1. Типы страниц SQL Server
Тип страницы

Содержимое

Data (Данные)

Строки данных, содержащие любые типы, кроме text,
ntext и image

Index (Индекс)

Данные о структуре индексов

Text/lmage (Текст/Рисунок)

Text, ntext и image

Глобальная карта разме­
щения, вторичная глобаль­
ная карта размещения

Информация о занятых экстентах

Свободное место страниц

Информация о доступном свободном месте страниц

Карта размещения индек­
сов

Информация об экстентах, занимаемых индексами

Карта изменения объема

Информация об экстентах, модифицированных в ре­
зультате увеличения баз с момента последней отмет­
ки о восстановлении журнала транзакций

Карта дифференциальных
изменений

Информация об экстентах, измененных с момента
последней отметки о восстановлении базы данных.

Файлы журналов (LOG files) не содержат страниц. Они состоят из обычных
последовательных записей.
Страницы типа data (данные) содержат все записи (строки таблиц) таблиц,
кроме полей типа text, ntext и image, для которых выделен отдельный тип
страниц. Записи располагаются последовательно на странице, сразу за заго­
ловком. В самом конце страницы расположена область, в которой хранится
информация о физическом расположении каждой записи. Она содержит
запись для каждой строки, указывающую, на сколько удален первый байт
записи от начала страницы.

Заголовок

л

Строка данных
Строка данных
Строка данных

Свободное место

3

!2

11 Данные о
записях

Рис. 7.12. Страница данных

Одна запись не может принадлежать более чем одной странице. Этим объ­
ясняется ограничение на ее размер — 8 060 байт. Это не относится к дан­
ным типа text, ntext, image, так как физически они хранятся отдельно.
То есть размер записи вычисляется без учета полей этих типов.
Экстенты — основная единица хранения объектов в SQL Server 2000. Экс­
тент — участок дискового пространства, занятый каким-либо объектом базы
данных (таблицей, индексом и т. п.). Экстент — это восемь последователь­
ных страниц, или 64 Кбайта. На один Мбайт дискового пространства при­
ходится до 16 экстентов.
В SQL Server 2000 существует два типа экстентов:
□ Однородные (uniform) экстенты принадлежат одному объекту. Все восемь
страниц в них могут быть использованы только этим объектом.
□ Смешанные (mixed) экстенты могут быть разделены между восьмью раз­
личными объектами каждый.
Новые таблицы или индексы обычно располагаются в смешанных экстен­
тах. Как только объект вырастает до размеров в восемь страниц, он преобра­
зуется к однородным экстентам. Если сразу после создания объект имеет
более восьми страниц, то все его экстенты однородны.
В представлении операционной системы вся информация Microsoft SQL
Server 2000 хранится в файлах. Данные объектов и журналы (LOG-файлы)
никогда не пересекаются в одном файле, и каждый отдельный файл при­
надлежит не более чем одной базе данных.
Базы данных SQL Server 2000 состоят из трех типов файлов:
□ Первичные файлы данных. Эти файлы составляют основу базы данных.
В них содержатся и пути к вторичным файлам. Каждая база данных име­
ет только один первичный файл. Рекомендуемое расширение для пер­
вичного файла — .mdf.

□ Вторичные файлы данных. В этих файлах содержится вся информация,
которую по каким-либо причинам было решено хранить отдельно. База
данных может и не иметь таких файлов. Рекомендуемое расширение для
них — .ndf.
□ Файлы журналов транзакций. В этих файлах содержится информация обо
всех изменениях в базе данных, тексты всех выполненных команд. Она
необходима при восстановлении баз данных. Для каждой базы обязатель­
но должен существовать хотя бы один файл журнала транзакций (хотя их
может быть и несколько). Рекомендуемое расширение — .ldf.
Смешанный экстент

А

А
Таблица
1

Индекс 1

Индекс 2

—
Индекс 1

Таблица
3

а------------ А------------ А----------Индекс 2

Индекс 2

Таблица
3

Однородный экстент

А
Таблица
1

А
Таблица
1

А
Таблица
1

А
Таблица
1

А
Таблица
1

А
Таблица
1

Таблица
1

А
Таблица
1

Рис. 7 . 1 3 . Однородный и смешанный экстенты

Приведенные выше расширения типов файлов не являются обязательными
для SQL Server, и система никак к ним не привязана. При необходимости
системный администратор может использовать любые расширения, какие
сочтет необходимым.
Расположение всех файлов каждой базы данных хранится в системной базе
данных master, кроме того, информация о вторичных файлах и журналах
транзакций содержится и в первичных файлах базы. SQL Server преимуще­
ственно полагается на базу master. Однако в следующих случаях происходит
обращение к первичным файлам:
□ П р и ИСПОЛЬЗОВанИИ Х ранимой П роцедуры s p _ a tta c h _ d b .

□ При обновлении SQL Server с версии 7.0 до SQL Server 2000.
□ При восстановлении базы данных master.
Каждый файл SQL Server имеет два имени.
□ Логическое имя файла (logicalJilejiame) — имя, используемое при обра­
щении к нему с помощью любых запросов Т-SQL. Оно должно подчи­
няться правилам присвоения имен SQL и быть уникальным для одной
системы SQL Server.

□ Имя операционной системы (osJïle name) — имя физического файла на
диске. Оно должно подчиняться правилам присвоения имен используе­
мой операционной системы.
Приведем пример именования логических и физических файлов SQL Server 2000
под управлением операционной системы Windows 2000 Datacenter Server
(рис. 7.14).
MyDB_primaiy
c:\Progiam Files\M icrosof t SQL Seivei\M SSQ L\D ala\M yD ata1 .mdf
Первичный файл данных

MyDB.secondary1
c:\Program Files\M icrosof t SQL Server\MSSQL\Data\MyData2.ndf
Вторичный файл данных

MyD B_secondary2
c:\Program File$\Microsoft SQL Server\MSSQL\Data\MyData3.ndf
Вторичный файл данных

MyDBJogl
c:\Program Files\M icrosof f SQL Server\MSSQL\Dala\MyLog4.ldf

Журнал транэага^й
MyDB_log2
cAProgram Files\Microsoft SQL Server\MSSQL\Data\MyLog5.ldf

Журнал транзакций
Рис. 7.14. Именование файлов

Файлы баз данных могут располагаться на носителях с файловыми система­
ми NTFS или FAT. Однако диск не должен быть "уплотнен" какой-либо
системой сжатия данных.
Все страницы SQL Server 2000 пронумерованы по возрастанию, начиная
с нулевой. Кроме страниц нумеруются и файлы. Уникальность каждой стра­
ницы обеспечивается сочетанием <номер_файпа-номер_страницы>.
Первая страница любого файла является его заголовком и содержит инфор­
мацию о его свойствах. Несколько следующих страниц содержат системные
данные, такие как карты расположения. Файлы баз данных SQL Server ав­
томатически растут, начиная с указанного при создании начального разме­
ра. Однако этот процесс не начнется до тех пор, пока реально хранимая
информация не достигнет этого размера. Кроме того, при создании базы
данных можно указать ее максимальный объем. Если этого не сделать, база
данных будет разрастаться до максимально возможного объема, определяе­
мого характеристиками носителя.

Вопросы и упражнения
1. Какие разновидности объектов базы данных для поддержки функциони­
рования СУБД необходимо хранить во внешней памяти?
2. Дайте характеристику страничной организации данных в СУБД.
3. Как осуществляется хранение таблиц при страничной организации дан­
ных в СУБД?
4. Что собой представляет технология хеширования, и для чего она ис­
пользуется в структурах хранения баз данных?
5. Какие ситуации называются коллизиями? Поясните некоторые доста­
точно распространенные стратегии разрешения коллизий.
6. В чем состоит основное назначение индексов?
7. Какой индекс называется плотным? Поясните методологии поиска,
вставки и удаления элемента основного файла при такой организации
индекса.
8. Опишите технологию создания неплотного индекса и использования его
при поиске, вставке и удалении элемента.
9. Чем обеспечивается высокая производительность бинарных индексов?
Поясните методологию получения Б-дерева.
10. Каким образом осуществляется моделирование такого компонента кон­
цептуальной модели, как структура "1 : М"?
11. Для чего строятся инвертированные списки? Какие три уровня можно
выделить при организации инвертированного списка?
12. Дайте характеристику технологии хранения данных в MS SQL Server.
13. Создайте концептуальную модель небольшой базы данных (четыре-пять
объектов). Для некоторого пробного набора данных продумайте структу­
ры хранения и объясните свой выбор.

ssssss
Глава 8

Управление
реляционной базой данных
Для управления реляционной базой данных Э. Ф. Кодц ввел реляционные
языки обработки данных — реляционную алгебру и реляционное исчисле­
ние. Появление реляционных языков дополнительно к реляционной моде­
ли, которая сама по себе имела, безусловно, большое значение, явилось
серьезным основанием для реляционной революции в области баз данных.
Реляционные языки, позволяя манипулировать данными на основе только
их логических характеристик, заняли одно из важнейших мест новой моде­
ли. В этом разделе пособия будут рассмотрены оба предложенных Коддом
языка манипулирования данными: реляционная алгебра и реляционное ис­
числение.
Реляционная алгебра — это процедурный язык обработки реляционных таб­
лиц. Это означает, что в реляционной алгебре используется пошаговый под­
ход к созданию реляционных таблиц, содержащих ответы на запросы.
Большое внимание, проявляемое к реляционной алгебре, обусловлено тем,
что она породила многие термины, часто встречающиеся в коммерческих
языках баз данных. Более того, некоторые коммерческие языки баз данных
основаны на реляционной алгебре.
Реляционное исчисление — непроцедурный язык. В реляционном исчислении
запрос создается путем определения таблицы запроса за один шаг.
Большое значение реляционного исчисления обусловлено двумя причинами:
□ оно основано на исчислении предикатов формальной логики, которая
является эффективным методом определения истинности высказывания
на основе истинности его компонентов. Следовательно, реляционное ис­
числение имеет столь же твердую логическую основу, что и любой суще­
ствующий язык программирования;
□ реляционное исчисление лежит в основе некоторых коммерческих реля­
ционных языков.
Кодд показал логическую эквивалентность реляционной алгебры и реляцион­
ного исчисления. Это означает, что любой запрос, который можно сформули­
ровать при помощи реляционного исчисления, также можно сформулировать,

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

8.1. Реляционная алгебра
В пятой главе были определены основные операции по обновлению инфор­
мации в реляционной базе данных. Данные операции обновления — это
операции не над отношениями, а над кортежами отношения. В этом же раз­
деле будут обсуждены операторы, применяемые к целым отношениям. Опе­
раторы реляционной алгебры используют одно или два из существующих
отношений для создания нового отношения, которое затем может быть ис­
пользовано в качестве операнда для нового оператора. Ценность поэтапного
создания новых отношений на основе старых трудно переоценить, посколь­
ку оно предоставляет пользователю широчайшие возможности для выпол­
нения множества операций обработки данных. Оно также чрезвычайно уп­
рощает создание запросов, поскольку позволяет экспериментировать до тех
пор, пока не будет найден подходящий способ решения.
Напомним, что алгеброй называется множество объектов с заданной на нем
совокупностью операций, замкнутых относительно этого множества. Реля­
ционная алгебра (или алгебра отношений) представляет собой совокупность
операций высокого уровня над отношениями. Реляционная алгебра опреде­
ляет следующие операции:
□ объединение;
□ пересечение;
□ разность;
□ произведение;
□ выбор;
□ создание проекций;
□ соединение;
□ деление.
Первые четыре операции взяты Коддом из математической теории множеств
и практически совпадают с операциями теории множеств. Правомерность
подобных действий основана на том факте, что, поскольку реляционные

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

8.1.1. Основные операции
реляционной алгебры
Два отношения с одной и той же схемой могут быть рассмотрены как мно­
жества одного и того же универсума — множество всех возможных кортежей
с этой схемой. К таким двум отношениям могут быть применены булевы
операции. К основным операциям относятся следующие булевы операции:
объединение, разность, декартово произведение.
Объединение (Union)

Пусть имеются отношения
динением
ги
или s, или им обоим.

ги
s,если каждый кортеж, принадлежащий

принадлеж

Пример 1
Пусть имеются следующие экземпляры отношений
ковые схемы:
S

А

В

С

D

Е

F

Р

1

а

0

3

а

Р

2

b

Q

2

с

Q

2

С

и

имеющих одина­

Тогда
t - ги
А

в

С

Р

1

а

Р

2

b

Q

2

С

Q

3

а

Пример 2

Пусть даны отношения:
г — Изделие 1

s — Изделие 2

К од _ дет

Н азв ан и е

В ес

Код__дет

Н азван и е

Вес

01

А
В
С

1

02

Д

2

03

03

2

04

В

3

с

04

2
3

Необходимо сформировать ответ на следующий запрос: какие типы деталей
входят в состав обоих изделий? Для достижения этой цели необходимо
выполнить операцию
t= гu
s.Результи
детали, которые входят в состав обоих изделий.
t
К од_дет

Н азвани е

Вес

01

А

1

02

д

2

03

В
С

2

04

3

Разность

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

s —г

r —s
А

В

С

А

В

с

Р

1

а

Q

3

а

Р

2

b

Пусть отношение г представляет потребности в некоторых видах деталей,
а отношение s — сведения о тех видах деталей, которые фирма может про­
извести сама, тогда отношение t= г — s содержит сведения о тех видах дета­
лей, которые нужно приобрести.
г - ПОТРЕБНОСТИ
s - ВОЗМОЖНОСТИ
Код_дет

Название

Вес

01

А

1

02

Д

2

02

д

2

03

В

2

03

В

04

с

3

04

С
Е

Код_дет Название

2

Вес

3

1

05

t — г —s
Код_лет
01
05

Название
А
Е

Вес
1
1

Декартово произведение

В рамках реляционной алгебры определена и такая теоретико-множествен­
ная операция, как расширенное декартово произведение. Эта операция не
накладывает никаких ограничений на схемы исходных отношений, и поэто­
му она допустима для любых двух отношений.
Под декартовым произведением двух отношений понимается множество упо­
рядоченных пар кортежей. Пусть имеются два отношения и тогда отно­
шение
t=
г *5-арности
k=
называется декартовым произведением r u s , если оно состоит из кортежей,
первые к\ компонентов которых образуют кортежи из г, а остальные kj — из 5.
Как видим, выполнение данной операции, в отличие от других уже рассмот­
ренных операций, приводит к тому, что степень результирующего отноше­
ния не совпадает со степенью ни одного из операндов, а равна сумме степе­
ней исходных отношений.

г* s
А

В

С

D

Е

F

Р

1

а

Q

2

С

Р

1

а

Q

3

а

Р

2

b

Q

2

с

Р

2

b

Q

3

а

Q

2

С

Q

2

с

Q

2

С

Q

3

а

Относительно влияния перестановки операндов на результат операции де­
картово произведение можно считать симметричной операцией. Данная
операция используется в тех ситуациях, когда необходимо получить отно­
шение, содержащее все возможные комбинации между элементами исход­
ных отношений.
Рассмотрим некоторый пример.
Пусть г СТУДЕНТЫ (Ном_зач_кн, ФИО);
s —> ЭКЗАМЕНЫ (Код_дисц, Назв_дисц, Дата, Оценка),
тогда г* s
ЭКЗАМ_ВЕД (Ном_зач_кн, ФИО, Код_дисц,
Назв_лисц, Дата, Оценка).
г - СТУДЕНТЫ
Номер
зач_книжки
02-Э-01
02-Э-02
02-Э-05

ФИО

s- ЭКЗАМЕНЫ
Кодлисц

Назв_ушсц

Дата

Иванов И.И.

01

Математика

10.01.03

Петров Т.Т.

02

Физика

Серов С.С.

03

Ин. язык

15.01.03
20.01.03

Оценка

! - ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ ПО ВСЕМ ДИСЦИПЛИНАМ
Номер
зачкнижки

ФИО

02-Э-01

Иванов И.И.

02-Э-01

Иванов И.И.

02-Э-01

Иванов И.И.

02-Э-02

Петров Т.Т.

Код_
дисц
01
02
03
01

Название_дисц

Дата

Математика

10.01.03

Физика

15.01.03

Ин. язык
Математика

20.01.03
10.01.03

Оценка

(iокончание)
02-Э-02

Петров Т.Т.

02

Физика

15.01.03

02-Э-02

Петров Т.Т.

03

Ин. язык

20.01.03

02-Э-05

Серов С.С.

01

Математика

10.01.03

02-Э-05

Серов С.С.

02

Физика

15.01.03

02-Э-05

Серов С.С.

03

Ин. язык

20.01.03

Были рассмотрены некоторые булевы бинарные операции.
Унарные операции Проекция и Выбор также являются основными, но это
уже не булевы операции. Они были введены специально в состав операций
реляционной модели данных.
Проекция (Project)

Оператор проекции (вертикальное подмножество) является унарным опера­
тором на отношениях. Он осуществляет выбор на множестве столбцов.
Пусть в отношении г выделено некоторое множество атрибутов Y, тогда от­
ношение t = Ру (г) называется проекцией отношения г, если оно является
вертикальным подмножеством столбцов отношения г из множества R.
PAdr)

РеЛ г)
Е

F

3

а

2

с

Иными словами, проекция
Rн
а
черкиванием столбцов, соответствующих атрибутам — У, и исключением,
по определению отношения, из оставшихся столбцов повторяющихся строк.
Операция проектирования чаще всего употребляется как промежуточная
операция при выполнении операции выбора, которая рассматривается далее.
Выбор (Select)

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

Итак, результатом селекции отношения г по некоторому ©будем считать
отношение t = 50 (г), которое включает в себя кортежи отношения г, удов­
летворяющие указанному условию 0.
Условие 0 — это формула, по которой определяется выборка. Операндами
в такой формуле являются атрибуты отношения, а знаками операций — ло­
гические операции и операции отношений.

5

8 A*qI\B > 1(г)

С *Ь (

А

в

С

А

В

С

Р

I

а

Р

2

b

Q

2

с

8.1.2. Дополнительные операции
реляционной алгебры
Состав операций реляционной алгебры является избыточным, поскольку
некоторые из них могут быть получены через остальные операции с исполь­
зованием определенных соотношений. Но Кода сознательно ввел эту избы­
точность в свою алгебру, учитывая то, что эти соотношения не так уж просты
и их использование, как правило, довольно-таки усложняет реляционные
выражения.
Итак, к дополнительным операциям относятся те операции реляционной
алгебры, которые можно выражать через основные операции.

Пересечение

Это четвертая булева бинарная операция над отношениями. Пусть имеются
два отношения
ги
s,тогда отношение =
на
если каждый кортеж, принадлежащий t, одновременно принадлежит г и б .
Операция применяется к отношениям одной арности. Справедлива следую­
щая формула:
t = г n s = г —(г —П
.)s рименительно к отношениям г и
лучим:
t — г ns .
А

в

С

Q

2

С

Рассмотрим пример использования операции пересечения. Пусть имеются
отношения:
5 - ИЗДЕЛИЕ 2

г - ИЗДЕЛИЕ 1
Код_дет

Название

Вес

Код_дет

Назваиие

Вес

01

А

1

02

д

2

2

04

с

3

2

03

в

2

06

к

Г

02
03
04

д

в
с
Е

05

3
1

Сформируем ответ на такой запрос: определить детали, входящие в состав
обоих изделий. Для этого необходимо выполнить операцию пересечения
двух исходных отношений. Результат представляется отношением:
t = г ns.
Код_дет

Название

Вес

02

Д

2

04

С

3

03

в

2

Е стественное со ед и н ен и е
Естественное соединение создает новое отношение из двух существующих.
Новое отношение формируется с помощью сцепления кортежей первого
отношения с кортежами второго отношения. При выполнении этой опера­
ции указывается, какой атрибут первого отношения, и какой атрибут вто­
рого отношения используются для сцепления кортежей.
Пусть даны отношения r(R) и s(S). Необходимо осуществить соединение
этих отношений, используя атрибут А отношения г и атрибут D отноше­
ния
S.

При таких условиях оператор выполняется следующим образом: создается
декартово произведение отношений г и
.sИз получ
чаются все кортежи кроме тех, в которых значение атрибута А и значение ат­
рибута D совпадают. В результате такого соединения получим новое отношение.

При этом в результирующее отношение равные атрибуты включаются толь­
ко один раз. Записывается этот оператор так:
г> s
A=D
А

в

С

Е

F

Q

2

С

3

а

Q

2

С

2

с

С о е д и н е н и е (Jo in )
Пусть имеются два отношения
г (X,
)Y
и (
X, Y, Z — непересекающиеся множества атрибутов и — множество атрибу­
тов, общих для
ги
,sтогда отношение
t-ry
0

4s

называется ©-соединением
ги
состоит из кортежей г H i, при выполненном условии 0. Справедлива сле­
дующая формула:
t = 8 ( г * s),

0
то есть ©-соединение представляет собой декартово произведение
над которым выполнена селекция по условию 0.

и

/•► 4 s

(В< Е) А (С # Ь)

А

в

С

D

Е

F

Р

1

а

Q

3

а

Р

1

а

Q

2

с

Q

2

с

Q

3

а

Например, из общей экзаменационной ведомости по всем дисциплинам по­
лучим экзаменационную ведомость по дисциплине математика. Для этого
выполним операцию соединение (Join) при условии Код^дисц = "01":

и

t - ЭКЗАМЕНАЦИОННАЯ ВЕДОМОСТЬ ПО ДИСЦИПЛИНЕ
МАТЕМАТИКА
Номер зам
книжки

ФИО

Код
дисц

Название
дисц

Дата

02-Э-01

Иванов И.И.

01

Математика

10.01.03

02-Э-02

Петров Т.Т.

01

Математика

10.01.03

02-Э-05

Серов С.С.

01

Математика

10.01.03

Оценка

Деление

Деление — это также бинарная несимметричная операция для получения
некоторого отношения из двух исходных, причем степень результирующего
отношения не совпадает со степенью ни одного из операндов, а вычисляет­
ся как разность между степенью отношения-делимого и степенью отноше­
ния-делителя.
Пусть имеются отношения r(X,
У)арности к\ и p(Z
определены на одном домене, тогда отношение
арности к\ - k l на­
зывается делением г на р, если любой кортеж из t вместе с любым кортежем
из р образуют кортеж, имеющийся в г.
Итак, к\ — арность г;
ki — арность р\
к = к\ — ikарность результирующего отношения.
Причем
к\> ki — всегда.

П р и м ер

Даны отношения, содержащие сведения об экзаменах, которые должны бы­
ли сдавать студенты, и сведения о результатах сдачи этих экзаменов:
VEDOM
RASP
Фамилия

Дисц_на

Дата

Дисц_на

Дата

02-Э-01

Иванов

Физика

10.01.03

Химия

14.01.03

02-Э-01

Иванов

Химия

14.01.03

Физика

10.01.03

02-Э-02

Сидоров

Физика

10.01.03

02-Э-02

Сидоров

Химия

14.01.03

02-Э-05

Коровин

Химия

14.01.03

Ном_зач_кн

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

STUD = VEDOM + RASP
Ном_зач_кн

Фамилия

02-Э-01

Иванов

02-Э-02

Сидоров

Каждый кортеж результата деления, сцепленный с любым кортежем делите­
ля, образует новый кортеж, который есть в делимом. Это же можно сказать
другими словами: в отношение t входят только те кортежи арности (£[ - kj),
декартово произведение которых с отношением р входит в г.
В процессе обсуждения материала, касающегося реляционной алгебры, для
иллюстрации изложения использовались примеры, предполагающие исполь­
зование простых выражений, содержащих только одну операцию.
Посмотрим, как работают операции реляционной алгебры для более слож­
ных ситуаций. Пусть сдача сессии моделируется следующим набором отно­
шений:
г—> СТУДЕНТЫ (Ном_зач_кн, ФИО, Группа);
s —> РЕЗУЛЬТАТЫ_СЕССИИ (Ном_зач_кн, ФИО, Назв_дисц, Оценка);
V—> ЭКЗАМЕНЫ (Группа, Назв_дисц).
Состав информации в отношениях довольно прозрачен:
г — содержит информацию о составе групп;
s — содержит сведения о результатах сдачи экзаменов;
V— включает список дисциплин, экзамены по которым надлежало сдавать
каждой группе.
Запрос 1 — получить список тех студентов, кто не явился на экзамен по фи­
зике, может быть реализован следующими выражениями:
□ операция проекции на атрибут ФИО результата выбора из отношения s
при условии Назв_дисц = "Физика" определит всех, кто сдавал экзамен
по физике:
□ w= .Рфио^деазв^исц = "Физика"] (5));
□ операция проекции на атрибут ФИО соединения отношений и v при
условии, что v.Назв_дисц = "Физика", определит всех, кто должен был
сдавать экзамен по физике:
□

р—

9 Зак. 3303

Рф т ( г

►

iv[у.Назв_дисц = "Физика'])-,

□ операция нахождения разности отношений р и w определит тех студен­
тов, кто не явился на экзамен по физике:
□ t = р — w.

8.2. Реляционное исчисление
Хотя реляционная алгебра и является основой нескольких языков запросов,
следует отметить, что большинство работающих языков запросов все-таки
основано на реляционном исчислении. Основной причиной такого положе­
ния является стремление пользователя, а значит, и разработчиков конкрет­
ных языков запросов по возможности облегчить процесс взаимодействия
с базой данных. Реляционная алгебра — процедурная система, а это значит,
что выражение реляционной алгебры задает набор операций над отноше­
ниями и порядок их выполнения. Реляционные исчисления — непроцедур­
ные системы. Исчисления выражают только то, каким должен быть резуль­
тат вычисления, но не то, каким образом проводить вычисления. Таким
образом, базирующиеся на непроцедурных системах языки запросов осво­
бождают пользователя от необходимости определять, как получить желае­
мый ответ, и пользователь может даже этого вовсе не знать. Эта обязанность
возлагается на процессор языка запросов данной СУБД.
Название реляционного исчисления происходит от исчисления предикатов
в математической логике. Различают реляционное исчисление кортежей и
реляционное исчисление доменов. Поскольку реляционное исчисление до­
менов сходно с реляционным исчислением кортежей за исключением того,
что переменные принимают значения в доменах, а не являются кортежами,
а исчисление кортежей используется чаще, в этом пособии рассматривается
только оно. В дальнейшем, когда речь будет идти о реляционном исчисле­
нии, будет подразумеваться именно реляционное исчисление кортежей.
В то время как реляционная алгебра использует в качестве операндов отно­
шения, реляционное исчисление кортежей строит свои выражения из кор­
тежей. Реляционное исчисление определяет результат запроса в виде реля­
ционного множества. Реляционное исчисление кортежей является, по сути,
формализацией системы обозначений, предназначенной для образования
множеств. В реляционном исчислении используются булевы операции
(И, ИЛИ, НЕ) над условиями, которые могут быть истинными или ложны­
ми. В нем также используются кванторы существования и всеобщности, оз­
начающие, соответственно, что элемент определенного типа существует или
что условие истинно для каждого элемента определенного типа.
Хотя в реляционном исчислении используется совершенно иной подход,
чем в реляционной алгебре, тем не менее эти два языка логически эквива­
лентны. Это означает, что любой запрос, который можно выполнить на од­
ном языке, можно сформулировать и выполнить на другом.

Рассмотрим отношение:
R — Деталь
Код_дет

Назв_дет

Вес

01

А

1

02

д

2

03

в
с

2

04

3

Запрос: Какие детали имеют вес, равный 2?
В реляционной алгебре для выполнения этого запроса необходимо исполь­
зовать алгебраическое выражение, которое должно содержать следующие
операции:
П операцию Выбор над отношением г; результатом ее применения к отно­
шению г является другое отношение, которое представляет собой под­
множество кортежей отношения г со значением, равным 2 в атрибуте Вес:
Код_дет

Назв_дет

Вес

02

Д

2

03
В
2
□ проецирование результата предыдущей операции на атрибут Назв_дет.
Окончательный результат запроса будет выглядеть следующим образом:
Назв_дет
Д

В
В реляционном же исчислении формулировка этого запроса должна иметь
следующий вид:
{ t.Ha3e_dem |

t in гand (.Вес =2},

где t — это переменная, обозначающая произвольную строку. Отношение, из
которого берется (, определяется выражением "t in г1', которое означает, что t
— строка отношения.
t.Ha3e_dem — значение атрибута Назв_дет в строке t; символ (|) — разделяет
целевой список и определяющее выражение. В данном случае:
(.Назв_дет— целевой список;
t in г and (.Вес = 2 — определяющее выражение;
(.Вес = 2 означает, что значение атрибута Вес в строке 1равно 2.

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

8.2.1. Целевой список
и определяющее выражение
Решением каждого запроса в реляционном исчислении является отношение,
которое задается целевым списком и определяющим выражением. Целевой
список определяет атрибуты отношения решения. Определяющее выраже­
ние — это условие, на основании которого отбираются значения из базы
данных, которые войдут в отношение решения.
В предыдущем примере целевой список содержит только
поэто­
му в данном случае отношение решения имеет только один атрибут. Легко
понять, как операция выбора и проецирования реляционной алгебры под­
держиваются в реляционном исчислении Действительные значения, входя­
щие в отношение решения, берутся из тех строк, которые удовлетворяют
определяющему выражению. В этом примере Назв^дет берется из строки и
помещается в строку решения, если строка удовлетворяет условию
t in г and t.Bec = 2.
Система просматривает строки отношения г одну за другой. Первой строке
временно присваивается имя t и проверяется истинность определяющего
выражения. Поскольку в этом случае t.Bec = 1, определяющее выражение,
ложно, поэтому А — значение атрибута г.Назв_^цет в этой строке не помеща­
ется в отношение решения. Затем система переходит к следующей строке,
дает ей имя t и снова проверяет истинность определяющего выражения.
На этот раз выражение истинно, поэтому Д помещается в отношение реше­
ния. Процесс повторяется для каждой строки отношения г. В результате по­
лучается следующее отношение, идентичное полученному ранее:
Назв_дет
Д

В
Вообще говоря, целевой список может состоять из нескольких атрибутов.
В списке можно перечислить даже все атрибуты, разделив их запятыми:
{t.Kodjdem, t.Назв_дет, t.Bec \t in г and t.Bec = 2}.
Более того, можно выбрать любое требуемое подмножество из этих атрибутов.

Рассмотрим еще один пример. Пусть даны отношения:
г - ИЗДЕЛИЕ 1

5 - ИЗДЕЛИЕ 2

Колщет

Название

01
02
03
04
05

А
Д
В
С
Е

Вес
1
2
2
3
1

Кодлет

Название

Вес

02
04
03
06

Д
С
в
к

2
3
2
1

Согласно алгебраическому выражению Р назв - е ( г n
реляционной алгеб­
ры, содержащему операции пересечения и проецирования, получим отно­
шение:
Название
Д
С
в
В реляционном же исчислении, если t кортеж г, а
может включать в себя следующие компоненты:

кортеж s, этот запрос

t.Ha3e_dem — целевой список;

t in г and
у in s and
t.Kodjdem= у. Код дет and t.Bec = у. В
у.Назв_дет — определяющее выражение.
В приведенном определяющем выражении для иллюстрации подробно пере­
числены все атрибуты обоих отношений. Однако следует отметить, что чаще
всего в этом нет необходимости, так как реляционное исчисление распола­
гает средствами для того, чтобы данное определяющее выражение могло
быть записано более компактно.
В только что рассмотренных примерах были использованы операции выбо­
ра, пересечения и проецирования реляционной алгебры. Аналогично можно
получить конструкции реляционного исчисления, соответствующие ряду
других операций: объединению, разности и произведению.
Несколько иначе выглядят аналоги только двух операций реляционной ал­
гебры — операций соединения и деления. Для построения аналогов этих
операций требуются кванторы: квантор существования для соединения и
квантор всеобщности для деления.

8.2.2. Формулы исчисления кортежей
Прежде чем перейти к рассмотрению аналогов операций соединения и де­
ления реляционной алгебры в реляционном исчислении, коснемся некото­
рых основных правил построения формул, определяемых в реляционном
исчислении.
В общем виде любое выражение исчисления кортежей можно записать сле­
дующим образом:
{*(Л) U*)},
где / — некоторый предикат над переменным кортежем х. Это выражение
обозначает отношение r(R), которое состоит из всех кортежей t(R), для ко­
торых / ( t) истинно.
Рассмотрим структуру выражения /(х ), как это сделал Д. Мейер. Основны­
ми строительными блоками для формул типа / (х) являются атомы, которые
бывают трех типов.
□ Пусть г — имя отношения из d, а х — переменный кортеж. Тогда г (х) —
атом, означающий, что х е г.
□ Пусть х н у — переменные кортежи (не обязательно различные), 0 е 0 —
знак сравнения, А и В — атрибуты из £/, которые 0-сравнимы. Тогда
х(Л) 0 у (В) — атом.
□ Пусть х — переменный кортеж, 0 6 0 — знак сравнения, А и В — атрибу­
ты из U, которые 0-сравнимы. Если с — константа из dont (А), то с Qx(B) —
атом, если с — константа из dom (В), то х(Л)0 с — атом.
Из атомов строятся более сложные выражения. Для рекурсивного построе­
ния формул из атомов используются связки 1 (НЕ), Д (И), V (ИЛИ), 3 (су­
ществует) и V (для каждого). Построение формул осуществляется в соответ­
ствии со следующими шестью правилами.
□ Каждый атом — формула.
□ Если / — формула, то 1 / — формула.
□ Если f u g — формулы, то / Д g u f \ J g — формулы.
□ Если х — переменный кортеж, / — формула, включающая х, a R — под­
множество U, то 3 х (R) / — формула (она истинна, если существует кор­
теж t над R, при подстановке которого вместо х в / формула становится
истинной).
□ Если х — переменный кортеж, / — формула, включающая х, a R — под­
множество U, то V х (R) f — формула (она истинна, если для каждого
кортежа t над R формула/ становится истинной при подстановке t вместо х).
П Если / — формула, то и (/) — формула.

Связки 3 и V имеют самый высокий (и равный) приоритет, затем следуют 1,
Д и V в порядке убывания приоритета. Скобки, как и в других случаях, ис­
пользуются тогда, когда требуется изменить порядок действий, диктуемый
установленным приоритетом связок.
В реляционном исчислении при построении разрешенных формул весьма
важными являются понятия: свободные и связанные вхождения переменной
в формулу. Свободные и связанные вхождения переменной в формулу несут
на себе такую же смысловую нагрузку, как и глобальные и локальные вхож­
дения переменной в программу. Кванторы, т. е. связки 3 и V, соответству­
ют декларациям; они связывают вхождения переменных, находящихся
в сфере их действия. Кванторы служат также для описания типа переменной
в формулах.
Свободные и связанные вхождения переменных определяются рекурсивно
одновременно с type (х, J) — типом переменной х в формуле / и men (х, f ) —
множеством ссылок переменной х в / И type (x, f) , и men (х, f ) определены
только в случае, если х имеет свободное вхождение в f i x "появляется в /
свободно"). Понятия свободы, связанности, типа и множества ссылок ис­
пользуются для определения класса разрешенных формул через ограничения
на употребление различных связок. Рассмотрим сначала случай, когда / —
атомарная формула.
□ Если / = г (х), то х свободен в f a type (x, f) = men (x, f) = R, где R — схе­
ма отношения г.
□ Если f = x (А) 0 у (В), то х и у свободны в f type (x, f ) и type (y, f ) не
определены, a men (x, f) = A, men iy,J) = B.
□ Если / = x (A) Q с или / = c 0 x (A), то x свободен в f type (x, j) не опреде­
лен, a men (x, f ) = A.
Атомарные формулы всегда разрешены (если удовлетворяют требованиям на
домены и знаки сравнения). Рассмотрим далее случай, когда / строится из
меньших формул, предполагая, что g и А — разрешенные формулы.
□ Если / = 1 g, то / разрешена, а вхождения переменных в / свободны или
связаны в зависимости от того, свободны или связаны вхождения этих
переменных в g. Если х входит в g свободно, то type (х, / ) = type (x, g) и
теп (x , f ) — теп (x, g).
□ Если / = / Д А или / = g V h, то вхождения переменных в / свободны
или связаны в зависимости от того, свободны или связаны они в g или А.
Для переменной х, входящей свободно в / типы type (х, А) и type (x, g)
должны совпадать, если они оба определены, для того чтобы / была раз­
решенной. Если же тип определен только для одной из подформул, ска­
жем для g, и х появляется свободно в А, то, чтобы / была разрешена,
должно быть выполнено включение type (x, g) □ теп (х, А). В обоих слу­
чаях type (x, f) = type (x, g). Если же тип х не определен в обеих под-

формулах, то
type(х, J) не определен. В любом случае теп
= теп (
х, )g и теп (х, h).
П Если / = 3 x(R) g или / = V
х (R) тg,о, чтобы / был
менная х должна входить свободно в g. Более того, type (х, g) должен быть
R, если он определен, и R должно содержать теп (х, g). Все вхождения х
в / связаны, a type{x,
f )и men (х, f ) не определены, так
свободно в
f .Если
у * х,то любое вхождение
в соответствии с тем, свободно или связано вхождение в причем type
(У, Л - W e Си, g) и теп
(у, f ) = теп (у, g).
□ Если / = (g), то / разрешена, а свободные вхождения, связанные вхожде­
ния, тип и множество ссылок переменных остаются теми же, что и у
В формулах вида Их
(R)gи Vx (Л) g полезно определить, какие
переменной х в
gсвязаны внешним квантором, а какие нет. Будем гово
что вхождение х в ^связано квантором 3 х (R) g, если х входит свободно в g.
То же самое применимо и к квантору V. Если же х входит связано в g, то он
должен бы связан некоторым квантором из g.

8.2.3. Квантор существования
Квантор вообще обозначает количество чего-либо.
Квантор существования означает, что существует хотя бы один экземпляр
определенного типа вещей. В реляционном исчислении квантор существо­
вания используется для задания условия того, что определенный тип строк
в отношении существует.
Рассмотрим отношения:
ПОТРЕБНОСТИ
Код_дет
01
02
03
04
05

СКЛАД

Назв_дет
А

Количество

д
в
с

2

Е

1
2

Код_дет
01
03
04

Стеллаж
05
10
02

Кол_дет
100
250
2

3
1

Запрос: Перечислить названия деталей, потребности в которых покрываются
деталями, хранящимися на складе.
Очевидно, что решением этой задачи будет отношение, содержащее назва­
ния некоторых деталей. Это отношение состоит из одного столбца, так что
в этом случае целевым списком является:
1.Назв_дет,

где t — строка из отношения ПОТРЕБНОСТИ.
Пусть s — строка отношения СКЛАД.
Формирование определяющего выражения осуществляется, исходя из сле­
дующего. Для того чтобы деталь вошла в отношение решения, должно удов­
летворяться условие, что на складе эта деталь имеется в достаточном коли­
честве. Другими словами, если Код_дет встречается в строке отношения
СКЛАД с Кол_дет > Количество в строке отношения ПОТРЕБНОСТИ, то
эта деталь должна быть включена в решение. Таким образом, условие тако­
во: существует хотя бы одна строка отношения СКЛАД, содержащая требуе­
мый Код^дет и где з.Кол дет > t.Количество. Это формируется следующим
образом:
exists s in СКЛАД
(,s.Kod_dem = t.Kodjdem and 5.Кол_дет > t.Количество).
Такое выражение читается: "Существует строка s в отношении СКЛАД та­
кая, что s.Koàjdem = t.Kodjdem и s.KoA_dem > t.Количество"
Приведенное выражение определяет строку /. Если оно истинно, то есть для
строки t существует такая строка s, то t.Ha3e_dem помещается в результи­
рующее отношение. Если выражение ложно — то есть такой строки s не су­
ществует —тогда t.Haeejdem не помещается в результирующее отношение.
Полное решение в реляционном исчислении выглядит следующим образом:
\t.Ha3e_dem \ t in ПОТРЕБНОСТИ and exists s in СКЛАД (s.Kodjdem =
= t.Kodjdem and s.Konjdem > t.Количество )}.
Оно описывает отношение, состоящее из одного столбца и содержащее на­
звания деталей, взятых из строк отношения ПОТРЕБНОСТИ. Данное на­
звание помещается в отношение решения, если его строка t удовлетворяет
условию после знака "|"
Рассмотрим подробнее вышеописанный механизм обработки нескольких
строк отношения ПОТРЕБНОСТИ, чтобы понять, как будет применяться
условие.
Первая строка отношения ПОТРЕБНОСТИ (которая обозначена /) имеет
Назв^дет —А, и оно будет помещено в результирующее отношение, если
в отношении СКЛАД существует строка, в которой Код_^дет = 01,
а КолДИет > t.Количество. Такая строка действительно существует, и она
обозначена как s. Итак, / удовлетворяет определяющему условию, поэтому
t.Ho3e_dem помещается в отношение решения. Этот процесс должен повто­
риться для каждой строки отношения ПОТРЕБНОСТИ. Когда закончена
обработка первой строки, вторая строка обозначена t, и теперь уже для нее
ищется соответствующая строка s в отношении СКЛАД. Такой строки не
существует, поэтому Д не помещается в результирующее отношение. Про­
должая дальше обработку строк отношений по указанному алгоритму, полу­

чим множество решения, которое составит новое отношение, и будет выгля­
деть следующим образом:

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

8.2.4. Квантор всеобщности
Квантор всеобщности означает, что некоторое условие применяется ко всем
строкам или к каждой строке некоторого типа. Он используется в тех же
целях, что и операция деления реляционной алгебры. Проиллюстрируем его
применение тем же запросом, который рассматривался в разделе, описы­
вающем операцию деления. Пусть даны два отношения:
VEDOM
RASP
Ном зач кн

Фамилия

Дисц_на

Дата

Дисц_на

Дата

02-Э-01

Иванов

Физика

10.01.03

Химия

14.01.03

02-Э-01

Иванов

Химия

14.01.03

Физика

10.01.03

02-Э-02

Сидоров

Физика

10.01.03

02-Э-02

Сидоров

Химия

14.01.03

02-Э-05

Коровин

Химия

14.01.03

Требуется определить фамилии тех студентов, каждый из которых сдавал все
экзамены, перечисленные в отношении RASP. Необходимо обратить внима­
ние на то, что условие выбора студента содержит определение каждый.
В результирующее отношение включаются только те студенты, которые сда­
вали каждый экзамен. Если взглянуть на полученный результат, то можно
увидеть, что условию запроса удовлетворяют только два студента.
Полное решение в реляционном исчислении с использованием квантора
всеобщности FORALL таково:
{г. Фамилия |
tin VEDOM and s in RASP and
FORALL s (
t.Дисц_на = s. Дисц_на)},
где t — кортеж отношения VEDOM;
s — кортеж отношения RASP.

Результат выполнения запроса:
Фамилия
Иванов
Сидоров

Имя студента из строки
tтаблицы VEDOM помещается в
отношение, если определяющее выражение истинно для строки t. А опреде­
ляющее выражение истинно, если для каждой строки s отношения RASP
должна существовать строка t в отношении VEDOM, удовлетворяющая усло­
вию, то есть в данном случае для каждой строки s отношения RASP должна
существовать строка t в отношении VEDOM с одной и то же фамилией:
□ Иванов присутствует в строках
t(1) и t (2): (1)
соответствует
s(1);
□ Сидоров присутствует в строках / (3) и t (4): t (3) соответствует s (2) и
t (4) соответствует
s(1);
□ Коровин присутствует только в строке t (5): t (5) соответствует 5(1), а для
s (2) нет соответствующей строки /.
Полное соответствие всем строкам отношения RASP есть только у Иванова
и Сидорова. Таким образом, они и вошли в результирующее отношение.

Вопросы и упражнения
1. Дайте подробное объяснение смысла каждого из перечисленных ниже
терминов:
• реляционная алгебра;
• непроцедурный;
• пересечение;
• вычитание;
• проецирование;
• естественное соединение;
• деление.
2. Дайте определение основным операциям реляционной алгебры. Покажи­
те, как могут быть получены дополнительные операции данной алгебры.
3. Опишите ситуации, в которых могло бы потребоваться использование
каждой из следующих операций реляционной алгебры:
• выборка;

• проецирование;
• соединение;
• вычитание;
• пересечение;
• деление.
4. Объясните функции каждого из следующих элементов формулировки
запроса в реляционном исчислении:
• целевой список;
• определяющее выражение;
• булевы операции (И, ИЛИ, НЕ);
• квантор существования;
• квантор всеобщности.
5. Покажите на конкретном примере реляционной модели некоторой пред­
метной области реализацию запроса посредством операций реляционной
алгебры.
6. Получите конструкции реляционного исчисления, соответствующие та­
ким операциям реляционной алгебры: объединению, разности и произ­
ведению.

Часть III

ЯЗЫКИ БАЗ ДАННЫХ

Глава 9. Язык SQL
Глава 10. Язык запросов по образцу

Глава 9

Язык SQL
Описанию предложенных Кодцом реляционной модели данных и реляци­
онным языкам обработки данных (реляционной алгебре и реляционному
исчислению) посвящены несколько предыдущих глав. Эти языки заложили
теоретические основы для разработки коммерческих языков РСУБД и, по
сути, являются эталоном при тестировании их логических возможностей.
Одним из языков, появившихся позднее и использующих заложенный
Кодцом теоретический базис, является SQL (Structured Query Language) —
структурированный язык запросов. Этот язык представляет собой настолько
удачную программную разработку для манипулирования данными реляци­
онной модели, что в настоящее время он является наиболее распространен­
ным программным продуктом такого рода.

9.1. Исторические аспекты развития SQL
Истоки языка SQL можно отнести к 1974 году, когда на четыре года позже
публикации Кодцом своей основополагающей статьи увидело свет опреде­
ление языка, получившего название "Structured English Query Language", или
сокращено SEQUEL, на базе которого был реализован первый прототип ре­
ляционной СУБД фирмы IBM System R. Впоследствии переработанная вер­
сия этого языка получила название SQL и постепенно в силу своего широ­
кого распространения стала стандартом для языков манипулирования
данными в реляционных СУБД.
Выход исходного варианта стандарта языка SQL относится к 1987 году. Сле­
дует отметить, что этот вариант стандарта языка имел ряд недостатков и
справедливо подвергался критике. К числу таких недостатков относили его
чрезмерную избыточность, отсутствие в языке важнейших функций под­
держки целостности и ряда других конструкций.
В 1989 году ISO (Международный комитет по стандартизации), учтя выска­
занные замечания в адрес предыдущей версии стандарта языка, опубликовал
первый международный стандарт языка SQL, а в 1992 году была принята
новая, существенно переработанная версия международного стандарта языка

SQL, которая получила название SQL/92 или SQL2. Для того чтобы можно
было различать раннюю и позднюю версии языка, версии 1989 года при­
своили название стандарта SQL1. Подавляющее большинство доступных на
рынке СУБД разрабатывались с ориентацией именно на стандарт SQL1, но
в настоящий момент основная часть производителей СУБД внесли измене­
ния в свои продукты так, чтобы они в большей степени удовлетворяли стан­
дарту SQL2.
В 1999 году появился новый стандарт языка, названный SQL3, в который
включен целый ряд расширений, способствующих качественным серьезным
преобразованиям стандарта языка. В SQL3 введены новые стандартные типы
данных, пользователю предоставляется возможность конструирования
сложных структурированных типов данных, которые позволяют организо­
вать объектно-ориентированную работу с данными, введены стандарты на
события и триггеры, и многое другое.
Похоже, что в настоящее время никто не намерен считать процесс развития
стандарта языка SQL завершенным. Работа над стандартом продолжается.
Специалисты прилагают значительные усилия по решению ряда проблем,
например, созданию расширений языка, которые позволят осуществить
взаимодействие между разнородными системами.
Итак, современное состояние дел в области создания и поддержки инфор­
мационных систем характеризуется наличием пока единственного стандарт­
ного языка для работы с базами данных. Практически все крупнейшие раз­
работчики СУБД создают свои продукты с использованием языка SQL и
стараются придерживаться его стандарта.
Следовать стандарту стремятся не только разработчики СУБД, но и их по­
требители. На это у тех и других существуют свои весьма веские причины.
С одной стороны, ни один серьезный разработчик, проектирующий базы
данных, не станет игнорировать стандарт. Каждый автор информационной
системы стремится к тому, чтобы его проект был рассчитан на расширяе­
мость и переносимость на другие платформы. Именно поэтому пользователь
СУБД, как правило, игнорирует дополнительные возможности данного про­
дукта, не входящие в стандарт, так как система, обладающая свойством пе­
реносимости, лучше защищает интеллектуальный труд, вкладываемый
в разработку.
С другой стороны, указанная выше причина предопределяет поведение и
большинства поставщиков программного обеспечения, которые в такой си­
туации вынуждены следовать стратегии поддержки стандартов, поскольку
в противном случае пользователи просто не будут такие продукты покупать.
В заключение этого небольшого введения следует обратить внимание чита­
теля на некоторые аспекты определения стандарта ISO SQL, которые не
совпадают с отдельными концепциями реляционной теории Кодда. Так,
в стандарте вместо таких понятий, как отношение, атрибут, кортеж исполь­

зуются более привычные для рядового пользователя и не требующие допол­
нительных пояснений термины: таблица, столбец, строка. В этой главе ма­
териал будет излагаться с использованием терминологии стандарта языка.
Кроме того, в языке SQL допускается, что созданная в результате выполне­
ния операции s e l e c t таблица может содержать дублирующие строки, столб­
цы таблицы считаются упорядоченными, ее строки также могут быть приве­
дены в упорядоченное состояние.

9.2. Структура и типы данных языка SQL
В этом разделе вашему вниманию предлагается рассмотрение структуры са­
мого языка SQL и типов данных, на которые можно опираться при созда­
нии различных конструкций языка.
В отличие от теоретических языков, введенных Коддом, реляционной алгеб­
ры и реляционного исчисления, предназначенных только для реализации
запросов к БД, SQL является полным языком, в нем присутствуют как со­
ставляющие обе необходимые для работы с базами данных части: язык ма­
нипулирования данными — DML и язык определения данных — DDL.
Кроме того, данный язык содержит операторы, предназначенные для управ­
ления БД.
Предполагая, что читатель знаком с методикой описания языков програм­
мирования, кратко обозначим основные базисные элементы языка SQL.
В языке SQL1 определен ряд типов данных, которые представлены в табл. 9.1.
Таблица 9.1. Типы данных
Пояснение

Тип
CHARACTER(п )
CHAR(п )

ИЛИ

Символьные строки постоянной длины в п символов

N U M ER IC [ ( n , m ) ]

Точные числа, здесь п — общее количество цифр в чис­
ле, ш — количество цифр слева от десятичной точки

D E C IM A L [ ( n , m ) ]

Точные числа, здесь п — общее количество цифр в чис­
ле, m — количество цифр слева от десятичной точки

DEC[ ( n , m ) ]

То же, ЧТО И DECIMAL

INTEGER ИЛИ IN T

Целые числа

SMALLIN T

Целые числа меньшего диапазона

FLO A T [ ( n ) ]

Числа большой точности, хранимые в форме с плаваю­
щей точкой. Здесь п — число байтов, резервируемое под
хранение одного числа

[ (n,m) ]

Т аб лиц а 9.1 (окончание)

Тип

Пояснение

REAL

Вещ ественны й тип чисел, который соответствует числам
с плаваю щ ей точкой, м еньш ей точности, чем f l o a t

DOUBLE P R E C IS IO N

С пециф ицирует тип данных с о п р ед ел ен н о й в р еал и ­
зации точностью, больш ей, чем о п р едел ен н ая в р еа л и за ­
ции ТОЧНОСТЬ ДЛЯ REAL

В стандарт SQL2 добавлено несколько расширяющих возможности языка
типов данных (табл. 9.2).
Таблиц а 9.2. Дополнительные типы данны х

Тип

Пояснение

VARCHAR(п )

Строки сим волов перем енн ой длины

NCHAR(N)

Строки локализованны х сим волов постоянной длины

NCHAR V A R Y IN G (n )

Строки локализованны х сим волов пер ем ен н ой д л и ­
ны

B IT (n )

Строка битов постоянной длины

B IT V A R Y IN G (n )

Строка битов перем енн ой длины

DATE

К алендарная дата

T IM ESTA M P(т о ч н о с т ь )

Д ата и время

INTERVAL

В рем енной интервал

В стандарте определены следующие константы:
□ для числовых типов данных определены константы в виде последователь­
ности цифр с необязательным заданием знака числа и десятичной точкой;
□ константы с плавающей запятой, как и в большинстве языков про­
граммирования, определяемые путем задания мантиссы и порядка, разде­
ленных символом Е, например
2.9Е-4
-134.235Е7 0.54267Е18;
□ строковые константы, которые должны быть заключены в одинарные
кавычки:
'Иванов И.И.';
□ константы даты, времени и временного интервала — в реляционных
СУБД представляются в виде строковых констант;
□ специальные системные константы.

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

Функция

Результат

B IT_LEN G TH

(< с т р о к а > )

Количество битов в строке

CAST (< з н а ч е н и е > AS < т и п
данны х>)

данных

CHAR_LENGTH

Длина строки сим волов

(< с т р о к а > )

Значение,

пр еобр азов ан н ое

в заданны й тип

CONVERT (< С Т р о ка > USING
< ф ун кц и я >)

Строка, преобразованная в соответствии с ука­
занной ф ункцией

c u r r e n t _DATE

Текущая дата
( « т о ч н о с т ь >)

CURRENT— T IM E

CURRENT_TIMESTAMP

(< т о ч -

Т екущ ее время с указанной точностью
Текущ ие дата и время с указанной точностью

Н О С Т Ь > )

LOWER

(< с т р о к а > )

OCTEDJLENGTH

Строка, преобразованная к верхнем у регистру

(< с т р о к а > )

P O S IT IO N (< п е р в а я с т р о к а >
IN <вто р ая с т р о к а > )

Число байтов в строке сим волов
Позиция, с которой начинается вхож дение пер­
вой строки во вторую

FOR < д л и н а > )

Часть строки, начинающаяся с л-го сим вола и
имеющ ая указанную длину

T r a n s l a t e (< с т р о к а > USING
« ф у н кц и я > )

указанной функции

s u b s t r in g

T R IM

(BOTH

(« с т р о к а > FROM п

« С И М В О Л

> FROM

<строка>)
Tr im ( l e a d in g
Fr o m < с т р о к а > )
T R IM

Строка,

преобразованная

с

использованием

Строка, у которой удалены все первые и по­
сл ед н и е символы

«

с и

м

в о

л

>

(T R A IL IN G «с и м в о л >

Строка, в которой удалены все первые указан­
ные символы

From < с т р о к а > )

Строка, в которой удалены п о сл едн и е указан­
ные символы

UPPER

Строка, преобразованная к верхнем у регистру

(с т р о к а )

9.3. Операторы языка SQL
Как уже было сказано, язык SQL включает в себя операторы разных катего­
рий. Любой SQL-оператор состоит из зарезервированных слов и слов, опре­
деляемых пользователем в соответствии с установленными синтаксическими
правилами. Как и во многих языках программирования, большинство ком­
понентов операторов языка не чувствительны к регистру. Исключение из
этого правила как обычно составляют символьные данные, при задании ко­
торых необходимо помнить о регистре и использовать тот, который необхо­
дим для представления данных.
Для записи операторов в языке принят свободный формат, позволяющий
посредством отступов и выравниваний придать SQL-программе более чита­
бельный вид.
При записи операторов рекомендуется придерживаться следующих правил:
□ каждая фраза в операторе должна начинаться с новой строки;
□ начало каждой фразы должно быть выровнено с началом остальных фраз
оператора;
□ каждая часть фразы должна начинаться с новой строки с некоторым от­
ступом относительно начала всей фразы, что позволит выделить подчи­
ненные части.
Для записи операторов применяются некоторые соглашения:
□ для записи зарезервированных слов используются прописные буквы;
□ для записи определяемых пользователем слов используются строчные
буквы;
□ вертикальная черта "|" указывает на необходимость выбора одного из не­
скольких значений;
□ фигурные скобки определяют обязательный элемент;
□ квадратные скобки определяют необязательный элемент;
□ многоточие
используется для указания необязательной возможности
повторения конструкции, от нуля до нескольких раз.
В данном разделе операторы каждой категории приведены в отдельной
таблице.
Операторы определения данных (табл. 9.4) применяются для описания
структур используемых данных. В состав этой категории входят следующие
операторы: c r e a t e t a b l e , d r o p t a b l e , a l t e r t a b l e , c r e a t e v i e w ,
ALTER VIE W , DROP VIEW .

Таблица 9.4. Операторы определения данных

Оператор

Пояснение

CREATE TABLE

С оздать таблицу

DROP TABLE

Удалить таблицу

ALTER TABLE

Изменить таблицу

CREATE VIEW

С оздать представление

ALTER VIEW

Изменить представление

DROP VIEW

Удалить представление

Операторы манипулирования данными, образующие следующую категорию
операторов, предназначены для заполнения таблиц данными и для обновле­
ния загруженной в них информации. К данной категории относятся сле­
дующие операторы: d e l e t e , i n s e r t , u p d a t e (табл. 9.5).
Таблица 9.5. Операторы манипулирования данными

Оператор

Пояснение

DELETE

Удаляет одну или несколько строк,
фильтрации, из б а зов ой таблицы

IN SER T

Вставляет одну строку в базовую таблицу

UPDATE

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

соответствующ их

условиям

Для выборки информации из базы данных предназначен язык запросов, ко­
торый в языке SQL представлен одним оператором s e l e c t (табл. 9 .6 ).
Таблица 9.6. Язык запросов

Оператор

Пояснение

SELECT

Выбирает строки; оператор, позволяющ ий сф орм ировать р е­
зультирующую таблицу, соответствующ ую за п р о су

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

Т аб лица 9.7. Управление транзакциями

Оператор

Пояснение

COMMIT

Заверш ить транзакцию — заверш ить обработку инф орм ации,
объединенную в транзакцию

ROLLBACK

Откатить тр ан зак ц и ю — отменить изм енения, проведенны е в
х о д е выполнения транзакции

SAVEPOINT

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

Таблица 9.8. Администрирование данных

Оператор

Пояснение

ALTER DATABASE

Изменить набор основных объектов в б а з е данных, ограниче­
ний, касающ ихся всей базы данных

ALTER DBAREA

Изменить р ан ее создан н ую область хранения

ALTER PASSWORD

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

create

С оздать новую б а зу данных

database

CREATE DBAREA

С оздать новую область хранения и сдел ать е е доступной для
р азм ещ ен ия данных

DROP DATABASE

Удалить сущ ествую щ ую б а зу данных

DROP DBAREA

Удалить сущ ествую щ ую область хранения (есл и в ней на на­
стоящ ий м ом ент не располагаю тся активные данны е)

GRANT

П редоставить права доступа на ряд действий н ад некоторым
объектом БД

REVOKE

Лишить прав доступа к некотором у объекту или некоторым
действиям над объектом

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

Начинать знакомство с данным языком принято с рассмотрения возможно­
стей языка запросов, который в языке SQL представлен одним оператором
s e l e c t , потому что этот мощный оператор, естественно, является и самым
сложным. К тому же в дальнейшем интересно посмотреть, как его можно
использовать совместно с операторами манипулирования данными.
Некоторые операторы, предназначенные для управления транзакциями,
и средства администрирования данных будут рассмотрены в последующих
разделах книги, специально выделенных для более детального знакомства
с этими вопросами.

9.3.1. Оператор выбора SELECT.
Формирование запросов к базе данных
Назначение оператора s e l e c t с о с т о и т в выборке и отображении данных од­
ной или нескольких таблиц БД. Этот исключительно мощный, наиболее
часто используемый оператор реализует все операции реляционной алгебры.
Возможности данного оператора широки и разнообразны. Один и тот же
запрос может быть реализован несколькими способами, которые могут су­
щественно отличаться по времени исполнения.
Синтаксис оператора s e l e c t :
SELECT [D IS T IN C T ! ALL]

{ * ! ' [< сп и со к п о л е й > ]} FROM <сп исо к таблиц>

[WHERE < п р е д и ка т-у с л о в и е выборки или соединения:^
[GROUP BY
[HAVING
[ORDER BY

< сп и со к полей р е з у л ь т а т а ^
< п р ед и кат-усл о в и е для группы>]
сс п и со к полей,

по которым тр е б у е тс я упорядочить вывод>]

Указанный порядок следования фраз в операторе s e l e c t не может быть из­
менен, но не все его части являются обязательными. К обязательным пред­
ложениям относятся только фразы s e l e c t и f r o m . Все остальные части опе­
ратора могут быть использованы по усмотрению программиста. Поясним
каждую фразу данного оператора.
□ Фраза s e l e c t :
•

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

• ключевое слово d i s t i n c t предназначено для приведения таблицы
в соответствие с принципами теории отношений, где предполагается
отсутствие дубликатов строк;
• символ
определяет очень часто встречаемую ситуацию, когда в ре­
зультирующий набор включаются все столбцы из исходной таблицы

запроса. Таким образом, программист может выбрать один из воз­
можных вариантов формирования результирующих таблиц: включение
только указанных столбцов или включение всех столбцов таблицы.
□ Во фразе f r o m задается перечень исходных таблиц запроса.
□ Во фразе w h e r e определяются условия отбора строк результата или усло­
вия соединения строк исходных таблиц, подобно операции условного со­
единения в реляционной алгебре. В качестве условий отбора могут быть
использованы следующие предикаты:
• сравнения "=, <>, >, <, >=, <=" — для сравнения результатов вы­
числения двух выражений; более сложные выражения строятся с по­
мощью логических операторов AND, OR, NOT; значения выражений
вычисляются в порядке, который определяется приоритетом исполь­
зуемых операторов и наличием скобок в выражении;
• between a and в — предикат истинен, когда вычисленное значение
выражения попадает в заданный диапазон (предикат not between а
and в истинен тогда, когда сравниваемое значение не попадает в за­
данный ин+ервал);
• in — предикат истинен тогда, когда сравниваемое значение входит
в множество заданных значений; при этом множество значений может
быть задано простым перечислением или встроенным подзапросом
(предикат not in истинен тогда, когда сравниваемое значение не вхо­
дит в заданное множество);
• lik e и not like — предикаты, смысл которых противоположен, тре­
буют задания шаблона, с которым сравнивается заданное значение;
предикат like истинен тогда, когда сравниваемое значение соответст­
вует шаблону, и ложен в противном случае;
• is null — предикат, применяющийся для выявления равенства зна­
чения некоторого атрибута неопределенному значению:
О <имя а т р и б у т а > is null — принимает значение true, если в дан­
ной строке указанный атрибут имеет неопределенное значение
и значение false , в противном случае;

О

is not null — все происходит наоборот.
• e x is t и not e x is t , используемые во встроенных подзапросах.
П Во фразе group by задается список полей группировки.
□ Во фразе having задаются предикаты-условия, накладываемые на каждую
группу.
□ Во фразе order by задается список полей упорядочения результата, то
есть список полей, который определяет порядок сортировки в результи­
рующей таблице.
<имя а т р и б у т а >

В стандарте SQL определено понятие NULL-значения, которое вызвало необхо­
димость применения трехзначной логики, где все логические операции выпол­
няются в соответствии с приведенной ниже таблицей истинности (табл. 9.9).
Таблиц а 9.9. Таблица

истинно сти

А

В

N ot A

ADB

AUB

TRUE

TRUE

FALSE

TRUE

TRUE

TRUE

FALSE

FALSE

FALSE

TRUE

TRUE

NULL

FALSE

NULL

TRUE

FALSE

TRUE

TRUE

FALSE

TRUE

FALSE

FALSE

TRUE

FALSE

FALSE

FALSE

NULL

TRUE

FALSE

NULL

NULL

TRUE

NULL

NULL

TRUE

NULL

FALSE

NULL

FALSE

NULL

NULL

NULL

NULL

NULL

NULL

П росты е за п р о с ы
Рассмотрим ряд простых запросов.
Запрос 1
Вывести сведения о кафедрах университета.
Данная задача сводится к выборке и выводу информации из одной таблицы,
причем выводу подлежат все ее строки и все ее столбцы. Реализуется такой
запрос с помощью оператора вида:
SELECT *
FROM k a f e d r a ;

Результатом выполнения такого запроса будет являться таблица, содержащая
сведения обо всех кафедрах университета. Приведем несколько строк такой
таблицы:
K o d .k a f

N a m e .k a f

N o m .te le f

N om _A uditoria

C o L so tr

Z a v jc a f

001

Физики

2 3 -3 4 -2 4

132

25

Иванов T.M.

002

О бщ ей
матики

2 3 -6 5 -4 3

003

22

Махов К.Л.

003

Истории

2 3 -7 8 -7 2

465

16

Р о сс Л.Т.

004

Граф ики

2 3 -9 9 -7 7

385

18

Фирсов С.С.

005

Прикладной
математики

2 3 -6 6 -6 2

028

24

Ляхова И.Т.

м ате­

Запрос 2
Вывести номера телефонов кафедр университета.
Результат такого запроса должен содержать только два столбца: Namejkaf и
Nom_telef, поэтому сам запрос должен выглядеть следующим образом:
SELECT N a iu e_ ka f, N o n \_ te le f
FROM k a f e d r a ;

Результирующая таблица приведена ниже:
N a m e .k a f

N o m je le f

Физики

2 3 -3 4 -2 4

О бщ ей математики

2 3 -6 5 -4 3

Истории

2 3 -7 8 -7 2

Графики

2 3 -9 9 -7 7

Прикладной математики

2 3 -6 6 -6 2

В сформированных выше запросах требовалось вывести все строки таблицы,
указанной в предложении f r o m . Если при выборке требуется ограничить ко­
личество выводимых строк в соответствии с каким-то условием, то этого
можно достичь, используя в запросе предложение w h e r e . В предложение
w h e r e можно включить одно иди несколько условий отбора строк.
Запрос 3

Вывести сведения о кафедре графики.
Запрос будет выглядеть следующим образом:
SELECT *
FROM k a f e d r a
WHERE Nam e_kaf = 'Г р а ф и к и ';

Ответ на такой запрос будет содержать только одну строку:
K od_kaf

N a m e jc a f

N o m .te le f

N om _A uditoria

C o l_ so tr

Z a v jc a f

004

Граф ики

2 3 -9 9 -7 7

385

18

Ф ирсов C.C.

Посмотрим, как работают другие предикаты, например

betw een

a

and

в.

Запрос 4

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

Запрос будет выглядеть следующим образом:
SELECT *
PROM k a f e d r a
WHERE N a m _ A u d ito ria BETWEEN 1 AND 9 9 ;

Результат запроса:
K o d jta f

N a m e .k a f

N o m je le f

N o m .A u d ito ria

C o L so tr

Z a v .k a f

002

О бщ ей
матики

2 3 -6 5 -4 3

003

22

Махов К.Л.

005

Прикладной
математики

2 3 -6 6 -6 2

028

24

Ляхова И.Т.

м ате­

До сих пор в запросах использовались только два обязательных предложе­
ния s e l e c t , f r o m и предложение для указания условия поиска w h e r e .
Рассмотрим ряд запросов с использованием других фраз.
В общем случае строки в результирующей таблице выводятся в неупорядо­
ченном каким-либо образом состоянии. Просматривать и анализировать
такой материал не всегда удобно. Для сортировки строк по какому-либо
столбцу применяется фраза o r d e r b y . Она включает список разделенных
запятыми наименований столбцов, по которым требуется упорядочить вы­
водимую информацию. Данная фраза должна всегда располагаться послед­
ней в операторе s e l e c t и при ее наличии появляется возможность отсорти­
ровать строки по возрастанию ( a s c ) и л и убыванию ( d e s c ) значений
указанного столбца или комбинации указанных столбцов, независимо от
того, присутствуют эти столбцы в результирующей таблице или нет.
Запрос 5

Вывести сведения о кафедрах университета в виде, отсортированном по
столбцу Namejcaf в порядке возрастания.
Запрос будет выглядеть следующим образом:
SELECT *
FROM k a f e d r a
ORDER BY N a m e jc a f ASC;

Результат данного запроса:
K ocL kaf

N a m e .k a f

N o m _ telef

N om _A uditoria

C o L so tr

Z a v jc a f

004

Графики

2 3 -9 9 -7 7

385

18

Ф ирсов C.C.

003

Истории

2 3 -7 8 -7 2

465

16

Р о сс Л.Т.

(окончание)
K od_kaf

N a m e .k a f

N o m _ telef

N o m .A u d ito ria

C o L s o tr

Z av_k af

00 2

О бщ ей м а­
тематики

2 3 -6 5 -4 3

003

22

Махов К.Л.

005

Прикладной
математики

2 3 -6 6 -6 2

028

24

Ляхова И.Т.

001

Физики

2 3 -3 4 -2 4

132

25

Иванов Т.М.

Часто для улучшения наглядности выводимую информацию полезно отсор­
тировать по нескольким столбцам. Для этого имена столбцов сортировки
необходимо перечислить через запятую во фразе o r d e r b y . При этом выво­
димая таблица будет содержать строки, упорядоченные по первому указан­
ному во фразе o r d e r b y столбцу, а строки, имеющие равные значения
в этом столбце, будут упорядочены по значениям второго столбца и т. д.
слева направо.

А гр е га тн ы е ф у н к ц и и я з ы к а
В стандарте языка SQL определено несколько агрегатных функций:
□

count

— возвращает количество значений в указанном столбце;

□

sum

— возвращает сумму значений в указанном столбце;

□

avg

— возвращает усредненное значение в указанном столбце;

□

m in

— возвращает минимальное значение в указанном столбце;

□

мах

— возвращает максимальное значение в указанном столбце.

В качестве операнда данных функций может использоваться наименование
только одного столбца, и все они возвращают единственное значение.
С функциями s u m и a v g могут использоваться только числовые поля.
С функциями c o u n t , м а х и m i n могут использоваться как числовые, так и
символьные поля. При вызове всех перечисленных выше функций, кроме
функции c o u n t ( *), осуществляется исключение всех пустых значений и
только после этого операция применяется к оставшимся значениям столбца.
Функция c o u n t ( * ) призвана осуществлять подсчет всех строк таблицы не­
зависимо от того, какие значения в них находятся.
Агрегатные функции нельзя использовать в предложении w h e r e , потому что
предикаты оцениваются в терминах одиночной строки, а агрегатные функ­
ции — в терминах групп строк.

Запрос 6
Подсчитать и вывести общее число кафедр университета.
Запрос будет выглядеть следующим образом:
SELECT COUNT ( * )

AS c o u n t

FROM k a f e d r a ;

Ответ на данный запрос будет выглядеть:
Count
5
Запрос 7
Определить среднее число сотрудников, работающих на кафедрах универси­
тета.
Запрос будет выглядеть следующим образом:
SELECT AVG(C o l _ s o t r ) AS avg
FROM k a f e d r a ;

Ответ на запрос:

__________________
avg

Tl
Гр у п п и р о в а н и е р е з у л ь т а т о в
Выбираемые пользователем данные могут быть подвергнуты различного ро­
да анализу и обобщению, и язык SQL имеет для этого свои средства. Только
что рассмотренные агрегатные функции являются примером таких средств.
В приведенных выше запросах агрегатные функции применялись ко всей
таблице и выдавали сводные данные на основании обработки значений
всего выделенного столбца. Такие результаты обычно размещаются в конце
отчета и сжимаются в итоговую строку.
Однако часто встречаются ситуации, когда в отчет необходимо поместить и
промежуточные результаты, опирающиеся на вычисления обобщенных
групповых значений. Для применения агрегатных функций в подобных слу­
чаях предполагается предварительная операция группировки. Суть операции
группировки состоит в том, что все множество строк таблицы разбивается
на группы, в каждой из которых собираются строки, имеющие одинаковые
значения атрибутов, которые заданы в списке группировки. Обработка та­
кой информации реализуется путем применения агрегатных функций уже
к каждой отдельной группе и выдаче полученных итогов.

В языке SQL для осуществления операции группировки в оператор s e l e c t
включается фраза g r o u p b y . Запрос, в котором присутствует фраза g r o u p b y ,
называется группирующим запросом, а столбцы, перечисленные в этой фразе,
называются группирующими столбцами.
Стандарт языка требует, чтобы предложение s e l e c t и фраза g r o u p b y были
тесно связаны между собой. Если в запросе должна использоваться группи­
ровка, то каждый элемент списка в предложении s e l e c t должен иметь
единственное значение для всей группы. К тому же в предложении s e l e c t
могут включаться в этом случае только следующие типы данных:
□ имена столбцов;
□ агрегатные функции;
□ константы;
□ выражения, состоящие из перечисленных выше элементов.
Таким образом, предложение g r o u p b y позволяет определять подмножество
значений в особом поле в терминах другого поля и применять функцию аг­
регата к подмножеству. Это дает возможность объединять поля и агрегатные
функции в едином предложении s e l e c t . В дальнейшем в качестве примера
будем работать с двумя БД: НИР и Сессия.
БД НИРсостоит из одной таблицы R, в которой хранится информация о
производимых выплатах специалистам за проделанную работу по опреде­
ленным этапам НИР: R = (ФИО, Этап, Начисления).
Пусть таблица содержит следующие данные.
Я
ФИО

Этап

Начисления(руб)

С ем енов Т.Т.

Этап_1

100 0

П росов С.М.

Этап_1

2000

М ехова И.И.

Этап_1

500

С ем ен ов Т.Т.

Этап_2

500

П росов С.М.

Этап_2

500

М ехова И.И.

Этап_2

1 000

П росов С.М.

Этап_3

1 000

М ехова И.И.

Этап_3

1 000

Немцов Я.Ю.

Этап_3

2000

Немцов Я.Ю.

Этап_4

2000

Яров И.М.

Этап_4

3000

Б Д Сессия включает в себя сводную таблицу, где представлены экзаменаци­
онные оценки студентов, полученные ими в сессию по определенным дис­
циплинам:

S

=

(ФИО, Дисциплина, Оценка);
S

ФИО

Дисциплина

Оценка

Мур С.М.

Ф изика

4

Цуканов Т.Т.

Ф изика

5

Думская М.Т.

Ф изика

3

Д р о з д Г.Р.

Ф изика

4

Мур С.М.

История

4

Цуканов Т.Т.

История

5

Думская М.Т.

История

3

Цуканов Т.Т.

Математика

5

Думская М.Т.

Математика

4

Д р о зд Г.Р.

Математика

5

Петрова С.О.

Электротехника

5

Ч асов И.И.

Электротехника

4

Иванова Я.С.

Электротехника

5

Крисс Р.О.

Электротехника

3

Ч асов И.И.

Иностр_язык

5

Иванова Я.С.

Иностр_язык

4

Часов И.И.

Экономика

4

Иванова Я.С.

Экономика

4

Крисс Р.О.

Экономика

5

Ф и рсова Л.Р.

Экономика

3

А теперь сформируем к базам данных несколько запросов.
Запрос 8
БД НИР. Для каждого специалиста определить сумму, выплаченную за работу
по данной теме, и количество сделанных exty выплат.
Для формирования запроса включим в предложение s e l e c t следующую ин­
формацию: ФИО, COUNT (Начисления) AS count, SUM (Начисления) AS sum,

где в качестве имен для двух вычисляемых столбцов используются псевдо­
нимы. Группировку будем производить по столбцу ФИО. Для того чтобы
проще было просматривать результаты, выводимые данные представим в
отсортированном по столбцу ФИО виде
SELECT ФИО, COUNT (Начисления) AS c o u n t,

SUM (Начисления) AS sum

FROM R
GROUP BY ФИО
ORDER BY ФИО;

Результат запроса:
ФИО

count

sum

М ехова И.И.

3

2500

Просов С.М.

3

3500

С ем енов Т.Т.

2

1 500

Немцов Я.Ю.

2

4000

Яров И.М.

1

3000

Для того чтобы сформировать результаты в таком виде, все строки были
сгруппированы по атрибуту ФИО, в каждой группе было подсчитано коли­
чество строк и сумма начислений.
Запрос 9
БД Сессия. Для каждой дисциплины определить количество студентов, сдавших
экзамен.
Запрос будет выглядеть следующим образом:
SELECT Дисциплина,

COUNT ( * )

AS c o u n t

FROM S
GROUP BY Дисциплина
ORDER BY Дисциплина ;

Результат запроса:
Дисциплина

count

Иностр_язык

2

История

3

Математика

3

Ф изика

4

Экономика

4

Электротехника

4

Поскольку в таблице отсутствуют неопределенные значения, т. е. в ней на­
ходятся сведения только о студентах, успешно сдавших экзамен, то в запрос
была включена функция c o u n t ( *), у которой аргумент представлен симво­
лом
определяющем в данном случае подсчет всех строк в группе.
Совместно с фразой g r o u p b y может быть использована фраза h a v i n g ,
предназначенная для задания ограничений отбора групп, которые будут по­
мещены в результирующую таблицу запроса. Стандарт языка требует, чтобы
имена столбцов во фразе h a v i n g обязательно присутствовали в списке фра­
зы g r o u p b y или применялись в агрегатных функциях.
В частности, если раздел h a v i n g присутствует в табличном выражении, не
содержащем g r o u p b y , т о результатом его выполнения будет либо пустая
таблица, либо результат выполнения предыдущих разделов табличного вы­
ражения, рассматриваемый как одна группа без столбцов группирования.
Агрегатные функции могут применяться не только в выражении вывода ре­
зультатов строки s e l e c t , но и в выражении условия обработки сформиро­
ванных групп h a v i n g . В этом случае каждая агрегатная функция вычисляет­
ся для каждой выделенной группы. Значения, полученные при вычислении
агрегатных функций, могут быть использованы для вывода соответствующих
результатов или для условия отбора групп.
В результат можно включить значение поля группировки и несколько агре­
гатных функций, а в условиях группировки можно использовать несколько
полей. При этом группы образуются по набору заданных полей группиров­
ки. Операции с агрегатными функциями могут быть применены к объеди­
нению множества исходных таблиц.
З а п р о с 10

БД НИР. В условиях предыдущего запроса вывести информацию, касающуюся
только тех специалистов, которым производились начисления более одного раза.
Для вывода такой информации в текст предыдущего запроса необходимо
добавить фразу h a v i n g с о ш т (Н а ч и с л е н и я ) > 1. И в этом случае весь за­
прос примет вид
SELECT ФИО, COUNT (Начисления) AS c o u n t,

SUM (Начисления)

FROM R
GROUP BY ФИО
HAVING COUNT(Начисления)

> 1

ORDER BY ФИО;

Результаты выполнения запроса представлены ниже.
ФИО

count

sum

М ехова И.И.

3

2500

П росов С.М.

3

3500

!0 3ак. 3303

AS sum

(окончание)
ФИО

count

sum

С ем енов T.T.

2

1500

Немцов Я.Ю.

2

4000

Запрос 11
БД Сессия. В условиях предыдущего запроса к данной базе вывести информа­
цию, касающуюся только тех дисциплин, количество сдавших экзамен по кото­
рым превосходит три.
Запрос будет выглядеть следующим образом:
SELECT Дисциплина,

COUNT ( * )

AS c o u n t

FROM S
GROUP BY
HAVING COUNT(Дисциплина )> 3
ORDER BY Дисциплина;

Результат запроса:
Дисциплина

count

Ф изика

4

Электротехника

4

Экономика

4

Вложенные запросы

Стандарт языка позволяет в тело одного оператора select внедрять другой
оператор select . В такой ситуации можно рассматривать внешний и внут­
ренний (внедряемый) операторы запроса. Обычно внутренний запрос гене­
рирует значение, которое проверяется в предикате внешнего запроса
(в предложении where или having), определяющего, верно оно или нет. Ес­
ли внутренний оператор запроса помёщен в предложения where и having
внешнего оператора select , то создается ситуация вложенных запросов
(подзапросов).
В сочетании с другими возможностями оператора выбора, такими как груп­
пировка, возможность вкладывать запросы внутрь друг друга представляет
собой мощное средство для достижения нужного результата. Во фразе from
оператора select , если при формировании запроса требуется более чем
один экземпляр некоторой таблицы, допустимо применять синонимы к
именам таблицы. Синонимы задаются с использованием ключевого слова a s :
FROM R l AS A ,

R I AS B .

Подзапросы могут быть нескольких видов:
□ скалярный подзапрос, возвращающий единственное значение;
□ строковый подзапрос, возвращающий несколько значений в виде одной
строки;
□ табличный подзапрос, возвращающий данные в виде таблицы.
Подзапрос может указываться непосредственно после операторов сравнения
(=, <, >, <=, >=), его текст должен быть заключен в скобки.
Запрос 12
БД НИР. Вывести список платежей, где величина единовременных начислений
превысила среднее значение.
Стандарт языка не позволяет применять агрегатные функции в предложении
w h e r e , поэтому единовременные начисления необходимо сравнивать с ре­
зультатом подзапроса, вычисляющего среднее значение начислений всех
строк таблицы. Данный скалярный подзапрос вернет значение, равное
1208.33, и уже с этим значением будут сравниваться все начисления и отби­
раться для помещения в таблицу вывода.
Запрос будет выглядеть следующим образом:
SELECT ФИО, Э тап,

Начисления

PROM R
WHERE Начисления >
(SELECT a v g (Начисления)
FROM R ) ;

Результат запроса:
ФИО

Э тап

Н а ч и с л е н и я (р у б )

П росов С.М.

Этап_1

2000

Н емцов Я.Ю.

Этап_3

2000

Н емцов Я.Ю.

Этап_4

2000

Яров И.М.

Этап_4

3000

Реализация вложенных запросов требует соблюдения определенных правил
и ограничений.
□ В подзапросах не должна использоваться фраза order by.
□ Список в предложении select может включать только имена столбцов и
составленные из них выражения.
□ По умолчанию имена столбцов в подзапросе относятся к таблице, ука­
занной во фразе f r o m .

□ Подзапрос, участвующий в операции, может быть только правым опе­
рандом.
В стандарте SQL2 операторы сравнения расширены до многократных срав­
нений с использованием ключевых слов any и all . Э то расширение исполь­
зуется при сравнении значения определенного столбца со столбцом данных,
возвращаемым вложенным запросом.
Ключевое слово any, поставленное в любом предикате сравнения, означает,
что предикат будет истинен, если хотя бы для одного значения из подзапроса
предикат сравнения истинен. Ключевое слово all требует, чтобы предикат
сравнения был бы истинен при сравнении со всеми строками подзапроса.
Запрос 13

БД НИР. Определить начисления, которые превышают начисления хотя бы
одного специалиста, выполнявшего Этап_1.
Подобный запрос может быть реализован разными путями. Например, мож­
но организовать подзапрос для нахождения минимальных начислений по
Этапу_1, а затем во внешнем запросе путем сравнения с полученным значе­
нием вывести те начисления, которые превосходят это значение.
Посмотрим, как будет выглядеть запрос с использованием ключевого слова
any. В этом случае внутренний запрос должен сформировать набор числовых
значений начислений для ситуации, где Этап-Этап_Г Внешний же запрос
выберет сведения о начислениях, больших любого из значений в этом наборе.
SELECT ФИО, Э тап, Начисления
FROM R
WHERE Начисления > ANY
(SELECT Начисления
FROM R
WHERE Этап =

* Э т а п _ 1 1) ;

Результат запроса:
ФИО

Этап

Н а ч и с л е н и я (р у б )

С ем ен ов Т.Т.

Этап_1

1000

П росов С.М.

Этап_1

2000

М ехова И.И.

Этап_2

1000

П росов С.М.

Этап_3

1000

М ехова И.И.

Этап_3

1000

Немцов Я.Ю.

Этап_3

2000

Немцов Я.Ю.

Этап_4

2000

Запрос 14

БД НИР. Определить начисления, которые превышают начисления любого спе­
циалиста, выполнявшего Этап_1.
Запрос будет выглядеть следующим образом:
SELECT ФИО, Э тап,

Начисления

FROM R
WHERE Начисления > ALL
(SELECT Начисления
FROM R
WHERE Этап = ' Э та п _ 1 ' ) ;

В данном случае результат запроса содержит только одну строку, поскольку
только эта выплата больше 2 000. Именно такое значение имеют наиболь­
шие начисления по первому этапу.
ФИО

Этап

Н а ч и с л е н и я (р у б )

Яров И.М.

Этап_4

3000

Запрос 15

БД Сессия. Найти студентов, которые сдали все экзамены на оценку не ниже
чем "хорошо"
Запрос будет выглядеть следующим образом:
SELECT ФИО
FROM S
WHERE 4 >= ALL
(SELECT Оценка
FROM S AS S I
WHERE Э.ФИО = S I . ФИО);

Результат запроса:
ФИО
Мур С.М.
Цуканов Т.Т.
Д р о зд Г.Р.
Петрова С.О.
Ч асов И.И.
Иванова Я.С.

Здесь также внутренний запрос формирует набор оценок определенного
студента, которые сравниваются со значением 4. В том случае, если все
оценки равны или превосходят данное значение, ФИО студента помещается
в таблицу вывода.
Совместно с подзапросами могут быть использованы специально предна­
значенные для этого предикаты e x is t s и not e x is t s . Результат их обработ­
ки имеет значение true или false .
Для ключевого слова e x is t s результат равен true в том и только в том слу­
чае, если в возвращаемой подзапросом таблице присутствует хотя бы одна
строка. Если результирующая таблица подзапроса пуста, результат обработ­
ки этого ключевого слова будет иметь значение false .
Для ключевого слова not e x is t s наблюдается полностью противоположная
ситуация. Он возвращает истину, если вывод подзапроса пуст, и ложь, если
вывод подзапроса не пуст.
Возможности использования данных предикатов будут проиллюстрированы
ниже при обсуждении многотабличных запросов.
Многотабличные запросы

При работе с базами данных потребности пользователей не ограничиваются
только реализацией простых запросов данных из одной таблицы. Во многих
случаях для получения ответа на запрос необходимо объединить информа­
цию из нескольких исходных таблиц. Для того чтобы осуществить такое
объединение в результирующей таблице, необходимо выполнить операцию
соединения, при которой объединение информации из двух таблиц проис­
ходит посредством образования пар связанных строк, выбранных из каждой
таблицы. Таблицам можно присвоить имена-псевдонимы, что бывает полез­
но для осуществления операции соединения таблицы с самой собою и в ря­
де других ситуаций.
Если в операторе select указано более одного имени таблицы, неявно под­
разумевается, что над перечисленными таблицами осуществляется операция
декартова произведения. Самый простой запрос select такого рода без не­
обязательных частей выглядит следующим образом:
SELECT *

FROM Rl, R2;

и соответствует декартову произведению таблиц R1 и R2.
Выражение
SELECT Rl.A, R2.B
FROM Rl, R2;

соответствует проекции декартова произведения двух таблиц на два столбца
А из таблицы R1 и В из таблицы R2.

Рассмотрим базу данных, в которой хранится информация о производимых
выплатах специалистам за проделанную работу по определенным этапам
НИР. Пусть она состоит из трех отношений RI, R2 и R3. Будем считать, что
они представлены таблицами RI, R2 и R3 соответственно.
R1 = (ФИО, Отдел);
R2 = (Отдел, Этап);
R3 = (ФИО, Этап, Начисления).
R1

R2

ФИО

Отдел

Отдел

Этап

С ем ен ов Т.Т.

03

03

Этап_1

Просов С.М.

03

03

Этап_2

М ехова И.И.

03

03

Этап_3

Н емцов Я.Ю.

04

04

Этап_3

Яров И.М.

04

04

Этап_4

R3
ФИО

Этап

Начисления(руб)

С ем ен ов Т.Т.

Э тагИ

1000

П росов С.М.

Этап_1

2000

М ехова И.И.

Этап_1

500

С ем ен ов Т.Т.

Этап_2

500

П росов С.М.

Этап_2

500

М ехова И.И.

Этап_2

1000

П росов С.М.

Этап_3

1000

М ехова И.И.

Этап_3

1000

Н емцов Я.Ю.

Этап_3

2000

Н емцов Я.Ю.

Этап_4

2000

Яров И.М.

Этап_4

3000

Для запросов будет использоваться и расширенная база данных Сессия,
представленная таблицами:
S1 = (ФИО, Дисциплина, Оценка) — содержащей сведения о результатах
сессии;

S2= (ФИО, Группа) — содержащей сведения о составе групп;
S3 = (Группа, Дисциплина) — содержащей перечень экзаменов, подлежащих
сдаче.
S1

ФИО

Дисциплина

Оценка

Мур С.М.

Ф изика

4

Цуканов Т.Т.

Ф изика

5

Думская М.Т.

Ф изика

3

Д р о з д Г.Р.

Ф изика

4

Мур С.М.

История

4

Цуканов Т.Т.

История

5

Думская М.Т.

История

3

Цуканов Т.Т.

М атематика

5

Думская М.Т.

М атематика

4

Д р о зд Г.Р.

М атематика

5

Петрова С.О.

Экономика

5

Часов И.И.

Электротехника

4

Иванова Я.С.

Электротехника

5

Крисс Р.О.

Электротехника

3

Часов И.И.

Иностр_язык

5

Иванова Я.С.

Иностр_язык

4

Ч асов И.И.

Экономика

4

Иванова Я.С.

Экономика

4

Крисс Р.О.

Экономика

5

Ф и рсова Л.Р.

Экономика

3

S2

S3

ФИО

Группа

Группа

Дисциплина

Мур С.М.

02-КТ-21

02-КТ-21

Ф изика

Цуканов Т.Т.

02-КТ-21

02-КТ-21

История

Думская М.Т.

02-КТ-21

02-КТ-21

М атематика

Д р о зд Г.Р.

02-КТ-21

02-К Т -12

Экономика

S 2 (окончание)

S 3 (окончание)

ФИО

Группа

Группа

Дисциплина

Петрова С.О.

02-К Т-12

02-КТ-12

Электротехника

Часов И.И.

02-К Т-12

02-КТ-12

Иностр_язык

Иванова Я.С.

02-К Т-12

Крисс Р.О.

02-К Т-12

Ф ирсова Л Р .

02-К Т-12

З ап р ос 16

БД НИР. Вывести список сотрудников отдела 03, которые участвовали в вы­
полнении Этапа_3.
Запрос будет выглядеть следующим образом:
SELECT R 3 . ФИО, R 3 .3 T a n
FROM R I , R3
WHERE R l . Отдел =

'0 3 '

AND

R 1 .ФИО = R3.®HO AND
R 3 . Этап =

'Э т а п _ 3 ';

Результат запроса:
ФИО

Этап

П росов С.М.

Этап_3

М ехова И.И.

Этап 3

Запрос 17

Вывести группы, в которых по одной дисциплине на экзаменах получено больше
одной пятерки.
Запрос будет выглядеть следующим образом:
SELECT S2 . Группа
FROM S I ,

S2

WHERE S I . ФИО = S 2 . ФИО AND
S I . Оценка = 5
GROUP BY S 2 . Группа
HAVING c o u n t ( * ) >

S I . Дисциплина

1;

Результатом выполнения раздела h a v i n g является сгруппированная таблица,
содержащая только те группы строк, для которых результат вычисления ус­
ловия поиска есть t r u e .

Результат запроса:
Группа
02-КТ-21
02-К Т -12

Дадим пример запроса, где будет использован предикат not e x is t s . Е го
возможности удобно проиллюстрировать в тексте многотабличного запроса.
Запрос 18

Вывести список тех студентов, кто должен был сдавать экзамен по истории,
но пока еще не сдавал.
Запрос будет выглядеть следующим образом:
SELECT ФИО
FROM S2 а ,

S3

WHERE S 2 .r p y n n a = S 3 .Группа AND
Дисциплина =
NOT EXISTS

'И с то р и я ' AND

(SELECT ФИО
FROM S I
WHERE ФИО = а.ФИО AND
Дисциплина =

'И с т о р и я ') ;

Результат запроса:
ФИО
Д р о з д Г.Р.

Напомним, что предикат e x is t s истинен, когда подзапрос не пуст, то есть
содержит хотя бы один кортеж, в противном случае предикат e x is t s ложен.
Предикат not e x is t s — истинен только тогда, когда подзапрос пуст.
Обработка такого запроса состоит в том, что для каждого студента, обучаю­
щегося в группе, студентам которой необходимо сдавать экзамен по истории,
проверяется истинность предиката not e x is t s . И стинность его устанавли­
вается по факту присутствия во внутреннем запросе значений. Если подза­
прос пуст, то данный студент еще не сдавал экзамен по истории, предикат
not e x is t s имеет значение true , и ФИО студента помещается в результи­
рующую таблицу вывода.
Множественные операции реляционной алгебры

Язык SQL позволяет использовать такие бинарные реляционные операции над
отношениями (таблицами), как объединение (union), пересечение ( intersect),
разность ( except). На таблицы, участвующие в таких множественных операциях,

накладываются определенные ограничения, обеспечивающие их совмести­
мость по соединению:
□ таблицы должны иметь одинаковые схемы;
□ значения в соответствующих столбцах таблиц должны принадлежать од­
ному и тому же домену.
Первое ограничение является обязательным, и его контроль обеспечивается
средствами языка. Следить за тем, чтобы исходные таблицы удовлетворяли
второму ограничению, и чтобы не происходило соединение "книг" и "боти­
нок", должен сам пользователь. Операторы имеют следующую структуру:
О п е р а то р

[A L L ]

[CORRESPONDING

[BY { c o lo m n l

[,...]}]]

Фраза corresponding by задает операцию для указанных в ней столбцов.
Если же в операторе слово by опущено, то операция задается для общих для
двух таблиц столбцов. Присутствие в операторе ключевого слова a l l опре­
деляет ситуацию, когда дублирующие строки из результирующей таблицы не
исключаются.
Запрос на выполнение, скажем, оператора объединения должен строиться
по следующей схеме:
(SELECT -

зап р о с)

UNION
(SELECT -

зап р о с)

UNION
(SELECT - з а п р о с );

Запрос на объединение может объединять любое число исходных запросов.
Все запросы, участвующие в указанных операциях, не должны содержать
выражений, то есть вычисляемых полей.
Ни один из исходных запросов в операции union не должен содержать
предложения упорядочения результата order by, однако результат объеди­
нения может быть упорядочен, для этого предложение order by с указанием
списка столбцов упорядочения записывается после текста последнего ис­
ходного SELECT-запроса.
Поскольку порядок записи всех указанных операторов одинаковый, здесь будет
приведен только один простой пример, который рассматривался в предыдущей
главе при изучении операций реляционной алгебры, где использовалась ситуа­
ция с двумя исходными отношениями, представляющими состав изделий:
г — Изделие 1
s — Изделие 2
Код_дет

Название

Вес

Код_дет

Название

Вес

01

А

1

02

д

2

03

В

2

03

в

2

04

С

3

04

с

3

Запрос 19

Какие типы деталей необходимы для производства обоих изделий?
Для достижения этой цели необходимо выполнить операцию объединения,
где запрос будет выглядеть следующим образом:
(SELECT *
FROM г )
UNION CORRESPONDING
(SELECT *
FROM s ) ;

Поскольку обе таблицы имеют все общие столбцы, то результирующее от­
ношение, которое содержит все детали, входящие в состав обоих изделий,
будет выглядеть так:
t

Код_дет

Название

Вес

0Ï

А

1

02

д

2

03

В

2

04

С

3

По умолчанию при выполнении запроса на объединение дубликаты корте­
жей всегда исключаются. Поэтому, если найдутся детали, которые входят
в состав обоих изделий, то они все равно в результирующий список попадут
только один раз.
В SQL один и тот же запрос можно выполнить различными способами
и этот запрос не является исключением. Тот же результат можно получить
простым изменением фразы w h e r e первой части исходного запроса, соеди­
нив локальные условия логической операцией ИЛИ и исключив дубликаты
кортежей.
Открытые соединения

При выполнении запросов часто необходимо проводить соединение данных
разных таблиц. Одна из возможностей реализации соединений заключается
в использовании условий, задаваемых в части w h e r e оператора s e l e c t .
В этом случае из двух таблиц комбинируются строки путем образования по
заданным условиям сцепленных пар строк, по одной из каждой таблицы,
для которых эти условия были определены и истинны. В качестве условия
сцепления строк можно использовать, например, факт равенства значений
сопоставляемых столбцов. Если строка одной из таблиц не находит себе

соответствия в другой, то она не попадает в результирующий набор данных.
Такое соединение называется внутренним.
Стандарт SQL2 расширил понятие условного соединения. В нем предусмот­
рено образование открытых соединений, при которых в результирующую
таблицу помещаются также строки, не удовлетворяющие условию соедине­
ния. Необходимость выполнения подобных соединений часто встречается
в действительности. Например, бывает необходимо в результирующую таб­
лицу поместить все строки одной из исходных таблиц, а если для какой-то
ее строки не находится соответствующей строки во второй таблице, то на
место этой второй строки помещаются неопределенные значения.
Существуют три типа открытых соединений:
□ left j o in — левое открытое соединение; в результат входят все строки
левого операнда-таблицы, а части результирующих строк, для которых не
было соответствующих значений в правой таблице-операнде, дополняют­
ся значениями NULL;
□ right j o in — правое открытое соединение; в результирующую таблицу
включаются все строки правой таблицы-операнда, а недостающие части
из левой таблицы-операнда заполняются NULL-значениями;
□ full j o in — полное открытое соединение; выполняются одновременно и
левое и правое открытые соединения: в результирующую таблицу вклю­
чаются все строки и левой и правой таблиц. В том случае, если какаялибо строка из какой-то таблицы не может быть сцеплена со строкой из
другой таблицы, то недостающие значения определяются как NULLзначения.
Для того, чтобы можно было отличать открытые соединения от внутреннего
соединения, последнее обозначается словом inner .
Запрос 20
БД НИР. Вывести таблицу, где будут представлены все специалисты отделов и
для каждого специалиста будут перечислены все этапы, в выполнении которых он
мог принимать участие. По каждому этапу для каждого специалиста необходи­
мо проставить величину выплаченных за работу сумм. Если же по какой-то при­
чине начисления не были произведены, то их определить как NULL-значения.
Операция внешнего объединения может использоваться для формирования
источников в предложении f r o m , поэтому реализация такого запроса воз­
можна при помощи следующей SQL-конструкции:
SELECT ЯЗ.ФИО, R 3 . Э тап, R 3 . Начисления
FROM (R1 INNER J O IN R2) LEFT JO IN R3 USING (ФИО, Э т а п );

В данном запросе во фразе from произведено вначале внутреннее соедине­
ние таблиц R1 и R2, а затем полученная таблица используется в открытом
левом соединении с таблицей R3 по столбцам ФИО и Этап.

Часть III. Языки баз данных

292

Результат выполнения такого запроса:
ФИО

Этап

Начисления(руб)

С ем енов Т.Т.

Этап_1

1000

П росов С.М.

Этап_1

2000

М ехова И.И.

Этап_1

500

С ем енов Т.Т.

Этап_2

500

П росов С.М.

Этап_2

500

М ехова И.И.

Этап_2

1000

С ем ен ов Т.Т.

Этап_3

NULL

П росов С.М.

Этап_3

1000

М ехова И.И.

Этап_3

1000

Н емцов Я.Ю.

Этап_3

2000

Яров И.М.

Этап_3

NULL

Немцов Я.Ю.

Этап_4

2000

Яров И.М.

Этап_4

3000

9.3.2. Операторы манипулирования данными
В предыдущем разделе были рассмотрены возможности языка SQL при ор­
ганизации выборки информации из базы данных. Этот раздел посвящен тем
структурам языка, которые должны использоваться для модификации со­
держимого БД. К операциям модификации данных относятся три операции:
□ операция удаления записей — ей соответствует оператор d e l e t e ;
□ операция добавления или ввода новых записей — ей соответствует опера­
тор i n s e r t ;
□ операция изменения (обновления записей) — ей соответствует оператор
UPD ATE.

Рассмотрим каждый из операторов подробнее.
Все операторы манипулирования данными позволяют изменить данные
только в одной таблице.
Оператор ввода данных IN S ER T

Оператор ввода данных

in s e r t

INSERT INTO имя_таблицы

имеет следующий синтаксис:

[ (< с п и с о к с т о л б ц о в > )] VALUES

(с с п и с о к зн а ч е н и й )

Подобный синтаксис позволяет ввести только одну строку в таблицу.
Например, введем нового студента в таблицу S2 БД Сессия:
INSERT INTO S2

( ФИО, Группа)

VALUES ('С идо р ов П . П . \

'02-КТ-21');

Задание списка столбцов необязательно тогда, когда, как в данном случае,
вводится строка с заданием значений всех столбцов. При таком вводе пред­
полагается, что информация будет вводиться в том порядке, в котором они
описаны в операторе c r e a t e t a b l e . Так как в рассматриваемом примере
вводится полная строка, то можно не задавать список столбцов, ограничить­
ся только заданием перечня значений, в этом случае оператор ввода будет
выглядеть следующим образом:
INSERT INTO S2
VALUES ( 'Сидоров П . П . ' 0 2 - К Т - 2 1 ' ) ;

Если столбец при описании таблицы имеет признак n o t n u l l , т о оператор
i n s e r t должен обязательно содержать данные для ввода в каждую строку
этого столбца. Поэтому, если в таблице для всех столбцов ввод обязателен,
то каждая вводимая строка должна содержать полный перечень вводимых
значений, а указание имен столбцов в этом случае можно опустить. В то же
время, если имеется хотя бы один необязательный столбец, в который не
вводится значение, задание списка имен столбцов — обязательно.
Между списком имен столбцов и списком значений должно быть следую­
щее соответствие:
□ количество элементов в обоих списках должно быть одинаковым;
□ между положением элементов в списках должно быть строгое соответст­
вие, которое определяется слева направо: первый элемент одного списка
соответствует первому элементу второго списка и т. д.;
□ типы данных соответствующих элементов списков должны быть одина­
ковые и принадлежать к одному и тому же домену.
В набор значений могут быть включены специальные функции и выраже­
ния. Ограничением здесь является то, что значения этих функций должны
быть определены на момент ввода данных.
Оператор ввода данных позволяет ввести сразу ряд строк, если их можно
выбрать из некоторой другой таблицы. В данном случае синтаксис операто­
ра ввода определяется так:
INSERT INTO имя_таблицы [ (<сп исо к с т о л б ц о в > )]
SELECT

Предложение s e l e c t может быть любого допустимого для него вида. Все
ограничения ввода, перечисленные выше, должны строго выполняться и
в этом случае.

Допустим, что есть таблица STUDENT, где указаны основные данные о сту­
дентах, имеющие следующий состав:
STUDENT (ФИО, Гр уп п а , Адрес,

Телефон, Д ата_рож ^ения) .

Тогда возможно поместить из нее в таблицу S2 несколько строк одним опе­
ратором:
INSERT INTO S2

(ФИО, Группа)

SELECT (ФИО, Группа)
FROM STUDENT;

Здесь приведен оператор s e l e c t достаточно простой структуры, но, как бы­
ло выше отмечено, при необходимости можно использовать оператор выбо­
ра любой степени сложности.
Оператор удаления данных DELETE

Оператор удаления данных позволяет удалить одну или несколько строк из
таблицы в соответствии с условиями, которые задаются для удаляемых
строк. Синтаксис оператора d e l e t e следующий:
DELETE FROM имя_таблицы
[WHERE усл о в и я _о тб о р а]

Условия отбора определяют, какие строки должны быть удалены. Если ус­
ловия отбора не задаются, то из таблицы удаляются все существующие в ней
строки. Однако это не означает, что удаляется вся таблица. Исходная табли­
ца остается, но она остается пустой, незаполненной.
Например, если нам надо удалить результаты прошедшей сессии, то мы мо­
жем удалить все строки из отношения S1 следующим оператором:
DELETE FROM S I ;

В результате выполнения данного оператора в БД сохранится только описа­
ние этой таблицы, в которую в дальнейшем можно будет поместить новую
информацию.
Условия отбора в части w h e r e имеют тот же вид, что и условия фильтрации
в операторе s e l e c t . Э т и условия определяют, какие строки из исходного
отношения будут удалены. Например, исключение по какой-либо причине
студента Крисс Р.О. из таблицы S2 можно выполнить оператором:
DELETE FROM S2
WHERE ФИО = 'К р и с с Р. О.

В части w h e r e может находиться встроенный запрос. Однако следует обра­
тить внимание на тот факт, что все операции манипулирования данными
связаны с понятием целостности базы данных и не всегда выполнимы, даже
если синтаксически они написаны правильно. Например, при выполнении
операции d e l e t e , включающей сложный подзапрос, в подзапросе нельзя

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

Операция обновления данных UPDATE

Операция обновления данных u p d a t e требуется тогда, когда требуется изме­
нить содержимое базы данных. Данный оператор, также как и другие опера­
торы обновления информации БД, применяется к одной конкретной табли­
це и имеет следующий формат:
UPDATE имя_таблицы
SET имя_столбца1 = новое_значение1

[, имя_столбца2 = новое_значение2...]

[WHERE условие_отб ора]

Здесь в предложении u p d a t e указывается имя обновляемой таблицы,
в предложении s e t указываются имена столбцов и новые данные. Новые
данные должны быть совместимы с теми данными, которые они призваны
заменить.
Часть w h e r e является необязательной, также как и в операторе d e l e t e . Она
играет здесь ту же роль, что и в операторе d e l e t e , — позволяет отобрать
строки, к которым будет применена операция модификации. Если условие
отбора не задается, то операция модификации будет применена ко всем
строкам таблицы.
Рассмотрим операцию обновления данных таблицы базы данных НИР.
Предположим, что решено все начисления специалистам увеличить на 10%.
Операция обновления информации в связи с этим будет выглядеть следую­
щим образом:
UPDATE

R3

SET Начисления = Начисления * 1 . 1 ;

В том случае, когда модификацию информации необходимо производить
выборочно, требуется использование предложения w h e r e . Допустим, что
в БД Сессия следует произвести изменение данных, поскольку студентка
Думская М.Т. пересдала экзамен по физике и получила оценку "отлично"
вместо "удовлетворительно" Для решения поставленной задачи необходимо
выполнить следующую операцию:
UPDATE S I
SET S I . Оценка = 5
WHERE S I . ФИО =

1Думская M . T . 1 AND

S1 . Дисциплина = ' ФИЗИКА' ;

Операция модификации, также как и операция удаления, может использо­
вать сложные подзапросы.

9.3.3. Операторы определения данных
Выше были рассмотрены различные операторы, позволяющие модифициро­
вать существующую базу данных и выполнять из нее выборки данных. Есте­
ственно, что возможность делать и то и другое появится лишь тогда, когда
такая база данных будет создана. Стандарт ISO не определяет, как должна
создаваться база данных, и каждая СУБД использует в этом вопросе свой
подход. В соответствии со стандартом компоненты базы данных существуют
в некоторой среде, которая включает ряд каталогов, а те, в свою очередь, —
наборы схем.
В указанной иерархии в стандарте предусмотрены только средства регламен­
тации механизма создания и удаления схем — самой нижней ступени дан­
ной иерархии. Механизмы создания всего остального закладываются в саму
СУБД. Оператор создания схемы БД определяется следующим образом:
CREATE SCHEMA [ Имя_схемы | AUTHORIZATION Имя_пользователя]

Следовательно, если пользователю Иванову требуется создать схему
ф а к у л ь т е т , то данный оператор, осуществляющий подобные действия, будет
выглядеть следующим образом:
CREATE SCHEMA ФАКУЛЬТЕТ AUTHORIZATION Иванов;

Для удаления раннее созданной схемы определен следующий оператор:
DROP SCHEMA

Имя_схемы [RESTRICT

| CASCADE]

По умолчанию принимается установка режима r e s t r i c t , при которой уда­
ление выполняется только в том случае, если схема пуста. В противном слу­
чае данный оператор не выполняется. Использование альтернативного ре­
жима c a s c a d e должно производиться с большой осторожностью, так как
реализация его приводит к автоматическому удалению всех связанных с уда­
ляемой схемой объектов.
Хотя рассмотренные два оператора определены в стандарте, на практике
они реализованы в очень редких случаях. Вместо операторов c r e a t e s c h e m a
и d r o p s c h e m a успешно используются не нуждающиеся в дополнительных
пояснениях операторы:
CREATE DATABASE Имя_БД
DROP DATABASE Имя_ БД

Однако конкретные реализации данных операторов могут содержать допол­
нительную информацию. После выполнения второго оператора уничтожает­
ся вся база данных вместе с содержащимися в ней данными.
Поскольку база данных является многокомпонентным объектом, то процесс
создания базы данных не исчерпывается выполнением только одного опера­
тора c r e a t e d a t a b a s e , а предполагает целую последовательность определен­
ных действий. Рассмотрим по очереди дальнейшие действия данного процесса.

Создание таблиц

Несомненно, главными компонентами базы данных являются ее таблицы,
представляющие отношения проекта БД. Создание таблицы осуществляется
посредством оператора create table. Его упрощенная версия выглядит сле­
дующим образом:
CREATE TABLE

Имя_таблицы

( Имя_столбца Тип_даных

[NULL | NOT NULL ]

[, ...J )

Оператор

такого вида приведет к созданию таблицы с именем
которая будет содержать столько столбцов, сколько их зада­
но в операторе. При определении столбца необходимо задать его имя, тип
данных, к которому будут относиться значения этого столбца, а также опре­
делить, можно ли в качестве значения рассматриваемого столбца использо­
вать ключевое слово null. Ключевым словом null помечается такой стол­
бец, который может содержать неопределенные значения. Такая ситуация
возможна для столбцов, соответствующих непервичным атрибутам отноше­
ния. Определения столбцов первичных ключей отношений всегда должны
содержать ключевые слова not null. Любая попытка ввести в такой столбец
NULL-значение будет отвергнута, и, следовательно, будет заблокирована
возможность нарушения ссылочной целостности данных. По причинам, об­
суждавшимся ранее, использование NULL-значений очень часто запрещают
и для столбцов внешних ключей.
Для того чтобы создать таблицу S1 БД СЕССИЯ, необходимо использовать
оператор вида
<им я_табл ицы >,

CREATE TABLE S I

(
ФИО

VARCHAR (20)

NOT NULL,

Дисциплина VARCHAR (20)

NOT NULL,

Оценка

NOT N U L L );

SMALLINT

В данном определении таблицы указаны три столбца, типы данных этих
столбцов, и все они помечены определителем not null. Запрет на NULLзначения в данной таблице введен не из соображений поддержки целостно­
сти данных, а из стремления иметь в таблице только тех студентов, которые
успешно сдали экзамены. Если же допустить присутствие в таблице всех
студентов, которые должны были сдавать определенные для группы экзаме­
ны, то естественно допустить для столбца Оценка NULL-значения для тех
студентов, кто по той или иной причине не сдавал экзамен. Оператор
в этом случае примет вид
CREATE TABLE S I

(
ФИО

VARCHAR (20)

NOT NULL,

Дисциплина

VARCHAR ( 20)

NOT NULL,

Оценка

SM ALLINT);

Полное описание оператора c r e a t e t a b l e д о л ж н о включать средства под­
держки целостности данных. Такие средства представляют собой специфи­
каторы, позволяющие задать ограничения для предотвращения попыток на­
рушить согласованность данных. Базовое определение оператора c r e a t e
t a b l e имеет следующий формат:
CREATE TABLE

имя_таблицы

( { имя_столбца тип_даных

[NOT NULL]

[DEFAULT значен ие по умолчанию]
на допустим ость) ] [, . . . ] }

[UNIQUE]

[CHECK (условие проверки

[PRIMARY KEY (сп и с о к с т о л б ц о в ) , ]
{ [UNIQUE (сп и с о к столбцов) , ]

[,...]}

{ [FORING KEY (сп и с о к столбцов внешних ключей)
REFERENCES имя родительской таблицы
кл ю ч е й -ка н д и д а т о в )] ,
[MATCH {PARTIAL

[ (сп и с о к столбцов

| FULL}

[ON UPDATE правило ссылочной ц ел о стн о сти ]
[ON DELETE правило ссылочной ц е л о с т н о с т и ]]
{[CHECK

[,...]}

(условие проверки на д о п у с ти м о с ть )]

[,...]})

Как ранее было отмечено, согласованность данных опирается на следующие
ограничения:
□ контроль возможности использовать NULL-значения;
□ ограничения для доменов атрибутов;
□ категорная целостность;
□ ссылочная целостность;
□ ограничения предметной области.
Поскольку проблема NULL-значений уже была рассмотрена выше, здесь
стоит только напомнить, что в том случае, когда необходимо запретить по­
мещать NULL-значения в некоторый столбец, в его определение требуется
включить спецификатор n o t n u l l .
Спецификатор c h e c k предназначен для задания ограничений для доменов
атрибутов. Так, например, для столбца Оценка можно задать следующее оп­
ределение:
О ц ен ка SM ALLINT CHECK(О ц е н ка >= 2 AND

О ц ен ка <=

5 );

Присутствие в определении таблицы строки со спецификатором p r i m a r y
призвано обеспечить категорную целостность данных. Обеспечение ка­
тегорией целостности состоит в том, что первичный ключ таблицы должен
иметь уникальное непустое значение в каждой ее строке. Первичный ключ
таблицы S1 является составным и включает два столбца (ФИО, Дисциплина),
его можно определить следующей фразой:
k e y

Фраза p r im a r y k e y может употребляться в таблице только один раз. Если же
надо гарантировать уникальность альтернативных ключей, то можно ис­
пользовать ключевое слово u n i q u e .
Для связывания строк родительской и дочерней таблиц используются внеш­
ние ключи. Каждая строка дочерней таблицы, содержащая этот ключ, свя­
зывается со строкой родительской таблицы, у которой потенциальный ключ
имеет такое же значение, что внешний ключ у дочерней таблицы. Ссылоч­
ная целостность обеспечивается тогда, когда поле внешнего ключа дочерней
таблицы имеет такое значение, которое обязательно присутствует в качестве
значения соответствующего потенциального ключа в родительской таблице.
Например, чтобы связать таблицы 57 и S2 базы данных Сессия, таблицу S2
необходимо определить как родительскую с первичным ключом ф и о , а таб­
лицу 57 — как дочернюю. В таблице 57 столбец ФИО является внешним
ключом, который должен обязательно ссылаться на первичный ключ табли­
цы S2, так как экзамены в сессию могут сдавать только студенты, обучаю­
щиеся в определенной группе и присутствующие в таблице S2. Таким обра­
зом, для таблицы 57 необходимо определить внешний ключ, для чего
служит фраза f o r i n g k e y . Данный ключ определяется следующим образом:
FORING KEY ФИО REFERENCES S2.

Произведенное определение внешнего ключа позволит системе отклонить
любые попытки ввести в таблицу 57 сведения о таком студенте, которого
нет в таблице S2.
В операторе c r e a t e t a b l e есть средства регламентировать деятельность сис­
темы и в случаях обновления информации посредством таких операторов,
как u p d a t e и d e l e t e . Поддержка ссылочной целостности предполагает рег­
ламентацию поведения системы в случае попытки с помощью операторов
u p d a t e и л и d e l e t e обновить или удалить значение потенциального ключа
в родительской таблице, если с ним связана хотя бы одна строка дочерней
таблицы. Указанная регламентация осуществляется посредством фраз o n
u p d a t e и o n d e l e t e предложения f o r i n g k e y . Пользователь должен выбрать
один из возможных квалификаторов:
□ c a s c a d e — удаление (изменение) строки из родительской таблицы при­
водит к автоматическому удалению (изменению) всех ссылающихся на
нее строк дочерней таблицы; если дочерняя таблица связана с другими
таблицами, то изменения распространяются далее аналогичным образом;
□ s e t n u l l — удаление строки из родительской таблицы приводит к авто­
матическому присвоению внешним ключам ссылающихся строк дочер­
ней таблицы NULL-значений; этот вариант может использоваться только
в том случае, если в определении столбца внешнего ключа отсутствует
ключевое слово n o t n u l l ;
□ s e t d e f a u l t — удаление строки из родительской таблицы приводит
к автоматическому присвоению внешним ключам ссылающихся строк

дочерней таблицы значений, принимаемых по умолчанию; этот вариант
может использоваться только в том случае, если в определении столбца
внешнего ключа присутствует ключевое слово default и задано значе­
ние, используемое по умолчанию;
□ no action — удаление (изменение) строки из- родительской таблицы от­
меняется; этот квалификатор используется по умолчанию также и в том
случае, когда фраза on delete ( on update) опущена.
В определении создаваемой нами таблицы S1 для внешнего ключа фио на
случай удаления или обновления строки родительской таблицы S2 должен
быть использован вариант cascade, так как сдавать экзамены, а значит и
присутствовать в данной таблице, имеют право только студенты, зачислен­
ные в определенную группу.
Способ обработки значений внешнего ключа может быть уточнен определи­
телем match. Если для таблицы указывается определитель match full , то
предполагается, что все компоненты внешнего ключа имеют либо некоторое
конкретное значение, либо значение null.
При использовании определителя match partial предполагается, что все
компоненты внешнего ключа либо имеют значение null, либо в родитель­
ской таблице должна существовать по крайней мере одна строка, удовлетво­
ряющая всем непустым значениям внешних ключей.
Исходя из сказанного, перепишем оператор создания таблицы S1 БД Сессия
следующим образом:
CREATE TABLE S I

(

ФИО

VARCHAR ( 20)

Дисциплина

VARCHAR ( 20 )

NOT NULL,
NOT NULL,

Оценка

SMALLINT

NOT N U L L );

PRIMARY KEY (ФИО, Д и сц и п л и н а),
FORING KEY ФИО REFERENCES S2
ON UPDATE CASCADE
ON DELETE CASCADE);

Учитывая то, что операторы языка SQL транслируются в режиме интерпре­
тации, создавать таблицы необходимо в определенном порядке: вначале ро­
дительские, а затем дочерние. В противном случае появятся сообщения об
ошибке в том случае, когда в определении дочерней таблицы будут присут­
ствовать ссыпки на еще не существующую родительскую таблицу.
О бновление таблиц
В уже созданную таблицу изменения могут быть внесены с помощью опера­
тора alter table , который имеет следующий обобщенный формат:
ALTER TABLE

имя_таблицы

[ADD [COLUMN] имя_столбца тип_даных

[NOT NULL]

[UNIQUE]

[DEFAULT зн а чен и е по умолчанию]
допустим о сть) ] ]
[DROP [COLUMN] ]
[ADD [CONSTRAINT

имя_столбца

[CHECK (условие проверки на

[R ISTR IC T

|

CASCADE]]

[имя о гр а н и ч е н и я ] ] ограничение]

[DROP CONSTRAINT имя ограничения

[R ISTR IC T

[ALTER [COLUMN] SET DEFAULT значение
[ALTER [COLUMN] DROP DEFAULT]

| CASCADE]]

по умолчанию]

В данном формате предусмотрены возможности для выполнения ряда дей­
ствий:
□ добавить новый столбец в существующую таблицу — add column;
□ удалить столбец из существующей таблицы — drop column;
□ добавить в определение таблицы новое ограничение — add constraint ;
□ удалить из определения таблицы существующее ограничение — drop
constraint ;

□ задать для существующего столбца значение по умолчанию —
[COLUMN] SET default;

alter

□ отменить установленное для столбца значение по умолчанию

alter

[COLUMN] DROP DEFAULT.

Параметр "ограничение" во фразе add constraint может принимать одно из
следующих значений: primary key, unique , foring key, check. Таким обра­
зом, используя эту фразу можно определять первичные, потенциальные и
внешние ключи и задавать дополнительные ограничения.
Фразы, связанные с удалением компонентов таблиц, — будь то столбец или
ограничения, содержат дополнительный квалификатор, позволяющий уточ­
нить порядок удаления:
О cascade — удаление осуществляется каскадным образом с удалением
ссылок на удаляемый компонент;
□ RISTRICT — удаление отменяется, если существуют ссылки на удаляемый
компонент; это значение квалификатора используется по умолчанию.

Значения остальных указанных в операторе alter table параметров совпа­
дают со значениями параметров в определении оператора create table.
Одним оператором alter table можно провести только одно изменение
таблицы, например, за один раз можно добавить один столбец. Чтобы доба­
вить два столбца в таблицу, необходимо использовать два оператора.
Добавить в таблицу 57 столбец Группа, содержащий символьный тип дан­
ных, можно с помощью оператора:
ALTER TABLE SI
ADD Группа

v a rc h a r

(7 ) NOT NULL;

У даление таблиц
Ставшая ненужной таблица может быть удалена из базы данных оператором
DROP TABLE имя таблицы [R IS T R IC T

| CASCADE],

Ключевые слова r is t r ic t и cascade используются для определения условий
удаления таблицы в том случае, если в базе данных присутствуют ее дочер­
ние таблицы. Ключевое слово r ist r ic t при наличии в базе данных зависи­
мых от удаляемой таблицы объектов вызовет отмену удаления. Ключевое
слово cascade в этой ситуации вызовет автоматическое удаление всех объек­
тов базы данных, существование которых зависит от данной таблицы.
Удалим таблицу Sl\
DROP TABLE S I ;

В данном операторе ключевые слова r ist r ic t и cascade не использовались,
так как таблиц, зависимых от таблицы S1, в базе данных нет.
Итак, в этом разделе были рассмотрены основные операторы создания базо­
вых структур данных и операторов манипулирования данными стандарта
языка SQL. Следует отметить, что диалекты языка SQL, реализованные
в конкретных СУБД, включают в себя дополнительные средства, расши­
ряющие возможности стандарта языка.
О ператоры с о зд а н и я и удален и я и н дексов
Поскольку базы данных предназначены для хранения больших объемов ин­
формации, эффективность их использования в информационных системах
во многом определяется скоростью выборки данных. Для увеличения скоро­
сти выборки в БД обычно используют специальную структуру, которая на­
зывается индексом. Стандарт языка SQL не предусматривает использование
индексов. Но тем не менее разработчики СУБД охотно идут на включение
средств поддержки индексов в систему, несмотря на то, что наличие индек­
са увеличивает нагрузку на систему из-за необходимости обновлять его при
каждом изменении данных таблицы, поскольку существенное повышение
скорости запросов окупает данные затраты.
Операторы создания и удаления индекса имеют следующий формат.
Создать индекс:
CREATE [UNIQUE]

INDEX им я_индекса

ON и м я_таб лицы

(с т о л б е ц

[ ASC|

DESC]

[,...])

Удалить индекс:
DROP IN D E X и м я _ и н д е к с а

Если в операторе create index используется квалификатор unique , то уни­
кальность значений индекса автоматически поддерживается системой. Для
каждого из ключевых столбцов можно указать порядок следования значений:
по возрастанию — asc (используется по умолчанию) и по убыванию — desc .

9.4. Встроенный SQL
Язык структурированных запросов не относится к традиционным языкам
программирования, поскольку он не содержит традиционные операторы,
управляющие ходом выполнения программы, операторы описания типов и
многое другое. Он содержит только набор стандартных операторов доступа
к данным, хранящимся в базе данных. Его операторы в том виде, в котором
они выше рассмотрены, предназначены для доступа к базе данных в инте­
рактивном режиме, позволяющем создавать базу данных, модифицировать
ее, а также выполнять запросы к хранящейся там информации.
В том случае, когда требуется обеспечить управление базой данных в авто­
матическом режиме, последний реализуется посредством выполнения при­
кладных программ на некотором базовом языке программирования, в кото­
рые встраиваются указанные операторы. Стандарт ISO предусматривает
обязательную поддержку внедренных SQL-операторов для языков ADA,
Fortran, С, PL/1, COBOL, Pascal. В основе встроенного SQL лежит опреде­
ленная концепция, которая позволяет ему применять любое выражение
SQL, если оно может быть использовано интерактивно.
Встраиваемый SQL-фрагмент начинается с инструкции e x e c s q l и закан­
чивается так, как это принято в базовом языке.
Прикладная программа со встроенными операторами SQL поступает на вход
препроцессора SQL, который компилирует встроенные операторы.
Обмен информацией прикладной программы и операторов SQL осуществля­
ется посредством переменных базового языка программирования. На эти
переменные могут ссылаться DML-операторы SQL, используя их значения
в качестве исходной информации или в качестве результатов запросов. Все
переменные такого рода должны быть определены в разделе описаний
встроенного SQL, а сами ссылки должны включать префикс в виде двоето­
чия для отделения их от имен столбцов SQL.
Обмен информацией между базовой программой и SQL-операторами дол­
жен осуществляться с учетом разного характера их работы с данными.
В процедурных языках данные обрабатываются построчно, в то время как
в SQL операции производятся одновременно с данными всех строк таблицы.
Поэтому в те операторы языка SQL, которые при внедрении в прикладную
программу могут работать с целыми таблицами, потребовалось внести до­
полнительные возможности. Таким оператором является s e l e c t , который
должен возвращать данные, затребованные запросом.
С указанной точки зрения возвращаемые оператором s e l e c t данные можно
разбить на две категории:
□ результаты однострочных запросов в виде одной строки данных;
□ результаты многострочных запросов в виде целого набора строк.

9.4.1. Однострочные запросы
Первая ситуация вызывает во встроенном операторе s e l e c t появление до­
полнительного раздела i n t o , содержащего список переменных базового
языка, в которые будет помещен результат однострочного запроса.
Структура оператора s e l e c t при этом принимает вид
SELECT [D IS T IN C T l ALL]

{*|

[« с п и с о к п о л е й > ]}

INTO < сп исо к переменных б азо в о го языка>
FROM <Список таблиц>
[WHERE < П р ед и кат-ус л о в и е выборки или с о е д и н е н и я ^

Список базовых переменных, предварительно описанных в прикладной
программе, и список полей, чьи значения будут помещаться в указанные
базовые переменные, должны быть согласованы как по порядку их распо­
ложения в списке, так и по их типу.
Например, если база данных создана при помощи структуры
CREATE TABLE S I

(

F IO

VARCHAR ( 20)

NOT NULL/

DICH

VARCHAR ( 20)

NOT NULL,

OHENKA

SMALLINT

NOT N U L L );

);

то запрос к ней, который будет возвращать оценку по дисциплине "Эконо­
мика" студентки Ивановой Я.С., может выглядеть следующим образом:
DECLARE 0 F IO VARCHAR ( 20)
DECLARE 0DICH VARCHAR ( 2 0 ) ,
SET @FIO =

0OHENKA SMALLINT

'И ванова Я . С . '

SET 0DICH =

'Э ко н о м и ка'

SELECT Sl.OHENKA
INTO 0OHENKA
FROM S I
WHERE S l . F I O

= 0 F IO AND S l.D IC H = 0DICH

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

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

Курсоры позволяют извлекать строки из таблицы по одной, проверять их
содержимое, выполнять различные операции на основе содержимого полей
и передавать их в процедурный код обработки. Поместив код SQL в цикл
обработки, можно строка за строкой полностью обработать всю таблицу.
Для работы с курсором в SQL добавлено несколько операторов:
□

declare cursor

— оператор определения курсора;

□

open

□

fetch

— оператор перемещения курсора;

□

close

— оператор закрытия курсора.

— оператор открытия курсора;

О ператор оп ределен и я курсора
В программе можно использовать только предварительно объявленный кур­
сор. Объявление курсора производится оператором declare cursor, кото­
рый объявляет его имя и определяет связанный с ним запрос. Данный опе­
ратор имеет следующий синтаксис:
DECLARE

<

и м

я

кур сор а>

[IN S E N S IT IV E ]

[SCROLL]

CURSOR

FOR <вы ражение з а п р о с а SELECT>
[FOR

{READ ONLY

| UPDATE

[OF С перечень имен с т о л б ц о в > ] } ] ;

Имя курсора строится по правилам базового языка, и оно должно быть уни­
кальным. При объявлении курсора можно использовать переменные базо­
вого языка. Выражением запроса может быть любой допустимый оператор
select . Выполнение оператора declare cursor не вызывает выполнение
объявленного в нем запроса. Для выборки данных дополнительно к объяв­
лению необходимо использовать оператор открытия курсора open.
Параметр in s e n s it iv e (нечувствительный) определяет для данного курсора
такой режим создания набора строк, при котором все изменения данных,
произведенные другими пользователями, в течение времени, когда рассмат­
риваемый курсор остается открытым, не видны в нем. Область действия
курсора в такой ситуации, следовательно, распространяется на строки, соот­
ветствующие исходным условиям запроса. Нечувствительный к обновлени­
ям курсор может быть открыт только для чтения. Для того чтобы запретить
обновление данных или их удаление в области действия курсора, необходи­
мо использовать спецификацию read only. Подобная спецификация обес­
печивает наивысшую скорость обработки такого курсора, поскольку изме­
нения данных не предусматриваются, а следовательно, не нужно тратить
время на контроль обеспечения целостности базы данных.
Специалисты советуют избегать режимов работы с несколькими открытыми
курсорами. Несколько открытых курсоров могут стать причиной ряда про­
блем, возникающих в результате их взаимодействия, которые можно разре­
шить только путем локализации транзакций.

Параметр scroll определяет возможности оператора перемещения по кур­
сору и будет рассмотрен несколько позже.
Ускорить работу с курсором можно также в том случае, когда известно, что
обновляться информация будет только в некоторых столбцах.
Параметром u p d a t e o f с п е р е ч е н ь имен с т о л б ц о в > можно определить те
столбцы, для которых допустимы изменения значений в процессе работы
с данным курсором. Если этот параметр не указан, то предполагается, что
для изменений данных доступны все столбцы курсора.
Приведем описание курсора, который позволит получить информацию
о студентах, сдавших предмет "Экономика" на оценку 5.
DECLARE O t l_ c u r s o r IN S E N S IT IV E CURSOR
FOR
SELECT S l . F I O
FROM S I
WHERE S1.0HENKA=5 AND S l.D IC H =

'Э ко н ом ика'

ORDER BY S l . F I O
FOR

READ ONLY

Оператор открытия курсора

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

[U SIN G < с п и с о к п ер ем ен н ы х> ]

При выполнении оператора open производится семантическая проверка
курсора, и прикладная программа получает сведения посредством перемен­
ной sqlcode о выполнении включенного в курсор запроса. Если результат
выполнения операции открытия курсора неудачен, то данная переменная
принимает отрицательное значение.
Выполнение оператора open приводит к отбору строк, которые впоследст­
вии должны быть выбраны согласно запросу, описанному в объявлении
курсора. Выборка осуществляется специальным оператором, который к тому
же способен управлять процессом перемещения курсора.
В ы борка данны х и уп равлен и е п ер ем ещ ен и ем курсора
Выборка данных, сформированных согласно запросу, осуществляется по­
средством оператора fetch , который в простом случае выглядит так:
FETCH < имя к у р с о р а >

IN TO < с п и с о к перем енны х б а з о в о г о

я зы ка >

Данный оператор использует механизм указателя текущей строки. После
открытия курсора упомянутый указатель установлен перед первой строкой
курсора. Выполнение оператора f e t c h , в приведенном выше виде, вызывает
перемещение указателя на следующую строку, которая теперь становится
текущей, и присваивание базовым переменным значений данных из теку­
щей строки.
В расширенном виде оператор
FETCH

[ [ориентация]

FROM]

fetch

имеет следующее представление:

< имя ку р с о р а >

INTO < с п и с о к переменны х б а з о в о г о язы ка>

В данной модификации оператора представлен еще один его компонент —
<ор иентация>.

В SQL99 существует шесть видов ориентации:
□

next

(используется по умолчанию и единственно возможное значение
в SQL и SQL92) — вызывает перемещение указателя на следующую стро­
ку запроса, если он уже указывает на последнюю строку, то оператор за­
вершает свою работу по отсутствию данных;

□

p r io r

— указатель перемещается на предыдущую строку;

□

f ir s t

— указатель перемещается на первую строку;

П

last

□

a b s o lu t e

— указатель перемещается на последнюю строку;
п

— указатель перемещается на строку с номером

п

от начала

выборки;
□

— указатель перемещается на п строк относительно текущей
строки выборки.
Для применения расширенного оператора f e t c h описание курсора обяза­
тельно должно содержать ключевое слово s c r o l l . Такие курсоры называют
прокручиваемыми курсорами.
Реализация прокручиваемых курсоров приводит к возрастанию числа бло­
кировок, так как в этом случае блокируются все записи сформированной
таблицы. Использование простого последовательного курсора значительно
упрощает ситуацию, поскольку каждая уже выбранная запись системой мо­
жет быть разблокирована, что приводит к минимизации числа блокировок и
существенно сказывается на режиме многопользовательской работы.
r e l a t iv e

п

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

курсоры могут породить некоторые проблемы. Закрытие курсора выполня­
ется оператором:
CLOSE <имя курсора:».

Выполнение такого оператора вызывает закрытие таблицы результата запро­
са, созданной оператором открытия курсора. При надобности курсор вновь
может быть открыт.
М одиф икация данны х с и сп ользован и ем курсора
Хотя курсоры в прикладных программах чаще всего используются для про­
смотра данных, в ряде ситуаций их можно применять и для оперативной
модификации данных. Если в запросе отсутствует операция группировки
записей, то в строке, на которую указывает курсор, можно выполнить опе­
рации обновления данных или же произвести удаление этой строки.
Операция удаления текущей строки имеет вид
DELETE FROM <имя таблицы:» WHERE CURRENT OF <имя кур сор а:»

Если указанный в программе курсор открыт, то та строка, на которую он
указывает, удаляется, а указатель курсора устанавливается перед следующей
строкой. Если курсор не указывает на строку, то генерируется ошибка,
а удаление отменяется.
Синтаксис операции обновления определяется следующим образом:
UPDATE <имя таблицы >
SET <имя столбца!.:» =
[ { , < и м я столбц а N > =

{< з н а ч е н и е >

I NULL}

(< з н а ч е н и е >

I NULL}}.. . ]

WHERE CURRENT OF <имя к у р с о р а >

Таким образом, как видно из определения оператора обновления, одним опе­
ратором можно обновить информацию нескольких столбцов одной строки.
Если при выполнении операции обновления возникает некоторая ошибка,
то обновление не проводится.
После выполнения операции обновления позиция курсора не меняется.
Следует отметить, что выполнение операций модификации не всегда воз­
можно. Так, например, необходимо следить за тем, чтобы запрос считывал
данные из одной таблицы, в нем не разрешается использовать конструкции
DISTINCT, GROUP BY, HAVING, ORDER BY.

Вопросы и упражнения
1. Какие две составляющие части, необходимые для работы с базами дан­
ных, присутствуют в языке SQL? Объясните их назначение.
2. Какой ряд типов данных определен в языке SQL1?

3. Дайте характеристику разных категорий операторов, которые включает
в себя язык SQL.
4. Объясните порядок следования фраз в операторе s e l e c t . Какие фразы
в операторе являются обязательными, а какие — нет?
5. Объясните порядок использования в стандарте языка SQL агрегатных
функций. Какие ограничения на них накладываются?
6. В чем заключается суть операции группировки? Каковы условия ее ис­
пользования?
7. Приведите пример необходимости организации вложенных запросов.
Какими средствами для их реализации располагает оператор s e l e c t ?
8. Во многих случаях для получения ответа на запрос необходимо объеди­
нить информацию из нескольких исходных таблиц. Как это может быть
реализовано в языке SQL?
9. Какими структурами представлены в языке SQL операторы манипулиро­
вания данными, позволяющие модифицировать существующую базу
данных?
10. Какую последовательность действий предполагает процесс создания та­
кого многокомпонентного объекта, как база данных? Поясните синтак­
сис необходимых структур.
11. Используя базу данных Сессия, получите:
• список студентов — претендентов на отчисление, считая, что в отно­
шении S1 находятся окончательные результаты сессии, и поэтому от­
числению подлежат все студенты, которые не сдали или не сдавали
два и более из положенных экзаменов в сессию;
• список студентов, переведенных на следующий курс;
• отчислить студентов по результатам текущей сессии.

Глава 10

868088
888868

Язык запросов по образцу
Язык QBE (Query-by-Example — Язык запросов по образцу) был разработан
отделением IBM Research в конце 70-х на примере шаблонов, предложен­
ных Робертом Злуфом в 1977 году. Он был задуман как средство, облегчаю­
щее работу для неспециалистов. Этот язык получил у пользователей столь
широкое признание, что в настоящее время он реализован практически во
всех популярных СУБД.
Язык QBE использует визуальный подход для организации доступа к ин­
формации в базе данных. Работа в нем осуществляется посредством задания
образцов значений в шаблоне запроса.
QBE может быть использован для ввода запросов к информации, содержа­
щейся в одной или более таблиц, а также для определения набора полей,
которые должны присутствовать в результирующей таблице. Отбор записей
может проводиться по конкретному или общему критерию и предусматри­
вать выполнение необходимых вычислений на основе сохраняемой в табли­
цах информации. Кроме того, средства языка QBE можно использовать для
выполнения различных операций над таблицами — например, для вставки и
удаления записей, модификации значений полей или создания новых полей
и таблиц.
Самые популярные пакеты баз данных, поддерживающие язык QBE: Mi­
crosoft Access и Borland Paradox. Синтаксис QBE отдельных пакетов может
не совпадать с официальным синтаксисом корпорации IBM. Например,
в пакете Access используется более современный метод по сравнению
с другими — графический запрос по образцу (GQBE — графический QBE),
получивший свое название потому, что объединения указываются графиче­
ски, а не с помощью элементов примеров и имеется полная поддержка
функции Drag-and-Drop (перетаскивания различных графических элементов
интерфейса пользователя). В свою очередь, в пакете Paradox for Windows
используется метод QBE, который весьма напоминает оригинальный QBE.
Оба пакета при создании QBE-запросов неявно генерируют предложения SQL,
эквивалентные по выполняемым действиям данному QBE-запросу по извле­
чению данных с сервера. Посмотреть этот SQL-оператор можно в окне SQL.

Access позволяет пойти и обратным путем, благодаря чему можно вносить
изменения в сгенерированное предложение SQL, и при этом они будут от­
ражаться в бланке QBE Access.

10.1. Создание запросов в MS Access
Запросы в Access подразделяются на несколько перечисленных ниже типов:
□ запросы на выборку;
□ запросы с обобщением;
П параметрические запросы;
□ запросы на выборку дубликатов;
□ запросы на выборку записей, не имеющих соответствия;
□ перекрестные запросы;
□ запросы с автоподстановкой;
□ активные запросы;
□ специфические запросы.
Об основных типах запросов будет рассказано ниже.
Access является наиболее удобным визуальным средством создания запро­
сов. Для быстрого создания запросов в Access предусмотрены мастера, одна­
ко в большинстве случаев приходится использовать QBE. Диалоговое окно
создания запроса, представляющее собой графический инструмент языка
QBE, показано на рис. 10.1.

Рис. 10.1. Диалоговое окно создания запроса в Microsoft Access

Окно создания разделено на две части. В верхней части находится область,
отображающая таблицы и связи между ними. Связи между таблицами до­
бавляются в запрос автоматически, однако их можно удалить, изменить или
создать новые.
II Зак. 3303

Таблица в нижней части предназначена для ввода полей и условий запроса.
Ячейки в строках полей, имен таблиц и сортировки содержат раскрываю­
щиеся списки. Групповые и агрегатные функции доступны при выборе
"Групповые операции” из выпадающего меню. Для определения образца ин­
тересующих пользователя записей в графической среде этого окна для вы­
борки, перетаскивания и манипулирования содержащимися в нем объекта­
ми можно использовать мышь.
Окно создания запроса имеет пять режимов, также доступных из
выпадающего меню:
1. Режим конструктора. Позволяет создавать запросы при помощи QBE.
2. Режим SQL. Ручной ввод всех запросов.
3. Режим таблицы. Вывод результатов запроса.
4. Сводная таблица. Вывод результатов в виде таблицы с древовидной
структурой.
5. Сводная диаграмма. Вывод результатов в виде диаграмм.
Режим конструктора и режим SQL взаимозаменяемы, т. е. при выборе од­
ного режима, появляется возможность перехода в другой.
Свойства запроса (рис. 10.2) также могут влиять на результаты выполнения.
Свойства запроса
Общие j
Описание ............................................ ИЗапрос на отбор набора максимальны;-®!
Режим по умолчанию......................... . Режим таблицы
Вывод всех полей.............................. . Нет
Набор значений............................ . , ,g ï o
Уникальные значения....................... . Нет
Уникальные записи........................... , Нет
При запуске предоставляются права , Пользователя
(текущая)
База данных-источник............,
Строка подключения-источник , , . . ,
Блокировка записей......... .................. Отсутствует
Тип набора записей............................ , Динамический набор
Время ожидания ODBC.......................
Фильтр................................ ................
Порядок сортировки.........................
Максимальное число записей............
Ориентация .......................................... Слева направо
Имя подтаблицы................................
Подчиненные поля..............................
Основные поля...................................
Высота подтаблицы............................ Осм
Развернутая подтаблица................... Нет
=
=
. =
. =
..= = = = = = .....= = ü

Р и с . 1 0 .2 . Свойства запроса

В отличие от других баз данных, в MS Access для изучения основ не требу­
ется создавать новую базу данных и вводить в нее данные. Все версии про­
граммы поставляются в комплекте с учебной базой данных Борей (в англий­
ской версии Northwind). Эта база доступна в подменю: Главное меню |
Справка | Примеры баз данных | Борей. В дальнейшем для иллюстрации воз­
можностей языка QBE будут использоваться операции над базой данных
Борей.

10.2. Создание запросов на выборку
Запросы на выборку данных являются самым распространенным типом за­
просов. Они предназначены для извлечения данных из одной или более
таблиц. Выбранная информация отображается на экране в виде сетки с по­
лученными результатами, при этом допускается некоторым образом ограни­
ченное обновление содержащихся в ней записей. В сетке извлеченная из
таблицы информация отображается в виде набора столбцов и строк — по­
добно обычной электронной таблице. Запросы на выборку допускают груп­
пирование записей, а также вычисление сумм, счетчиков, средних значений
и применение обобщающих функций других типов.
При создании нового запроса с помощью конструктора в добавление к окну
запроса появляется также окно добавления таблицы (рис. 10.3). В данном
окне кроме таблиц для добавления доступны также запросы. Это позволяет
решить проблему отсутствия визуальных средств поддержки вложенных за­
просов. После закрытия окно доступно из popup-меню окна запроса.

Р и с . 1 0 .3 . Окно добавления таблицы к запросу

Добавлять поля в запрос можно путем переноса их из таблиц на нужную
колонку таблицы запроса, либо выбором поля из раскрывающегося списка.
Иu jiii4 .jjim* u ;jim»u jm u .jilim
» m m! u .jiii..jj.innr|
: - ?
*
jЖ
КодТовара
Марка
КодПоставщика
КодТипа
ЕдинииаИзмеоения

'
JÜ1

СамыеДорогиеТовары: Марка
Товары
и

Цена
Товары
по убыванию
и

Р и с . 1 0 .4 . Запрос "Десять самых дорогих товаров"

Рассмотрим простой пример: выбор десяти самых дорогих товаров. Откроем
конструктор нового запроса и добавим таблицу Товары (рис. 10.4), из кото­
рой будет производиться выборка. Перенесем в сетку запроса поля Марка и
Цена. Поле Марка будет служить для удобного отображения названий това­
ров, а поле Цена — для сортировки и выбора самых дорогих товаров. Доба­
вим перед словом Марка надпись СамыеДорогиеТовары:, означающую, что в
результирующей таблице так будет называться данное поле. Выберем для
поля Цена сортировку по убыванию, необходимую для выбора самых доро­
гих, а не дешевых товаров. Откроем окно свойств запроса и введем число 10
в поле Набор значений, чтобы оставить только десять записей в результи­
рующей таблице. Выберем режим SQL. Запрос должен выглядеть следую­
щим образом:
SELECT ТОР 10 Товары.Марка AS СамыеДорогиеТовары, Товары.Цена
FROM Товары
ORDER BY Товары.Цена DESC;

10.2.1. Задание критериев отбора
К ри т ери ем о т б о р а называют ограничения, которые накладываются на резуль­
таты выполнения запроса с целью выборки только тех полей или записей
данных, которые представляют интерес для пользователя. Самым простым
критерием является отбор полей, значения которых совпадают с введенным
значением.

При задании критериев отбора можно также использовать логические опе­
раторы (AND, OR, NOT), операторы b e t w e e n и l i k e , операторы сравнения

(>, <, >=, <=, =), оператор i n . Ниже приведено несколько примеров зада­
ния критериев отбора:
□ 12000 — значение поля совпадает с данным числом;
□ "п е т р о в и .я. " — значение поля совпадает с данной строкой;
□ >= "5” o r < "2" — значение поля больше 5 или меньше 2;
□ b e t w e e n 1 0 0 a n d 200 — все записи со значением поля от 100 до 200;
□

l ik e

”Сидор?в* "

(a n s i - 89) — значение поля удовлетворяет приведенному

шаблону;

□

in
("Петров",
"С идоров») — значение поля совпадает с одним из
приведенных значений;
□ n o t n u l l — значение в поле существует, is n u l l — значения не сущест­
вует.
Символ ”?" в выражении l i k e указывает местоположение единственного не­
известного символа, а символ
подразумевает произвольное их количество.
Любые условия отбора можно вводить в одноименное поле сетки запроса
в конструкторе. Для задания условий в сетке запроса можно использовать
все строки данной колонки, начиная со строки Условие отбора. Причем все
условия, введенные в разные ячейки, при генерации SQL-оператора объе­
диняются дизъюнктивно (ключевым словом o r ).

10.2.2. Многотабличные запросы
При добавлении более одной таблицы Access отображает имеющиеся связи
между таблицами и автоматически связывает таблицы с совпадающими по­
лями. Новую связь можно легко добавить, если перенести поле одной таб­
лицы на требуемое для связи поле другой. Можно также изменить имею­
щиеся связи (рис. 10.5) и удалить старые.
Откроем конструктор нового запроса и добавим таблицы Товары и Заказано
из окна добавления таблиц и запросов. Заметим, что в окне таблиц и связей
автоматически появилась связь между таблицами. В данном случае это
имеющаяся в базе данных связь. MS Access также автоматически может соз­
дать связь, бели в обеих таблицах имеются поля с одинаковыми названиями
и типами. Перенесем поле Марка из таблицы Товары, которое будет
служить для удобного отображения названий товаров, и поля: КодЗаказа,
КодТовара, Цена, Количество, Скидка из таблицы Заказано (рис. 10.6) для
отображения дополнительной информации о товарах. Сгенерированный
SQL-оператор будет выглядеть следующим образом:
SELECT З а к а з а н о .К о д З а к а з а , З ака за н о .К о д Т о в ар а, Товары .М арка,
З а к а з а н о . Ц ен а, З а к а з а н о . Количество, З а к а з а н о . Скидка
FROM Товары INNER JO IN З ака за н о ON Товары.КодТовара = З ака за н о .К о д Т о в ар а;

JLL*l

! Параметры объ еди н ен и я
Правая таблица

Левая таблица
[И Ш Я Я

^ | (заказано

Левый столбец

Правый столбец

|КодТовара

|КодТовара

L

С 2,
С з,

Объединение только тех записей, в которых связанные поля обеих
таблиц совпадают.
Объединение ВСЕХ записей из "Товары" и только тех записей из
"Заказано", в которых связанные поля совпадают.
Объединение ВСЕХ записей из "Заказано" и только тех записей из
"Товары", в которых связанные поля совпадают.
OK

]

Отмена

I

Создать

I

Р и с . 1 0 .5 . Параметры связи между таблицами в запросе

Р и с . 1 0 .6 . З а п р о с на выборку из нескольких таблиц

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

10.2.3. Запросы с обобщением
Необходимость обобщения той или иной группы данных появляется доста'
точно часто. Под обобщением в MS Access понимается группировка данных
по отдельным полям и использование агрегатных функций (sum, m ax, avg

и т, д.). В разделе Групповая операция, доступном из Popup-меню, можно
выбрать один из следующих типов обобщения для поля:
□ г р у п п и р о в к а . Группировка записей результатов запроса по полю.
□

sum.

Суммирование всех значений данного поля.

□
□

A vg.

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

M in .

□ мах. Нахождение максимального числа.
□ count. Подсчет количества строк в результирующей таблице.
□ stdev. Подсчет среднеквадратичного отклонения от среднего значения.
□ var. Дисперсия значений поля.
□

F ir s t.

□

L a s t.

Извлечение первой записи.
Извлечение последней записи.

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

Условия отбора для поля, которое не участвует в группировке.
Если для поля выбирается этот параметр, автоматически снимается фла­
жок Вывод на экран.
Условие.

Рассмотрим пример: вывод списка проданных товаров, сгруппированных по
типам.
Добавим в окно конструктора нового запроса таблицы Типы и Товары,
предназначенные для отображения названий и группировки, запрос Сведения
о заказах, служащий для вычисления суммы всех проданных товаров с дан­
ным названием, и таблицу Заказы, используемую для выбора промежутка
времени продажи товаров. Откроем поле Групповая операция из Popup-меню.
Перенесем поля: КодТипа и Категория из таблицы Типы, и поле Марка из
таблицы Товары. Они будут служить для отображения основной информа­
ции о названии товаров, а также для сортировки. Перенесем поле Отпускная
цена из запроса Сведения о заказах, переименуем его, как показано на рис. 10.7,
и установим sum в качестве групповой операции. В этом поле будет произ­
водиться суммирование всех проданных товаров с данным названием.
Перенесем поле ДатаРазмещения из таблицы Заказы, укажем условие в ка­
честве групповой операции и введем в поле Условие отбора значение
b e t w e e n # 1 / 1 / 1 9 9 7 # a n d # 1 2 / 3 1 /1 9 9 7 # , означающее, что данные будут вы­
браны в период с 1 января по 31 декабря 1997 года. Знаки решетки в датах
предназначены для правильного преобразования во внутренний формат при
выполнении запроса.

I ? Продаж и по типам : запрос на выборку

w r
♦

Код Тита
Категория
Описание
Изображение

4
»

-Ч

\
■

ч

'

КодТовара
Марка

'Щ

Поле:
Иия таблицы:
Групповая операция:
Сортировка:
Вывод на экран:
Условие отбора:

'4
1(

КодПоставщика
КодТипа

КодТипа
Типы
Г руппировка

Категория
Типы
Группировка

0

0

или:

Марка
Товары
Г руппировка
по возрастанию

ПродажиТовара: ОтпускнаяЦена
Сведения о заказах

Sum

0

ДатаРаэмещемия

з5саэы

Условие!

0

г

____________________ □ ____________________
Between # 0 1 .0 1 .1 9 9 7 * And # 3 1 .1 2 .1 9 9 7 #

шшшш

à!
г

Р и с . 1 0 .7 . Пример запроса с обобщением

Полученный оператор SQL будет выглядеть следующим образом:
SELECT Типы.КодТипа, Типы.Категория, Товары.Марка, S u m ( [Сведения о
заказах].ОтпускнаяЦена) AS ПродажиТовара
FROM Типы INNER JOIN (Товары INNER JOIN (Заказы INNER JOIN [Сведения о
заказах] ON Заказы.КодЗаказа = [Сведения о заказах].КодЗаказа) ON
Товары.КодТовара = [Сведения о заказах].КодТовара) ON Типы.КодТипа =
Товары.КодТипа
WHERE Заказы.ДатаРазмещения Between #1/1/1997# And #12/31/1997#
GROUP BY Типы.КодТипа, Типы.Категория, Товары.Марка
ORDER BY Товары.Марка;

В учебной базе данных данный пример называется Продажи по типам.

10.2.4. Запросы с параметром
Параметрические запросы создаются тогда, когда определенное условие от­
бора не может быть вычислено системой и требуется ввод данных пользова­
телем. В MS Access параметры часто получают данные от форм, и процесс
ввода значений становится прозрачным для пользователя. Для создания па­
раметра достаточно в условии отбора указать его имя в квадратных скобках
Если необходимо использовать параметр несколько раз, его следует доба­
вить в список параметров, доступный из Popup-меню (рис. 10.9).
Для примера создадим запрос на выборку заказов, выполненных сотрудни­
ками в определенный, заранее неизвестный период. Откроем окно новогс
запроса и добавим таблицы Сотрудники, Заказы и запрос Промежуточна]
сумма заказа. Перенесем поля Страна, Фамилия, Имя из таблицы Сотрудни
ки, которые будут служить для вывода информации о сотрудниках. Перене
сем поля ДатаИсполнения и КодЗаказа из таблицы Заказы. Введем в пол<
Условие отбора колонки ДатаИсполнения значение b e t w e e n [Начальная дата
a n d [конечная дата], означающее выборку данных между двумя заранее неиз
вестными периодами времени (рис. 10.9). Перенесем поле СуммаПродах

из запроса Промежуточная сумма заказа и переименуем его, как показано на
рис. 10.8.
♦. Ю1 х |

\Ж Ш т №

_^

B E : ,- ...

КпдСотруд>*жа

Фамилия

£1
Попе: Страна
таблицы: Сотрудники
Сортировка:
Вывод на тгран:
Условие отбора:
или:

___0_

КодКлиеита
КодСотрудмика
ДатаРатиеще>*1Я

КодЗаказа
Промежуто^паяСуииа
*J

дГ*
Фамилия
Сотрудники

Имя-----' " ' ' '

.0

0

Сотрудники

ДатаИсполнения
Закаты

КодЗаката
Закаты

g

СуммаПродаж: Поомежуто^чаяСу>ыа
Промежуточная сунна таката

0

0

Between [Начальная дата] And [Коне'♦чая дата]

.iL-L

>

Р и с . 1 0 .8 . Запрос с параметром

Откроем окно параметров через Popup-меню. Зададим параметры, показан­
ные на рис. 10.9.

Р и с. 1 0 .9 . Параметры запроса

SQL-эквивалент будет следующим:
PARAMETERS [Начальная Дата] DateTime,

[Конечная Дата] DateTime;

SELECT Сотрудники.Страна, Сотрудники.Фамилия, Сотрудники.Имя,
Заказы.ДатаИсполнения, Заказы.КодЗаказа, [Промежуточная сумма
заказа].ПромежуточнаяСумма AS СуммаПродаж
FROM Сотрудники INNER JOIN (Заказы INNER JOIN [Промежуточная сумма
заказа] ON Заказы.КодЗаказа = [Промежуточная сумма заказа].КодЗаказа) ON
Сотрудники.Ко дСотрудника = Заказы. Ко дСотрудника
WHERE Заказы.ДатаИсполнения Between [Начальная Дата] And [Конечная Дата]

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

10.2.5. Перекрестные запросы
Перекрестные запросы могут использоваться для обобщения обрабатывае­
мых данных и отображения их в формате компактной электронной таблицы.
Этот формат позволяет более наглядно представить большой объем данных
с целью выявления существующих тенденций и проведения сравнительного
анализа.
Установка типа запроса как перекрестного доступно в меню Конструктор
запросов | popup-меню | тип запроса | перекрестный. В результате в таблице
QBE появится новая строка — Перекрестная таблица. В ее ячейках доступны
следующие значения:
□ Заголовки строк. Значения данного поля будут располагаться в столбец
в качестве заголовков строк.
□ Заголовки столбцов. Значения данного поля будут располагаться в строку
в качестве заголовков столбцов.
□ Значение. Значения данного поля будут располагаться в ячейках под заго­
ловками столбцов после заголовков строк.
□ Не отображается. В данном поле обычно вводятся условия отбора.
В учебной базе данных имеется пример перекрестного запроса: Квартальные
обороты по товарам (рис. 10.10). В качестве заголовков столбцов в данном
запросе используется длинное выражение, означающее список из четырех
значений с Кв 1 по Кв 4. В качестве значения выбрано не менее длинное
выражение, вычисляющее сумму стоимостей заказанных товаров. Функция
ccur служит для преобразования вещественного формата в денежный.
Не показанное на рисунке поле ДатаРазмещения служит для выбора данных
в определенный период (с 1 января по 31 декабря 1997 года).

SQL-оператор данного запроса выглядит следующим образом:
TRANSFORM Sum(CCur(Заказано.Цена*[Количество]*(1-[Скидка])/100)*100) AS
СуммаПоТовару
SELECT Товары.Марка, Заказы.КодКлиента, Year([ДатаРазмещения]) AS
ГодЗаказа
FROM Товары INNER JOIN (Заказы INNER JOIN Заказано ON Заказы.КодЗаказа =
Заказано.КодЗаказа) ON Товары.КодТовара = Заказано.КодТовара
WHERE (((Заказы.ДатаРазмещения) Between #1/1/1997# And #12/31/1997#))
GROUP BY Товары.Марка, Заказы.КодКлиента, Year ([ДатаРазмещения] )
PIVOT "Кв
& DatePart("q",[ДатаРазмещения],1,0) In ("Кв 1","Кв 2","Кв
3","Кв 4");

Перекрестный запрос можно построить также с помощью мастера, доступ­
ного в меню: Главное меню | Вставка | Запрос | Перекрестный запрос. С его
помощью можно легко создать простой перекрестный запрос, однако опи­
сание мастера не будет рассмотрено, т. к. мастера не входят в язык QBE и
используются только в MS Access.

10.2.6. Запросы с автоподстановкой
Запросы с автоподстановкой могут использоваться для автоматического по- •
мешения в определенные поля вновь создаваемых записей. При вводе в ок­
не запроса некоторого значения в поле, используемое для соединения двух
таблиц, Access автоматически поместит поле со списком возможных значе­
ний. По умолчанию выводится список со значениями поля с именем Назва­
ние или подобных ему.
JS Jx

а£В Запрос Заказы : запрос на выборку
_

♦
'

л!

КодЗаказа
■ ;

КодЮнента

Название
ОбращатьсяК
Должность

щ

КодКлиента
КодСотрудника
ДатаРазмещения

1

.ш

Ш
Поле: КодЗаказа
Имя таблицы; Заказы
Сортировка;
Вывод на экран:
Условие отбора;
или;

КодКлиента
Заказы

и

и

КодСотрудника
Заказы

ДатаРазн^Заказы __

0

г

ill______
Рис. 10.11. Пример запроса с автоподстановкой

▼

__ ± Г

Откроем конструктор нового запроса, добавим таблицы Клиенты и Заказы и
поместим в таблицу запроса поля КодЗаказа, КодКлиента, КодСотрудника и
ДатаРазмещения из таблицы Заказы (рис. 10.11). SQL-оператор данного за­
проса не содержит ничего примечательного, за исключением повторяющих­
ся полей:
SELECT Заказы.КодЗаказа, Заказы.КодКлиента, Заказы.КодСотрудника,
Заказы.ДатаРазмещения
FROM Клиенты INNER JOIN Заказы ON Клиенты.КодКлиента = Заказы.КодКлиента;

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

ИШ Ш &г

ршВ Запрос! : запрос на выборку
Код заказа
►

Клиент

С отрудник

1 0 7 0 2 A lfre d s F u tte rk is t

d f li
Д ата разм ещ ения

В оронова, Д арья

1 0 9 5 2 ' A lfr e d s F u tte r k is te

!

Б елова, М ария

поп!

A n a T ru jillo E m p a r e la d o s

__

Б а б к и н а , О л ь га

10308

A n to n io M o re n o T a q u e ria

К р а л е в , П е тр
1 0 6 2 5 ' A ro u n d th e H o rn
Б а б к и н а , О л ь га
B e rg lu n d s s n a b b k o p
10759
Б а б к и н а , О л ь га
B la u e r S e e D e lik a te s s e n
10926
В оронова, Д арья
B lo n d e l p e re et fils
10365;
Б а б к и н а , О л ь га
B o lid o C o m id a s p re p a ra d a s
▼
10507
\rilUI iror-TVI-OTCI IU I lHjUCI'IU----------К р а л е в , П е тр

1 3 -1 0 -1 9 9 7
1 6 -0 3 -1 9 9 8
.... 0 9 - 0 4 - 1 9 9 8
1 8 -0 9 -1 9 9 6
0 8 -0 3 -1 9 9 7
2 8 -1 1 -1 9 9 7
0 4 -0 3 -1 9 9 3
2 7 -1 1 -1 9 9 6
1 5 -0 4 -1 9 9 7
1 3 -0 5 -1 9 9 7

1 0 5 3 5 A n to n io M o re n o T a q u e ria

В оронова, Д арья

1 0 5 7 3 A n to n io M o re n o T a q u e ria

К р а л е в , П е тр

1 9 -0 6 - 1 9 9 7

1 0 6 7 7 A n to n io M o re n o T a q u e ria

К р а л е в , П е тр

2 2 -0 9 -1 9 9 7

1 0 6 8 2 A n to n io M o re n o T a q u e ria
|| З а п и с ь :

И !

i

!I

Г

! Б а б к и н а , О л ь га
;-

► | И |K * 1 ns 830

В
3

2 5 -0 9 -1 9 9 7

3

Р и с . 1 0 .1 2 . Результат запроса с автоподстановкой

Готовый пример запроса с автоподстановкой содержится в учебной базе
данных под названием Заказы.

10.2.7. Другие запросы на выборку
Как упоминалось ранее, MS Access не имеет визуальных средств создания
вложенных запросов, однако в нем имеется несколько мастеров создания
сложных запросов. Эти конструкторы доступны в меню: Главное меню
Вставка | Запрос (рис. 10.13). Вложенный запрос можно ввести и ручным
способом. Обычно это делается в поле Условие отбора.
Рассмотрим пример создания запроса на повторяющиеся записи. Пустк
необходимо найти клиентов, которые находятся в городах, содержащих как

минимум два клиента. После запуска мастера выберем таблицу Клиенты,
укажем поле Город в качестве поля с повторяющимися записями. Затем до­
бавим поля КодКлиента, Название, Адрес в список Дополнительные поля,
выберем пункт Изменить структуру запроса и нажмем Готово. В первой ко­
лонке сетки QBE можно увидеть вложенный запрос на выборку записей,
имеющих повторение в поле Город.

Рис. 10.13. Варианты создания запроса в MS Access

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

10.3. Активные запросы
В MS Access существует шесть типов запроса, поддерживаемых QBE:
1. Выборка.
2. Перекрестный.
3. Создание таблицы.
4. Добавление.
5. Обновление.
6. Удаление.
При создании запроса MS Access обычно создает запрос на выборку данных,
если только в меню Query не будет выбран какой-либо другой тип запроса.
После выполнения запроса на выборку СУБД отображает его результирую­
щую сетку данных. Если эта сетка допускает обновление содержащихся
в ней данных, то требуемые изменения можно вносить непосредственно

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

10.3.1. Создание таблиц
Активные запросы создания таблиц позволяют создавать новые таблицы на
базе всех или части данных одной или нескольких уже существующих таб­
лиц. Вновь созданная таблица может быть сохранена в текущей открытой
базе данных или экспортирована в другую базу данных.
Запрос на создание таблицы в MS Access ничем не отличается от простого
запроса на выборку данных, за исключением того, что выбранные данные
будут помещены в новую таблицу.
Рассмотрим пример преобразования существующего запроса в запрос на
создание таблиц. Откроем запрос Запрос Заказы. Это позволит не создавать
новый запрос, а использовать уже имеющийся. Из Popup-меню изменим
тип запроса на Создание таблицы. На экране появится диалоговое окно вво­
да названия новой таблицы (рис. 10.14). Задайте имя Таблица Заказы.

Рис. 10.14. Задание имени новой таблицы в окне Создание таблицы

При генерации SQL в запрос добавляется оператор i n t o , с т о я щ и й перед
оператором f r o m . И м я , стоящее после этого оператора, является именем
создаваемой таблицы:
SELECT Заказы.КодЗаказа, Заказы.КодКлиента, Заказы.КодСотрудника,
Заказы. Да’гаРазмещения, Заказы.ДатаНазначения, Заказы.ДатаИсполнения,
Заказы.Доставка, Заказы.СтоимостьДоставки, Заказы.НазваниеПолучателя,
Заказы.АдресПолучателя, Заказы.ГородПолучателя, Заказы.ОбластьПолучателя,
Заказы.ИндексПолучателя, Заказы.СтранаПолучателя, Клиенты.Название,

Клиенты.Адрес, Клиенты.Город, Клиенты.Область, Клиенты.Индекс,
Клиенты.Страна Ю Т О [Таблица Заказы]
FROM Клиенты INNER JOIN Заказы ON Клиенты.КодКлиента = Заказы.КодКлиента;

После запуска запроса появится новая таблица с именем Таблица Заказы
с данными результата запроса на создание.

10.3.2. Удаление данных
Активные запросы удаления предназначены для удаления групп записей из
одной или более таблиц. Один запрос удаления может использоваться для
удаления записей из одной таблицы; из нескольких таблиц, между которы­
ми существует связь типа "один к одному"; из нескольких таблиц, между
которыми существует отношение "один ко многим", но только в том случае,
если установленные правила поддержки ссылочной целостности разрешают
каскадное обновление.
Таблица QBE при создании запроса на удаление выглядит несколько иначе
(рис. 10.15). Для удаления всех записей выбранной таблицы достаточно вне­
сти ее в поле запроса. Для задания условий на удаление по нужному полю
необходимо выбрать его в таблице QBE и ввести условие отбора. Пункт
Условие в ячейке Удаление будет установлен автоматически. Пункт Из
используется при удалении всех записей из таблицы.
Поле:
Имя таблицы:
Удаление:
Условие отбора:
или:

I

Р и с . 1 0 .1 5 . Таблица запроса на удаление данных

Удалим, для примера, все заказанные поставщикам товары из Австралии.
В базе данных Борей таких два: Pavlova, ltd и G’day Mate. Кроме таблицы
Поставщики, необходимые для удаления записи содержатся в таблицах
Товары и Заказано. Откроем конструктор нового запроса и добавим все три
таблицы. Добавим в сетку QBE поле * из таблицы Заказано и поле Страна
из таблицы Поставщики. Значок
служит для того, чтобы указать таблицу,
из которой будут удаляться записи, а выбор поля говорит о том, что будет
задано условие для удаления. Введем в ячейку Условие отбора слово Австра­
лия. Сгенерированный SQL-оператор будет следующим:
DELETE Заказано.*, Поставщики.Страна
FROM (Поставщики INNER JOIN Товары ON Поставщики.КодПоставщика =
Товары.КодПоставщика) INNER JOIN Заказано ON Товары.КодТовара =
Заказано.КодТовара
WHERE Поставщики.Страна="Австралия" ;

Сохраним и откроем запрос. После диалогового окна подтверждения на из­
менение данных появится окно с предложением на удаление 261 записи.
После подтверждения будут удалены все необходимые записи.
Для удаления всех записей о поставщиках (т. е. записей из всех трех таблиц)
необходимо выполнить два действия:
1. В схеме данных (Главное меню | Сервис | Схема данных) в связях между
указанными таблицами необходимо поставить флажок Каскадное удале­
ние, позволяющий удалять записи из подчиненных таблиц.
2. В конструкторе нового запроса на удаление необходимо добавить таблицу
Поставщики, выбрать поле Страна и указать Австралия в условии отбора.
MS Access выполнит удаление записей из всех таблиц автоматически.

10.3.3. Обновление данных
Активные запросы обновления выполняют глобальные обновления в груп­
пах записей одной или более таблиц.
При выборе типа запроса Обновление появится строка Обновление, в поля
которой и требуется ввести данные для обновления. Правила ввода условий
остаются прежними.
Допустим, в заказанных хлебобулочных изделиях, у которых цена превыша­
ет 10 рублей, необходимо установить скидку в размере 10%. Откроем конст­
руктор и внесем таблицы Типы, Товары и Заказано. Установим тип запроса
на обновление. Перенесем поле скидка йз таблицы Заказано и поставим в
ячейку Обновление число 10. Перенесем поле Категория из таблицы Типы и
поле Цена из таблицы Заказано. Введем условия отбора: Хлебобулочные из­
делия в поле Категория и >10 в поле Цена. В режиме SQL запрос будет сле­
дующим:
UPDATE (Типы INNER JO IN Товары ON Типы .КодТипа = Товары .КодТипа) INNER
JO IN З а ка за н о ON Товары .КодТовара = З а ка за н о .К о д Т о в а р а SET З а к а з а ­
н о. Скидка = 10
WHERE Типы .Категория="Хлебобулочны е изделия" AND З а к а з а н о .Ц е н а > 1 0 ;

После запуска запроса и подтверждения на обновление данных будет пред­
ложено внести изменения в 145 полей.

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

Запрос на добавление записей похож на запрос создания таблиц за одним
исключением. В запросе на добавление нужно указывать не только исход­
ные поля таблиц, но и поля таблицы, в которые следует занести данные.
На рис. 10.16 показан пример такого запроса, заносящего данные в таблицу е2.
Как и в случае запроса на создание таблицы, имя таблицы было запрошено
при выборе типа запроса (Popup-меню | Тип запроса | Добавление). Ячейки
в строке Добавление служат для ввода полей таблицы для добавления, куда
необходимо поместить полученные данные с выбранного поля используе­
мой для выборки результатов таблицы. Например, на рис. 10.16 результаты
выборки из таблицы Клиенты по полю КодКлиента помещаются в поле
поле1 таблицы е2. При указании условия отбора (например, Совладелец),
значение в ячейку Добавление можно не вводить. В таком случае данное по­
ле будет служить только лишь для задания критериев выборки данных.
Поле:
Имя таблицы:

КодКлиента

Название

Должность

Клиенты

Клиенты

Клиенты

Сортировка:

по возрастанию

Добавление:

поле!

поле2

Условие отбора:

"Совладелец"

или:

Р и с . 1 0 .1 6 . Запрос на добавление данных

SQL-оператор запроса является обычным запросом на добавление данных
с вложенными операторами выборки:
INSERT INTO е2 ( поле1, поле2 )
SELECT Клиенты.КодКлиента, Клиенты.Название
FROM Клиенты
WHERE Клиенты.Должность="Совладелец"
ORDER BY Клиенты.КодКлиента;

Вопросы и упражнения

1. Используя базу данных Сессия (
глав9), продумайт
языка может быть использован для получения следующей информации:
• список студентов — претендентов на отчисление, считая, что в отно­
шении SI находятся окончательные результаты сессии, и поэтому от­
числению подлежат все студенты, которые не сдали или не сдавали
два и более из положенных экзаменов в сессии;;
• список студентов, переведенных на следующий курс;
• отчислить студентов по результатам текущей сессии.

2. Выполните активный запрос создания таблицы Успеваемость, включаю­
щей поля ФИО и Оценка, заполненные данными из таблицы 37, и при­
ведите эквивалентный SQL-оператор.
3. Создайте и выполните активный запрос на зачисление в группу 02-КТ-12
нового студента.
4. Создайте и выполните активный запрос на изменение ФИО студентки
Петровой С.О., вышедшей замуж и ставшей Красновой С.О.
5. Создайте и выполните запрос для определения студентов, получивших
хотя бы по одной дисциплине "отлично"

Часть IV

ИСПОЛЬЗОВАНИЕ БАЗ ДАННЫХ

Глава 11. Обеспечение функционирования
баз данных
Глава 12. Новые технологии БД
Глава 13. Современные СУБД

Глава 11

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

11.1. Управление транзакциями
Напомним, что транзакция — это неделимая с точки зрения воздействия на
БД последовательность операторов манипулирования данными (чтения, уда­
ления, вставки, модификации), рассматриваемая СУБД как единое целое.
Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД,
произведенные этой транзакцией, во внешней памяти, либо ни одно из этих
изменений никак не отражается на состоянии БД. Транзакция может быть
представлена отдельной программой некоторого приложения или ее частью,
и выполнение программы с точки зрения базы данных может восприни­
маться как серия транзакций, в промежутках между которыми выполняется
обработка данных вне среды базы данных.
Понятие транзакции имеет непосредственную связь с понятиями целостно­
сти и безопасности БД. Эти два аспекта функционирования баз данных об­
ладают некоторыми сходными чертами, главное из которых состоит в том,
что система должна содержать сведения о тех правилах, которые пользова­
телю нельзя нарушать. Указанные правила реализуются посредством необ­
ходимых ограничений.
Очень часто БД может обладать такими ограничениями, которые просто не­
возможно не нарушить, выполнив лишь один оператор изменения БД, при­
надлежащий транзакции. Поэтому в системах с развитыми средствами огра­
ничения и контроля целостности допускается нарушение целостности
внутри транзакции с таким условием, чтобы каждая транзакция начиналась

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

11.1.1. Модель транзакции
Итак, для транзакции возможны два варианта завершения:
□ если все ее операторы выполнены успешно, транзакция фиксируется; до
фиксации транзакции допустимо аннулирование произведенных ее изме­
нений, после фиксации результатов транзакции ее изменения становятся
видимыми пользователю;
□ если нормальное завершение транзакции невозможно, осуществляется
откат транзакции — ее результаты аннулируются.
В стандарте SQL определена следующая модель транзакции (рис. 11.1):
□ транзакция начинается с первого SQL-оператора;
□ последующие SQL-операторы составляют тело транзакции;
□ оператор c o m m i t выполняется в случае успешного завершения обработки
информации, объединенной в транзакцию; его выполнение фиксирует
изменения, внесенные в базу данных текущей транзакцией;
□ оператор rollback (откат транзакции) прерывает выполнение транзакции
и осуществляет отмену изменений, проведенных в ходе выполнения
транзакции.

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

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

Р и с . 1 1 .1 . Модель транзакции

11.1.2. Свойства транзакции
Любая из транзакций должна обладать четырьмя основными свойствами:
D атомарности — это свойство как раз и отражает главную сущность тран­
закции: либо она выполняется полностью, либо не выполняется совсем;
□ согласованности — это свойство гарантирует, что транзакция не наруша­
ет согласованность данных;

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

11.1.3. Журнализация
Возможность реализации транзакций предполагает способность системы
сохранять промежуточные состояния базы данных, необходимые для отката
транзакций. Сохранение требуемых состояний осуществляется посредством
специального механизма, который называется журналом транзакций.
Журнал транзакций — важнейшая часть СУБД — используется не только с
целью обеспечения работы механизма транзакций. Он предназначен для
поддержки одного из основных требований к СУБД: надежности хранения
данных во внешней памяти.
Понятно, что в любом случае для восстановления БД нужно располагать
некоторой дополнительной информацией, причем та часть данных, которая
используется для восстановления, должна храниться особо надежно. Наибо­
лее распространенным методом поддержания такой избыточной информа­
ции является ведение журнала изменений БД. Общими принципами восста­
новления являются следующие:
□ результаты зафиксированных транзакций должны быть сохранены в вос­
становленном состоянии базы данных;
□ результаты незафиксированных транзакций должны отсутствовать в вос­
становленном состоянии базы данных.
Журнал — это особая часть БД, недоступная пользователям СУБД и под­
держиваемая с особой тщательностью (иногда поддерживаются две копии
журнала, располагаемые на разных физических дисках), в которую поступа­
ют записи обо всех изменениях основной части БД. В разных СУБД изме­
нения БД журнализуются на разных уровнях: иногда запись в журнале соот­
ветствует некоторой логической операции изменения БД (например,
операции удаления строки из таблицы реляционной БД), иногда — мини­
мальной внутренней операции модификации страницы внешней памяти;
в некоторых системах одновременно используются оба подхода.
Журнализация изменений тесно связана с буферизацией страниц базы дан­
ных в оперативной памяти. Буферизация страниц — единственный способ
достижения удовлетворительной эффективности СУБД.
Если бы запись об изменении базы данных, которая должна поступить
в журнал при выполнении любой операции модификации базы данных, ре­
ально немедленно записывалась бы во внешнюю память, это привело бы

к существенному замедлению работы системы. Поэтому записи в журнал
тоже буферизуются: при нормальной работе очередная страница выталкива­
ется во внешнюю память журнала только при полном заполнении записями.
Итак, имеются два вида буферов — буфер журнала и буфер страниц опера­
тивной памяти, которые содержат связанную информацию. И те, и другие
буфера могут выталкиваться во внешнюю память. Проблема состоит в выра­
ботке некоторой общей политики выталкивания, которая обеспечивала бы
возможности восстановления состояния базы данных после сбоев.
В СУБД эта политика выталкивания состоит в том, что во всех случаях ве­
дения журнала придерживаются стратегии "упреждающей" записи в журнал
(так называемого протокола Write Ahead Log — WAL). Эта стратегия заклю­
чается в том, что запись об изменении любого объекта БД должна попасть
во внешнюю память журнала раньше, чем измененный объект попадет во
внешнюю память основной части БД. Известно, что если в СУБД корректно
соблюдается протокол WAL, то с помощью журнала можно решить все про­
блемы восстановления БД после любого сбоя.
Таким образом, если во внешней памяти базы данных находится некоторый
объект базы данных, по отношению к которому выполнена операция моди­
фикации, то во внешней памяти журнала обязательно находится запись, со­
ответствующая этой операции. Обратное неверно, т. е. если во внешней па­
мяти журнале содержится запись о некоторой операции изменения объекта
базы данных, то сам измененный объект может отсутствовать во внешней
памяти базы данных.
Дополнительное условие на выталкивание буферов накладывается тем тре­
бованием, что каждая успешно завершившаяся транзакция должна быть ре­
ально зафиксирована во внешней памяти. Какой бы сбой не произошел,
система должна быть в состоянии восстановить состояние базы данных, со­
держащее результаты всех зафиксированных к моменту сбоя транзакций.
Простым, но дорогостоящим решением было бы следом за выталкиванием бу­
фера журнала обеспечить массовое выталкивание буферов страниц базы дан­
ных, изменявшихся данной транзакцией. Однако есть лучший, гарантирующий
возможность восстановления последнего согласованного состояния базы дан­
ных вариант, который предполагает выталкивание при фиксации транзакции во
внешнюю память журнала всех записей об изменении базы данных этой тран­
закцией. При этом последней записью в журнал, производимой от имени дан­
ной транзакции, является специальная запись о конце транзакции.
Существует два альтернативных варианта ведения журнала транзакций. Рас­
смотрим оба варианта.
□ Протокол с отложенными обновлениями осуществляет для каждой изме­
няемой записи занесение в протокол нового значения. Если все дейст­
вия, предусмотренные транзакцией, выполнены успешно, то транзакция
частично фиксируется, и из протокола изменения переносятся в базу

данных. При сбое СУБД просматривает протокол и определяет, какие
транзакции были зафиксированы, и их необходимо выполнить повторно.
Поскольку все изменения, произведенные транзакцией, содержатся в про­
токоле, то предназначенная для подобной ситуации системная процедура,
просматривая протокол в прямом порядке, восстанавливает потерянные
значения, осуществляя зарегистрированные в протоколе действия. Если
транзакция не была зафиксирована, то она просто не выполняется.
□ протокол с немедленными обновлениями.
Рассмотрим различные ситуации восстановления базы данных при поддерж­
ке в системе общего для всех транзакций журнала с общей буферизацией
записей в соответствии с протоколом WAL.
Индивидуальный откат транзакции

Индивидуальный откат транзакции предполагает самую простую процедуру
восстановления. Если бы требовалось осуществлять только ее, то для этого не
было бы необходимости вообще вести общесистемный журнал изменений БД.
Достаточно было бы для каждой транзакции поддерживать локальный журнал
операций модификации БД, выполненных в этой транзакции и связанных в
обратный список (от конца к началу). Началом списка для не закончившихся
транзакций является запись о последнем изменении базы данных, а концом
списка служит первая запись о ее изменении. Тогда реализовать индивиду­
альный откат такой транзакции можно путем выполнения обратных опера­
ций, следуя от конца локального журнала. В некоторых СУБД так и делают,
но в большинстве систем локальные журналы не поддерживают, а индивиду­
альный откат транзакции выполняют по общесистемному журналу.
Переход к следующему элементу обратного списка при индивидуальном от­
кате транзакции выполняется в следующем порядке:
□ выбирается очередная запись из списка данной транзакции;
□ для восстановления предыдущего состояния объекта базы данных выпол­
няется противоположная по смыслу операция;
□ обратная операция журнализуется.
При успешном завершении отката в журнал заносится запись о конце тран­
закции.
Восстановление в результате сбоев

Под надежностью хранения понимается то, что СУБД должна быть в со­
стоянии восстановить последнее согласованное состояние БД после любого
аппаратного или программного сбоя. Обычно рассматриваются два возмож­
ных вида аппаратных сбоев:
□ так называемые мягкие сбои, характеризуемые внезапной потерей содер­
жимого оперативной памяти, наступающие в результате внезапной оста­
новки работы компьютера (например, аварийное выключение питания);

□ жесткие сбои, характеризуемые потерей информации на носителях
внешней памяти.
Примерами программных сбоев могут быть: аварийное завершение работы
СУБД (по причине ошибки в программе или в результате некоторого аппа­
ратного сбоя) или аварийное завершение пользовательской программы,
в результате чего некоторая транзакция остается незавершенной. Первую
ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя;
при возникновении последней требуется ликвидировать последствия только
одной транзакции.
Если произошел мягкий сбой и содержимое буферов утрачено, для проведе­
ния восстановления базы данных необходимо иметь некоторое согласован­
ное состояние журнала и базы данных во внешней памяти. При мягком сбое
во внешней памяти основной части БД могут наблюдаться нежелательные
ситуации двух типов:
□ присутствие объектов, модифицированных транзакциями, не закончив­
шимися к моменту сбоя;
□ отсутствие объектов, модифицированных транзакциями, которые к мо­
менту сбоя успешно завершились, но по причине использования буферов
оперативной памяти, содержимое которых при мягком сбое пропадает,
не были помещены во внешнюю память.
При соблюдении протокола WAL во внешней памяти журнала должны га­
рантированно находиться записи, относящиеся к операциям модификации
обоих видов объектов. Целью процесса восстановления после мягкого сбоя
является состояние внешней памяти основной части БД, которое возникло
бы при фиксации во внешней памяти изменений всех завершившихся тран­
закций, и которое не содержало бы никаких следов незаконченных транзак­
ций. Для того, чтобы этого добиться, необходимо:
□ произвести откат незавершенных транзакций;
□ повторно воспроизвести те операции завершенных транзакций, результа­
ты которых не отображены во внешней памяти.
Для восстановления БД после жесткого сбоя журнала изменений базы дан­
ных явно недостаточно. Основой восстановления последнего согласованного
состояния базы данных после жесткого сбоя является журнал и архивная
копия БД. Грубо говоря, архивная копия — это полная копия БД к моменту
начала заполнения журнала.
Конечно, для нормального восстановления БД после жесткого сбоя необхо­
димо, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала
во внешней памяти в СУБД предъявляются особо повышенные требования.
Тогда восстановление БД состоит в том, что, исходя из архивной копии, по
журналу воспроизводится работа всех транзакций, которые закончились
к моменту сбоя. Для транзакций, которые не закончились к моменту сбоя,
осуществляется откат.

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

11.1.4. Проблемы многопользовательских систем
Поскольку в многопользовательских системах с одной базой данных одно­
временно могут работать несколько пользователей или прикладных про­
грамм, то в связи со свойством сохранения целостности БД транзакции яв­
ляются подходящими единицами изолированности пользователей, где
каждый пользователь начинает работу с согласованным состоянием базы
данных.
Несколько одновременно работающих пользователей инициируют парал­
лельные транзакции. При параллельной обработке транзакций возникает
ряд проблем. Для того чтобы получить корректно работающую транзакцию,
недостаточно написать ряд правильно составленных операторов манипули­
рования данными. Дело в том, что при обработке правильно составленных
операторов манипулирования данными транзакций возникают ситуации,
которые могут привести к получению неправильного результата из-за вза­
имных помех среди некоторых транзакций, вызванных бесконтрольным че­
редованием операций из двух правильных транзакций. Ниже анализируется
три таких проблемы.
□ Проблема потерянных результатов обновления. Рассмотрим ситуацию
(рис. 11.2):
• транзакция А1 читает некоторый объект Р в момент времени tl;
• транзакция А2 читает этот же объект Р в момент времени t2;
• транзакция А1 обновляет некоторый объект Р в момент времени t3;
• транзакция А2 обновляет тот же объект Р в момент времени t4.

Результат операции обновления, выполненной транзакцией А1, будет
утерян, поскольку в момент времени t4 она не будет учтена, и потому бу­
дет отменена операцией обновления, выполненной транзакцией А2. Что­
бы исключить такую ситуацию требуется, чтобы до завершения транзак­
ции А1 никакая другая транзакция не могла изменять объект Р.
Отсутствие потерянных изменений является минимальным требованием
к СУБД в области синхронизации параллельно выполняемых транзакций.
Время

Транзакция A1

Транзакция A2

t1

Чтение P

—

t2

—

Чтение P

t3

Обновление P

—

t4

—

Обновление P

Р и с . 1 1 .2 . Потерянные результаты обновления

□ Проблема несогласованных данных. Данная проблема появляется, если с
помощью некоторой транзакции осуществляется извлечение (обновле­
ние) некоторого объекта, который в данный момент обновляется другой
транзакцией, но это обновление еще не закончено (если обновление не
завершено, существует некоторая вероятность того, что оно не будет за­
вершено никогда). В таком случае в первой транзакции будут прини­
мать участие данные, которые больше не существуют. Поясним это
заключение рассмотрением следующего сценария совместного выполне­
ния транзакций А1 и А2 (рис. 11.3).
Время

Транзакция A1

Транзакция A2

t1

—

—

t2

—

Чтение P

t3

Обновление P

—

t4

—

Чтение P

Р и с . 1 1 .3 . Проблема несогласованных данных

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

несогласованных данных до завершения транзакции А1, изменившей
объект Р, никакая другая транзакция не должна читать объект Р.
О Проблема несовместимого анализа возникает тогда, когда, например, тран­
закция А1 осуществляет вычисление некоторой статистической величи­
ны, скажем, среднего значения, а транзакция А2 выполняет обновление
кортежа РЗ, который еще только будет использован транзакцией А1.
Причем транзакции А1 не зависит от транзакции А2, так как транзакция
А2 выполнила все обновления до того, как транзакция А1 извлекла кор­
теж РЗ (рис. 11.4).
Время

Транзакция A1

Транзакция А2

И

Чтение P1

—

t2

Чтение P2

Обновление РЗ

t3

Чтение РЗ

—

t4

Вывод результата

—

Рис. 11.4. Несовместимый анализ

Полученный в итоге транзакции А1 результат, очевидно, неверен, и если
он будет записан в базе данных, то в ней может возникнуть проблема не­
совместимости. В таком случае говорят, что транзакция А1 встретилась с
несовместимым состоянием и на его основе был выполнен несовмести­
мый анализ.
Понятно, что для того, чтобы избежать подобных проблем, в СУБД должны
использоваться какие-либо методы регулирования совместного выполнения
транзакций. Эти методы должны опираться на следующие правила:
□ в ходе выполнения транзакции пользователь видит только согласованные
данные;
□ результаты параллельно выполняемых транзакций должны быть такими же,
как если бы вначале выполнялась одна транзакция, а потом — вторая.
Реализация этих методов управления транзакциями в многопользователь­
ской СУБД опирается на такие важные понятия, как: сериализация тран­
закций и сериальный план выполнения смеси транзакций.

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

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

Х-блокировки сохраняются вплоть до конца выполнения транзакции.
S-блокировки также обычно сохраняются вплоть до этого момента, однако
при работе с ними есть свои особенности.
Посмотрим, как будет выглядеть решение проблем параллельного выполне­
ния двух транзакций в свете вышеизложенного.
□ Проблема потери результатов обновления. С учетом применения прото­
кола блокировки для чередующихся операций складывается следующая
ситуация (рис. 11.5).
Время

Транзакция A1

Транзакция А2

t1

Чтение P

—

Задание S-блокировки P
t2

—

Чтение Р
Задание S-блокировки Р

t3

Обновление P

—

Задание Х-блокировки P
t4

Ожидание

Обновление Р
Задание Х-блокировки Р

t5

Ожидание

Ожидание

Рис. 11.5. Блокировки и потерянные результаты обновления

Чтение объекта Р в момент времени t l транзакцией А1 вызывает нало­
жение на этот объект S-блокировки. Такую же блокировку объекта Р ус­
танавливает транзакция А2 в момент времени tl. Операция обновления
для транзакции А1 в момент времени t3 не будет выполнена, поскольку
она является неявным запросом с заданием Х-блокировки для объекта Р,
а этот запрос вступает в конфликт с S-блокировкой, уже заданной тран­
закцией А2. Таким образом, транзакция А1 переходит в состояние ожи­
дания. По аналогичным причинам транзакция А2 переходит в состояние
ожидания в момент времени t4. Как видим, решение этой проблемы
с помощью блокировок привело к некоторой конфликтной ситуации,
которая получила название тупик. Способы выхода из тупиковых ситуа­
ций будут рассмотрены несколько позже.
□ Проблема незафиксированной зависимости. Они демонстрируют чере­
дующееся выполнение операций согласно описанному выше протоколу
блокировки (рис. 11.6).
Операция для транзакции А2 в момент времени t l не будет выполнена.
Дело в том, что она является неявным запросом с заданием S-блокировки
для объекта Р, а этот запрос вступает в конфликт с Х-блокировкой, уже

заданной транзакцией А1. Таким образом, транзакция А2 переходит в со­
стояние ожидания до тех пор, пока не будет прекращено выполнение
транзакции А1. Тогда заданная транзакцией А1 блокировка будет снята, и
транзакция А2 может быть выполнена. Ее результаты в любом случае не
будут зависеть от незафиксированного обновления.
Время

Транзакция А1

Транзакция А2

t1

Обновление Р

—

Задание Х-блокировки Р
Х2

—

Чтение Р
Запрос на S-блокировку Р

t3

—

Ожидание

ХА

Снятие Х-блокировки Р

Чтение Р
Задание S-блокировки Р

Р и с . 1 1 .6 . Блокировки и проблем а несогласованных данных

П Проблема несовместимого анализа. Ситуация, рассмотренная в предыду­
щем разделе, с учетом блокировок будет развиваться следующим образом
(рис. 11.7).
Время

Транзакция A1

Транзакция А2

t1

Чтение P1

Чтение РЗ

Задание S-блокировки P1

Задание S-блокировки РЗ

Чтение Р2

Обновление РЗ

Задание S-блокировки Р2

Задание Х-блокировки РЗ

Чтение РЗ

—

Х2

t3

Запрос на S-блокировку РЗ
t4

Ожидание

Завершение транзакции
Снятие Х-блокировки РЗ

t5

Чтение РЗ

—

Задание S-блокировки РЗ

Р и с . 1 1 .7 . Блокировки и несовместимы й анализ

Операция чтения кортежа РЗ для транзакции А1 в момент времени t3
не будет выполнена, так как для ее реализации необходимо задать
S-блокировку для этого кортежа, которая не может быть установлена,
12 Зак. 3303

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

Тупиковая ситуация возникает тогда, когда две или более транзакции одно­
временно находятся в состоянии ожидания, причем для продолжения рабо­
ты каждая из транзакций ожидает прекращения выполнения другой тран­
закции. Выше был дан пример совместного выполнения транзакций
с возникшей тупиковой ситуацией (рис. 11.5). Следует отметить, что можно
предположить существование более сложных ситуаций, например, количе­
ство заблокированных транзакций больше двух, но специалисты утвержда­
ют, что на практике никогда не встречаются тупиковые ситуации с участием
более чем двух транзакций. И в дальнейшем будем обсуждать ситуации,
включающие именно две транзакции.
Поскольку тупик сама транзакция обнаружить не может, его должна обна­
ружить и разрешить система. Для обнаружения тупиковой ситуации следует
обнаружить цикл в графе состояний ожидания — направленном графе,
в вершинах которого расположены имена транзакции (рис. 11.8).

Р и с . 1 1 .8 . Граф ожидания транзакций

На диаграмме видно, что транзакции A4 и А5 образуют цикл, свидетельст­
вующий о возникшем тупике.
Если транзакция А1 ждет окончания транзакции А2, то из вершины А1 в
вершину А2 идет стрелка. Дополнительно стрелки могут быть помечены
именами заблокированных объектов и типом блокировки.

Для примера, изображенного на рис. 11.5, граф ожиданий транзакций имеет
простую форму (рис. 11.9).
Р(х)

Р(х)
Р и с . 1 1 .9 . Граф ожидания транзакций
к п р обл ем е потери результатов обновления

Поиск выхода из тупиковой ситуации состоит в выборе одной из заблокиро­
ванных транзакций в качестве жертвы и отмене ее выполнения. Таким об­
разом, с нее снимается блокировка, а выполнение другой транзакции может
быть возобновлено. Критерием выбора жертвы является стоимость транзак­
ции, которая учитывает многие факторы (время выполнения, число накоп­
ленных захватов, приоритет), и в качестве жертвы выбирается самая дешевая
транзакция. Для выбранной транзакции-жертвы осуществляется откат, во
время которого снимаются ее блокировки, и у других транзакций появляет­
ся возможность продолжить работу.
На практике не все системы в состоянии обнаружить тупиковую ситуацию,
Например, в некоторых из них используется хронометраж выполнения
транзакций, и сообщение о возникновении тупиковой ситуации поступает,
если транзакция не выполняется за некоторое предписанное заранее время.
В некоторых системах предусмотрен автоматический перезапуск транзакции
с самого начала из расчета, что обстоятельства, которые привели к тупико­
вой ситуации, не повторятся вновь.
Д вухф азн ая блокировка
Поскольку для централизованных систем граф ожиданий становится очень
громоздким, в распределенных СУБД к сериализации транзакций обычно
применяется другой подход. Он основан на следующей концепции: чере­
дующееся выполнение заданного множества транзакций будет верным, если
оно упорядочено. А упорядоченным это множество будет тогда, когда при
его выполнении будет получен такой же результат, как и при последова­
тельном выполнении тех же транзакций. Приведем основополагающие пра­
вила данной концепции.
1. Отдельные транзакции считаются верными, если при их выполнении ба­
за данных переходит из одного непротиворечивого состояния в другое
непротиворечивое состояние.
2. Выполнение транзакций одна за другой в любом последовательном по­
рядке также является верным.

3. Чередующееся выполнение транзакций является верным, если оно экви­
валентно некоторому последовательному выполнению, т. е. если его воз­
можно принудительно упорядочить.
Для заданного набора транзакций любой порядок их выполнения называет­
ся графиком запуска. Выполнение транзакций по одной без их чередования
называется последовательным графиком запуска, а непоследовательное вы­
полнение транзакций — чередующимся графиком запуска. Два графика назы­
ваются эквивалентными, если при их выполнении будет получен одинаковый
результат, независимо от исходного состояния базы данных. Таким образом,
график запуска является верным, если он эквивалентен некоторому по­
следовательному графику запуска.
Стоит подчеркнуть, что при выполнении двух различных последовательных
графиков запуска, содержащих одинаковый набор транзакций, можно полу­
чить совершенно различные результаты.
Рассматриваемая концепция, предложенная Есвараном, основана на теореме
двухфазной блокировки.
Если все транзакции подчиняются протоколу двухфазной блокировки, то
для всех возможных чередующихся графиков запуска существует возмож­
ность упорядочения.
При этом протокол двухфазной блокировки, в свою очередь, формулируется
следующим образом.
□ Перед выполнением каких-либо операций с некоторым объектом (на­
пример, с кортежем базы данных) транзакция должна заблокировать этот
кортеж.
□ После снятия блокировки транзакция не должна накладывать никаких
других блокировок.
Таким образом, транзакция, которая подчиняется этому протоколу, характе­
ризуется двумя фазами: фазой наложения блокировки и фазой снятия бло­
кировки. На практике вторая фаза часто сводится к единственной операции
окончания выполнения (или отмены выполнения) в конце транзакции.
Таким образом, если А1 и А2 являются любыми двумя транзакциями неко­
торого графика запуска, допускающего возможность упорядочения, тогда
либо А1 использует результаты выполнения транзакции А2, либо наоборот
А2 использует результаты выполнения А1.
Уровни изоляции транзакций

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

сериализации транзакций по различным причинам обычно допускаются
транзакции, которые работают на уровне изоляции ниже максимального.
Уровней изоляции может быть несколько, в стандарте языка SQL их — че­
тыре. Чем выше уровень изоляции, тем меньше степень вмешательства в ее
работу.
О Уровень неподтвержденного чтения READ UNCOMMITED. Транзакция
видит промежуточные и несогласованные данные и не исключается про­
блема несовместимого анализа, однако предотвращаются потери резуль­
татов обновления.
□ Уровень подтвержденного чтения READ COMMITED не позволяет тран­
закции обновить строку, уже обновленную другой транзакцией. Текущая
транзакция не имеет доступа к промежуточным результатам другой тран­
закции, однако окончательные данные, полученные в ходе выполнения
других транзакций, могут быть ей доступны.
□ Уровень подтвержденного чтения REPEATABLE READ — исключает
доступ одной транзакции к промежуточным или окончательным резуль­
татам других транзакций, но не исключает проблему несовместимого
анализа.
□ Уровень SERIALIZABLE — обеспечивает полную изоляцию транзакций.
Все данные выше характеристики уровней изоляции транзакций хорошо
представлены в табл. 11.1.
Таблица

11.1. Уровни изоляции транзакций

Уровень изоляции

Потери
результатов
обновления

Появление
промежу­
точных
данных

Появление
несогласо­
ванных
данных

Несовмес­
тимый
анализ

READ UNCOMMITED

Нет

Возм ож но

В озм ож но

В озм ож но

READ COMMITED

Нет

Нет

В озм ож но

В озм ож но

REPEATABLE READ

Нет

Нет

Нет

В озм ож но

SERIALIZABLE

Нет

Нет

Нет

Нет

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

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

значения атрибута внутри заданного кортежа. Ситуация такого типа называ­
ется степенью дробления блокировок: чем крупнее объект синхронизацион­
ного захвата, тем меньше блокировок можно задать и протестировать. На­
пример, если транзакция накладывает Х-блокировку на целое отношение, то
нет необходимости задавать Х-блокировку для отдельных кортежей внутри
этого отношения, что в результате приводит к уменьшению общего числа
блокировок. С другой стороны, никакая другая параллельная транзакция не
в состоянии наложить никаких других блокировок на это отношение или
кортежи этого отношения.
Таким образом, вопрос о выборе уровня блокируемого объекта является
очень важным. С одной стороны, при укрупнении объекта синхронизаци­
онного захвата преднамеренно огрубляется ситуация и вводятся конфликты
там, где при другом подходе их может не быть. Поэтому в большинстве со­
временных СУБД используются покортежные синхронизационные захваты.
С другой стороны, такого рода захваты навряд ли стоит применять в тех
случаях, когда операциям подвергается все отношение целиком (например,
удаление отношения).
Для разрешения этой коллизии введено понятие преднамеренной блокиров­
ки или гранулированного синхронизационного захвата и соответствующего
поддерживающего его механизма.
Этот механизм предполагает специальный протокол, в соответствии с кото­
рым синхронизационные захваты могут запрашиваться по отношению
к объектам разного уровня. Помимо Х-блокировок и S-блокировок, которые
можно задавать как для отдельных кортежей, так и для целых отношений,
вводятся три типа новых преднамеренных блокировок, имеющих смысл для
целых отношений, а не для отдельных кортежей.
□ Преднамеренная блокировка с возможностью взаимного доступа (Intent
Shared lock— IS) по отношению к некоторому составному объекту озна­
чает намерение захватить некоторый входящий в него объект в совмест­
ном режиме. Например, при намерении читать некоторый кортеж из от­
ношения последнее должно быть захвачено в режиме IS.
□ Преднамеренная блокировка без взаимного доступа (Intent exclusive
lock— IX) по отношению к некоторому составному объекту означает на­
мерение захватить некоторый входящий в него объект в монопольном
режиме. Например, при намерении удалять некоторые кортежи из отно­
шения последнее должно быть захвачено в режиме IX.
□ Преднамеренная блокировка одновременно как с возможностью взаим­
ного доступа, так и без него (Shared Intent exclusive lock — SIX) по отно­
шению к некоторому составному объекту означает совместный захват
всего этого объекта с намерением впоследствии захватить некоторые вхо­
дящие в него объекты в монопольном режиме.

Формальные определения этих типов блокировок можно дать с помощью
матрицы совместимости (табл. 11.2).
Таблица 11.2. Матрица совместимости блокировок
X

S

IX

IS

SIX

-

X

Нет

Нет

Нет

Нет

Нет

S

Нет

Да

Нет

Да

Нет

IX

Нет

Нет

Да

Нет

IS

Нет

Да

Да

SIX

Нет

Нет

Нет

—

Да

Да

Да

Да
Да
Да
Да

Да
Да
Да
Да
Да

Да
Нет

Да

Уточним формулировку протокола преднамеренной блокировки.
1. Прежде чем транзакция наложит S-блокировку на данный кортеж, она
должна наложить IS-блокировку или другую более сильную блокировку
на отношение, в котором содержится данный кортеж.
2. Прежде чем транзакция наложит Х-блокировку на данный кортеж, она
должна наложить IX-блокировку или другую более сильную блокировку
на отношение, в котором содержится данный кортеж.
Взаимную силу блокировок можно выяснить с помощью диаграммы при­
оритета, представленной на рис. 11.10.
♦
I—
Т

—I
Т

Р и с . 1 1 .1 0 . Диаграмма приоритетов блокировок

Стоит отметить, что на уровне отношений блокировки обычно задаются не­
явным образом. Например, для транзакции считывания система может не­
явным образом наложить IS-блокировку на каждое отношение, к которому
обращается данная транзакция. А для транзакции обновления вместо этого,
вероятно, потребуется задать 1Х-блокировку.
Оптимизация процесса наложения множества блокировок осуществляется
следующим, очень полезным на практике, образом. Устанавливается неко­
торый заранее заданный порог, достигая который система автоматически

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

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

11.2.1. Основные сведения
Триггер — это специальный тип хранимой процедуры, которая автоматиче­
ски выполняется при каждой попытке изменить защищаемые ей данные.
Триггеры обеспечивают целостность данных, предотвращая их несанкцио­
нированное или неправильное изменение.
Допустим, что в базе данных есть таблицы, связанные через поле Surname.
Например, это могут быть таблица клиентов предприятия и их заказов. Ра­
зумно определить триггер, который при каждой попытке удалить запись
клиента проверит наличие у него заказов и позволит удалить эту запись
только при их отсутствии. Конечно, подобную задачу можно решить при
помощи средств декларативной ссылочной целостности. Однако при помо­
щи триггеров можно создавать значительно более сложные рабочие правила.
Можно создать триггер, который при каждом добавлении записи в таблицу
заказов анализирует предыдущие заказы этого же клиента и определяет при­
емлемый срок оплаты этого заказа.
Триггеры не принимают параметров и не возвращают значений. Они вы­
полняются неявно. То есть триггер запускается только при попытке измене­
ния данных.
Триггеры могут иметь до 32 уровней вложенности. Вложенные триггеры ра­
ботают следующим образом: пусть при создании записи о новом заказе
триггер добавляет информацию в таблицу неоплаченных счетов. При этом
выполняется другой триггер, который проверяет, имеет ли клиент просро­
ченные неоплаченные счета и, если они есть, триггер выводит сообщение об
этом. В этом примере один триггер обновляет таблицу, вызывая при этом
выполнение другого триггера.
По умолчанию все триггеры ( i n s e r t , d e l e t e , u p d a t e ) срабатывают сразу по­
сле выполнения операции изменения данных. Эти триггеры относятся к ти­
пу a f t e r (после). Начиная с SQL Server 2000 появилась еще одна группа
триггеров — i n s t e a d o f (вместо), которые выполняются вместо оператора,
предполагающего изменение данных.

С точки зрения быстродействия триггеры не имеют никаких преимуществ.
Выполнение триггера связано с постоянными обращениями к различным
таблицам. Соответственно его работа быстрее, если используемые таблицы
находятся в оперативной памяти, и медленнее —.если данные считываются
с диска.
Триггер является частью транзакции, следовательно, если триггер терпит
неудачу, отменяется вся транзакция. И наоборот, если какая-то часть тран­
закции не удалась, то и триггер будет отменен.
В своей работе триггеры используют таблицы Inserted и Deleted. Это логиче­
ские таблицы, они постоянно находятся в оперативной памяти и имеют ту
же структуру, что и таблица, для которой создан триггер. Каждая добавлен­
ная к защищаемой триггером таблице строка добавляется и в таблицу
Inserted. Обновление производится почти так же, как и удаление с после­
дующей вставкой. Когда строка обновляется, старая строка записывается
в таблицу Deleted, затем обновленная строка записывается в базовую табли­
цу и в таблицу Inserted.

11.2.2. Создание триггера
Триггер создается оператором
CREATE TRIGGER
ON

[в л а д е л е ц .]

[в л а д е л е ц .] им я_таб лицы

FOR {AFTER

| INSTEAD OF)

create

t r ig g e r .

Рассмотрим его синтаксис:

и м я _ тр и гге р а
| им я_представления

{IN S E R T

| UPDATE

| DELETE)

[W IT H ENCRYPTION]
AS o n e p a T o p _S Q L

Таблица может иметь произвольное количество триггеров любых типов
( i n s e r t , u p d a t e и л и d e l e t e ). П о умолчанию триггер выполняется после из­
менения данных, однако, если указать параметр i n s e a d o f , т о создается
триггер, выполняющийся вместо изменения данных.
Каждая операция ( i n s e r t , u p d a t e и d e l e t e ) может вызывать выполнение
произвольного количества триггеров. С единственным ограничением —
имена триггеров, вызываемых одной операцией, должны быть уникальными.
Изменить триггер можно, удалив его и создав заново в другом виде или при
помощи оператора a l t e r t r i g g e r . При удалении таблицы, имеющей триг­
геры, все они также удаляются.
При создании триггеров необходимо придерживаться следующих правил:
□ Триггеры создаются для поддержания целостности данных, ссылочной
целостности и рабочих правил.
□ Нельзя создавать триггеры для временных таблиц. Однако триггеры могут
к таким таблицам обращаться так же, как и к представлениям.

□ Триггер не может возвращать результирующих наборов данных. Это зна­
чит, что к использованию оператора select при его создании нужно
подходить крайне осторожно. Обычно в этих случаях используется опера­
тор SELECT С директивой I F E X IS T S .
□ С помощью опции with encryption исходный код триггера, хранящийся
в таблице syscomments, можно зашифровать.
□ Операторы writetext не инициализируют триггеры. Они используются
для изменения данных типа Text или Image, а эти изменения не заносят­
ся в журнал транзакций.
□ В триггерах нельзя использовать следующие операторы: все операторы
CREATE, все операторы DROP, alter table, alter database, truncate
TABLE, GRANT И REVOKE, RECONFIGURE, LOAD

update st a t ist ic s , select into

DATABASE ИЛИ TRANSACTION,

и все операторы DISK.

□ Операторы отмены транзакций, входящие в состав триггера, могут стать
причиной непредсказуемого поведения операторов вызывающей про­
граммы.
Следующий пример демонстрирует использование триггера, срабатывающего
при вставке или обновлении таблицы. По умолчанию это триггер a f t e r .
USE p ub s
GO
CREATE TRIGGER tr A d d A u t h o r
ON a u t h o r s
FOR IN S E R T ,

UPDATE

AS r a i s e r r o r

( ' %d ro w s h a v e b e e n m o d if e d ' ,

0,

1

@ @ rowcount)
RETURN

Данный триггер будет стартовать при каждой вставке или изменении дан­
ных и возвращать сообщение о количестве измененных строк. Рассмотрим
результат его работы:
USE p u b s
GO
IN S E R T a u t h o r s
( a u _ id ,

au_name, au _fn am e, p ho n e, a d d re s s ,

c ity ,

s ta te ,

z ip ,

c o n tra c t)

VALUES
( '7 7 7 - 6 6 - 5 5 5 ',
'M a g a d a n '

’V a s iliy ',

'M a g a d .

O b i.'

'S i d o r o v ',

'+ 7 0 0 0 6 6 6 6 6 6 ',

*6 66 h e l l - s t r e e t ' ,

’ 8 7 4 7 6 3 ', 0 )

После выполнения этого кода на экран будет выведено:
1 ro w s h a v e b e e n m o d i f i e d
(1 r o w ( s )

a ffe c te d )

Где первая строка

И

есть результат работы триггера.

11.2.3. Триггер удаления
Рассмотрим триггеры удаления ( d e l e t e ). С т о и т отметить, что при использо­
вании оператора t r u n c a t e t a b l e (удаляющего все строки таблицы) триггер
не сработает. Для демонстрации создадим еще одну запись в таблице
authors, отличающуюся от предыдущей только значением поля au_id.
USE p u b s
GO
IN SER T a u t h o r s
(au__id, au_nam e, au _fn am e, p ho n e, a d d re s s ,

c ity ,

s ta te ,

z ip ,

c o n tra c t)

VALUES
( '7 7 7 - 6 6 - 5 5 5 ',
'M a g a d a n ',

'V a s iliy ',

'M a g a d .

'S i d o r o v ',

O b i.'

'+ 7 0 0 0 6 6 6 6 6 6 ',

'6 6 6 h e l l - s t r e e t ' ,

'8 7 4 7 6 3 ',0 )

После выполнения этого кода на экран будет выведено:
1 ro w s h a v e b e e n m o d i f i e d
(1 r o w ( s )

a ffe c te d ).

Теперь создадим триггер
строк:

delete,

подсчитывающий количество удаленных

CREATE TRIGGER t r D e l A u t h o r s
ON a u t h o r s
FOR DELETE AS r e i s e r r o r
('% d
ro w s
@ @ rowcount)

a re

g o in g

to

be

d e le te d

fro m

t h is

Теперь при удалении всех строк со значением поля
Sidorov:

ta b le '
a u _ fn a m e

0,

1,

равным

DELETE FROM a u t h o r s
WHERE a u _ fn a ro e =

'S i d o r o v '

После выполнения этого кода на экран будет выведено:
2 ro w s a r e g o in g
(2 r o w ( s )

to

be d e le te d

fro m t h i s

ta b le

a ffe c te d )

Основным применением триггеров является обеспечение целостности дан­
ных (ссылочная целостность, поддержка правил, каскадное изменение дан­
ных). Операция каскадного изменения легко программируется в триггере.
Допустим, закрывается книжный магазин. Можно создать триггер, удаляю­
щий его из таблицы shops и все относящиеся к нему строки из таблицы
sales. Такой триггер называется каскадным триггером delete.
Для начала можно создать две таблицы:
s p _ d b o p t io n p u b s

'S 6L E C T IN T O '

TRUE

GO
SELECT *

IN T O tb lS h o p s

FROM p u b s . . s t o r e s

SELECT *

IN TO t b l S a l e s

FROM p u b s . . s a l e s

После выполнения этого кода на экран будет выведено:
C H EC K PO IN Ting d a t a b a s e
(6 r o w ( s )

t h a t was c h a n g e d .

a ffe c te d )

(2 1 r o w ( s )

a ffe c te d )

Просмотреть содержимое полученных таблиц можно, выполнив команду:
SELECT s a . s t o r _ i d ,
WHERE s t . s t o r _ i d

s t . s to r_ n a m e FROM tb lS h o p s

s t,

t b lS a le s

sa

= s a .s to r _ id

Будем удалять 4 строки c s to r _ id , равным 7 067. Перед этим создадим для
таблицы tblSales триггер, сообщающий, сколько удаляется строк при удале­
нии записи о магазине из таблицы tblStores:
CREATE TRIGGER t r D e l S a l e s
ON t b l S a l e s
FOR DELETE AS
R a i s e r r o r ('% d ro w s
0 , 1 , @ @ rowcount)

a re

g o in g

to

be

d e le te d

frO o m

th e

s a le s

ta b le '

Теперь создается триггер для таблицы tblShops:
CREATE TRIGGER t r D e lS h o p s
ON tb lS h o p s
FOR DELETE AS
DELETE t b l S a l e s

FROM d e l e t e d WHERE d e l e t e d . s t o r _ i d

= t b lS h o p s . s t o r _ id

Удаление из таблицы tblShops, например, магазина под названием
News&Brews наглядно демонстрирует работу созданных триггеров:
DELETE FROM tb lS h o p s
WHERE t b l S h o p s . s t o r _ i d

=

>7067'

Результат:
4 ro w s a r e g o in g
(1 r o w ( s )

to

be d e le te d

fo rm

s a le s

ta b le

a ffe c te d )

Триггеры также применяются для поддержки правил. Конечно, для этого час­
то достаточно использования ограничений ANSI, значений по умолчанию или
пользовательских типов данных, однако при необходимости обращения к
другим таблицам триггеры оказываются совершенно незаменимыми. Кроме
того, при помощи триггеров реализуется механизм ссылочной целостности.
Нужно отметить, что триггеры изначально были разработаны именно для этой
цели. Они особенно эффективны при каскадном удалении и обновлении дан­
ных. При изменении данных условия триггеров проверяются в последнюю
очередь, а в начале проверяются ограничения. То есть если условие ограниче­
ния нарушено, то операция отменяется, и триггер не срабатывает.
Отдельное внимание стоит уделить триггерам типа i n s t e a d o f . Е с л и триггер
создается с этой опцией, то код триггера выполняется не после заданной
пользователем (или удаленной программой) команды, а вместо нее. Напри­

мер, разумно использовать триггеры i n s t e a d o f д л я сообщений о невоз­
можности удаления какого-либо объекта. Разумеется, эту функцию можно
реализовать и с помощью триггера a f t e r , однако в этом случае придется
отменять уже проделанную операцию, что неприемлемо для высоко загру­
женных систем, где ведется строгий контроль производительности.

11.3. Хранимые процедуры
Данный раздел посвящен одному из механизмов повышения эффективности
функционирования информационных систем, который базируется на ис­
пользовании хранимых процедур. Рассмотрим некоторые детали организа­
ции этого механизма на примере СУБД MS SQL Server.

11.3.1. Назначение хранимых процедур
Хранимая процедура — это последовательность компилированных операторов
Transact-SQL, хранящихся в системной базе данных SQL Server. Хранимые
процедуры предварительно откомпилированы, поэтому эффективность их
выполнения выше, чем у обычных запросов. Хранимые процедуры работают
непосредственно на сервере и хорошо укладываются в модель клиент —
сервер.
Существует два вида хранимых процедур: системные и пользовательские.
Системные хранимые процедуры предназначены для получения информации
из системных таблиц и выполнения различных служебных операций и осо­
бенно полезны при администрировании базы данных. Их имена начинаются
с sp_ (stored procedure).
Пользовательские хранимые процедуры создаются непосредственно разработ­
чиками или администраторами базы данных.
Полезность хранимых процедур определяется в первую очередь высокой (по
сравнению с обычными Т-SQL запросами) скоростью их выполнения. Кро­
ме того, они являются средством систематизации часто выполняемых опе­
раций. При выполнении в первый раз хранимой процедуры можно выделить
ряд этапов.
1. Процедура разбивается на отдельные компоненты лексическим анализа­
тором выражений.
2. Компоненты, ссылающиеся на объекты базы данных (таблицы, индексы,
представления и т. п.), сопоставляются с этими объектами с предвари­
тельной проверкой их существования. Этот процесс носит название раз­
решение ссылок.
3. В системной таблице syscomments сохраняется исходный текст процеду­
ры, а в таблице sysobjects — ее название.

4. Создается предварительный план выполнения запроса. Этот предвари­
тельный план называется нормализованным планом или деревом запроса и
хранится в системной таблице sysprocedures.
5. При первом выполнении хранимой процедуры дерево запроса считывает­
ся и окончательно оптимизируется. Выполняется ранее созданный план
процедуры.
Такая схема дает возможность при повторных вызовах не тратить время на
синтаксический анализ, разрешение ссылок и компиляцию дерева запросов.
А при последующих вызовах выполняется только пятый шаг. Причем план
хранимой процедуры после первого выполнения содержится в быстродейст­
вующем процедурном кэше. Это значит, что во время вызова процедуры
скорость его считывания будет очень высока.
Использование хранимых процедур имеют еще ряд дополнительных пре­
имуществ.
□ Хранимые процедуры позволяют выделять правила в отдельную структу­
ру. В дальнейшем эти правила используются многими приложениями,
образуя устойчивый к ошибкам интерфейс данных. Выгода такого подхо­
да состоит в том, что можно осуществлять изменение правил только для
отдельной части объектов базы данных, а не для всех ее приложений.
□ Использование хранимых процедур значительно повышает производи­
тельность запросов, однако наибольшей ее прирост достигается при вы­
полнении многократно повторяющихся операций, когда план запроса
постоянно хранится в системном кэше.
□ Хранимые процедуры могут принимать аргументы при запуске и возвра­
щать значения (в виде результирующих наборов данных).
□ Хранимые процедуры могут запускаться по расписанию (в режиме авто­
матического выполнения), задаваемому при запуске SQL Server.
□ Хранимые процедуры используются для извлечения или изменения дан­
ных в любое время.
□ Хранимые процедуры, в отличие от триггеров, вызываются явно. То есть
при непосредственном обращении к процедуре из приложения, сцена­
рия, пакета или задачи.
Хранимые процедуры — мощное средство обработки данных. Системные
хранимые процедуры играют очень важную роль в администрировании и
поддержке базы данных. Пользовательские хранимые процедуры применя­
ются при решении практически любых задач. Кроме того, пользователь мо­
жет получить право выполнения хранимой процедуры, даже если он не име­
ет права доступа к объектам, к которым обращается процедура.

11.3.2. Создание и использование
хранимых процедур
Хранимые процедуры создаются при помощи оператора c r e a t e p r o c e d u r e .
Процедура создается в текущей базе данных или, если это временная хра­
нимая процедура, во временной базе tempdb. Для создания необходимо об­
ладать правом вызова оператора c r e a t e p r o c e d u r e .
Существуют правила, которых необходимо придерживаться при создании
хранимой процедуры:
□ Имя хранимой процедуры подчиняется правилам по именованию иден­
тификаторов.
□ Во время выполнения хранимой процедуры все объекты, на которые она
ссылается, должны присутствовать в базе данных. Однако существует
свойство (позднее связывание имени), которое позволяет ссылаться на
несуществующий объект во время компиляции. Кроме того, хранимая
процедура при создании может генерировать временные объекты и затем
ссылаться на них при запуске.
□ В хранимой процедуре нельзя, создав объект, удалить его или создать за­
ново под тем же именем.
□ Хранимая процедура имеет не более 1024 параметров.
□ В хранимой процедуре можно ссылаться на временные таблицы. Все ло­
кальные временные таблицы по окончании ее выполнения удаляются.
□ В хранимых процедурах нельзя применять следующие операторы созда­
ния объектов:

create default , create

procedure, create view , create

RULE И CREAT TRIGGER.

□ Позволяется создавать процедуры, с уровнем вложенности, равным 32.
□ Если в хранимой процедуре используется оператор select * и в базовую
таблицу добавлены столбцы после создания этой процедуры, то новые
столбцы не будут отображаться при ее выполнении. Для того чтобы уст­
ранить это обстоятельство, необходимо использовать оператор alter
PROCEDURE.

Синтаксис оператора
CREATE PROC[EDURE]

create procedure:
им я_процедуры

[{@ п а р а м а тр ти п _ д а н н ы х }
[O U T P U T ]]
[W IT H

[,

число}

[= з н а ч е н и е _ п о _ у м о л ч а н и ю ]

...п]

[RECOM PILE

| ENCRYPTION

[FOR A P P L IC A T IO N S ]
AS o n e p a o p _S Q L

[VAR YIN G ]

{;

[... n ]

| RECOMPILE,

EN C RYPTIO N}]

Например:
CREATE PROCEDURE p A u th o r s
AS SELECT a u _ ln a m e ,

a u _ fn a m e

FROM a u t h o r s
ORDER BY a u _ ln a m e DESC

Результат:
T h is

command d i d

n o t re tu rn

d a ta ,

and i t

d id

n o t re tu rn

a n y ro w s .

Действительно, процедура и не должна возвращать какую-либо информа­
цию. Все операции произошли внутри базы данных.
Выполнив процедуру:
EXEC p A u th o r s

Получим следующий результат (табл. 11.3):
Таблица 11.3. Результат выполнения процедуры EX E C pAuthors
a u jn a m e

a u jn a m e

Yokomoto

Akiko

White

Johnson

Stringer

Dirk

Blotchet-Halls

Regenald Abraham

Bennet
(23 row(s) affected)

Как и было задано при создании процедуры, результат ее выполнения упо­
рядочен по фамилиям авторов с конца алфавита.
Для получения информации о существующей хранимой процедуре исполь­
зуется команда s p _ h e ip t e x t :
EXEC s p _ _ h e lp te x t p A u th o r s

Результат:
te x t
CREATE PROCEDURE p A u th o r s AS SELECT a u _ ln a m e ,

a u _ fn a m e FROM

A u th o r s ORDER BY au__lname DESC

To есть при вызове системной хранимой процедуры s p _ h e l p t e x t на экране
отобразился код пользовательской хранимой процедуры p A u th o r s .

Как уже было сказано выше, хранимые процедуры могут принимать пара­
метры. Рассмотрим их синтаксис:
(^параметр ти п _ д ан н ы х

[= зн а ч ен и е_ п о _у м о л ч ен и ю

| NULL]

[VARYING]

[OUTPUT]

Ключевое слово п а р а м е т р задает имя параметра хранимой процедуры. Ко­
личество параметров не может превышать 1024. Тип данных может быть
любым системным или пользовательским типом, кроме Image. Далее опре­
деляется значение параметра по умолчанию или n u l l (параметр не опреде­
лен). Ключевое слово o u t p u t определяет возвращаемость или невозвращаемость параметра. Рассмотрим использование процедур с параметрами на
простом примере:
CREATE PROCEDURE s c o r e s
@S1 S M A LLIN T,
@s2 S M A LLIN T,
@s3 S M A LLIN T,
@s4 S M A LLIN T,
@s5 S M A LLIN T,
@myAvg SM ALLINT OUTPUT
AS SELECT @myAvg =

(@ sl + @ s i

+ @s3 + @s4 + @s5)

/

5

Для того чтобы использовать эту процедуру, необходимо объявить перемен­
ную, в которой будет сохранен результат ее работы, а затем выполнить ее:
DECLARE S A v g S c o re SMALLINT
EXEC s c o r e s
SELECT

10,

9,

8,

'A v e r a g e s c o r e

8,

10,

is :

O A vg S core OUTPUT
@ AvgScore

GO

В результате на экран будет выведен следующий текст:
A v e ra g e s c o re
(1 r o w ( s )

is :

9

a ffe c te d )

Хранимые процедуры могут создаваться и использоваться не только на ло­
кальных машинах, но и на удаленных. Для этого должны быть выполнены
следующие три требования:
1. Сервер должен допускать удаленные подключения. Эта опция задается
при инсталляции и по умолчанию включена.
2. Оба сервера должны быть зарегистрированы друг у друга в таблицах
sysservers.
3. Оба сервера должны иметь в своих таблицах syslogins сведения об учетной
записи пользователя.

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

Для регистрации на удаленном сервере следует выполнить следующую команду:
EXRC и м я _ с е р в е р а .m a s t e r . d b o .s p _ a d d lo g in и м я _ п о л ь зо в а те л я

11.4. Администрирование баз данных
Администрирование любой системы управления базами данных сводится
к следующему ряду задач:
□ создание и удаление баз данных и файлов данных;
□ создание учетных записей, групп пользователей и распределение прав;
□ резервное копирование баз данных;
□ восстановление данных;
□ мониторинг производительности.
Microsoft SQL Server 2000 не является исключением. Рассмотрим вкратце
реализацию некоторых перечисленных задач в этой СУБД.

11.4.1. Создание и удаление баз данных
Для сервера, принадлежащего большой корпорации или нескольким фир­
мам одновременно, создание и удаление баз данных является практически
повседневной процедурой. Для менее крупных серверов, например, сервера
малой компании, создание большинства баз данных выполняется в процессе
проектирования. Каждая отдельная база данных является средством выпол­
нения какой-либо отдельной задачи.
Создание баз данных не представляет сложности и может выполняться любым
пользователем, имеющим право на выполнение команды c r e a t e d a t a b a s e .
Создать базу данных в Microsoft SQL Server можно тремя способами:
1. Оператором c r e a t e d a t a b a s e .
2. Мастером создания базы данных (Database Creation Wizard).
3. Средствами Enterprise Manager.
Рассмотрим синтаксис оператор c r e a t e d a t a b a s e :
CREATE DATABASE им я_базы _данны х
[ON {[P R IM A R Y ]
(NAME

л о ги ч ес ко е _и м я ,

FILENAME =

'ф и з и ч е с к о е _ и м я ',

[,

s iz e

= разм ер]

[,• M AXSIZE = м аксим альны й р а з м е р
[,
}[,

I U N L IM IT E D ]

FILEGROWTH = и н к р е м е н т _ у в е л и ч е н и я файлов]

)

...п]

[LOG ON
{(NAM E = л о г и ч е с к о е _ и м я ,
FILENAME =

'ф и з и ч е с к о е им я'

[,

S IZ E = р а з м е р

[,

M AXSIZE = м аксим альны й р а з м е р

[,

FILEGROWTH = и н к р е м е н т_ у в е л и ч е н и я _ ф а й л о в ]

[.

I U N L IM IT E D ]
I U N L IM IT E D ]
)}

n ]]

[COLLATE с п о с о б _ с о р т и р о в к и ]
[FOR LOAD]

[FOR ATTACH]

Вообще для создания базы данных в SQL Server 2000 достаточно одного па­
раметра — name (логическое имя). В этом случае создаваемая база данных
является точной копией системной базы model и отличается от нее лишь
логическим именем и параметром D a ta b a s e o w n e r, где хранится имя созда­
теля базы данных.
Ниже приведено краткое описание параметров вызова оператора create
database:
□ им я_б азы _дан ны х — определяет название базы данных, то есть логическое
имя, по которому к ней обращается пользователь SQL Server;
□ on p r im a r y — задает принадлежность файлов базы данных основной
группе;
□ name — определяет логическое имя для файлов базы данных;
□ filename — задает физическое имя файла, создаваемого на носителе ин­
формации;
□ s iz e — определяет начальный размер создаваемого файла;
□ M A X S IZE — определяет максимальный размер, до которого может увели­
читься файл;
□ FILEGROWTH — определяет, с каким шагом будет увеличиваться размер
базы данных;
□ log on — задает место положения журнала транзакций и его размер.
Другим способом создания базы данных является использование Enterprise
Manager. Его использование является предпочтительным во время проекти­
рования базы данных. Окно утилиты Enterprise Manager показано на рис. 11.11.
В левой части окна во вкладке структура иерархически отображаются все
доступные для администрирования сервисы SQL Server 2000. Для создания

новой базы данных нужно выполнить следующие действия. Последователь­
но перейдите к Console Root | Microsoft SQL Servers | SQL Server Group |
имя_запущенного_сервера. Далее щелкните правой кнопкой мыши на папке
Databases и выберите пункт New Database. Откроется окно Database Proper­
ties (рис. 11.12), где предлагается указать все характеристики создаваемой
базы данных. Параметры абсолютно идентичны тем, что задаются при вы­
полнении оператора c r e a t e d a t a b a s e .
В этом окне можно также менять свойства существующих баз данных. Из­
начально в папке Database отображаются только системные базы данных —
master, model, msdb, Northwind, pubs, tempdb.
Для создания базы данных с помощью мастера Database Creation Wizard,
необходимо в разделе Tools главного окна консоли Enterprise Manager
выбрать пункт Wizards, а в появившемся окне перейти к Database | Create
Database Wizard. Откроется окно создания базы данных, изображенное
на рис. 11.13. Этот мастер поэтапно запросит все параметры создаваемой
базы, сводя процесс к последовательному заполнению необходимых полей и
выбору приемлемых вариантов из списка.

Р и с. 1 1 .1 1 . Enterprise Manager

Рис. 11.12. Окно Database Properties

Рис. 11.13. Окно мастера Database Creation Wizard

Все три способа дают один и тот же результат. Первый является наименее
наглядным, однако при удаленном администрировании он же является
единственным приемлемым. Использование Enterprise Manager наиболее

разумно, когда администратор и сама СУБД находятся на одной машине, то
есть при локальном администрировании. Мастер создания базы данных яв­
ляется лишь средством упрощения работы с SQL Server и предпочтителен,
пожалуй, только для начинающих администраторов.
Для удаления базы данных используется оператор drop databse или утилита
Enterprise Manager. Особенностью этой процедуры является то, что при ее
выполнении должны быть учтены следующие условия:
□ При удалении базы данных удаляется вся информация, хранимая в ней,
информация об этой базе в системных таблицах и журналах транзакций.
□ Удаленная база данных может быть восстановлена только с резервной
копии.
□ Во время удаления базы данных ни один пользователь не должен быть
к ней подключен.
□ Для удаления базы данных необходимы права db_owner или sysadmin.
□ Чтобы выполнить оператор drop databse, необходимо находиться в базе
данных master.
Синтаксис оператора drop databse:
DROP DATABSE и м я _ б а з ы _ д а н н ы х !,

и м я _б азы _д а н н ы х 2,

11.4.2. Управление учетными записями
и правами доступа в Microsoft SQL Server
При подключении к MS SQL Server проверка прав доступа пользователя
возможна на трех уровнях. Первый уровень представляет служба защиты
данных Windows NT/2000 (в случае использования Windows 9х эта проверка
не осуществляется), второй — SQL Server (проверка учетной записи), а тре­
тий — отдельно взятая база данных (проверка имени пользователя и его
прав). То есть подключение происходит поэтапно. В идеале, удаленный
пользователь проходит следующие проверки:
□ Операционная система определяет, имеет ли данный пользователь права
на установку соединения. При положительном результате устанавливает­
ся соединение с удаленной машиной.
□ СУБД проверяет наличие учетной записи пользователя. При положи­
тельном результате создается сеанс подключения к службе Microsoft SQL
Server.
□ Вызываемая БД проверяет имя пользователя и определяет его права.
□ БД предоставляет доступ или отказывает в нем при каждом обращении
к тому или иному компоненту в зависимости от прав, которыми обладает

Другими словами, если, например, у пользователя имеется учетная запись,
это не значит, что ему будет предоставлен доступ ко всем базам данных.
Доступ к БД определяется только именем пользователя.
Microsoft SQL Server 2000 может использовать один из трех способов аутен­
тификации:
□ Смешанный режим (Mixed mode), при котором выполняются все выше­
описанные действия по аутентификации пользователя.
□ Режим аутентификации Windows (Integrated mode), при котором все обя­
занности по защите данных ложатся на операционную систему. Любой
пользователь, зарегистрированный в Windows, получает доступ к SQL
Server.
□ Режим аутентификации SQL Server. Используется для операционных
систем, не имеющих средств аутентификации пользователей, таких как
Windows 95/98/МЕ.
Для получения информации о выбранном режиме защиты или для его из­
менения в Enterprise Manager следует щелкнуть правой кнопкой мыши на
имени администрируемого сервера и, выбрав пункт меню Свойства, перейти
к вкладке Security. Окно SQL Server Properties с выбранной вкладкой
Security показано на рис. 11.14.

Создание учетных записей Windows в этой книге не рассматривается. Для
управления учетными записями и группами пользователей используется
компонент Пользователи и пароли панели управления.
Для управления учетными записями пользователей предназначены храни­
мые процедуры s p _ g r a n t l o g i n и s p _ r e v o k e i o g i n (для режима аутентифика­
ции SQL Server — s p _ a d d lo g in И s p _ d r o p _ lo g in ) .
Синтаксис процедуры s p _ g r a n t l o g i n :
EXEC s p _ g r a n t l o g i n

[@ lo g in n a m e = ]

'р е г и с т р а ц и о н н о е _ и м я '

Параметр р е г и с т р а ц и о н н о е _ и м я определяет имя пользователя или группы
Windows, которым предоставляется доступ к SQL Server.
Синтаксис s p _ r e v o k e i o g i n абсолютно идентичен:
EXEC s p _ r e v o k e l o g i n

[ @ lo g in n a m e = ]

'р е г и с т р а ц и о н н о е _ и м я '

При удалении учетных записей пользователей следует помнить о том, что
выполнение процедуры s p _ r e v o k e l o g i n для имени пользователя не имеет
смысла, если группа, в которую он входит, по-прежнему имеет права досту­
па. Для удаления учетной записи отдельного члена группы следует исполь­
зовать Хранимую процедуру s p _ d e n y lo g in .
Синтаксис s p _ d e n y lo g in :
EXEC s p _ d e n y o g in

' р еги стр а ц и о н н о е_и м я '

Для получения доступа к базе данных пользователь должен получить имя,
идентифицирующее его. По умолчанию пользователь, не являющийся сис­
темным администратором и не имеющий учетной записи в базе данных,
подсоединяется к ней под именем guest, которое создается по умолчанию
при создании базы данных. Если эта учетная запись была отключена, то
доступа к базе без учетной записи получить не удастся. Для создания псев­
донима имени пользователя БД используется системная хранимая процедура
s p _ a d d a ii a s . Эта процедура сопоставляет псевдоним с именем пользователя
SQL Server.
Синтаксис:
s p _ a d d a li a s

учетная_запись,

и м я _ п о л ь зо в а те л я

Для удаления псевдонима используется хранимая процедура
Синтаксис:
s p _ d r o p a lia s

s p _ d r o p a lia s .

р е ги с т р а ц и о н н о е _ и м я

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

ходимо регулярно создавать резервные копии баз данных и журналов тран­
закций. На крупных серверах, где интенсивность изменений в базе данных
очень велика, копирование баз данных происходит по несколько раз в су­
тки, а журналов транзакций — как минимум раз в два часа. Процесс восста­
новления базы данных состоит в восстановлении ее с резервной копии, вне­
сении в нее изменений из журнала транзакций, датированных временем
между созданием этой копии и последним копированием журнала и, если
это необходимо, ручным восстановлением изменений, внесенных в проме­
жуток времени между последним копированием журнала транзакций и по­
терей информации.
Не исключено, что повреждению может подвергнуться и резервная копия.
Поэтому рекомендуется хранить копии на отдельных носителях (съемных
жестких дисках или магнитной ленте), которые не могут быть повреждены
вместе с оборудованием, на котором работает MS SQL Server. Кроме того,
рекомендуется хранить резервные копии на несколько колен назад.
Сам процесс резервного копирования и восстановления полностью автома­
тизирован. Возможно даже составление распорядков резервного копирова­
ния, в соответствии с которыми SQL Server будет автоматически выполнять
эту процедуру для указанных баз данных в определенное время.
Непосредственно перед началом процедуры резервного копирования необ­
ходимо проверить целостность базы данных, например с помощью команды
d b c c c h e c k d b . Конечно, она не определит корректность информации в таб­
лицах, но проверит структурную целостность базы. Такие проверки умень­
шают риск копирования уже поврежденной базы, которую надо уже не ко­
пировать, а восстанавливать. Для создания резервных копий баз данных
служит оператор b a c k u p d a t a b a s e .
Синтаксис оператора b a c k u p d a t a b a s e :
BACKUP DATABASE {им я_базы _данны х

| @п ер ем ен н ая

ТО у с т р о й с т в о _ р е з е р в н о г о _ к о п и р о в а н и я
[W ITH

[B LO C K SIZE =

[[,]

D E S C R IP T IO N =

[[,]

D IF F E R E N T IA L ]

[[,]

E X PID A TE =

| RETAINDAYS =
[[,]

FORMAT

[[,]

{ IN IT

{р а з м е р _ б л о к а
(т е к с

{д а т а

{д ни

[,

}
n]

I @ п ер ем енн ая}]

| т е к с т о в а я _ п е р е м е н н а я }]

| © пе р е м ен н а я}

| б п е р е м е н н а я }]

| NOFORMAT]
| N O IN IT } ]

[[,]

M E D IA D E S C R IP T IO N =

[[,]

MEDIANAME =

[[,]

MEDIAPASSWORD =

[[,]

NAME =

[[,]

{N O SK IP

{ текст

{и м я _ н о с и т е л я

| @ т е к с т о в а я _ п е р е м е н н а я }]
| © п е р е м е н н а я }]

{п а р о л ь _ н о с и т е л я

{и м я _ р е з е р в н о й _ к о п и и
| S K IP } ]

| © п е р е м е н н а я }]

| © п е р е м е н н а я }]

,]

{NOÜNLOAD

| UN LO AD )]

[[,]

{NOREWIND

I R E W IN D )]

[[,]

RESTART]

[[,]

STATS

[ I

[= п р о ц е н т ы ]] ,

где устройство резервного копирования определяется следующим образом:
у с т р о й с т в о _ р е з е р в н о го _ к о п и р о в а н и я

: :=

{
{и м я _ у с т р о й с т в а _ р е з е в н о го _ к о п и р о в а н и я

| © п ерем ен ная

}

I
{D IS K

| ТАРЕ

| P IP E )

=

{ 'в р е м е н н о е _ у с т р о й с т в о _ р е з е р в н о г о _ к о п и р о в а н и я '

| бперем енная)

)
Основные параметры имеют следующие значения.

имя базы данных, с которой создается резервная копия.
□ б п е р е м ен н а я — значение параметра, хранимое в переменной, заменяю­
щей его в команде.
□ у с т р о й с т в о _ р е з е р в н о го _ к о п и р о в а н и я — имя устройства резервного копи­
рования (имя файла, устройства записи на магнитную ленту и т. п.).
□ d e s c r i p t i o n — описание устройства резервного копирования. Не более
256 символов.
□ Дата, до которой резервная копия не может быть перезаписана. При по­
пытке перезаписать резервную копию с неистекшим сроком будет выве­
дено сообщение об ошибке.
Резервное копирование журналов транзакций отличается лишь заголовком
( b a c k u p l o g ) и двумя параметрами — t r u n c a t e _ o n l y / n o _ l o g и n o _ t r u n c a t e .
Полное восстановление базы данных производится с помощью команды
□

имя_базы_данных —

RESTORE DATABASE.

Синтаксис

RESTORE

database:

RESTORE DATABASE имя__базы_данных FROM
у с т р о й с т в о _ р е з е р в н о го _ к о п и р о в а н и я
[ RESTRICTED__USER]
[[,]
[[,]
[[,]
[[,]

PASSWORD =

[ [ , ] F IL E

{п ар о л ь

MEDIANAME =

W ITH

= номер_ф айла ]

| © п е р е м е н н а я }]

{п а р о л ь _ н о с и т е л я

MOVE 'и м я _ ф а й л а '

n]

| © п е р е м е н н а я }]

{имя__носителя

MEDIAPASSWORD =

[,

TO

| © п е р е м е н н а я }]

'новое__имя_ф айла' ]

[,

n]

[ [ , ] KEEP R E P L IC A T IO N ]
[[,]

{NORECOVERY

[[,]

{NOUNLOAD

| RECOVERY

I UNLOAD}]

| STANDBY = и м я _ з а п а с н о го _ ф а й л а } ]

[ [ , ] REPLASE]
[ [,]

RESTART]

[[,]

{NOREWIND

[[,]

STATS

| R E W IN D }]

[= п р о ц е н т ы ]]

Вопросы и упражнения
1. Что означает термин "транзакция"? Поясните модель транзакции, опре­
деленную в стандарте SQL.
2. Какими основными свойствами должна обладать любая из транзакций?
3. Объясните, посредством какого специального механизма осуществляется
реализация транзакции.
4. Осветйте проблемы, возникающие при параллельной обработке транзакций.
5. Какой порядок планирования работы транзакций позволяет обеспечить
такой суммарный эффект выполнения смеси транзакций, который экви­
валентен эффекту их некоторого последовательного выполнения?
6. Какие типы блокировок различают? Как формулируется протокол двух­
фазной блокировки?
7. Каким образом с помощью триггеров можно обеспечивать целостность
базы данных? Каких правил необходимо придерживаться при создании
триггеров?
8. Чем в первую очередь определяется полезность хранимых процедур? Пе­
речислите этапы выполнения хранимой процедуры.
9. Каких правил необходимо придерживаться при создании хранимой про­
цедуры? С помощью какого оператора создаются хранимые процедуры и
как они используются?
10. Какой ряд задач включает в себя администрирование любой системы
управления базами данных?
11. Кем может быть создана база данных, и посредством какого оператора
это создание реализуется?
12. Опишите процесс управления учетными записями и правами доступа
в Microsoft SQL Server.

Глава 12

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

12.1. Объектно-ориентированные СУБД
Последние изменения в сфере разработки программного обеспечения связа­
ны с широким внедрением в эту область объектно-ориентированной техно­
логии. Данная технология позволяет работать на любом уровне абстракции.
Она снимает ограничение на типы данных, упаковывая вместе данные и код
для их обработки.
Начало работ над объектно-ориентированными СУБД (ООСУБД) было по­
ложено в середине 80-х годов. Целью разработок являлось обеспечение под­
держки приложений систем автоматизированного проектирования (САПР).
Иерархическая информация чертежей САПР обычно включает связи глуби­
ной порядка десяти уровней, что требует достаточно сложных операций для
"сборки" результата, и объектные базы данных хорошо соответствовали по­
добным задачам.
В начале 90-х годов производители ООСУБД обратили внимание на другие
области применения, уже прочно занятые реляционными СУБД. Для ус­
пешной конкуренции с ними ООСУБД потребовалось оснастить рядом до­
полнительных функций.
В 1989 г. был опубликован Манифест ООСУБД. Согласно Манифесту,
ООСУБД должны поддерживать сложные объекты, идентифицируемость
объектов, инкапсуляцию, ведущую к четкому различию между специфика­
цией и реализацией, понятия типа и класса, включая иерархии типов, рас­
ширяемость, вычислительную полноту и поддержку языка запросов.

12.1.1. Стандарт объектных баз данных ODMG-93
Летом 1991 г. в США была образована Object Database Management Group
(ODMG) — группа управления объектными базами данных — как консор­
циум фирм-производителей ООСУБД и других заинтересованных участни­
ков для разработки стандарта ООСУБД или, иначе, СУОБД (системы управ­
ления объектными базами данных). В конце 1993 г. группа опубликовала
стандарт объектных баз данных ODMG-93.
Архитектура СУОБД

ODMG-93 определяет СУОБД как СУБД, интегрирующую свойства баз
данных и объектно-ориентированных языков программирования.
В качестве основы объектной модели ODMG-93 используется объектная мо­
дель OMG. Объектная модель-ядро архитектуры OMG спроектирована
в качестве "общего знаменателя" брокеров объектных заявок, объектных
систем баз данных, объектных языков программирования и других приме­
нений. ODMG-93 конструирует профиль СУОБД для модели-ядра OMG,
вводя дополнительные компоненты (такие, как, например, связи).
Язык определения объектов (ODL). Основой языка определения объектов
ODL является язык определения интерфейсов IDL архитектуры OMG.
Язык объектных запросов (OQL) определен как декларативный язык запросов
для обращения к объектным базам данных и их обновления. Хотя OQL об­
ладает более мощной семантикой, в качестве синтаксической основы OQL
используется стандарт языка SQL-3.
Связывание с языками программирования. Особое внимание уделено наиболее
важному в настоящее время языку для связывания с СУОБД — языку C++.
Связывание с C++ основано на определении версии ODL на базе синтакси­
са C++. Связывание с C++ определяет способы написания мобильных
программ на нем для манипулирования долговременно хранимыми объекта­
ми, а также общие принципы связывания с языком Smalltalk. Синтаксис
языка манипулирования данными зависит от языка программирования.
На рис. 12.1 представлена структура типовой СУОБД. Программист исполь­
зует определения схем баз данных на ODL или их отображение в некоторый
язык программирования, например в C++ ODL. Прикладная программа
представляется на этом же языке программирования, расширенном средст­
вами манипулирования объектами. Определения схем баз данных и при­
кладная программа компилируются и обрабатываются редактором связей.
В результате образуется исполняемая программа, готовая к взаимодействию
с базами данных. Базы данных могут использоваться совместно с другими
прикладными программами благодаря управлению транзакциями и блоки­
ровкам, поддерживаемым СУОБД.

М одель данн ы х
В соответствии со стандартом объектная модель данных характеризуется ря­
дом свойств.
□ Базовыми примитивами являются объекты и литералы. Каждый объект
имеет уникальный идентификатор, литерал не имеет идентификатора.
П Объекты и литералы различаются по типу. Все элементы одного типа
имеют одинаковый диапазон изменения состояния (множество свойств)
и одинаковое поведение (множество определенных операций). Объект, на
который можно установить ссылку, называется экземпляром; он хранит
определенный набор данных.
□ Состояние объекта определяется набором значений, реализуемых множе­
ством свойств. Этими свойствами могут быть атрибуты объекта или связи
между объектом и одним или несколькими другими объектами.
□ Поведение объекта определяется набором операций, которые могут быть
выполнены над объектом или самим объектом. Операции могут иметь
список входных и выходных параметров строго определенного типа. Ка­
ждая операция может также возвращать типизированный результат.

□ База данных хранит объекты, позволяя совместно использовать их раз­
личным пользователям и приложениям. База данных основана на схеме
данных, определяемой языком определения данных, и содержит экземп­
ляры типов, определенных схемой.
Каждый тип имеет внешнюю спецификацию и одну или несколько реали­
заций. Спецификация определяет внешние характеристики типа: пользова­
телю для работы с объектом предоставляется набор операций и набор атри­
бутов объекта, при помощи которых можно работать с реальными
экземплярами. Реализация определяет внутреннее содержание объектов, на­
пример операции.
Тип также является объектом. Поддерживается иерархия супертипов и под­
типов, реализуя стандартный механизм объектно-ориентированного про­
граммирования — наследование.
Н о в ы е типы д а н н ы х
Одним из принципиальных отличий объектных баз данных от реляционных
является возможность создания и использования новых типов данных. Кон­
цептуально объект характеризуется поведением и состоянием. Определение
типа заключается в определении поведения, т. е. операций, которые могут
быть выполнены объектом или над состоянием объекта — набором атрибу­
тов определенных типов (атрибут может иметь любой объявленный в базе
тип). Важная особенность ООСУБД состоит в том, что создание нового типа
не требует модификации ядра базы и основано на принципах объектноориентированного программирования: инкапсуляции, наследовании, пере­
грузке операций и позднем связывании.
Как правило, в ООСУБД для объектов, которые предполагается хранить в
базе, требуется, чтобы их предком был конкретный базовый тип, опреде­
ляющий все основные операции взаимодействия с сервером баз данных.
Поэтому для создания своего типа необходимо унаследовать свойства лю­
бого имеющегося типа, наиболее подходящего по своему поведению и со­
стоянию к типу, который требуется получить, расширить недостающие опе­
рации и атрибуты и переопределить, по необходимости, уже имеющиеся.
В объектных базах данных также различают два вида операций и атрибутов,
распространяющих свое действие только на конкретный экземпляр или на
весь тип.
Поскольку ядро ООСУБД оптимизировано для операций с объектами, то ес­
тественными операциями для него являются кэширование объектов, ведение
версий объектов, разделение прав доступа к конкретным объектам. Как след­
ствие, ООСУБД свойственно более высокое быстродействие на операциях,
требующих доступа и получения данных, упакованных в объекты, по сравне­
нию с реляционными СУБД, для которых необходимость выборки связных
данных ведет к выполнению дополнительных внутренних операций.

Я зы к СУБД и з а п р о с ы
Общепризнаны две группы вариантов языков запросов.
□ Первая группа объединяет языки, унаследованные от SQL и представ­
ляющие собой разновидность языка OQL (Object Query Language), стан­
дартизованного ODMG. Однако поскольку некоторые функции принци­
пиально не могут быть реализованы для объектных баз данных только
средствами SQL (например, функции модификации структуры данных),
объектно-реляционные СУБД используют различные варианты ограни­
ченных объектных расширений SQL.
□ Вторая группа языков запросов базируется на языках группы XML QL
(или XQL). Они могут применяться в качестве языков запросов в объект­
ных и объектно-реляционных базах данных.
Т ран закц и и
В соответствии со стандартом ODMG 2.0, транзакции представляют логиче­
ский блок, гарантирующий атомарность, целостность, изолированность и
долговечность. На примере ООСУБД Versant рассмотрим наиболее типич­
ные виды транзакций: короткие, длинные, вложенные.
Короткие транзакции характеризуются малым временем выполнения; они
могут существовать только в рамках сеанса работы с ООСУБД. Все объекты,
подлежащие изменениям, блокируются, а после принятия транзакции с них
снимается блокировка, изменения же записываются в базу данных.
Длинные транзакции предназначены для увеличения производительности
при групповой работе. Для снижения вычислительной нагрузки на цен­
тральный сервер при одновременной работе большого числа пользователей
Versant предлагает пользователям, постоянно работающим с определенны­
ми объектами, возможность организации персональной базы данных. Поль­
зователи работают со своей базой, а объекты из нее синхронизируются
с групповой базой данных. Пользователь, начав длинную транзакцию, тем
самым отмечает объекты, с которыми предстоит работать в групповой базе
данных.
Эти объекты копируются в его персональную базу, а в групповой базе бло­
кируются, причем блокировать их можно как на запись, так и на чтение.
В групповой базе создается объект, содержащий все данные о длинных
транзакциях. В случае повреждения групповой базы или физического от­
ключения сервера групповой базы пользователь сможет продолжа+ь работу
с объектами в своей персональной базе, а после восстановления групповой
базы — синхронизировать объекты. Перед завершением длинной транзак­
ции пользователь должен поместить все измененные объекты обратно в ос­
новную базу (операция регистрации). После этого объекты копируются
в основную базу, а блокировка снимается. В случае аварийного завершения
длинной транзакции все изменения будут потеряны.

Вложенные транзакции по принципу функционирования аналогичны корот­
ким. В процессе выполнения одной транзакции формируются другие. Если
в текущем сеансе работает один процесс, то создается стек, а если несколь­
ко процессов — дерево транзакций.
Блокировки
В соответствии с терминологией, принятой в системе Versant, существуют
короткие, продолжительные блокировки.
Короткие блокировки предназначены для обеспечения последовательного
доступа к данным при многопользовательском режиме работы. Они автома­
тически выполняются во время выполнения коротких транзакций.
Продолжительные блокировки обеспечивают блокирование объектов на про­
должительное время — часы, дни, недели. Применяются совместно с длин­
ными транзакциями. При этом объект может быть заблокирован несколь­
кими способами: с исключением снятия другим процессом, с возможностью
снятия другим процессом, по конкретным операциям.
П ер ем ещ ен и е и верси он ность объектов
Немалое значение для ООСУБД имеет возможность перемещения объектов
из одной базы в другую. Подобный механизм применяется в ООСУБД
Versant, в которой поддерживаются следующие способы перемещения объектов.
□ Миграция объектов: постоянное их перемещение, например в другую ба­
зу данных.
□ Постановка на контроль: копирование объектов из групповой базы в пер­
сональную базу данных при выполнении длинной транзакции.
□ Регистрация объектов: копирование объектов в групповую базу данных из
персональной при выполнении длинной транзакции.
Проблема переносимости объектов из базы в базу тесно связана с разреше­
нием вопросов идентификации объектов. Как было отмечено выше, каждый
объект в базе данных должен иметь уникальный идентификатор (OID —
Object Identificator). Существует несколько подходов формирования OID:
□ формирование OID из идентификатора базы данных и идентификатора
объекта в базе, позволяющего переносить объекты из базы в базу без по­
тери связи между объектами;
□ формирование OID из имени класса объекта и собственно номера объек­
та, где уникальность номеров соблюдается только в пределах одной базы;
□ формирование OID из трех частей: номера базы, номера класса, номера
объекта, весьма проблематичного при использовании ООСУБД на раз­
личных платформах.
13 Зак. 3303

Большинство современных коммерческих ООСУБД поддерживает версионность, которая рассматривается многими авторами как отличительная черта
ООСУБД. Поддержка версионности полезна для некоторых приложений,
например, таких как делопроизводство, где также необходима поддержка
многих редакций документа. Кроме того, версионность способствует повы­
шению надежности информационной системы в целом: пользователи моди­
фицируют не сами объекты, а их версии, а окончательные изменения про­
исходят на сервере лишь после выполнения специальных процедур.
Три о с н о в н ы е х а р а к т е р и с т и к и О О СУ БД
Все ООСУБД по определению поддерживают сохранение и разделение объ­
ектов. ООБД не требуют многих из тех внутренних функций и механизмов,
которые столь привычны и необходимы в реляционных БД. Например, при
небольшом числе пользователей, длинных транзакциях и незначительной
загрузке сервера объектные СУБД не нуждаются в поддержке сложных ме­
ханизмов резервного копирования/восстановления.
В то же время важно представлять, как осуществляется поддержка трех
главных характеристик таких систем: целостности, масштабируемости и отказоустой чивости.
Большинство объектных СУБД помещают код приложения непосредственно
в то же адресное пространство, где работает сама СУБД. Благодаря этому
достигается повышение производительности, часто в 10—100 раз по сравне­
нию с раздельными адресными пространствами. Но при такой модели объ­
ект с ошибкой может повредить объекты и разрушить базу данных.
Грамотный специалист всегда учитывает, что большинство систем передают
приложению указатели на объекты (рис. 12.2), которые рано или поздно
обязательно становятся неверными и могут вызвать в лучшем случае крах
системы, в худшем — нарушить целостность базы данных.

Безопасная модель

Во избежание подобных проблем применяется косвенная адресация. СУБД
добавляет дополнительный указатель и, если объект перемещается, система
может автоматически разрешить ситуацию без возникновения конфликтной
ситуации.
Это необходимо для реализации второго необходимого свойства баз дан­
ных — масштабируемости. С этой задачей успешно справляется система
с многозвенной архитектурой клиент — сервер, благодаря которой происхо­
дит равномерное распределение вычислительной нагрузки между сервером и
конечным пользователем.
Третье необходимое качество базы данных — это отказоустойчивость. Суще­
ствуют несколько способов обеспечения отказоустойчивости.
□ Резервное копирование и восстановление: программистом определяются
потенциально опасные участки кода и вставляются некоторые операции,
соответствующие сохранению информации, необходимой для восстанов­
ления в случае сбоя.
□ Распределение компонентов: в использовании многозвенной архитектуры
источником сбоя могут послужить не только сами компьютеры, но и
коммуникационные каналы. При этом применяется трехфазный монитор
транзакций (транзакции осуществляются не в два, а в три этапа — посы­
лается запрос на готовность к транзакции) и осуществляется доступ ко
всем объектам.
□ Независимость компонентов: в современных системах у администратора
есть возможность динамически управлять сегментацией сети и дублиро­
вать критически важную информацию в каждом из сегментов и таким
образом поддерживать возможность работы в сети.
□ Копирование: подход, когда создается необходимое число копий в сег­
менте. Таким образом, увеличивается доступность копий и даже (при
распределении нагрузки между серверами) повышается скорость чтения.
Для создания ООСУБД были реализованы несколько проектов, например:
ORION, 02 и Cache. Приведем некоторые характеристики одного из них.
П р о е к т ORION
Проект ORION осуществлялся с 1985 по 1989 г. фирмой МСС под руково­
дством известного еще по работам в проекте System R Вона Кима. Под на­
званием ORION скрывается семейство трех СУБД.
Реализация всех систем производилась с использованием языка Common
Lisp на рабочих станциях (и их локальных сетях) Symbolics 3600 с ОС Genera 7.0
и SUN-3 в среде ОС UNIX.
Основными функциональными компонентами системы являются под­
системы управления памятью, объектами и транзакциями. В ORION-1 все

компоненты, естественно, располагаются на одной рабочей станции;
в ORION-1SX — разнесены между разными рабочими станциями. Сетевые
взаимодействия основывались на стандартных средствах операционных систем.
В число функций подсистемы управления памятью входит распределение
внешней памяти, перемещение страниц из буферов оперативной памяти во
внешнюю память и наоборот, поиск и размещение объектов в буферах опе­
ративной памяти.
Подсистема управления объектами включает подкомпоненты обработки за­
просов, управления схемой и версиями объектов. При обработке запросов
используется техника оптимизации, аналогичная применяемой в реляцион­
ных системах.
Подсистема управления транзакциями обеспечивает традиционную сериализуемость транзакций, а также поддерживает средства журнализации изменений и
восстановления БД после сбоев. Для сериализации транзакций применяется
разновидность двухфазного протокола синхронизационных захватов с раз­
личной степенью гранулированности.

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

ООСУБД полностью поддерживают объектно-ориентированные языки
программирования. Разработчики, применяющие C++ или Smalltalk, могут
использовать такие преимущества объектной технологии, как наследование,
инкапсуляция и полиморфизм. Прикладные программы обращаются и
функционируют с объектами, сохраненными в базе данных, которая исполь­
зует стандартную объектно-ориентированную семантику языка и операции.
Напротив, реляционная база данных требует, чтобы разработчик транслиро­
вал объектную модель к поддерживаемой модели данных и включил под­
программы, чтобы обеспечить это отображение во время выполнения. След­
ствием являются дополнительные усилия при разработке и уменьшение
эффективности.
ООСУБД подходят для организации распределенных вычислений, когда
приложения, и в первую очередь базы данных и средства принятия реше­
ний, работают в распределенных средах, в которых объекты (объектные
программные компоненты) распределены по многим рабочим станциям и
серверам и где любой пользователь может получить доступ к любому объек­
ту. Благодаря стандартам межкомпонентного взаимодействия, все эти фраг­
менты кода комбинируются друг с другом независимо от аппаратного
и программного обеспечения, операционных систем, сетей, компиляторов,
языков программирования, различных средств организации запросов и
формирования отчетов и динамически изменяются при манипулировании
объектами без потери работоспособности.

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

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

Р С У БД

ОРСУБД

Файловые
системы

ООСУБД

■>

Сложность данных
Р и с . 1 2 .3 . Классификация СУБД

Эта оригинальная классификация относит в нижний левый квадрант при­
ложения, предназначенные для обработки простых данных, не предусмат­
ривающие каких-либо требований в отношении выполнения запросов
к данным. К ним относятся такие пакеты для обработки текстов, как Word,
WordPerfect и Framemaker, использующие базовую операционную систему
для получения доступа к важнейшим функциональным возможностям лю­
бых СУБД.
В нижнем правом квадранте находятся приложения, призванные обрабаты­
вать сложные данные, но также не имеющие каких-либо серьезных потреб­
ностей выполнения запросов к данным. Для таких приложений, например
пакетов автоматизированного проектирования, наиболее подходят ООСУБД.
В верхнем левом квадранте расположены приложения, использующие про­
стые данные, но требующие выполнения сложных запросов. К этой катего­
рии можно отнести многие традиционные бизнес-приложения, для которых
наиболее подходящим типом систем управления базами данных являются
РСУБД.
И наконец, в верхнем правом квадранте находятся приложения, связанные с
обработкой сложных данных, в отношении которых необходимо выполнять
сложные запросы. Для их создания наиболее подходят ОРСУБД.
Естественно, что приведенная классификация имеет очень упрощенный ха­
рактер, поскольку в ее рамки не всегда удается уложить многие приложения
баз данных, и предназначена для того, чтобы только обозначить некоторые
усредненные тенденции.

12.2.1. Подходы к построению
объектно-реляционных СУБД
По мнению Стоунбрекера, существует три наиболее вероятных подхода
к построению ОРСУБД:
□ построить ядро объектно-реляционной СУБД;
□ сделать "надстройку" над реляционным ядром;
□ сделать "надстройку" над объектно-ориентированным ядром.
Рассмотрим по очереди каждый из них.
Для предоставления необходимых возможностей требуется ядро СУБД, ко­
торое было бы таблично управляемо из базы метаданных, содержащих ин­
формацию о таблицах, типах, функциях, операторах и наследовании. Каждый
отдельный модуль СУБД должен взаимодействовать с этими метаданными:
□ парсер должен определять, насколько правилен запрос;
□ оптимизатор — решать, какой путь доступа является наиболее подходя­
щим для запроса с функциями и операторами, определенными пользова­
телем;

О исполнитель — определить, какая именно функция будет выполняться
в каждой конкретной ситуации;
□ код метода доступа В-деревьев должен взаимодействовать с этими мета­
данными для определения того, какой из экземпляров оператора будет
использован для обхода структуры данных В-дерева.
Таким образом, вся СУБД должна быть таблично управляема этим обшир­
ным набором метаданных.
Теперь обратимся к архитектуре существующих реляционных СУБД. Все
они содержат метаданные, описываемые набором таблиц, но не имеют ин­
формации о типах, операторах, функциях или наследовании. К тому же, су­
ществующие типы, операторы и функции SQL являются жестко-встроенными
в ядро. Такие архитектуры крайне сложно расширить или изменить, вслед­
ствие чего их практически невозможно уложить в концепцию ОРСУБД. Во
избежание этих трудностей поставщики реляционных систем могут пойти
одним из следующих двух путей:
□ переписать ядра СУБД с самого начала;
□ написать "надстройку" над своими текущими продуктами, которая обес­
печивала бы требуемые возможности.
Первый путь рискован, труден и требует много времени и ресурсов, так что
может быть использован только в долговременной перспективе. В настоя­
щее время сложилось так, что поставщики, добавляющие поддержку объек­
тов, делают это, используя второй подход, "надстройку" Ведущие фирмы
в области разработки РСУБД, такие как Oracle, Informix и IBM, так и по­
ступили. Но поскольку расширению подвергались уже существующие сис­
темы, их функциональные возможности имеют свои особенности.
Основная идея заключается в том, чтобы создать "надстройку" между клиен­
том и реляционным ядром. Эта "надстройка" позволяет создать ОРСУБД на
основе существующих реляционных ядер. Легко заметить, что пользователь,
имеющий приложение в верхнем правом квадранте схемы на рис. 12.5, мо­
жет сам написать такой моделирующий уровень для современных реляци­
онных продуктов. Все, что будет делать такая надстройка, — автоматизиро­
вать эту функцию моделирования. Однако большинство пользователей,
которые попытались создать собственные надстройки для существующих
систем, столкнулись в итоге с очень плохой производительностью. В резуль­
тате технология надстроек только замаскирует, но не решит любую из про­
блем производительности, проистекающих из применения реляционных
систем при решении задач, для которых они не были разработаны.
И последний вариант — построение объектно-реляционной СУБД на основе
существующей объектно-ориентированной СУБД. То есть построение ядра
расширенного SQL над реализацией C++. Существует несколько препятст­
вий для такого рода реализаций.

□ Большой объем работы, связанный с тем, что современные объектноориентированные продукты обеспечивают только малую часть требуемых
функциональных возможностей, а следовательно, необходимо реализо­
вать значительную часть объектно-реляционной СУБД (парсер, система
поддержки представлений, оптимизатор и исполнитель расширенного
языка SQL).
□ В системах, построенных на базе C++ с постоянным хранением, прин­
ципиально отсутствует безопасность, а для создания программного обес­
печения, призванного защищать такие БД, потребуются значительные
финансовые вливания.
□ Серьезной проблемой администрирования будет являться тот факт, что
в среде C++ с постоянным хранением процедуры для добавления в
СУБД новой функции, оператора или типа данных программа должна
быть полностью перекомпилирована. В любой динамичной среде, где
множество пользователей выполняют множество программ, это крайне
нежелательно.
□ Поставщики объектно-ориентированных систем должны реализовать
много функций, чтобы переместиться из нижней части схемы наверх.
Кроме того, некоторые из их архитектурных решений были мотивирова­
ны созданием высокопроизводительного ядра для C++ и не подходят для
основанной на SQL объектно-реляционной СУБД.
В итоге получается следующее: поставщики реляционных систем должны
переписать свои продукты для движения из левого верхнего квадранта
в правый верхний квадрант. И такой вариант будет, конечно, с радостью
принят пользователем, поскольку расширенный реляционный подход по­
зволяет воспользоваться обширным объемом накопленных знаний и опыта,
связанных с разработкой реляционных приложений, и позволяет организа­
циям воспользоваться преимуществами новых расширений эволюционным
путем, без потери преимуществ, полученных от использования компонентов
и функций уже существующей базы данных.
Но при таком движении от квадрата к квадрату возникает, к сожалению,
целый ряд проблем, которые все еще не получили в настоящее время долж­
ного разрешения. Вот аргументы специалистов, скептически настроенных
по отношению к этому вопросу.
□ Сложность перехода и связанные с ним расходы.
□ Простота и ясность, присущая реляционной модели, утрачивается при
использовании подобных типов расширений.
□ Расширения РСУБД предназначены для незначительного количества
приложений. Причем в таких приложениях не может быть достигнута оп­
тимальная производительность при использовании имеющейся реляци­
онной технологии.

□ Потенциально утрачивается смысл объектно-ориентированного подхода,
что и обнаруживается большим семантическим разрывом между этими
двумя технологиями. Объектные приложения не настолько ориентирова­
ны на структуру данных, как реляционные приложения. Фактически
объекты принципиально не являются очередным расширением приятия
данных, потому что представляют совершенно другую концепцию,
с большим потенциалом выражения связей и поведения сущностей ре­
ального мира.
Таким образом, в отношении СУБД будущего поколения специалисты не
пришли еще к общему мнению относительно принципов ее организации.
Тем не менее несмотря на продолжающиеся горячие споры по основопола­
гающим концепциям этого вопроса, уже есть некоторый опыт построения
первых образцов ОРСУБД.

12.2.2. Первая попытка создания ОРСУБД
Одной из первых попыток создания ОРСУБД является система Postgres
(Post Ingres). Это исследовательская система управления базами данных, ко­
торая разрабатывалась как наследник РСУБД INGRES (Stonebraker and
Rowe, 1986). Задачей этого проекта было осуществление ряда целей.
□ Предоставление улучшенной поддержки сложных объектов.
□ Предоставление пользователям средств расширения типов данных, опе­
раторов и методов доступа.
□ Предоставление активных функций базы данных (обработчиков преду­
преждений и триггеров) и поддержка процесса логического вывода.
□ Упрощение кода СУБД для восстановления в случае сбоя.
□ Создание такого проекта системы, в котором использовались бы все пре­
имущества оптических дисков, многопроцессорных рабочих станций и
специализированных VLSI-микропроцессоров.
□ Внесение минимального количества изменений в реляционную модель.
Реляционная модель в СУБД Postgres бьша расширена с помощью включе­
ния следующих механизмов:
□ абстрактные типы данных;
□ данные типа "процедура";
□ правила.
Данные механизмы используются для поддержания разнообразных семанти­
ческих и объектно-ориентированных конструкций моделирования данных,
включая агрегацию, генерализацию, составные объекты, атрибуты, содер­
жащие ссылки на кортежи в других отношениях.
Рассмотрим кратко основные компоненты этой системы.

Абстрактные типы данных

В СУБД Postgres тип атрибута в отношении может быть атомарным или
структурированным. Предусматривается как использование некоторых пре­
допределенных атомарных типов, так и возможность создания пользовате­
лем новых структурированных и атомарных типов. Все типы данных опре­
деляются как абстрактные типы данных (ADT — Abstruct Data Type).
Определение ADT включает в себя: имя типа, его длину в байтах, процедуры
преобразования значения из внутреннего во внешнее представление (и на­
оборот), и принимаемое по умолчанию значение.
Процедуры преобразования реализуются на языке высокого уровня, напри­
мер на языке С, и определяются внутри системы. Оператор для абстрактных
типов данных определяется на основе типа возвращаемого значения, ука­
занного количества и типа операндов, приоритета и ассоциативности дан­
ного оператора, а также процедуры, с помощью которой он определяется и
которая указывается в определении данного.
Структурированные типы определяются с помощью конструктора типа для
массивов и процедур. Массив переменной или фиксированной длины опре­
деляется с помощью конструктора массива. В случае не упоминания длины
массива создается массив с динамической длиной. В свою очередь, конст­
руктор процедур позволит использовать в атрибутах значения типа
p r o c e d u r e , в таком случае процедура представляет собой ряд команд на
языке Postquel (языке запросов, используемом в СУБД Postgres). Этот тип
данных называется p o s t q u e l .
Отношения, наследование и запросы

В СУБД Postgres отношение может включать в себя как объявленные, так и
наследуемые атрибуты. При наследовании отношение получает все атрибуты
своих родителей, если только в его определении не выполнено переопреде­
ление каких-либо атрибутов. Поддерживается множественное наследование,
но только в том случае, если предки имеют одни и те же атрибуты. Таким
же образом происходит наследование спецификаций ключей.
В СУБД Postgres предусмотрены два способа доступа к атрибутам. В первом
используется вложенное обозначение на основе точки для неявного испол­
нения запроса. В другом способе выполнения запроса используется специ­
альная команда.
Параметры запроса могут быть взяты из других атрибутов кортежа, в этом
случае используется параметрические процедурные типы. Знак $ использу­
ется для ссылки на кортеж, в котором хранится запрос.
По сравнению с ООСУБД, в СУБД Postgres механизм абстрактных типов
данных ограничен. В системе Postgres объекты состоят из абстрактных типов
данных, а в объектно-ориентированных системах управления базами данных

все объекты рассматриваются как абстрактные типы данных. Это не совсем
соответствует концепции инкапсуляции. Также не существует механизма
наследования абстрактных типов данных, наследование может применяться
только к таблицам.
Любое отношение имеет явно определенный атрибут oid, который содержит
уникальный идентификатор кортежа, где каждое Oid-значение создается и
поддерживается СУБД Postgres. Атрибут oid доступен для пользовательских
запросов, но его обновление невозможно. Также атрибут oid может исполь­
зоваться как механизм, имитирующий типы атрибутов, ссылающихся на
кортежи из других отношений.
В то же время имя отношения может использоваться в качестве имени типа,
так как отношения, типы и процедуры имеют отдельные ячейки имен. Фак­
тическое значение аргумента передается тогда, когда атрибуту присваивается
некоторое значение.
Процессор запросов в ОРСУБД в случае необходимости выполняет оптими­
зацию запросов. Оптимизация запроса осуществляется за счет реализации
пользовательской функции на языке SQL, которая может быть определена
как внешняя, путем использования расширенного механизма оптимизации
запросов. Естественно, что для работы такого механизма требуется инфор­
мация определенного типа.
Так, например, в ОРСУБД при определении внешней пользовательской
функции для оптимизации выполнения запроса требуется предоставить сле­
дующую информацию.
□ Затраты вычислительных ресурсов центрального процессора для органи­
зации перехода к функции.
□ Предполагаемая доля байтов в аргументе, которую фактически считывает
функция. Этот фактор важен тогда, когда функции в качестве аргумента
требуется лишь некоторая часть полученного ею большого объекта.
□ Затраты вычислительных ресурсов центрального процессора для каждого
чтения байта.
Таким образом, возникает вопрос: каким образом получить эту необходи­
мую информацию. Проблема заключается в том, что пользователю будет
затруднительно предоставить необходимые данные. Другой способ заключа­
ется в том, чтобы ОРСУБД могла сама получить такие сведения, экспери­
ментируя с функциями и объектами разного размера и сложности.
Основными преимуществами расширенной реляционной модели данных
являются повторное и совместное использование компонентов. Повторное
использование основано на возможности расширения сервера СУБД стан­
дартными функциями, которые выполняются централизованно и не входят
в виде выполняемого кода в состав каждого приложения. В случае располо­
жения таких функций на сервере можно избежать их дублирования в каждом

приложении и организовать совместное использование данных функции
всеми приложениями. Эти преимущества также позволяют повысить произ­
водительность труда как разработчиков, так и конечных пользователей.
Альтернативная стратегия заключается в вызове пользовательской функции
не сервером РСУБД, а клиентом. Такая стратегия наиболее подходит тогда,
когда объем вычислений в пользовательской функции очень велик и клиент
обладает необходимой вычислительной мощностью и возможностью выпол­
нения пользовательской функции. Это позволяет снизить нагрузку на сервер
и загруженность всей сети, а следовательно, увеличить производительность
системы в целом.
Такой подход позволяет решить проблему обеспечения безопасности при
работе с пользовательской функцией. Так, например, если пользовательская
функция вызывает появление некоторой неисправимой ошибки во время ее
выполнения, а код пользовательской функции совмещен с ОРСУБД, то та­
кая ошибка может вызвать сбой всей системы.
Ясно, что в ОРСУБД должны быть предусмотрены необходимые средства
защиты от возникновения подобных ситуаций. Так, например, один из под­
ходов заключается в том, чтобы создавать все пользовательские функции на
таких интерпретируемых языках, как SQL или Java. Но в стандарте SQL до­
пускается использование внешней подпрограммы на языке высокого уров­
ня, такой, как C++, которая вызывается как пользовательская функция.
В таком случае можно применять подход, заключающийся в различных ад­
ресных пространствах пользовательской функции и сервера ОРСУБД, а для
их взаимодействия следует предусмотреть какой-либо вариант взаимодейст­
вия процессов. При использовании такого подхода ошибка в пользователь­
ской функции приведет всего лишь к сбою процесса самой пользователь­
ской функции и не затронет функционирование системы в целом.
Новые типы индексов

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

□ Квадро-деревья.
□ K-D-B-деревья.
□ R-деревья (region trees), предназначенные для быстрого доступа к дву­
мерным и трехмерным данным.
□ Решеточные деревья.
П D-деревья, предназначенные для поддержки текстов.
За счет механизма подключения любой определенной пользователем ин­
дексной структуры обеспечивается наивысший уровень гибкости. Для этой
цели в РСУБД публикуется интерфейс метода доступа, что позволяет поль­
зователям создавать свои собственные методы доступа, максимально подхо­
дящие для выполнения их задач. Поэтому программист, отвечающий за соз­
дание метода доступа, не должен забывать о таких механизмах СУБД, как
блокировка, восстановление и управление страницами памяти.
В некоторых ОРСУБД предусмотрена шаблонная универсальная структура
индекса, которая является достаточно общей, для охвата большей части
проектируемых пользователями индексных структур, одновременно обеспе­
чивающая взаимодействие с обычными механизмами СУБД.

12.2.3. Стандарт SQL3
В 1998 году в стандарт SQL был предложен к включению ряд дополнитель­
ных компонентов, необходимых для поддержки объектно-ориентированного
управления данными. Данная версия стандарта получила название SQL-3.
Стандарт SQL-3 спроектирован с учетом совместимости снизу вверх со
стандартом SQL, а потому любые ОРСУБД, совместимые с SQL-3, должны
удовлетворять этому условию.
Некоторые из данных компонентов, многие из которых уже обсуждались
раньше, приведены в табл. 12.1.
Таблица 12.1. Дополнительные компоненты стандарта SQL-3
Тип компонента

Пояснения

Типы-конструкторы
для строковых
и ссылочных типов

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

О пределенны е
пользователем
типы

Типы, которые могут участвовать в связях супертип/подтип
(UDT-типы) и использоваться так ж е, как и встроенны е типы, и
которые делятся на д в е категории: отдельны е типы и структу­
рированные типы

Таблица 12.1 (окончание)

Тип компонента

Пояснения

О пределенны е
пол ьзовател ем
процедуры, ф унк­
ции, операторы

Вызываемые средствам и SQL UDR-подпрограммы могут оп ­
ределяться как часть UDT-типа или отдельно как часть схемы

Т ипы-конструкторы
для типов коллек­
ций

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

П оддерж ка
боль­
ших объектов

Большой о б ъ ек т — это поле таблицы, с о д е р ж а щ е е больш ое
количество данных (больш ой текстовой или графический
ф айл)

Как стало очевидно, развитие стандарта языка SQL идет по пути все боль­
шего его усложнения. Это приводит к потере следующих неоспоримых пре­
имуществ языка SQL-89:
□ простота использования для конечных пользователей;
□ простая структура команд и синтаксис.
Дальнейшее развитие концепций объектно-реляционных СУБД ожидается
в стандарте SQL-4.

12.2.4. К. Дейт об объктно-реляционных СУБД
Таким образом, из приведенного выше материала можно сделать вывод, что
в мире еще не найден компромиссный вариант соединения принципов объ­
ектно-ориентированных и реляционных СУБД, способный аккумулировать
все привлекательные с точки зрения баз данных стороны. Пока проблема
кажется неразрешимой. Среди специалистов существует мнение, что в уже
имеющихся попытках для такого объединения был выбран не совсем удач­
ный базис.
В этом плане заслуживает внимательного рассмотрения позиция по этому
вопросу такого крупного специалиста в области баз данных, как К. Дейт.
Приведем здесь некоторые его взгляды на принципы построения ОРСУБД.
□ Осторожное обращение с инкапсуляцией в системах поддержки баз дан­
ных, которая предполагает составление процедур доступа к данным на
этапе разработки системы. Такое положение дел вступает в противоречие
с практикой, показывающей, что всегда будет существовать необходи­
мость реализации такого способа доступа к данным, который не мог быть
предвиден на этапе создания системы. В такой ситуации в процессе экс­
плуатации каждый новый доступ к данным потребует составления новой

процедуры, что не может являться приемлемым решением, поскольку
именно такая ситуация имела место для дореляционных систем, и имен­
но это привело к их исчезновению.
□ Разработчики многих ОРСУБД в качестве отправных моментов выбрали
не совсем правильные соответствия. Они исходили из того, что сравни­
мыми понятиями являются классы и отношения. В основу создания
ОРСУБД должна быть положена следующая основная параллель: фунда­
ментальной основе ОО-систем, которой является объектный класс (опре­
деленный пользователем инкапсулированный тип данных с произволь­
ной внутренней сложностью), должна соответствовать фундаментальная
основа реляционных систем, которой должен являться домен (также оп­
ределенный пользователем инкапсулированный тип данных с произволь­
ной внутренней сложностью).
Таким образом, исходя из того, что домены и объектные классы — это,
по сути, одно и то же, реляционная система, в которой воплощены до­
мены, в принципе могла бы решить все задачи, выполнимые в объектноориентированной системе и не выполнимые в реляционной системе.
Взяв упомянутую выше концепцию за основу, можно провести дальше
параллель на более детальных уровнях:
• экземпляр — элемент домена;
• семейство — набор значений любого атрибута, определенного на дан­
ном домене, причем доступ к отдельному экземпляру со стороны не­
скольких семейств может быть достигнут с помощью внешних ключей
значениям.
□ Полученная система должна оставаться реляционной, а значит сохранять
преимущества реляционных систем, естественно расширяясь за счет при­
обретения следующих, в том числе и объектно-ориентированных черт. Это:
• открытая архитектура;
• пользовательские типы данных и функции с наследованием;
• строгое определение типов;
• увеличение быстродействия за счет того, что методы выполняются
сервером, а не клиентом;
• улучшенная производительность, вызываемая использованием клас­
сов, которые обеспечивают увеличение как скорости разработки при­
ложений, так и их использования;
• восстановление, безопасность и параллелизм на уровне объектов;
• доступность.
□ Поскольку основа такой системы — реляционная, то данная система
будет способна без затруднений поддерживать функции, которые

в отношении объектно-ориентированных систем вызывали критические
замечания:
• незапланированные запросы;
• двухрежимный доступ (программируемый и интерактивный);
• связи между двумя и более объектами;
• методы, охватывающие несколько классов;
• симметрическая обработка;
• декларативные ограничения целостности;
• ограничения целостности, охватывающие несколько классов;
• правила внешних ключей;
• семантическая оптимизация.
Полученный в результате таких посылок программный продукт будет со­
четать в себе преимущества систем обоих классов и окажется способным
использоваться для сложных прикладных областей.

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

12.3.1. Оперативные системы
Рассмотрим фирму, которая ведет некую производственную и торговую дея­
тельность: скажем, что-то проектирует, производит и продает. Для продажи
у нее имеется, в частности, торговая система, которая учитывает движение
товарных и денежных средств.
Повседневная деятельность такой фирмы сопровождается ежедневным вне­
сением в базу данных десятков счетов, накладных и других оперативных до­
кументов. Реляционные СУБД, рассмотренные выше, проектировались и
используются для выполнения именно такой работы — для управления
большим потоком транзакций, каждая из которых связана с внесением не­
больших изменений в оперативные данные предприятия. Системы такого
типа называются системами оперативной обработки транзакций или OLTP

(Online Transaction Processing). Будем называть их просто оперативными сис-г
темами.
Известно, что структура БД оперативных с-истем в высокой степени норма­
лизована, т. е. состоит из множества таблиц, связанных между собой по­
средством внешних ключей. Такая нормализованная структура оптимизиро­
вана именно для быстрого поиска и обработки единичных записей.
Потребности в оперативных документах краткосрочны. С оперативными
документами работают в течение какого-то времени: отслеживают оплату
счета, приход денег, поставку товара и т. д. Для контроля данного процесса
периодически формируются отчеты, которые имеют несколько стандартных
для фирмы разновидностей и строятся путем выборки данных непосредст­
венно из БД торговой системы. Оперативный документ, сыграв свою роль,
далее в рамках торговой системы, как правило, больше не используется.
Со временем растущий объем данных начинает замедлять выполнение опе­
раций, что порождает естественное желание избавиться от старых неисполь­
зуемых данных.

12.3.2. Информационные системы
Между тем в накопленных данных содержится история развития предпри­
ятия, история его взаимоотношений с поставщиками и покупателями. Дан­
ные, накопленные в предприятии, — уникальный ресурс. В результате их ана­
лиза можно было бы получить ценнейшую информацию, позволяющую
принимать эффективные управленческие решения. Ценность информации,
а следовательно, и глубина анализа еще более возрастут, если использовать
объединенную информацию всего предприятия, всех его систем. Но для этого
руководителю может потребоваться исследование десятков тысяч комбинаций
данных, не укладывающихся в имеющийся набор готовых отчетных форм.
Следует отметить, что подобные исследования редко проводятся самим руко­
водителем. Чаще он приглашает или выращивает в своей фирме аналитика,
который хочет извлечь из данных все, что можно. Например, понять, какой
тип клиентов наиболее перспективен для фирмы, или какие скидки будут оп­
тимальными этой весной. Но сделать это оказывается не так-то просто.
Традиционный анализ, который, как правило, осуществляется при помощи
изучения набора готовых отчетных форм, а его результатом является приня­
тие одного из стандартных бизнес-решений, здесь явно не поможет. Если
считать, что в распоряжении аналитика имеется только традиционная
СУБД, то при выполнении возложенных на него обязанностей он столкнет­
ся с рядом проблем:
□ построение сводных отчетов над нормализованной структурой, как пра­
вило, неэффективно: связывание большого числа таблиц в одном запросе
выполняется достаточно долго, если объем этих таблиц велик;

□ выполнение сложных аналитических запросов над большими таблицами
может поглотить значительную долю ресурсов сервера и ощутимо замед­
лить работу оперативной системы;
□ замедление может быть вызвано и тем, что аналитический запрос блоки­
рует таблицы и не дает возможность оперативным приложениям обнов­
лять данные (они должны ждать, пока запрос завершится);
□ для реализации возложенных на него задач аналитик, таким образом, дол­
жен не только мыслить категориями предметной области, но и обладать
специальными знаниями в области баз данных, чтобы разобраться в высоконормализованной структуре БД и понять логику работы приложений;
□ может оказаться, что нужные данные находятся в разных подсистемах
автоматизации, которые к тому же могут иметь другой формат, и их све­
дение в единый отчет потребует существенно большего времени.
Таким образом, традиционными средствами выполнить работу, необходи­
мую аналитику, даже один раз сложно. А успешная повседневная жизнь
предприятия требует проведения таких исследований в большом количестве,
и величина их ценности подчас обратно пропорциональна времени их вы­
полнения. Наиболее подходящий вариант в такой ситуации — быстро полу­
чить любые нужные для анализа данные путем нескольких щелчков мышью.
Это позволит своевременно увидеть изменение коммерческой ситуации и
оперативно на него отреагировать.
Для реализации указанных выше целей типичную структуру СУБД необхо­
димо изменить коренным образом. Однако и теория, и практика говорят
о том, что попытки сочетать в одной системе оперативные и информацион­
ные функции хороших результатов не дают. Информационная система
должна строиться на особой структуре данных.
Для упрощения подобного анализа была предложена и разработана концеп­
ция хранилища данных. Предполагается, что такое хранилище содержит све­
дения, поступающие от разных источников, а также интегрированные дан­
ные, получаемые в результате анализа первичных данных. Естественно, для
поддержки предложенной концепции потребовались специальные средства
управления процессом хранения и обработки информации, к которым отно­
сятся инструментальные средства OLAP-технологии.
OLAP ( Online Analytical Processing — оперативная аналитическая обработка) —
это способ представления данных в простом и понятном для конечного
пользователя виде. Назначение систем класса OLAP — предоставить пользо­
вателям гибкий, интуитивно понятный и простой доступ к данным. Нали­
чие такого доступа позволяет отказаться от использования предопределен­
ных отчетов, делает пользователей самодостаточными, независящими от
администраторов БД и программистов. В основе концепции OLAP лежит
принцип многомерного представления данных. Данные представляются
в виде многомерного куба, причем пользователь может быстро свернуть или

развернуть данные по любому измерению. Хранилища данных не заменяют,
а дополняют традиционные реляционные базы данных с первичной инфор­
мацией.
Для построения систем OLAP используются специализированные много­
мерные БД либо надстройки над обычными реляционными БД. До послед­
него времени OLAP-технология ассоциировалась с большими проектами
по хранению массивов данных и сложными приложениями для их анализа.
Сложный и дорогой OLAP-инструментарий был доступен только очень
крупным компаниям.
И все же в последнее время ситуация на рынке резко изменилась. Про­
изошло это благодаря тому, что было найдено компромиссное решение:
укомплектовать полноценным OLAP-сервером хорошо зарекомендовавшие
себя недорогие программные продукты. К таким продуктам относится, на­
пример, MS SQL-сервер баз данных, начиная с версии 7 и позднее, который
во всем мире активно используется для построения хранилищ данных. Ком­
пания Microsoft предпринимает ряд серьезных мер, чтобы обеспечить наи­
лучшую поддержку хранилищ данных и построения информационных сис­
тем. Вследствие указанного изменения ситуации современные OLAPсистемы анализа данных стали действительно доступны малому и среднему
бизнесу.

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

□ Для создания репозитория очищенных данных системы обработки тран­
закций и последующего получения отчетов из этих данных без измене­
ния самой OLTP-системы.
□ Для упрощения формирования запросов и отчетов по данным из не­
скольких систем обработки транзакций, а также из внешних источников
данных и/или по данным, которые хранятся только для отчетности.
□ Для создания репозитория данных OLTP-системы, содержащего долго­
временную информацию, хранение которой в системе обработки тран­
закций не эффективно. Либо для генерации отчетов, отражающих ситуа­
цию в предыдущие периоды.
□ Для ограничения доступа к базе данных системы и программной логике
ее управления лицам, использующим данные OLTP-систем исключи­
тельно для составления отчетов и запросов.
Как нетрудно заметить, большинство перечисленных выше причин создания
хранилищ данных часто связано с несовершенством систем обработки тран­
закций. Толчком к разработке хранилища данных могут послужить либо все
описанные выше причины, либо даже только одна из них.

12.3.4. Основополагающие концепции
Хранилище данных (Data warehouse) — это предметно-ориентированное, ин­
тегрированное, привязанное ко времени и неизменяемое собрание данных
для поддержки процесса принятия управляющих решений. Поясним смысл
указанных характеристик.
□ Предмето-ориентированностъ означает, что данные в хранилище организова­
ны вокруг существенных аспектов деятельности предприятия: товар, покупа­
тель, продажа и т. д. (а не узких атрибутов: счет, накладная, прайс-лист).
□ Интегрированность означает, что информация, которая загружается
в хранилище, должна интегрироваться в целостную структуру, отвечаю­
щую целям анализа данных. При этом минимизируются несоответствия
между данными из различных оперативных систем, одни и те же по
смыслу данные, полученные из разных оперативных систем, в хранилище
именуются и выражаются единым образом. Данные интегрированы на
множестве уровней: на уровне ключа, атрибута, на описательном, струк­
турном уровне и так далее. Общие данные и общая обработка данных
консолидированы и являются единообразными для всех данных, которые
подобны или схожи в хранилище данных. При этом информация струк­
турируется по различным уровням детализации:
• высокая степень суммаризации;
• низкая степень суммаризации;
• текущая детальная информация.

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

12.3.5. Основные компоненты хранилища данных
Использование технологии хранилищ данных предполагает наличие в сис­
теме следующих компонентов (рис. 12.4):
□ оперативных источников данных;
□ средств переноса и трансформации данных;
□ метаданных — включают каталог хранилища и правила преобразования
данных при загрузке их из оперативных БД;
□ реляционного хранилища;
□ OLAP-хранилища;
□ средств доступа и анализа данных.
Назначение перечисленных компонентов таково. Оперативные данные со­
бираются из различных источников. К ним относятся:
□ иерархические и сетевые базы данных первого поколения, хранящие
корпоративные данные;
□ реляционные базы данных, хранящие оперативные данные различных
подразделений;
□ закрытые сервера;
□ внешние системы (Интернет, базы данных поставщиков и т. д.).
Поступившие оперативные данные очищаются, интегрируются и складыва­
ются в реляционное хранилище. Они уже доступны для анализа при помо­
щи средств построения отчетов. Затем данные (полностью или частично)
подготавливаются с использованием средств переноса и трансформации
данных для OLAP-анализа, который реализуется применением средств дос­
тупа и анализа данных. При этом они могут быть загружены
в специальную БД OLAP или оставаться в реляционном хранилище.
Важнейшим элементом хранилища являются метаданные, т. е. данные о
структуре, размещении, трансформации данных, которые используются лю­
быми процессами хранилища. Метаданные могут быть востребованы для

различных целей, например: извлечения и загрузки данных; обслуживания
хранилища и запросов. Метаданные для различных процессов могут иметь
различную структуру, т. е. для одного и того же элемента данных может су­
ществовать несколько вариантов метаданных.
Источники оперативных данных •

Хранилище
*4

а

Реляционное
хранилище

S

3

Частично
обобщенные данные

“1

Интегрированные
данные

Нисходящий поток

А

JL
Метаданные

Метапоток
«------ ►

Выходной поток

Архивные
и резервные
копии

Пользователи
Рис. 12.4. Основные компоненты и потоки хранилища данных

12.3.6. Основные потоки данных в хранилище
В технологии хранилищ данных можно выделить пять основных информа­
ционных потоков данных (рис. 12.4).
□ Входной поток — процессы извлечения, очистки и загрузки исходных
данных в хранилище. Поступающие данные в хранилище подвергаются
перестройке в соответствии с определенными требованиями. Перестрой­
ка включает следующие действия:
• очистку данных;

• преобразование данных (включая, если потребуется, их денормали­
зацию);
• проверку внутренней непротиворечивости данных и их непротиворе­
чивости по отношению к данным хранилища.
Сложность процесса извлечения информации зависит от степени согла­
сованности между различными источниками информации.
□ Восходящий поток — повышение ценности сохраняемых в хранилище
данных. Данный поток представляет собой следующие процессы:
• обобщение данных посредством, как реляционных операций, так и
проведения сложного статистического анализа данных для получения
удобных и полезных для пользователя представлений информации;
• упаковку данных с преобразованием в более удобный формат пред­
ставления (электронные таблицы, диаграммы и многое другое);
• pàcпpeдeлeниe исходных данных на соответствующие группы для по­
вышения их подготовленности к использованию и доступности.
□ Нисходящий поток — архивирование и резервное копирование данных.
Нисходящий поток включает также процедуры, обеспечивающие воз­
можность восстановления текущего состояния хранилища в случае поте­
ри данных после сбоев в программном или аппаратном обеспечений.
□ Выходной поток — предоставление данных пользователям. Это, естест­
венно, наиболее важный с точки зрения пользователя поток информа­
ции. Для его формирования ему должна предоставляться среда с эффек­
тивно
работающими
инструментами,
позволяющими
создавать
разнообразные запросы, обеспечивая доступ к наиболее подходящим
данным хранилища. Данный поток может содержать и публикации раз­
личных объектов, которые доставляются по рассылке на рабочие станции
конечным пользователям.
□ Метапоток — управление метаданными. Он связан с перемещением са­
мих метаданных. Поскольку метаданные содержат описание информации
хранилища данных, которое со временем меняется, то и сам метапоток
должен соответственно обновляться во времени.

12.3.7. Типы хранилищ данных
Итак, хранилища данных являются структурированными. Они содержат ба­
зовые данные, которые образуют единый источник для обработки данных во
всех системах поддержки принятия решений. Элементарные данные, при­
сутствующие в хранилище, могут быть представлены в различной форме.
Хранилища данных исключительно велики, поскольку в них содержатся ин­
тегрированные и детализированные данные.

Эти характеристики являются общими для всех хранилищ данных. Но, не­
смотря на то что хранилища обладают общими свойствами, разные типы хра­
нилищ имеют свои индивидуальные особенности. Приведем ряд примеров.
Ф и н ан совы е храни ли щ а данны х
В большинстве случаев финансовые хранилища данных — это хранилища,
которые организации строят в первую очередь из-за ряда причин.
□ Финансовые данные находятся в центре организации. Поэтому привлечь
внимание к хорошо построенному финансовому хранилищу данных
очень легко.
□ В большинстве организаций (но не во всех) финансовые данные пред­
ставляют самые маленькие объемы данных.
□ Финансы охватывают все аспекты функционирования корпорации и
имеют один общий знаменатель — деньги.
□ Финансовые данные по своей природе имеют структуру, на которую напря­
мую влияет повседневная практика обработки финансовой информации.
По этим причинам финансы становятся предпочтительной областью по­
строения корпоративного хранилища данных.
Однако финансовые хранилища данных имеют серьезные, присущие только
этому типу хранилищ, недостатки. Главный из них заключается в том, что в
организациях ожидают, что сведения из финансовых хранилищ будут с точ­
ностью совпадать с данными существующей финансовой среды. Существует
множество причин, почему данные, находящиеся в хранилищах данных, от­
личаются от данных оперативных систем.
□ Меняются отчетные периоды. В операционной среде отчетный период
завершается в конце месяца, в среде хранилища данных заканчивается на
корпоративном календаре.
□ Меняются схемы группировки и кодирования счетов. В операционной
среде данные рассчитываются в соответствии с одним планом бухгалтер­
ских счетов, а в финансовой среде всей корпорации может быть совер­
шенно другой набор схемы группировки и кодирования.
□ Меняются классификации данных.
□ Меняются валюты. Операционные денежные средства соответствуют той
валюте, в которой они обращаются. В глобальной среде деньги преобра­
зуются к одной общей валюте.
Х ранилищ а данны х в области страхован ия
Хранилища данных в области страхования похожи на другие хранилища.
Но есть и ряд отличий:
□ продолжительность существования имеющихся хранилищ очень велика;
такие хранилища содержат данные, которые являются очень старыми;

□ среда страхования отличается наличием огромного числа дат всевозмож­
ных типов;
□ хранилища данных используют свой рабочий цикл деловой активности;
большинство организаций имеет весьма ограниченный и короткий эко­
номический цикл, и скорость, с которой функционирует страхование,
отличается от скорости, характерной для других отраслей.
Эта разница в скорости отражается в хранилище данных. В области страхо­
вания транзакция может откладываться на неопределенный срок, а ее раз­
личные части могут отражаться в хранилище данных. Результатом этого яв­
ляется совершенно особый подход при проектировании и внедрении таких
хранилищ данных.
Х ранилищ а данн ы х д л я уп равлен и я лю дски м и р е с у р с а м и
Хранилища данных для управления людскими ресурсами имеют весьма су­
щественные отличия от других хранилищ. Такое хранилище данных неиз­
бежно имеет одну важную предметную область — это работник. Практиче­
ски все остальное подчинено этой области или занимает второстепенное
положение. Большинство же других хранилищ данных имеют несколько ба­
зовых предметных областей.
Однако основное отличие хранилищ данных для управления людскими ресур­
сами состоит в том, что такие хранилища вообще-то используют очень мало
транзакций. Так, имеется дата, когда некто становится работником. Дата, ко­
гда человек увольняется. Годовые прибавки и повышения. Но, кроме транзак­
ций фонда заработной платы и прочих редких, сгенерированных работником
транзакций, в таком хранилище практически больше ничего и нет.
Эта разница в темпах транзакций между рассматриваемой и другими сфера­
ми деятельности является причиной возникновения определенной сложно­
сти, которая заключается в том, что в области управления человеческими
ресурсами наблюдается тенденция к объединению операционной обработки
людских ресурсов и обработки людских ресурсов для систем принятия ре­
шения в одну среду. В других же отраслях соблазн совершить такую архи­
тектурную ошибку весьма невелик.
Х ранилищ а данн ы х в о б л асти телеком м ун и кац и й
Отличительная особенность этих хранилищ состоит в том, что они в значи­
тельной степени определяются данными, сгенерированными в деталях
на уровне звонка. Разумеется, в отрасли телекоммуникации присутствует
множество других типов данных. Но ни одна другая область хранилищ дан­
ных не предопределяется в такой степени размером одной предметной об­
ласти — деталями на уровне звонка.
К сожалению, несмотря на разнообразие методов обработки, для данного
хранилища данных обработка может быть выполнена только над деталями

на уровне звонка. А работа на итоговом или агрегированном уровне просто
невозможна.
Г лобальны е хранилищ а данны х
Глобальные хранилища данных предназначены для глобального представле­
ния корпорации. Различают три типа таких хранилищ:
□ географически превалирующая обработка данных (например, необходимо
интегрировать бизнес в Москве с бизнесом в Ростове и так далее);
□ функционально превалирующая обработка данных (производственная
деятельность должна быть интегрирована с поставками, которые необхо­
димо интегрировать с продажами, а те — с исследованиями и так далее);
□ отраслевая превалирующая обработка данных (например, требуется ин­
тегрировать печатное дело с консалтингом, который подлежит интегра­
ции с бизнесом в сфере медицинского оборудования, а тот — со специа­
лизацией в области программного обеспечения).
Особенность глобального хранилища данных заключается в том, что на гло­
бальном уровне зачастую очень мало общих измерений. Единственное об­
щее измерение — это деньги. И интеграция бизнеса может быть достигнута
только с его помощью.
Помимо этого, глобальное хранилище данных подвержено воздействию пе­
ремен. Если в прочих хранилищах изменения базовых данных случаются
нечасто, то для этого типа хранилищ они происходят постоянно и в самом
основании. Поэтому структура и технология, используемая для размещения
и обслуживания глобального хранилища данных, должна позволять поддер­
живать эти непрерывные перемены.
Х ранилищ а данны х
с в о з м о ж н о с т я м и D ata M ining и E x p lo ra tio n
Построение хранилища и наполнение его данными — это только подготовка
к анализу. Для собственно анализа используются самые различные инстру­
менты, начиная от простого интерактивного построителя запросов типа
Microsoft Query и заканчивая средствами OLAP и Data Mining.
Хранилища данных, поддерживающие технологию Data Mining и Exploration
(методы добычи и исследования данных), являются гибридом классических
хранилищ. Такие хранилища используются для выполнения мощной стати­
стической обработки данных. Эта технология находит такую информацию
в хранилище, которую практически невозможно обнаружить, пользуясь за­
просами и отчетами. Достигается это за счет применения технологий искус­
ственного интеллекта. Эти хранилища являются:
□ очень детальными;

□ глубоко историческими;
□ оптимизированными для статистического анализа.
Кроме того, для таких хранилищ характерна ориентация на какой-либо про­
ект. Это означает, что, в отличие от всех других типов хранилищ данных, их
перестают использовать сразу по завершении анализа, ради которого они
создавались.
Еще одно важное отличие хранилищ данных с возможностями Data Mining
и Exploration заключается в том, что эти хранилища очень часто включают
внешние данные. Такие данные очень полезны с точки зрения обеспечения
бизнес-перспективы, которую не так легко увидеть без их участия.

12.3.8. СУБД для хранилища данных
Выше было отмечено, что для работы с хранилищем данных используются
СУБД, к которым предъявляются специальные требования. Поскольку в хо­
де обсуждения проблем хранилищ данных эти требования либо уже обсуж­
дались, либо присутствие их в перечне и без обсуждения интуитивно понят­
но, просто перечислим их:
□ высокая производительность загрузки данных;
□ возможность обработки данных на уровне загрузки;
□ наличие средств управления качеством данных;
□ высокая производительность запросов;
□ широкая масштабируемость по размеру и количеству пользователей;
□ возможность организации сети хранилищ данных;
П наличие средств администрации хранилищ данных;
□ поддержка интегрированного многомерного анализа;
□ расширенный набор функциональных средств запросов.

12.3.9. Мультихранилища данных
Поскольку технология хранилища данных испытывает колоссальный подъем
и востребована во многих отраслях, неудивительно, что многие компании
(в первую очередь крупные организации) должны определиться: строить
только одно или несколько хранилищ данных и какое архитектурное реше­
ние проблемы предпочесть.
Существуют различные типы хранилищ. Ниже описаны два наиболее общих
типа.
□ Хранилище данных, детализированное на уровне исходных систем, в ко­
тором собраны и интегрированы структурированные атомарные данные.

Этот тип хранилища служит основным источником данных, такое храни­
лище является общим для многих подразделений корпорации и часто со­
держит огромное количество данных.
□ Витрины данных, в которых различные отделы собирают данные для
своих частных целей. Витрины данных обычно содержат как итоговые,
так и заказные данные, которые отражают индивидуальные пристрастия
и потребности вышестоящие отделов, таких как финансовый, маркетин­
говый отделы, отдел продаж и так далее.
Эти два типа хранилищ данных всегда существовали бок о бок, взаимно до­
полняя другу друга. Хранилище детальных данных создает благоприятную
почву для удовлетворения различных потребностей различных отделов.
В хорошо сконструированной архитектуре такое хранилище получает интег­
рированные и трансформированные данные из операционной среды и пере­
дает эти данные в различные витрины данных. Это хранилище, как правило,
питает много витрин данных. Следовательно, существование множества
витрин данных и хранилища детальных данных в одной компании вполне
нормальное и естественно явление. Точно так же нормально и естественно
располагать несколькими хранилищами данных в одной и той же компании.
М ультихранилищ а д етал ьн ы х данн ы х
Если компания является крупной транснациональной корпорацией, воз­
можность создания многочисленных хранилищ (мультихранилищ) деталь­
ных данных вполне допустима. У производственного отдела будет свое хра­
нилище детальных данных, у отдела внешних продаж — свое, у отдела
внутренних продаж — свое и так далее.
Однако даже в тех случаях, когда существование мультихранилищ данных
продиктовано бизнес-необходимостью, все же следует рассмотреть некото­
рые вопросы, связанные с архитектурой и проектированием.
Первый необходимый момент заключается в том, что каждая база должна
содержать данные, которые не пересекаются с данными из любой другой
базы. Если бы такое наложение имело место, то достижение высокой степе­
ни корпоративной интеграции было трудно выполнимым или даже невоз­
можным. Один из критериев успешности многочисленных корпоративных
баз данных заключается в том, что единственно допустимое перекрытие ме­
жду ними существует в виде связей посредством внешних ключей.
Если в компании построено несколько хранилищ данных, обязательно воз­
никнет необходимость в соединении этих хранилищ. Такое соединение
можно реализовать, создав и поддерживая связи между этими хранилищами
посредством внешних ключей. Однако связи с помощью внешних ключей
неизбежно вызовут некоторую степень избыточности данных.
Еще один тип данных, который должен быть совместимым среди различных
хранилищ детальных данных — это корпоративные справочные данные.

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

12.3.10. Архитектурные решения
На сегодняшний день методика построения хранилищ данных опирается на
богатейший набор архитектурных решений, которые тем не менее основы­
ваются на двух главных подходах: "сверху вниз" (top down) и "снизу вверх"
(bottom up). Рассмотрим некоторые варианты.
К л асси ч еск о е хранилищ е данны х
Как уже отмечалось, классическое хранилище данных является широко рас­
пространенным и уникальным репозиторием информации предприятия.
Среда хранилища предназначена только для чтения и состоит из детальных
и агрегированных данных, которые полностью очищены и интегрированы;
кроме того, в нем хранится обширная и детальная история данных на уров­
не транзакций. Хранилище данных реализует свои функции, прежде всего,
через подмножество зависимых витрин данных (рис. 12.5).

Р и с . 1 2 .5 . Классическое хранилище данных

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

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

Система объединенных хранилищ и витрин данных характеризуется совме­
стным использованием общих информационных точек, устраняя, таким об­
разом, избыточность и гарантируя достоверность информации по всей орга­
низации (рис. 12.6).
Источники оперативных данных

Витрины данных

Р и с . 1 2 .6 . Системы объединенны х хранилищ данных

Достоинства системы объединенных хранилищ и витрин данных:
□ общая семантика и бизнес-правила;
□ один набор процессов извлечения и бизнес-правил;
□ децентрализованные ресурсы и управление;
□ параллельная разработка.
Недостатки такого архитектурного решения:
□ необходимость в координировании работ;
□ сложности в преодолении моментов согласования и решении вопросов
авторских прав;
□ требуется согласованность среди различных отделов по вопросам архи­
тектуры, бизнес-правил и семантики;
□ сложнейшая техническая среда;
□ наличие многочисленных репозиториев метаданных.
С и с т е м а п о с т е п е н н о р а з в и в а е м ы х ви тр и н д а н н ы х
Данная архитектура является альтернативой хранилища данных предпри­
ятия. Для наполнения таких витрин обычно используется инструментальное
средство класса предприятия.

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

Первоначально этот подход был единственным способом создания системы
хранилища данных. При подходе "сверху вниз" хранилище данных разраба­
тывается, проектируется и строится итерационным способом. Хранилище
данных предприятия составляется из множества предметных областей, таких
как финансы, людские ресурсы, маркетинг, продажи, производство и так
далее. При таком подходе хранилище разрабатывается целиком, а затем вы­
бирается узкий срез предметной области для конструирования (рис. 12.7).
Далее строятся последующие слои до тех пор, пока хранилище полностью
не завершено. На создание систем хранилища данных предприятия с ис­
пользованием данного подхода уходит 3—4 года.
Несмотря на свойственную этому подходу техническую элегантность, он
изобилует множеством реальных проблем, порождаемых отклонением ре­
альной обстановки создания системы от идеальных условий. В реальном
мире разработчики хранилищ часто оказываются во власти взаимопротиворечащих факторов, не выдерживаемых предельных конечных сроков, уста­
ревших систем данных, неразумных требований пользователей.
Основная проблема заключается в том, что, создавая хранилище данных
предприятия, специалисты должны задействовать все политические, функ­
циональные, ведомственные, юридические, организационные и прочие ас­
пекты в рамках всей организации. К этому необходимо прибавить еще ряд
14 Зак. 3303

требований, таких, как: ориентированность на пользователя на все 100%,
способность к постоянным изменениям и умение бесконечно и беспрерыв­
но перепродавать и заново продвигать систему хранилища данных. К сожа­
лению, добиться наличия всех необходимых и устранения всех нежелатель­
ных факторов практически невозможно, а отсюда появляется желание
использовать какой-либо более практичный подход.
Источники оперативных данных

Подход "снизу вверх"

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

витрины данных. Архитектура витрин данных предприятия расширяется на
эту область, чтобы включить полный диапазон деталей, необходимый для ее
проектирования и разработки. Постепенно на последующих этапах проис­
ходит заполнение архитектуры витрин данных предприятия (рис. 12.8).
Этап 1
Источники оперативных данных

Витрины
Этап 2
Источники оперативных данных

Хранилище

Р и с . 1 2 .8 . Итерационная разработка хранилища данных по м етоду "снизу вверх"

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

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

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

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

П р о е к т и р о в а н и е с х е м ти п а " з в е з д а "
Предмето-ориентированность хранилища и использование его данных толь­
ко для чтения предполагают использование структур БД, отличных от нор­
мализованных. Одной из них является схема "звезда" с логической структу­
рой, в центре которой находится сводная таблица фактов с детальными
данными, содержащая поля, необходимые для анализа (рис. 12.9). Эта таб­
лица окружена справочными данными, помещенными в таблицы размерно­
стей. Применение схемы "звезда" позволяет избежать соединения многих
таблиц в одном запросе, что значительно повышает эффективность выпол­
нения запросов.
Таблица фактов содержит внешний ключ для каждой таблицы размерностей.
Эта структура отражает то, что фактические данные были созданы события­
ми в прошлом и вряд ли изменятся. Поскольку основная часть информации
в хранилище данных представлена в виде фактов, то размер таблицы фактов
гораздо больше размера таблиц размерностей. Поэтому важно рассматривать
факты как данные, доступные только для чтения и неизменные с течением
времени.
Таблица
размерностей 1

1
м/

1
М»

Таблица
размерностей 2

Таблица
размерностей 5

фактов
М

Таблица
размерностей 4

Таблица
размерностей 3

Р и с . 1 2 .9 . Схема типа "звезда"

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

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

Основная цель проектирования таблицы фактов в центре схемы "звезда" за­
ключается в том, чтобы найти компромисс между ценностью хранимых
данных и стоимостью их хранения. Размер таблиц фактов может быть ог­
ромным и превышать 1 Терабайт (1012 байт). Поэтому для оптимального
проектирования базы данных необходимо обдумать ряд следующих проблем,
связанных в том числе и с сокращением объема хранимой информации:
□ определение требуемого времени отклика для каждого приложения под­
держки принятия решения;
□ поиск компромисса между необходимостью использования статистиче­
ских выборок подмножеств данных и необходимостью обработки деталь­
ных сведений;
□ определение удаляемых столбцов;
□ сокращение размера столбцов таблицы фактов;
□ определение наилучшего способа применения настраиваемых и нена­
страиваемых внешних ключей;
□ определение оптимального подхода для введения в таблицу фактов раз­
мерности Время;
□ секционирование таблиц фактов для улучшения их управляемости.
Определение требуемого времени отклика
для каждого приложения поддержки принятия решения

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

Сокращения объема хранимой детальной информации можно добиться так­
же за счет сохранения лишь некоторого представительного объема детальных

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

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

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

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

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

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

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

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

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

Один из вариантов схемы "звезда", в котором каждая размерность может
иметь свои собственные размерности, называется схемой "снежинка" (рис.
12.10). В этом случае таблицы размерностей не содержат денормализованных данных.
Таблица
размерностей

Таблица
размерностей
фактов

Таблица
размерностей

Нормализования
таблица 1
----- ^

Нормализования
таблица 2

-------- ------------------Нормализования
таблица 3

Рис. 12.10. Схема типа "снежинка"

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

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

Многомерный и реляционный подходы возникли практически одновремен­
но. Однако только начиная с середины девяностых годов, когда появилась
новая программная статья Э. Кодда, в которой он сформулировал 12 основ­
ных требований к средствам реализации OLAP (табл. 12.2), интерес
к МСУБД начал приобретать всеобщий характер. В этой же статье Кода
привел анализ некоторых субъективных и объективных недостатков реляци­
онного подхода, затрудняющих его использование в задачах, требующих
сложной аналитической обработки данных.
Таблица 12.2. Основные требования к средствам реализации OLAP

Многомерное представление
данных

Средства должны поддерживать
многомерный на концептуальном уровне
взгляд на данные

Прозрачность

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

Доступность

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

Согласованная производительность

Производительность практически не должна
зависеть от количества Измерений в запросе

Поддержка архитектуры клиент —
сервер

Средства должны работать в архитектуре
клиент — сервер

Равноправность всех измерений

Ни одно из измерений не должно быть базо­
вым, все они должны быть равноправными
(симметричными)

Динамическая обработка
женных матриц

разре-

Неопределенные значения должны храниться
и обрабатываться наиболее эффективным
способом

Поддержка многопользовательского режима работы с данными

Средства должны обеспечивать возможность
работать более чем одному пользователю

Поддержка операций
различных измерений

основе

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

Простота манипулирования данными

Средства должны иметь максимально удоб­
ный, естественный и комфортный пользова­
тельский интерфейс

на

Гпава 12. Новые технологии БД

417
Таблица 12.2 (окончание)

Многомерное представление
данных

Средства должны поддерживать
многомерный на концептуальном уровне
взгляд на данные

Развитые средства представления
данных

Средства должны поддерживать различ­
ные способы визуализации (представления)
данных

Неограниченное число измерений
и уровней агрегации данных

Не должно быть ограничений на число под­
держиваемых Измерений

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

12.4.1. Требования к средствам реализации систем
оперативной и аналитической обработки данных
Главное достоинство МСУБД состоит в том, что они узко специализиро­
ванны и область их применения — интерактивная аналитическая обработка
агрегированных исторических и прогнозируемых данных. Рассмотрим более
детально некоторые понятия.
Агрегированные данные

Пользователя, занимающегося анализом, редко интересуют детализирован­
ные данные. Более того, чем выше уровень пользователя (руководителя,
управляющего, аналитика), тем выше уровень агрегации данных, используе­
мых им для принятия решения. Рассмотрим в качестве примера фирму по
продаже автомобилей. Коммерческого директора такой фирмы мало интере­
сует вопрос: "Какого цвета "Жигули" успешнее всего продает один из ее ме­
неджеров: белого или красного?" Для него важно, какие модели и какие
цвета предпочитают в данном регионе. Его также мало интересует детализа­
ция на уровне контракта, часа или даже дня. Для правильного формирова­
ния склада ему важна и необходима информация на уровне декады, месяца
или даже квартала.
Исторические данные

Важнейшим свойством данных в аналитических задачах является их истори­
ческий характер. После того как зафиксировано, что Петров в июне теку­
щего года продал 2 автомобиля "Волга" и 12 автомобилей "Жигули", данные
об этом событии становятся историческим (свершившимся) фактом. И по­
сле того, как информация об этом факте получена, верифицирована и заве­

дена в БД, она может быть сколько угодно раз считана оттуда, но уже не
может и не должна быть изменена. Историчность данных предполагает не
только высокий уровень статичности (неизменности) как собственно данных,
но и их взаимосвязей. А это, в свою очередь, дает возможность использовать
специализированные, основанные на предположении о статичности данных и
их взаимосвязей методы загрузки, хранения, индексации и выборки.
Другим неотъемлемым свойством исторических данных является обязатель­
ная спецификация времени, которому эти данные соответствуют. Причем
время является не только наиболее часто используемым критерием выборки,
но и одним из основных критериев, по которому данные упорядочиваются
в процессе обработки и представления пользователю. А это накладывает со­
ответствующие требования, с одной стороны, на используемые механизмы
хранения и доступа:
□ для уменьшения времени обработки запросов желательно, чтобы уже
в БД данные хранились (были предварительно отсортированы) в том по­
рядке, в котором они наиболее часто запрашиваются.
С другой стороны, соответствующие требования накладываются и на языки
описания и манипулирования данными, например:
□ во многих организациях используются как общепринятые, так и собст­
венные календарные циклы (финансовый год может начинаться не в ян­
варе как календарный, а, например, в июне);
□ время является стандартным параметром практически любой аналитиче­
ской, статистической или финансовой функции (прогноз, нарастающий
итог, переходящий запас, скользящее среднее и т. д.).
Прогнозируемые данные

Когда говорится о неизменности и статичности данных в аналитических
системах, имеется в виду неизменность исключительно исторических дан­
ных. Такое предположение ни в коем случае не распространяется на про­
гнозируемые данные (данные о событии, которое еще не происходило).
И этот момент является весьма существенным.
Например, при построении прогноза об объеме продаж на конкретный месяц
будущего года для менеджера Петрова по мере поступления фактических
данных за текущий год, прогнозируемая цифра может и будет многократно
изменяться и уточняться. Более того, достаточно часто прогнозирование
и моделирование затрагивает не только будущие, еще не произошедшие, но
и прошлые, уже свершившиеся события. Например, анализ: "а что будет
(было бы) ..., если (бы) ?" строится на предположении о том, что значения
некоторых данных, в том числе и из прошлого, отличны от реальных. Одна­
ко, сколько бы такие упражнения не выполнялись, значения исторических
данных должны оставаться неизменными.

Оперативные данные

В свою очередь, к оперативным данным, отражающим состояние некоторой
предметной области в данный текущий момент времени, не применимы та­
кие понятия, как прошлое или будущее. Для них существует единственное
понятие — сейчас, а их основное назначение — адекватное детализирован­
ное отображение текущих событий, происходящих в реальном мире.
Вместе с тем изменчивость оперативных данных ни в коем случае не подра­
зумевает их близость по свойствам к прогнозируемым данным. Между ними
существует коренное различие. Оперативным данным, в отличие от прогно­
зируемых, присуще свойство общезначимости, и обычно все пользователи
работают с одним и тем же экземпляром данных. После того как в опера­
тивную систему заведены данные о том, что Петров продал еще один авто­
мобиль, эта информация сразу же должна стать доступной всем заинтересо­
ванным в ней пользователям. Причем до тех пор, пока это изменение не
зафиксировано, никакой другой пользователь не имеет права изменять
строку с информацией о продажах Петрова.
Существенно иная ситуация с прогнозируемыми данными. Они носят, ско­
рее, личностный (индивидуальный) характер. Вполне реальна ситуация,
когда коммерческий директор фирмы и управляющий региональным отде­
лением одновременно решили получить прогноз возможного объема продаж
на будущий год для Петрова. Однако каждый из них делает собственный
прогноз. Каждый из них может использовать свои функции прогнозирова­
ния, и даже если применяется один и тот же метод (или функция), прогноз
может основываться на различных исторических интервалах, и результаты,
по всей вероятности, будут различны. Но после того, как некоторый про­
гноз будет утвержден в качестве плана, данные просто перейдут в другую
категорию и станут историческими.
Следует заметить, что в области информационных технологий всегда суще­
ствовало два взаимодополняющих друг друга направления развития:
□ системы, ориентированные на оперативную обработку данных;
О системы, ориентированные на анализ данных — системы поддержки
принятия решений.
И практически до настоящего времени, когда говорилось о стремительном
росте числа реализаций информационных систем, прежде всего, имелись в
виду системы, предназначенные исключительно для оперативной обработки
данных. Именно для этого изначально и создавались и на это были ориен­
тированы РСУБД, которые сегодня стали основным средством построения
информационных систем самого различного масштаба и назначения. Но,
являясь высокоэффективным средством реализации систем оперативной
обработки данных, РСУБД оказались менее эффективными в задачах анали­
тической обработки.

Конечно, средствами традиционных РСУБД и на основании данных, храня­
щихся в реляционной БД, можно построить заранее регламентированный
аналитический отчет и даже Прогноз об ожидаемом объеме продаж автомоби­
лей на следующий год, но ждать его можно часы, а иногда и дни. Обычно ка­
ждый новый непредусмотренный заранее запрос должен быть сначала фор­
мально описан, передан программисту, запрограммирован и только потом
выполнен. Но после того, как аналитик получит долгожданный ответ, доста­
точно часто оказывается, что решение не могло ждать и оно уже принято.
Более того, для решения большинства аналитических задач скорее всего,
потребуется использование внешних по отношению к РСУБД, специализи­
рованных инструментальных средств. Выполнение большинства аналитиче­
ских функций (например, построение прогноза) невозможно без предполо­
жения об упорядоченности данных. Но в РСУБД предполагается, что
данные в БД не упорядочены (или, более точно, упорядочены случайным
образом). Естественно, здесь имеется возможность после выборки данных
из БД выполнить их сортировку и затем аналитическую функцию. Но это
потребует дополнительных затрат времени на сортировку. Сортировка
должна будет проводиться каждый раз при обращении к этой функции, и,
самое главное, такая функция может быть определена и использована толь­
ко во внешнем по отношению к РСУБД пользовательском приложении и не
может быть встроенной функцией языка SQL.
Не менее важно и то, что многие критически необходимые для оперативных
систем функциональные возможности, реализуемые в РСУБД (например,
развитые средства обеспечения целостности, восстановления и устранения
взаимных блокировок), являются избыточными для аналитических задач
(табл. 12.3). А это не только существенно облегчает и упрощает сами средст­
ва реализации, но и значительно снижает внутренние накладные расходы и,
следовательно, повышает производительность при выполнении их основной
целевой функции — поиске и выборке данных.
Таблица 12.3. Характеристики данных в системах, ориентированных
на оперативную и аналитическую обработку данных

Характеристика

Оперативные данные

Аналитические данные

Частота
ления

Высокая частота, малень­
кими порциями

Малая частота, большими пор­
циями

В основном внутренние

В основном внешние (по отноше­
нию к аналитической системе)

Текущие (за период от не­
скольких месяцев до одно­
го года)

В основном исторические (за пе­
риод в несколько лет, десятки
лет) и прогнозируемые

Источники
ных

обнов­
дан­

Возраст данных

Таблица 12.3 (окончание)
Характеристика

Оперативные данные

Аналитические данные

Уровень агрега­
ции данных

Детализированные данные

В основном агрегированные дан­
ные

Назначение

Фиксация,
оперативный
поиск и обработка данных

Работа с историческими данными,
аналитическая обработка, про­
гнозирование и моделирование

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

Достаточно очевидно, что даже при небольших объемах данных отчет, пред­
ставленный в виде двухмерной таблицы (модели автомобиля по оси Y и
время по оси X) (рис. 12.12), нагляднее и информативнее отчета с реляци­
онной построчной формой организации (рис. 12.11).
М одель

М есяц

Объем

"Жигули"

Июнь

12

"Жигули"

Июль

24

"Жигули"

Август

5

"Москвич"

Июнь

2

"Москвич"

Июль

18

"Волга"

Июль

19

Рис. 12.11. Реляционная модель

Июнь

Июль

Август

"Жигули"

12

24

5

"Москвич"

2

18

No

"Волга"

No

19

No

Рис. 12.12. Многомерная модель

Нетрудно представить, что, если анализируются не три модели, а 30, и не
три, а 12 различных месяцев, то в случае построчного (реляционного) пред­
ставления получится отчет в 360 строк (30 х 12), который займет не менее
5—6 страниц. В случае же многомерного (в данном случае двухмерного)
представления получится достаточно компактная таблица 12 на 30, которая
вполне уместится на одной странице и которую, даже при таком объеме
данных, можно реально оценивать и анализировать.
И когда говорится о многомерной организации данных, вовсе не подразуме­
вается то, что данные представляются конечному пользователю (визуализи­
руются) в виде четырех или пятимерных гиперкубов. Это невозможно, да и
пользователю более привычно и комфортно иметь дело с двухмерным таб­
личным представлением и двухмерной бизнес-графикой. Поэтому когда го­
ворится о многомерности, то имеется в виду не многомерность визуализа­
ции, а многомерное представление при описании структур данных и
поддержка многомерности в языках манипулирования данными.

12.4.3. Многомерное представление
при описании структур данных
Основными понятиями, с которыми оперирует пользователь и проектиров­
щик в многомерной модели данных, являются:
□ измерение;
□ ячейка (cell).
Иногда вместо термина ячейка используется термин показатель.
Измерение — это множество однотипных данных, образующих одну из гра­
ней гиперкуба. Например, дни, месяцы, кварталы, годы — это наиболее час­
то используемые в анализе временные измерения. Примерами географиче­
ских измерений являются: города, районы, регионы, страны и т. д.
В многомерной модели данных измерения играют роль индексов, исполь­
зуемых для идентификации конкретных значений (показателей), находя­
щихся в ячейках гиперкуба.
В свою очередь, показатель — это поле (обычно цифровое), значения кото­
рого однозначно определяются фиксированным набором измерений. В за­
висимости от того, как формируются его значения, показатель может быть
определен, как:
□ переменная — значения таких показателей один раз вводятся из какоголибо внешнего источника или формируются программно и затем в явном
виде хранятся в многомерной базе данных;
□ формула — значения таких показателей вычисляются по некоторой зара­
нее специфицированной формуле, т. е. для показателя, имеющего тип

Формула, в БД хранится не его значения, а формула, по которой эти зна­
чения,могут быть вычислены.
Заметим, что это различие существует только на этапе проектирования и
полностью скрыто от конечных пользователей.
Рис. 12.11 иллюстрирует пример, когда каждое значение поля Объем продаж
однозначно определяется комбинацией полей:
□ Модель автомобиля;
□ Месяц продаж.
Но в реальной ситуации для однозначной идентификации значения показа­
теля, скорее всего, потребуется большее число измерений, например:
□ Модель автомобиля;
□ Менеджер;
□ Время (например, Год).
Измерения;
□ Время (Год) - 1994, 1995, 1995;
□ Менеджер — Петров, Смирнов, Яковлев.
Показатель:
□ Объем Продаж.
И в терминах многомерной модели речь будет идти уже не о двухмерной
таблице, а о трехмерном гиперкубе:
□ первое измерение — Модель автомобиля;
□ второе измерение — Менеджер, продавший автомобиль;
□ третье измерение — Время (Год), на пересечении граней которого нахо­
дятся значения показателя Объем продаж.
Заметим, что, в отличие от измерений, не все значения показателей должны
иметь и имеют реальные значения. Например, Менеджер Петров в 1994 г.
мог еще не работать в фирме, и в этом случае все значения показателя
Объем продаж за этот год будут иметь неопределенные значения.

12.4.4. Гиперкубические
и поликубические модели данных
В различных МСУБД используются два основных варианта организации
данных:
□ гиперкубическая модель;
□ поликубическая модель.

Системы, поддерживающие поликубическую модель (примером является
Oracle Express Server), предполагают, что в МВД может быть определено не­
сколько гиперкубов с различной размерностью и с различными измерения­
ми в качестве их граней. Например, значение показателя Рабочее Время
Менеджера, скорее всего, не зависит от измерения Модель Автомобиля и
однозначно определяется двумя измерениями: День и Менеджер. В п о л и т и ­
ческой модели в этом случае может быть объявлено два различных гиперкуба:
□ двухмерный — для показателя Рабочее Время Менеджера;
□ трехмерный — для показателя Объем Продаж.
В случае же гиперкубической модели предполагается, что все показатели
должны определяться одним и тем же набором измерений. То есть только
из-за того, что Объем Продаж определяется тремя измерениями, при описа­
нии показателя Рабочее Время Менеджера придется также использовать три
измерения и вводить избыточное для этого показателя Измерение Модель
Автомобиля.

12.4.5. Операции манипулирования Измерениями
Формирование среза

Пользователя редко интересуют все потенциально возможные комбинации
значений Измерений. Более того, он практически никогда не работает од­
новременно сразу со всем гиперкубом данных. Подмножество гиперкуба,
получившееся в результате фиксации значения одного или более измерений,
называется срезом. Например, если мы ограничим значение измерения Мо­
дель Автомобиля = "ВА32108", то получим подмножество гиперкуба (в на­
шем случае — двухмерную таблицу), содержащее информацию об истории
продаж этой модели различными менеджерами в различные годы.
Операция вращения

Изменение порядка представления (визуализации) измерений (обычно при­
меняется при двухмерном представлении данных) называется вращением.
Эта операция обеспечивает возможность визуализации данных в форме,
наиболее комфортной для их восприятия. Например, если менеджер перво­
начально вывел отчет, в котором Модели автомобилей были перечислены по
оси X, а Менеджеры по оси Y, он может решить, что такое представле­
ние мало наглядно, и поменять местами координаты (выполнить вращение
на 90 градусов).
Отношения и иерархические отношения

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

ниями обычно существует множество различных отношений типа "один ко
многим"
Например, каждый Менеджер может работать только в одном подразделе­
нии, а каждой модели автомобиля однозначно соответствует фирма, которая
ее выпускает:
Менеджер —Подразделение;
Модель Автомобиля —>Фирма-производитель.
Заметим, что для измерений, имеющих тип Время (таких, как День, Месяц,
Квартал, Год), все отношения устанавливаются автоматически и их не тре­
буется описывать.
В свою очередь, множество отношений может иметь иерархическую струк­
туру. Например:
День —> Месяц —> Квартал —> Год;
Менеджер —> Подразделение —> Регион —> Фирма —> Страна;
Модель Автомобиля —> Фирма-производитель —> Страна.
И часто более удобно не объявлять новые измерения и затем устанавливать
между ними множество отношений, а использовать механизм иерархических
отношений. В этом случае все потенциально возможные значения из раз­
личных измерений объединяются в одно множество. Например, мы можем
добавить к множеству значений измерения Менеджер ("Петров", "Сидоров",
"Иванов", "Смирнов"), значения измерения Подразделение ("Филиал 1",
"Филиал2", "ФилиалЗ”) и измерения Регион ("Восток", "Запад”) и затем оп­
ределить между этими значениями отношение иерархии.
Операция агрегации

С точки зрения пользователя Подразделение, Регион, Фирма, Страна явля­
ются точно такими же измерениями, как и Менеджер. Но каждое из них
соответствует новому, более высокому уровню агрегации значений показате­
ля Объем продаж. В процессе анализа пользователь не только работает
с различными срезами данных и выполняет их вращение, но и переходит от
детализированных данных к агрегированным, т. е. производит операцию
агрегации. Например, посмотрев, насколько успешно в 1995 г. Петров про­
давал модели "Жигули" и "Волга", управляющий может захотеть узнать, как
выглядит соотношение продаж этих моделей на уровне подразделения,
где Петров работает. А затем получить аналогичную справку по региону
или фирме.
Операция Детализации

Переход от более агрегированных к более детализированным данным назы­
вается операцией детализации. Например, начав анализ на уровне Региона,

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

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

Основное назначение МСУБД — реализация систем, ориентированных на
динамический, многомерный анализ исторических и текущих данных, ана­
лиз тенденций, моделирование и прогнозирование будущего. Причем такие
системы в большой степени ориентированы на обработку произвольных,
заранее не регламентированных запросов, и при их разработке фактически
отсутствует этап проектирования регламентированных пользовательских
приложений (наиболее ответственный и трудоемкий в традиционных опера­
тивных системах).
Проектирование МВД обычно начинается с определения вопросов, с которы­
ми конечные пользователи хотели бы обратиться к системе. Причем на этом
этапе интерес представляют даже не сами тексты вопросов, а понимание того,
о каких личностях, местах, событиях и объектах в них спрашивается.
После того как первичный анализ вопросов выполнен и получено представ­
ление о том, какие данные потенциально могут выступать в качестве пока­
зателей и измерений, можно переходить к проектированию ее структуры —
определению конкретных измерений, их взаимосвязей и уровней агрегации
хранимых данных.
Критерии выбора уровня агрегации

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

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

Как уже было сказано выше, основное назначение МСУБД — работа с дос­
таточно стабильными во времени данными. В OLAP-системах загрузка дан­
ных может производиться практически из разных внешних источников дан­
ных, включая:
□ различные РСУБД;
□ плоские файлы с фиксированной структурой записей;
□ электронные таблицы;
□ в интерактивном режиме через специально написанные пользовательские
приложения.
Следует заметить, что данные могут храниться как на постоянной основе,
так и загружаться динамически в тот момент, когда к ним обратится пользо­
ватель. Таким образом, имеется возможность постоянно хранить в МБД
только ту информацию, которая наиболее часто запрашивается пользовате­
лями. Для всех остальных данных хранятся только описания их структуры и
программы их выгрузки из центральной (обычно реляционной) БД. И хотя
при первичном обращении к таким виртуальным данным время отклика
может оказаться достаточно продолжительным, такое решение обеспечивает
высокую гибкость и требует более дешевых аппаратных средств.
В заключение необходимо сказать, что реляционный и многомерный подхо­
ды не конкурируют, а взаимно дополняют друг друга. Как отметил Э. Кодд,
реляционный подход никогда не предназначался для решения на его основе
задач, требующих синтеза, анализа и консолидации данных. И изначально
предполагалось, что такого рода функции должны реализовываться с помо­
щью внешних по отношению к РСУБД инструментальных средств.
Но именно на решение таких задач и ориентированы МСУБД. Область, где
они наиболее эффективны хранение и обработка высоко агрегированных и
стабильных во времени данных.
Такое "распределение обязанностей" позволяет наиболее полно реализовать
и использовать достоинства каждого из подходов: компактное хранение де­
тализированных данных и поддержка очень больших БД, обеспечиваемые
РСУБД, а также простота настройки и хорошие времена отклика, при рабо­
те с агрегированными данными, обеспечиваемые МСУБД.
Сегодня МСУБД все чаще используются не только как самостоятельный
программный продукт, но и как аналитические средства переднего плана
к системам Хранилищ Данных или традиционным оперативным системам,
реализуемым средствами РСУБД.

Глава 13

Современные СУБД

В заключительной главе помешен материал, посвященный нескольким со­
временным реляционным СУБД, которые занимают достойное место среди
своих собратьев, получивших наибольшее распространение в качестве инст­
румента создания и поддержки информационных систем различного уровня.
Рассматриваются следующие три системы такого рода:
□ Microsoft Visual FoxPro;
□ MS SQL Server;
□ Access.
Для каждой системы приводятся историческая справка, краткая характери­
стика ее возможностей и пример создания простой информационной систе­
мы, содержащей три-четыре отношения. Естественно, что желание дать
представление обо всех имеющихся в распоряжении пользователя инстру­
ментах создания ИС нескольких СУБД в небольшой главе нереально.
Да такая цель и не преследуется.
Желающим освоить данные системы в совершенстве в настоящее время прела­
гаются разнообразные литературные источники, содержащие по 1000 стра­
ниц каждый, довольно часто появляющиеся в продаже. Материал данной
главы, как раз наоборот, призван, с одной стороны, привлечь внимание
пользователей к данным системам, показав самые простые и результативные
их механизмы для разработки основных компонентов приложения. С другой
стороны, у ознакомившегося с этими сведениями читателя появляется воз­
можность сравнить данные системы и получить о них некоторые общие
представления.

13.1. Microsoft Visual FoxPro 9.0
Visual FoxPro 9.0 представляет собой СУБД реляционного типа с развитыми
средствами создания БД, организации запросов к ним, построения при­
ложений, включающих все необходимые составляющие информационных

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

13.1.1. Историческая справка
СУБД Visual FoxPro имеет долгую историю развития, и сейчас ее знают на
мировом рынке как самое гибкое и современное средство разработки баз
данных. Назовем важные этапы развития системы.
□ Прародителем Visual FoxPro можно считать FoxBase. Первоначально
Foxbase был задуман как улучшенный вариант dBase, обладающий пол­
ной с ним совместимостью.
□ Преемником FoxBase стал продукт FoxPro 1.0, в котором были реализо­
ваны некоторые новые концепции проектирования графического интер­
фейса пользователя и способов разработки программных продуктов.
□ Версия FoxPro 2.0 произвела переворот в области разработки баз данных
на персональных компьютерах. Достаточно назвать лишь некоторые ее
передовые в то время технологии:
• значительное увеличение скорости работы;
• инструкции SQL, заменяющие собой целые процедуры;
• включение в систему совершенно нового метода разработки графиче­
ского интерфейса пользователя посредством генерирующих код масте­
ров экранов и отчетов.
□ Visual FoxPro 3.0 обогатилась множеством давно ожидаемых возможно­
стей, главные из которых:
• контейнер базы данных;
• представления;
• устойчивая объектная модель и возможность построения собственных
классов и подклассов.
□ Visual FoxPro 5.0 представляла собой усовершенствованный вариант вер­
сии 3.0, предлагающий следующие новые возможности:
• использование и создание серверов СОМ;
• новые команды и функции;
• поддержка публикаций приложений Visual FoxPro в Internet.
□ Visual FoxPro 6.0 представляла собой совместимую с предыдущими вер­
сиями систему, позволяющую:
• одновременно работать как с собственными, так и с сетевыми табли­
цами, расположенными на других компьютерах локальной сети;

• используя стандарт ODBC и SQL-запросы, работать с СУБД Access,
Paradox и т. п.;
• работать с серверами БД: Microsoft SQL Server, Oracle и др.
• создавать масштабируемые компоненты, интегрируемые в архитектуру
"клиент-сервер", а также в среду сетей Internet и intranet;
• имея усовершенствованную среду разработки и набор инструменталь­
ных средств, обеспечивать небывалую гибкость настройки и произво­
дительность.
□ В Visual FoxPro 7.0 добавлено множество дополнений как в редактор, ок­
на отладки и другие визуальные элементы, так и собственно в синтаксис
языка, которые намного увеличивают производительность работы:
• внедрение новой технологии IntelliSense, облегчающей ввод операторов;
• разработка расширений редактора;
• добавление события на объект Database Container (DBC);
• поддержка Active Accessibility;
• добавление списка задач, просмотра объектов, закрепления окон.
□ В версию Visual FoxPro 8.0 вошли:
• структурированные средства обработки ошибок;
• новые базовые классы и элементы управления;
• функции универсального доступа к данным;
• расширенные возможности для работы с XML Web-сервисами;
• улучшенная совместимость с Microsoft Visual Studio .NET и Microsoft
SQL Server 2000.

13.1.2. Общая характеристика
Microsoft Visual FoxPro 9.0
Visual FoxPro является постоянно развивающейся объектно-ориентированной,
визуально-программируемой, управляемой по событиям программной сре­
дой. Новая версия 9.0 популярного продукта компании Microsoft снабжена
рядом новых функций, облегчающих разработку .NET-совместимых клиентсерверных и Web-приложений баз данных для малого бизнеса и департамен­
тов крупных компаний.
Одним из самых главных достоинств продукта является его полная со­
вместимость с предыдущими версиями. Производители смогут создавать
приложения в среде Visual FoxPro 9.0 и использовать инструменты преды­
дущих версий для их развертывания. Таким образом, разработчики смо­
гут воспользоваться функциональными возможностями новой платформы,

не беспокоясь о совместимости существующих приложений с новой сре­
дой выполнения.
С помощью VFP 9.0 можно создавать Web-сервисы и СОМ-компонеиты,
а также без усилий организовывать их взаимодействие с .NET-приложениями.
В версии 9.0 реализованы новые типы данных, сняты многие ограничения
языка SQL, введены дополнительные типы индексов, упрощена работа с уда­
ленными данными.
В новой версии усовершенствованы возможности построения пользователь­
ских интерфейсов, реализованы механизмы создания форм с автоматиче­
ской расстановкой управляющих элементов, а также расширена поддержка
графики.
Дополнительно архитектура новой FoxPro позволяет осуществлять вывод
в XML, HTML и форматах изображений, предоставляет настраиваемое
многостраничное окно предварительного просмотра результатов печати.
Многочисленные усовершенствования и изменения коснулись системы ге­
нерирования отчетов, интегрированной среды разработки, библиотек FoxPro
Foundation Classes, синтаксиса языка программирования, элементов управ­
ления и т. д.
Для упрощения и ускорения процесса разработки баз данных и приложений
Visual FoxPro 9.0 предоставляет пользователю несколько уровней разработки
приложений, из которых он может выбрать наиболее для себя подходящий
в зависимости от своего профессионального уровня и стоящих перед ним
задач:
□ мастера;
□ конструкторы;
□ построители;
□ создание собственных пользовательских классов.
Наличие собственных механизмов управления реляционными базами дан­
ных, тесная взаимосвязь между языком и данными, полноценные возмож­
ности объектно-ориентированного программирования и широкий спектр
функциональных возможностей позволяют использовать Visual FoxPro 9.0
для создания производительных, масштабируемых приложений со встроен­
ными базами данных (настольные, клиент-серверные и Web).
Технологии и возможности Visual FoxPro 9.0

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

Автоматизация создания приложений. Мастер приложений и средство созда­
ния приложений Application Builder предоставляют простую в использова­
нии объектно-ориентированную структуру для создания приложений.
Инструмент для отладки Coverage Profiler. Усовершенствование процесса
тестирования и отладки с использованием инструмента Coverage Profiler.
Coverage Profiler проверяет выполняемые в текущий момент строки про­
граммного кода и определяет время выполнения каждой строки.
Библиотека компонентов Component Gallery. Применение библиотеки ком­
понентов Component Gallery для создания и организации каталогов много­
кратно используемых объектов. Функциональные возможности приложений
расширяются простым перетаскиванием объектов из библиотеки Component
Gallery в проект.
Поддержка системы Microsoft Transaction Server. Использование системы
Microsoft Transaction Server для автоматического управления, размещения и
масштабирования компонентов СОМ системы Visual FoxPro.
Документы Active Documents. Возможность создания документов Active
Documents, запускающих приложения Visual FoxPro в обозревателе.
Технология перетаскивания OLE. Использование технологии перетаскивания
OLE для разделения данных между системой Visual FoxPro и другими при­
ложениями, такими как Word, Excel, Explorer и т. д.
Улучшенные возможности

Обработка данных и интероперабельность. Разработчику предоставлена воз­
можность создавать решения для платформы .NET с использованием техно­
логии XML и Web-служб XML. Поддерживается обмен данными с СУБД
SQL Server с применением расширенных возможностей языка SQL и новых
поддерживаемых типов данных.
Расширяемый набор вспомогательных инструментов разработчика. Расширить
возможность пользовательского интерфейса помогут закрепляемые пользо­
вательские формы, автоматическая привязка элементов управления, а также
расширенная поддержка работы с изображениями. Окно свойств объекта
можно дополнить наиболее необходимыми расширенными атрибутами, соб­
ственными модулями редактирования, шрифтами и параметрами настройки
цвета.
Гибкая адаптация ко всем типам СУБД-приложений. Разработчик может
создавать самостоятельные приложения и программы для удаленной работы,
ориентированные на использование в планшетных компьютерах Tablet PC
с операционной системой Windows. Также можно создавать и использо­
вать COM-компоненты и Web-службы XML, совместимые с платформой
Microsoft .NET.

Богатые возможности системы генерации отчетов. Новая расширяемая архи­
тектура вывода информации обеспечивает детальное управление всеми па­
раметрами вывода и форматирования содержимого отчетов. При конструи­
ровании отчетов можно использовать множество диапазонов объединения
данных, поворот текста, а также сцепку нескольких отчетов в один состав­
ной отчет. Поддерживается вывод отчетов в разных форматах, в том числе
в XML, HTML, в виде изображений. Также в распоряжении разработчика
находится гибко настраиваемое многостраничное окно предпросмотра отче­
тов. Обеспечивается обратная совместимость с уже существующими отчета­
ми предыдущих версий пакета Visual FoxPro.
Удобство перехода на новую версию. Переход на версию Visual FoxPro 9.0 не
потребует серьезных усилий, поскольку это самая надежная и технологиче­
ски развитая версия платформы FoxPro, предлагающая 100-процентную со­
вместимость с пакетом Visual FoxPro 8.0. Разработчики могут даже создавать
приложения с использованием пакета Visual FoxPro 9.0, а затем разверты­
вать их с применением исполняемых модулей пакета Visual FoxPro 8.0, если
в развертываемом приложении не используются новые команды и функции.
Все это позволяет разработчикам и группам разработчиков быстро перейти
на пакет Visual FoxPro 9.0 и выиграть от множества новых вспомогательных
функций, постепенно перенося существующие приложения на более новую
платформу исполнения.
Требования к оборудованию
Процессор

частота 400 МГц или более мощный

Операционная
система

Microsoft Windows 98/МЕ или Microsoft Windows 2000 SP3
(или 4);
Microsoft Windows ХР (Home, Professional) c Service Pack 1
(или 2)

Память

128 Мбайт для Windows 2000 (рекомендуется 192 Мбайт);
192 Мбайт для Windows ХР (рекомендуется 256 Мбайт)

Дисковое
пространство

типовая установка: 300 Мбайт

Монитор

VGA (800x600) или с большим разрешением

полная установка: 600 Мбайт

рекомендуется Super VGA (1024x768)
Дисковод

для компакт-дисков

Указывающее
устройство

Microsoft Mouse, Microsoft IntelliMouse или совместимое указы­
вающее устройство

13.1.3. Элементы проекта
Visual FoxPro 9.0 состоит из отдельных компонентов, которые используются
для хранения информации, ее отображения и редактирования. Этими ком­
понентами являются таблицы, представления данных, формы, отчеты, за­
просы, программы и библиотеки.
В Visual FoxPro вся информация хранится в базе данных, которая состоит из
таблиц, отношений между таблицами, индексов, триггеров и хранимых про­
цедур. Каждая таблица имеет уникальное имя и хранится в отдельном фай­
ле, наименование которого совпадает с именем таблицы. Формат созданного
файла — DBF.
Каждая организовываемая таблица может иметь связанные с ней индексы,
используемые для упорядочения данных и быстрого поиска необходимых
записей, причем одна таблица может иметь несколько индексов.
Д л я х р а н е н и я зн а ч е н и й п о л ей ти п а Memo и G e n e r a l п р и м ен я ю т с я о тд ел ьн ы е
ф ай л ы . Memo-п о л я т а б л и ц со дер ж ат текстовую и н ф о р м а ц и ю , а п о л я т и п а
G e n e r a l и сп о льзу ю тся д л я х р а н е н и я д в о и ч н о й и н ф о р м а ц и и и д ан н ы х других
W indow s-п р и л о ж е н и й .

В Visual FoxPro реализованы триггеры, которые позволяют централизованно
обрабатывать события, возникающие при любых изменениях в базе данных;
присутствует возможность создавать хранимые процедуры, которые являют­
ся частью базы данных и могут использоваться при описании таблиц, для
проверки введенных данных, определения значения по умолчанию и т. п.
Удобным и полезным средством доступа к базе данных являются представ­
ления данных, которые позволяют объединять данные таблиц и отображать
их в более удобном виде.
Для отображения и редактирования данных используются формы, отчеты,
запросы и программы. При создании форм, отчетов и запросов применяют­
ся конструкторы, поэтому эти компоненты называются конструкторскими
объектами. Формы и отчеты являются составными объектами, т. к. они со­
стоят из более мелких объектов (полей, кнопок, рамок, диаграмм, OLEкомпонентов и т. д.), которые называются объектами интерфейса.
Формы используются для просмотра или ввода данных в таблицы. Отчеты
служат для печати содержащейся в базе данных информации. Запросы яв­
ляются средством выборки данных из одной или нескольких таблиц.
Программы, написанные на языке Visual FoxPro, являются объектноориентированными. С помощью них обрабатываются события в форме, соз­
даются объекты, осуществляются различные вычисления, происходит управ­
ление базой данных. Для удобства работы можно объединять программы
в библиотеки.

Для создания форм в Visual FoxPro можно использовать не только базовые
классы, но и создавать собственные. Классы, созданные в Visual FoxPro,
хранятся в библиотеках классов.
Основным средством объединения всех вышеперечисленных компонентов и
управления ими в Visual FoxPro является проект. С помощью проекта Visual
FoxPro осуществляет поиск и собирает вместе файлы проекта, отслеживает
текущие версии элементов, перекомпилирует программы, обновляет экран­
ные формы, меню и т. д. Из проекта осуществляется генерация приложения.
Вся информация о проекте хранится в специальной таблице — файле с расши­
рением PJX и соответствующем Memo-файле с расширением PJT.
Имя файла пользователь может задать самостоятельно, в соответствии с его
нуждами и представлениями. Расширение же формируется автоматически и
указывает на тип данных, которым соответствует данный файл (табл. 13.1).
Файлы, содержащие элементы, созданные на базе других элементов, имеют
общие с ними имена.
Таблица 13.1. Элементы проекта

Компоненты

Расширения имен, примечания

Приложение

АРР, сгенерированная програм м а ЕХЕ

Проект

PRJ, FPC, CAT, PJX, PJT

Б аза данных

DBC

Таблица Visual FoxPro

DBF

Одиночный индексный ф ай л

ЮХ

С оставной индексный ф ай л

CDX

Memo-п о л е и поле типа G e n e r a l

FRT

Ф орм а

SCX, SCT, Memo-поле

З ап р ос

QPR, сгенерированная исходная програм м а QPX,
программа п осл е компиляции

Отчет

FRX, FRM, Memo-поле

Этикетка

LBX, LBL, М ето-поле

Меню

MNX, описание облика меню MNT, Memo-поле
MPR, сгенерированная исходная программа
МРХ, программа посл е компиляции

Библиотеки

VCX, класса VCT, Memo-поле библиотеки класса
DLL, динамических свя зей W indows FLL, динам и­
ческих связей Visual FoxPro

Таблица 13.1 (окончание)
К ом п он ен ты

Р а сш и р ен и я и м ен , п р и м еч а н и я

Программа

PRG, исходный текст FXP, п осл е компиляции

Ошибки компиляции

ERR

Файл ф ор м ата

FMT

О писание окружения

VUE

Рисунок

BMP, JPG, GIF, ICO, DIB, CUR, ANI

Звуковая запись

WAV

Текст

TXT

13.1.4. Создание баз данных и приложений
При первом запуске Visual FoxPro поверх основного окна (рис. 13.1) появля­
ется окно под названием Task Pane Manager (Менеджер витрины задач),
а также окно для сетевых подключений (рис. 13.2).

Р и с . 1 3 .2 . Вид окна С етев ы е п одкл ю ч ения

Пользуясь ссылками окна Task Pane Manager, можно просмотреть список
новых возможностей Visual FoxPro, настроить среду, создать приложение,
создать новый проект или новую базу данных и, если вы подключены к
Internet, посетить Web-сайт разработчиков. Это окно позволяет быстро от­
крыть уже существующие проект или базу.
Поскольку функции окна Task Pane Manager дублируют возможности пунк­
тов меню Visual FoxPro, при желании появление данного окна можно ис­
ключить, обратившись к его настройкам.
Типы д а н н ы х M ic ro so ft V isual F o x P ro
В табл. 13.2 дан перечень типов данных Microsoft Visual FoxPro и их краткая
характеристика.
Таблица 13.2. Типы данных Microsoft Visual FoxPro

О бозн а­
чени е

Тип

А

A rray

В

D ouble

Д и ап азон

О б ъ ем
памяти,
бай т

О п и са н и е

М ассив данных некоторо­
го типа
от + /-4,940656485412 4 7 Е -3 2 4 8
д о + /- 1 ,79769313486232Е+308

Число с плаваю щ ей точ­
кой двойной точности

Диапазон

Объем
памяти,
байт

Описание

с

C h a ra c te r

Любые символы

1 -2 5 4

Текстовая (символьная)
строка

D

D a te

от 0 1 /0 1 /1 0 0 д о 1 2 /3 1 /9 9 9 9

8

Д ата

F

F lo a t

от —0 ,9 9 9 9 9 9 9 9 9 9 х 10 +19
д о 0 ,9 9 9 9 9 9 9 9 9 9 x 1 0 20

8

Такое же, как N u m e ric

G

G en eral

О пределяется доступной
памятью

4 (в dbf)

Ссылка на OLE-объект

1

In te g e r

- 2 147 4 8 3 6 4 7
д о 2 147 4 8 3 6 4 6

4

Число ц ел о е

L

L o g ic a l

Истина (Да), Ложь (Нет)

1

Л огическое знач ен и е

М

Memo

О пределяется доступной
памятью (в dbf)

4

Ссылка на прим ечание

N

N u m e ric

от -0 ,9 9 9 9 9 9 9 9 9 9 x 1 0 19
д о 0 ,9 9 9 9 9 9 9 9 9 9 x 1 0 20

8

Число с фиксированной
точкой целое или дробное;
допускает от 1 д о 20 сим ­
волов в таблице

T

D a te T im e

от 0 1 /0 1 /1 0 0 д о 1 2 /3 1 /9 9 9 9 и
от 0 0:00:00 утра д о 23:59:59
вечера

8

Д ата и время

Y

C u rre n c y

от - 2 2 3 3 7 2 0 3 6 8 5 4 7 7 ,5 8 0 7
д о 9 2 2 3 3 7 2 0 3 6 8 5 4 7 7 ,5 8 0 7

8

Д ен еж н о е зн ач ение

О бозна­
чение

Тип

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

Р и с . 1 3 .3 . Концептуальная м одель базы данных

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

Имя таблицы

Имена полей и их типы

Имя таблицы

Имена полей и их типы

Owner

ld_owner (I)

Journal

ld_visit (I)

P ets

N am e (С20)

ld_pet (I)

Tel (СЮ)

Visitdate (D)

A ddress (С50)

R eason (С 100)

ld_pet (I)

Result (C 100)

N am e (C20)
ld_owner (I)
G en u e (C20)
Birth (D)
15 Зак. 3303

В проекте Vet будет задействовано 3 таблицы — Owner, Pets, Journal.
В таблице Owner будет указываться информация о владельце животного: его
первичный ключ (Id_owner), имя (Name), телефон (Tel) и адрес (Address).
В таблице Pets будет храниться информация о животном: уникальный иден­
тификационный номер (Id_pet), кличка (Name), имя владельца (Id_owner),
биологический вид, к которому это животное относится (Genue) и дата его
рождения (Birth).
В таблице Journal будет сохраняться информация о посещении животным
ветеринарного врача, в ней будут указываться: уникальный идентификаци­
онный номер посещения (Id_visit (I)), дата посещения (Visitdate), уникаль­
ный идентификационный номер животного (Id_pet), причина посещения
(Reason) и заключение, сделанное врачом в результате посещения (Result).
Как уже говорилось ранее, для создания базы данных и входящих в нее таб­
лиц будем использовать Database Designer (Конструктор базы данных).
Для начала выполним команду New из меню File. В результате чего откроет­
ся диалоговое окно New (рис. 13.4).
В нем необходимо выбрать Database и нажать кнопку New. В этом случае
открывается стандартный диалог сохранения файла, с помощью которого
следует сохранить файл базы данных в нужной папке диска. После чего по
нажатию кнопки Save открывается окно Database Designer (рис. 13.5).

Рис. 13.5. Окно Database Designer

При этом в системном меню Visual FoxPro появится новое подменю
Database (табл. 13.4).
Таблица 13.4. Команды подменю Database
К ом ан д ы

Н а зн а ч е н и е

N ew T ab le

С озд ан и е новой таблицы

A dd T a b le

Д обавл ен и е созданн ой таблицы в б а зу данных

N ew R e m o te V iew

Новое удал енное представление данных

N ew L ocal V iew

Н овое локальное представление данных

M odify

Открыть таблицу в конструкторе таблиц

B row se

Отобразить со д ер ж и м о е таблицы в реж им е просм отра

R em ove

Удалить таблицу из базы данных

Find O b ject

Найти объект в окне конструктора базы данных

R eb u ild T ab le I n d e x e s

Перестроить индексы

Таблица 13.4 (окончание)
Н азн ач ен и е

К ом ан ды
R e m o v e D e le te d R e c o r d s

Ф изически удалить записи, пом еченны е на уд ал ен и е

Edit R e la tio n sh ip

Редактировать межтабличные связи

Edit R eferen tia l Integrity

О пределить условия целостности данных

Edit S to r e d P r o c e d u r e s

Открыть окно редактирования хранимых процедур

C o n n e c tio n s

Показать окно С о е д и н е н и я , в котором мож но создав ать
или изменять соединен ия с удаленны ми данными

A rrange

Упорядочить объекты по имени или типу и выровнять их
по горизонтали или вертикали

R e fr e sh

Обновить инф орм ацию в окне конструктора БД

C lea n Up D a ta b a se

Очистить БД от помеченных на уд ал ен и е объектов

P r o p erties

Вывести на экран ди ал оговое окно D a ta b a s e P r o p e r tie s

Для создания новой таблицы в меню Database выбираем соответствующий
пункт (New Table); кроме этого, можно нажать соответствующую кнопку на
плавающей панели инструментов (рис. 13.6).

Р и с . 1 3 .6 . Панель инструментов D a ta b a se D e sig n e r

В появившемся диалоге выбираем New Table, после чего сохраняем файл
таблицы в каталоге с базой. На экране появляется окно, изображенное
на рис. 13.7.
На вкладке Fields заполняем имя столбца (Name), его тип (Туре), размер
(Width), десятичную часть (Decimal), тип сортировки по этому столбцу (In­
dex), а также допустимо ли значение NULL.
Кроме того, здесь же (в группе Display) можно задать формат вывода (For­
mat), маску ввода (Input mask), заголовок (Caption).

Рис. 13.7. Окно Table Designer

В группе Field validation задаются параметры проверки правильности ввода,
а именно:
□ Rule — правило проверки. По нажатию на кнопку, находящуюся рядом
с полем ввода; появляется диалог Expression Builder (Построитель выра­
жений) (рис. 13.8);
□ Message — сообщение, появляющееся при неправильном вводе данных
в поле;
□ Default value — значение, вводимое в поле по умолчанию.
На вкладке Indexes (рис. 13.9) происходит создание индексов.

Р и с . 1 3 .9 . С о здан и е индексов

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

Индексы хранятся в отдельных файлах и содержат ссылки на записи в таб­
лице. Благодаря этому их размер во много раз меньше, чем размер самой
таблицы.
В целях обратной совместимости с предыдущими версиями Visual FoxPro
поддерживает большое количество типов индексов.
В поле Name задаем имя индекса. Справа от него располагается выпадаю­
щий список, задающий тип индекса (табл. 13.5).
Таблица 13.5.

Типы индексов

Тип

О п и са н и е

P r im a r y

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

(Первичный)

C a n d id a t e

(Потенциальный)

R e g u la r

(Обычный)

B in a r y

(Двоичный)

U n iq u e

(Уникальный)

Создается уникальный индекс, не содержащ ий полей с пустыми
значениями. Он является кандидатом на роль первичного ключа, но
не является таковым, т. к. в таблице может быть только один пер­
вичный ключ
Создается индекс, в котором для каждой записи таблицы хранится
значение индексного выражения. При наличии одного и того же
значения для нескольких записей в индексном ф ай л е будет указа­
тель на каждую из них. При просмотре таблицы такие записи появ­
ляются в порядке их ввода
С оздается индекс на основе логических выражений. Может ис­
пользоваться как для свободны х таблиц, так и для таблиц, вхо­
дящ их в б а зу данных. Бинарные индексы занимаю т значительно
меньш е м еста, з а счет чего позволяют увеличить скорость ис­
пользования индексов. Для этих индексов нельзя использовать
выражения, принимающие нулевое значение, со д ер ж а щ и е о п е ­
ратор f o r , операции упорядочения и поиска
Создается индекс, в котором хранятся только неповторяющиеся
значения индексного выражения. Значение индексного выражения
записывается только для первой из повторяющихся записей и толь­
ко на нее в индексном ф айле есть указатель. При просмотре таб­
лицы видна только одна (первая) из записей с одинаковым значе­
нием индексного выражения

В поле Expression вводится индексное выражение. Оно может состоять из
имени одного поля или же, в более сложных случаях, из комбинации имен
полей, пользовательских переменных и функций.
Вооружившись имеющимися данными о структуре базы данных и принци­
пах создания таблиц, создадим три таблицы (Pets, Journal и Owner).

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

Для создания межтабличных связей необходимо убедиться в наличии сле­
дующих индексов (в случае отсутствия создадим их) (рис. 13.10).

Рис. 13.10. База данных перед установкой межтабличных связей

В области каждой таблицы в окне Database Designer указывается информа­
ция о наличии индексов. Primary-индекс отмечен значком ключа слева от
названия индекса и может быть использован для создания межтабличных
связей и проверки целостности БД.
Постоянные связи, о которых идет речь, автоматически устанавливаются
при открытии таблиц.
Условия установления постоянных связей:
□ Одна из связываемых таблиц является родительской, другая дочерней.
□ Для родительской таблицы должен быть определен первичный ключ
(P r im a r y )

ИЛИ КЛЮЧ-канДИДат ( c a n d i d a t e ) .

□ Для дочерней таблицы индекс может быть не уникальным, по этому ин­
дексу дочерняя таблица будет связываться с родительской.
Для установки межтабличной связи необходимо выделить Primary-ключ ро­
дительской таблицы и перетащить его на соответствующий индекс дочерней
таблицы. В случае успешного проведения данной операции произойдет
установление межтабличной связи, и это будет графически отражено
в Database Designer так, как это показано на рис. 13.11.

Рис. 13.11. База данных с межтабличными связями

Заполнение базы данных

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

(

Зам ечание

^

Для настройки вида формы ввода используется меню V iew . На рисунке пред­
ставлен табличный вид, именуемый B ro w se (Обзор).

Создание формы с помощью мастера

Формы служат для работы с базой данных и ее таблицами в удобной форме.
Для создания новой формы необходимо выполнить команду New в меню File.
После этого на экране появится окно (рис. 13.4), в котором следует выбрать
Forms и нажать кнопку Wizard. По нажатию этой кнопки вам будет предло­
жено выбрать тип мастера (рис. 13.13), в данном случае выберем One-toMany Form Wizard, с помощью которого создадим форму для работы со свя­
занными таблицами Owner и Pets.

Рис. 13.13. Вы бор типа мастера

После этого запустится непосредственно мастер создания формы. На пер­
вом шаге (рис. 13.14) его работы предлагается выбрать родительскую табли­
цу, работу с которой будем осуществлять посредством этой формы, а также
выбрать поля, которые при этом будут использоваться. Выделяем таблицу
Owner из списка таблиц БД и из списка Available fields перенесем все необ­
ходимые для представления в форме поля этой таблицы в Selected fields на­
жатием кнопки >>.
На втором шаге мастер предлагает выбрать из таблиц БД дочернюю таблицу
и ее поля, которые пользователь хочет видеть в форме (рис. 13.15).
Третий шаг работы мастера (рис. 13.16) позволяет установить связи между
двумя таблицами. Если же они уже были связаны ранее, то пользователь
может убедиться в правильности установки связи.

V One To Many Form Wizard
! Step 1 - Select Parent Table Fields
Which fields do you want from the parent table? These are the
"one" side of the relationship and will appear in the top half of
the form.
Select a database or the Free Tables, select a table or view,
and then select the fields you want.

Databases and tables:
Free T ables

Available fields:

Selected fields:

Ж id^ownor
~

*

Owner
JOURNAL

Tel

OWNER

Adress

Finish

Рис. 13.14. Вы бор родительской таблицы

k One-To-Many Form W izard
^Step 2 * Select Child Table Fields
Which fields do you want from the child table? These make up
the "many" side of the relationship and will appear in a grid
below the parent fields.
Select a database or the Free Tables, select a table or view,
and then select the fields you want.

Databases and tables:

f DATA2

Available fields:

Selected fields:

V
Name
ld_owner

Ш

Genue
Birth

JOURNAL

Cancel

Рис. 13.16. Третий шаг работы мастера

Выбрав на четвертом и пятом шагах работы мастера тип стиля оформления
текстовых полей и управляющих элементов, а также вид сортировки выво­
димых записей, перейдем к последнему этапу работы мастера.
На этом шаге создания формы необходимо указать действие, которое будет
использоваться по окончании этого процесса:
□ Save form for later use — сохранить форму для последующего использова­
ния;
□ Save and run form — сохранить и запустить форму;
□ Save form and modify it in Form Designer — сохранить форму и перейти
в режим редактирования в Form Designer.
Нажатие кнопки Preview позволит запустить предварительный просмотр
формы для оценки корректности введенных параметров во время прохожде­
ния этапов создания формы.
Здесь появляется возможность наблюдать текстовые поля для редактирова­
ния полей таблицы. Кроме того, в нижней части этой формы располагаются
кнопки навигации по записям таблиц. Благодаря этому работа с таблицами
будет происходить легко и удобно.
Нажатие кнопки Finish завершает работу с мастером. Созданная форма
представлена на рис. 13.17.

Рис. 13.17. Форма OWNER.PET

Для создания формы, отражающей статистику посещения ветеринара от­
дельными животными, также используется только что рассмотренный мастер.
1. На первом шаге необходимо выбрать поля таблицы-родителя, которые
будут отражены на форме. Табл идей-родителем в данном случае будет
являться таблица Pets рассматриваемой базы данных. Из списка Available
fields перенесем все ее поля в список Selected fields. Именно эти поля и
будут отображаться на форме текстовыми элементами.
2. На втором шаге выберем поля дочерней таблицы, которые будут исполь­
зоваться в управляющем элементе типа Grid. Дочерней таблицей будет
являться Journal. Так как целью создания формы будет просмотр стати­
стики посещения ветеринара, то из списка Available fields мы переносим
интересующие нас ее поля в Selected fields.
3. После этого мастер предложит установить соответствие, которое будет
определять характер отношений, отраженный на форме. То есть необхо­
димо выбрать 2 поля, по которым между выбранными таблицами будет
установлено соответствие. В данном случае в одной и другой таблице это
поля Id_pet, которые выбираются в обоих списках.
4. На четвертом шаге определяется стиль формы. Стиль выполнения эле­
ментов управления будет меняться в зависимости от выбранных значе­
ний. Оставим здесь все по умолчанию.

5. Предпоследний, пятый шаг предлагает выбрать поля, по которым будет
производиться сортировка записей.
Результат работы мастера по созданию формы, где использованы две табли­
цы со связью "один ко многим", представлен на рис. 13.18.

Рис. 13.18. Форма PETS_JOURNAL

Рассмотрим принцип работы формы. В верхней части формы находятся тек­
стовые поля, соответствующие полям таблицы, выбранным на первом шаге
работы мастера. Ниже находятся записи из журнала посещения ветеринара,
касающиеся непосредственно данного животного.
Любая из созданных форм может быть доработана в конструкторе форм.
Вызовем форму OWNERJPET для доработки. Для этого в Project Manager
выделим ее и нажмем кнопку Modify. В таком режиме становятся доступ­
ными все элементы формы, их свойства и связанные с ними события.
Немного переместив элементы формы, освободим место для нового элемен­
та типа Grid. Поместив его на выбранное место, щелкнем по нему правой
кнопкой мыши и во всплывающем меню выберем Builder. Появившееся ок­
но Grid Builder позволяет, используя уже знакомые приемы, настроить дан­
ный элемент Grid для вывода информации. Свяжем его с отношением Jour­
nal, определив для просмотра его три первых атрибута.
Сохраним эту сводную форму и вызовем ее для выполнения (рис. 13.19).

Р и с. 1 3 .1 9 . Сводная форма

Как показано на рис. 13.19, данная форма позволяет просмотреть, какими
животными владеет зарегистрированное в базе данных лицо, и ознакомиться
с посещениями определенного животного ветеринара.
Создание отчета

В Visual FoxPro есть несколько средств создания отчетов.
□ Report Wizard (Мастер отчета) позволяет быстро создать отчет, применяя
сортировку, группировку данных и заданный пользователем стиль оформ­
ления.
□ Report Designer (Конструктор отчета) помогает разрабатывать собствен­
ные отчеты либо модифицировать отчеты, которые были созданы с по­
мощью мастера.
□ Quick Report (Быстрый отчет) предназначено для размещения в конст­
рукторе отчета полей и задания среды окружения (разработчику на выбор
предлагается два варианта размещения полей).
Мастер создания отчетов запускается таким же образом, как и мастер созда­
ния форм — в окне New выбираем Report и нажимаем Wizard. Рассмотрим
пример создания отчета, несущего ту же функциональность, что и форма
с межтабличными связями из предыдущего раздела.
I. На первом шаге выбираем поля таблицы-родителя.

(

Зам ечание

^

Для краткости здесь не будем приводить снимки экрана и упоминать парам ет­
ры, используемые мастером, в том случае, если они, аналогичны полям из пре­
дыдущего раздела.

2. На втором шаге необходимо выбрать поля дочерней таблицы, участвую­
щие в отчете.
3. На третьем шаге приводим в соответствие поля, которые осуществляют
связь таблиц.
4. В окне, соответствующем четвертому шагу, определяем поля, по которым
будет происходить сортировка.
5. На пятом шаге выбираем стиль оформления отчета, а также расположе­
ние листа (книжное или альбомное).
Результат проведенной работы представлен на рис. 13.20.

W Report Designer * Report2 * Page 1

OWNER
03/25/06
Id O w n e r :

1

O w n e r : И в а н о в И И.
T e l: 2 2 3 - 3 5 - 1 3
A d r e s s : К р а с н а я 3 5 , к в .2 3
Id P e t

G enue

B irth

5

Nam e
Ры жик

1

KOT

0 6 /1 8 /0 4

4

Б ар с

1

KOT

1 2 /2 6 /0 4

Id O w n e r :

Id O w n e r

2

O w n e r : С и д о р о в М .И .
T e l: 2 5 5 - 4 6 - 2 6
A d re s s : Кирова 6
Id P e t

Id O w n e r :

Nam e

G enue

B irth

3

М аркиз

2

KOT

0 6 /1 6 /0 5

1

Ш арик

2

с о б а ка

0 1 /2 3 /0 6

Id O w n e r

3

(

Замечание

^

Во всех случаях при создании форм, отчетов и запросов на финальном этапе
выбиралась опция С о х р а н и ть в ф а й л д л я д а л ь н е й ш е г о и с п о л ь зо в а н и я . По­
сле чего посредством команды Add file меню P ro ject указанные сохраненные
файлы добавлялись в проект.
Для запуска (открытия) сохраненных данных использовалась команда Run па­
нели P ro je c t M an ag er.

С о з д а н и е з а п р о с а (q u e ry )
После выделения пункта Query в окне New и нажатия кнопки Wizard появ­
ляется окно, которое предлагает 3 варианта мастера по созданию запроса.
Мы воспользуемся Query Wizard — мастером для создания стандартных за­
просов (рис. 13.21).

Р и с . 1 3 .2 1 . Первое окно мастера по созданию запроса

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

лактических посещений ветеринара. Для этого в список Selected fields зане­
сем все поля отношения Journal.
В окне третьего шага в поле Field выберем JournaI.reason, а в поле Value за­
несем Профилактика. На следующем шаге указываем поле для сортировки
Id_pet.
Во второй части этого шага задаются параметры ограничения в ы д а в а е м ы х
результатов. Нам необходимы все записи в журнале, удовлетворяющие за­
просу, поэтому здесь оставим все без изменений.
В пятом шаге требуется сохранить полученные результаты. Запрос, соответ­
ствующий всем проделанным действиям, будет иметь следующий вид:
SELECT J o u r n a l. i d _ v i s i t , J o u r n a l. id__pet, J o u m a l .v i s i t d a t e ,;
J o u rn a I.rea so n , J o u r n a l.r e s u lt ;
FROM DATA2! JOURNAL;
WHERE J o u rn a I.rea so n = ( "Профилактика" );
ORDER BY J o u m a l .v i s i t d a t e

Результаты запроса № 1 показаны на рис. 13.22.

Р и с . 1 3 .2 2 . Результаты запроса № 1

Теперь создадим сложный запрос (№ 2), в котором будут использованы не­
сколько таблиц. Он будет преследовать ту же цель, что и предыдущий, с тем
исключением, что выборка будет содержать кличку животного, посетившего
ветеринара, и имя его хозяина.
1. На первом шаге выбираем поля Reason, Visitdate и Id_pet из таблицы
Journal, а также поля Name и Id_Owner из таблицы Pets.
2. На втором шаге подтверждаем связь между Pets.Id_pet и Journal.Id_pet
путем нажатия кнопки Add.
а) На шаге 2а ставим точку около All row from this table JOURNAL, тем
самым заявляем, что нас будут интересовать все записи из таблицы
Journal, удовлетворяющие условию, указанному на третьем шаге.
3. На третьем шаге формируем условие отбора записей для ответа на за­
прос, а именно Journal.Reason contains value "п р о ф и л а к т и к а " .

4. На четвертом шаге указываем поля, по которым будет производиться
сортировка, в нашем случае пусть это будет Journal.visitdate. Ограничи­
вать количество записей каким-либо образом не будем, поэтому можем
пропустить вторую часть четвертого шага.
5. На последнем, пятом шаге сохраняем результат.
Текст составленного мастером запроса:
SELECT Journal.id_visit, Journal.id_pet, Journal.reason;
Pets.id_owher, Pets.name;
FROM
DATA2 !JOURNAL
LEFT OUTER JOIN DATA2!PETS
ON
WHERE

Journal.id_pet = Pets.id_pet;
Journal.reason = ( "Профилактика" );

ORDER BY Journal.id__visit

Этот запрос возвращает данные, представленные на рис. 13.23.

Р и с . 1 3 .2 3 . Результаты запроса 2

С о зд ан и е прилож ения
Ранее в этом разделе были рассмотрены основные этапы создания компо­
нентов приложения, а именно создание базы данных, таблиц, форм, отчетов
и запросов. Логическим завершением данного обзора будет рассмотрение
создания приложения.
Этот процесс не представляет пользователям особых трудностей.
Для того чтобы скомпоновать приложение на основе данного проекта, необ­
ходимо в боковом меню Project Manager (Менеджера проектов), состоящем
из кнопок, нажать кнопку Build. Диалоговое окно, которое появится в ре­
зультате нажатия кнопки, представлено на рис. 13.24.
В данном окне применительно к рассматриваемому случаю выбираем для
переключателя Build Action значение Application. Если отметить в окне переклю­
чатель Run After Build, то после построения приложения оно будет запущено
и на экране появится главная форма. В нашем случае главной является

форма ow nerjet. Для того чтобы сделать главной другую форму, необходи
мо в ее контекстном меню выбрать пункт Set Main.

Р и с . 1 3 .2 4 . Построение приложения

13.2. MS SQL Server 2005
Microsoft SQL Server является реляционной системой управления базамг
данных (СУБД), позволяющей организовать хранение значительных объе­
мов данных и стабильно поддерживать работу пользователей, осуществляю­
щих одновременный доступ к этим данным.
Система спроектирована настолько грамотно, что удовлетворяет всем требо­
ваниям, предъявляемым к современной СУБД, — стабильность и высокаг
производительность, масштабируемость и удобство в эксплуатации — вс<
эти качества в совокупности с широким спектром функциональных воз

можностей и низкой ценой делают СУБД SQL Server лучшей системой
в своем классе.
Новая 2005 версия СУБД от Microsoft стала продолжением линейки продук­
тов серверов реляционных баз данных, зарекомендовавших себя с наилуч­
шей стороны в отношении надежности, производительности, расширяемо­
сти, масштабируемости, а также простоты управления и использования.
Microsoft SQL Server 2005 имеет ряд преимуществ, которые выгодно отли­
чают его от других программных продуктов для управления базами данных и
позволяют продвинуться на рынок решений, ранее монопольно занимаемый
Oracle.

13.2.1. Язык SQL
Как и большинство других программных продуктов для работы с базами
данных, MS SQL Server имеет свой диалект SQL, называемый Transact-SQL.
Он имеет специфичный дополнительный синтаксис, изменения которого по
сравнению с ISO-версией SQL в основном касаются работы с транзакциями
и управления потоками данных.
Используя Transact-SQL, пользователь получает дополнительный набор воз­
можностей к базовому языку SQL, который позволяет формировать более
функциональные запросы.

13.2.2. Нововведения относительно
предыдущих версий
Изменения коснулись практически всех аспектов жизни SQL Server. Архи­
тектура программного решения от Microsoft теперь значительно улучшена,
что позволило новой системе укрепиться на рынке решений для обработки
онлайн-транзакций (OLTP), надежного хранения данных, создания и ис­
пользования всевозможных сервисов, мощных средств для OLAP-анализа,
а также приложений электронной коммерции.
Основными улучшениями новой версии СУБД являются:
□ интеграция продукта с Microsoft .NET Framework;
□ появление новых типов данных;
□ введение дополнительных сервисов и утилит;
□ удобство от объединения различных утилит управления и обращения
к СУБД в одну;
□ улучшение работы с XML;
□ возможность использования некоторых расширений языка Transact-SQL;

□ использование расширенных механизмов репликации и масштабируе­
мость систем на основе SQL Server 2005;
□ увеличение безопасности и разграничение прав доступа на уровне базы
данных;
□ появление возможностей пересылки протоколов баз данных с помощью
механизма их зеркалирования;
□ возможность создавать и использовать представления баз данных в ре­
жиме только для чтения (снимок базы данных);
□ возможность выполнить восстановление данных отдельно взятого экзем­
пляра базы данных без его остановки;
□ интеграция с мобильными телефонами (версия SQL Server 2005 Windows
CE Edition).
Н о в ы е утилиты
В 2005 версии разработчики Microsoft представили целый спектр новых
утилит по разработке, администрированию и управлению базами данных.
К нововведениям относятся: улучшенный SQL Profiler, улучшенный DTS
Import/Export Wizard, Report Manager, утилита Database Tuning Advisor, ути­
лита Configuration Manager, компоненты Analysis Services Wizards.
Вместо утилит Enterprise Manager, Query Analyzer и утилиты по управлению
OLAP-базами данных, присутствующих в версии SQL Server 2000, в 2005
используется одна — SQL Server Management Studio, объединившая все воз­
можности перечисленных утилит и тем самым предоставившая разработчику
новые возможности работы с СУБД: общий интерфейс для управления ба­
зами данных SQL Server и среду, допускающую совместную работу несколь­
ких разработчиков над одним проектом.
В SQL Server 2005 представлена новая утилита под названием Business Intel­
ligence Development Studio, назначением которой является создание OLAPрешений. Эта утилита путем интеграции с Visual Studio IDE позволяет реа­
лизовать свои идеи на новой платформе и совместить их с системой SQL
Server.
Н овы е серви сы
Брокер сервисов — новый уровень в приложениях на основе SQL Server,
разграничивающий пользовательские приложения и базы данных. Благодаря
этому средству разработчики могут строить распределенные приложения на
основе асинхронного обмена сообщениями с базой данных через очередь
сообщений, управляемой брокером сервисов.
Улучшена архитектура новых сервисов преобразования данных, за счет чего
производительность сервиса DTS Designer, занимающегося управлением по­
токами данных и задач, несколько возросла.

В SQL Server 2005 усовершенствованы средства доступа к данным, для чего
была переработана и улучшена работа адаптеров Microsoft Data Access
и SQLClient, контролирующих доступ к данным.
В 2005 версии сервисы аналитики используются для анализа статистической
информации, составления различных аналитических отчетов, разрезов дан­
ных с целью их дальнейшего применения в различных приложениях. Для
разработки приложений, использующих эти сервисы, реализована возмож­
ность интеграции с .NET Framework.
Служба сервисов нотификации предоставляет разработчику возможности
для построения приложений, способных обмениваться сообщениями с пользо­
вателем. Подобные сообщения могут быть отправлены в любое время и на
различного рода устройства, начиная от мобильных телефонов и электрон­
ной почты и заканчивая КПК.
Сервисы отчетов позволяют выполнять всесторонний анализ данных, распо­
лагающихся в базе, осуществлять их разрезы в необходимых плоскостях и
выводить результаты статистического анализа соответствующим пользовате­
лям в нужном формате. С помощью компонента Reporting Service теперь
можно создавать, управлять и доставлять клиенту как обычные, так и интер­
активные отчеты.
Н о в ы е ти п ы д а н н ы х
В последней версии SQL Server появился новый тип данных — XML, плат­
формо-независимый формат представления неструктурированных и структу­
рированных данных, который в настоящий момент используется во многих
программных системах. В SQL Server 2000 были реализованы два механизма
для работы с XML — хранения файлов в текстовых полях и конвертации
содержимого XML-документа в реляционные таблицы. Из-за существующих
проблем, которые невозможно было разрешить с помощью этих меха­
низмов, был создан новый тип данных, называемый XML. Этот тип наряду
с другими типами данных SQL Server может использоваться в качестве ко­
лонок таблиц, переменных Т-SQL и параметров процедур.
Помимо XML, в 2005 версии добавлены еще три новых типа данных:
v a r c h a r (m a x ), n v a r c h a r (m ax) И v a r b i n a r y (m a x ) , которые значительно рас­
ширяют существующие и позволяют хранить до 2 Гбайт данных.

13.2.3. Варианты поставки SQL Server 2005
Новая версия SQL Server имеет ряд редакций, которые включают 32- и 64разрядные версии данного программного продукта.
SQL Server 2005 Enterprise Edition — это мощная платформа масштаба пред­
приятия для управления данными и их анализа, предназначенная для кри­
тически важных корпоративных приложений; обладает неограниченным

масштабированием, улучшенными средствами зеркалирования, создания
разделов, параллелизмом, созданием снимков баз данных, мощными средст­
вами анализа, улучшенными службами интеграции и настраиваемыми служ­
бами создания отчетов. Эта редакция выпускается для 32- и 64-разрядных
систем.
SQL Server 2005 Developer Edition — обладая всеми преимуществами редак­
ции Enterprise Edition и являясь полноценной средой разработки для СУБД,
позволяет разработчикам создавать мощные решения для платформы, ис­
пользующей СУБД SQL Server.
SQL Server 2005 Standard Edition — это мощная платформа для управления
данными и их анализа, предназначена для предприятий среднего размера;
совместима с 64-разрядными системами.
SQL Server 2005 Workgroup Edition — это новая редакция SQL Server, пред­
ставляющая собой высокопроизводительное и простое в использовании ре­
шение для управления базами данных; наилучшим образом подходит для
небольших и средних предприятий, где требуется недорогая и достаточно
мощная СУБД.
SQL Server 2005 Express Edition — это самая простая версия известного
программного продукта, имеющая ряд ограничений по сравнению с други­
ми редакциями SQL Server; позволяет быстро разворачивать приложения на
предприятиях с малым количеством компьютеров, используя при этом ос­
новные функции SQL Server.
SQL Server 2005 Mobile Edition — это новая редакция сервера SQL, позво­
ляющая работать с данными через мобильный телефон, тем самым расши­
ряя возможности новой СУБД.

13.2.4. Создание базы данных
Ограничившись небольшим обзором новых возможностей системы SQL
Server 2005, автор не ставит перед собой цель раскрыть и проиллюстриро­
вать их в полной мере на десяти отведенных страницах. Естественно, осу­
ществить это невозможно. Поэтому ниже, чтобы материал имел такую же
структуру, как и другие подразделы главы 13, проиллюстрированы лишь
некоторые составляющие процесса создания и использования баз данных
в SQL Server 2005.
В новой версии разработчик имеет возможность управлять любыми базами
данных SQL Server через один общий интерфейс, что становится намного
удобней, нежели в предыдущих версиях данной СУБД. Средство, с помощью
которого достигается гибкость управления, называется SQL Server Management
Studio.
Для создания базы данных нам необходимо запустить SQL Server Management
Studio и пройти аутентификацию.

Данные в SQL Server организованы в нескольких различных объектах, кото­
рые пользователь видит при создании базы данных:
□ таблицы (Tables);
□ представления (SQL Server Views);
□ синонимы (Synonyms);
□ пользователи базы данных (Database Users);
□ роли базы данных (Database Roles);
□ хранимые процедуры (Stored Procedures), функции (Functions), триггеры
(Database Triggers), типы данных, определяемые пользователем (Types),
правила (Rules), значения по умолчанию (Defaults), объединенные одним
именем Programmability;
□ брокер Сервисов (Service Broker);
□ хранилище (Storage);
□ пользователи (Users), роли (Roles), схемы (Schemas) и симметричные
ключи (Symmetric Keys), объединенные в одной вкладке Security.
На рис. 13.25 представлено исходное окно Microsoft SQL Server Management
Studio.
Щ Microsoft SQL Server Management Studio
File

Edit

View

l NewQu^ ’

Tools

'

^

Window

€

1

..

Registered Servers

0

у

Microsoft SQL Servers

Шduron
Object Explorer

0

j g ) Durojri (SQL Server 9 .0 .8S 2 * sa)

Ш£ j jp&k>acse$ i
Ш 0 2 Security
& D ii Notification Services
0

£ j | Replication

0

0 2 Management

Ш C 2 Support Services
©

SQL Server Agent

4 ®

Help

i

rtered Servers

p

В качестве примера базы данных возьмем уже использованную ранее
в разд. 13.1.4. ER-модель "Владелец — Животные — Ветеринар”, включаю­
щую три основные таблицы: Owners, Pets и Journal (см. рис. 13.3).
Создать новую базу данных и журнал транзакций посредством графического
интерфейса можно несколькими способами. Один из них — выбрать из
контекстного меню, выпадающего из каталога Databases подключенного
сервера, пункт New Database (рис. 13.26).

Р и с . 1 3 .2 6 . Создание новой базы данных

После этого откроется окно новой базы данных (New Database) (рис. 13.27).
На странице General задаются физические параметры новой базы данных:
□ именование базы данных;
□ использование одного или нескольких файлов базы данных;
□ "рост" объема базы данных;
□ применение файлов журналов транзакций;
□ определение параметров разрастания файлов журналов.
На странице Options (рис. 13.28) задаются специфические особенности ра­
боты новой базы данных.

Р и с . 1 3 .2 8 . Страница O p tion s окна N ew D a ta b a se

Параметры роста файлов новой базы данных:
□ Do not automatically grow the database files — не увеличивать объем файлов
автоматически в случае разрастания базы данных;

□ Automatically grow the database files — автоматически увеличивать размер
файлов, без выдачи запроса на подтверждение:

• Grow the files in megabytes (MB) — при нехватке объема файла для
хранения необходимой информации увеличить размер файла на за­
данное количество мегабайт;

• Grow the files by percent — увеличить размер файла на заданное коли­
чество процентов:
О Unrestricted file growth — неограниченное увеличение размера фай­
ла в соответствии с необходимостью;
О Restrict file growth to MB — установить указанный лимит на размер
файла.
На следующих страницах — Filegroups и Extended Properties — окна New
Database необходимо указать, к какой группе относятся файлы новой базы
данных, а также дополнительные опции новой базы данных.

В случае отсутствия ошибок после нажатия кнопки ОК на вкладке Databases
рядом со списками System Databases и Database Snapshots появится новый
экземпляр шаблонной базы данных model с именем, указанным в окне New
Database.

Кроме способа создания базы данных с помощью визуальных средств SQL
Server Management Studio, эту же операцию можно произвести и с помощью
команды Transact-SQL следующего формата:
CREATE DATABASE
[ON [PRIMARY]

< И М Я

БД>

сспецификация файла>

[LOG ON С п ец и ф и кац и я файла>

[,...

11 ] ]

[, . . .п ] ]

[FOR RESTORE]
сспецификация файла> : : =
(МАМЕ=логическое имя файла,
FILENAME= hüw файла операционной системы
[ , SIZE=pa3M ep]
[ ,MAXSIZE= {максимальный размер

| U N LIM ITED }]

[ , F ILEGROWTH=npnpащениe ] )

Параметры команды c r e a t e d a t a b a s e :
□ on — определяет список файлов на диске для размещения информации
базы данных;
□ primary — определяет первичный файл; если параметр опущен, то пер­
вичным является первый файл в списке;
□ N — на месте этого символа можно указать дополнительные файлы для
размещения БД;
□

log on — определяет список файлов на диске для размещения журнала
транзакций;

□

s iz e

□

m a x s iz e

□

for restore

— определяет первоначальный размер файла;

— определяет максимальный размер файла базы данных;

— не разрешает пользователю доступ к базе данных до за­
вершения операции restore .

Для наглядной демонстрации создания базы данных посредством Transact-SQL
приведем следующий пример:
CREATE DATABASE V e te r in a r D B
ON PRIMARY
(N A M E=Veter,
FILENAME= ' C : \ SQLBAZAW etDB. m d f' ,
SIZE=5M b,
FILEGROWTH=10%)
LOG ON (N A M E = V e te r_ lo g ,
FILENAME=' C :\S Q L B A ZA \V etD B L o g.l d f ' ,
SIZE=2MB,
FILEGR0WTH=1MB)

Запрос на создание новой базы данных с указанием всех ее параметров
можно сгенерировать автоматически, выбрав из предыдущего окна New Da­
tabase вкладку Script. В этом случае будет создан скрипт запроса, который
можно будет сохранить в буфер обмена, в файл, либо вывести на экран
(рис. 13.30).

Р и с . 1 3 .3 0 . Сгенерированный скрипт создания новой базы данных

13.2.5. Удаление базы данных
Удаление базы данных приводит к освобождению всего занимаемого ею
пространства во всех файлах этой базы данных и, следовательно, к удале­
нию всех содержащихся в ней объектов.
При удалении базы данных следует помнить, что восстановить ее крайне
непросто, а в случае с отсутствием резервной копии этой базы данных и ее
журналов транзакций необходимо будет восстанавливать БД без помощи
SQL Server, работая непосредственно с диском и файловой системой.
Для удаления базы данных необходимо выделить ее в иерархическом дере­
ве утилиты SQL Server Management Studio, вызвав контекстное меню
(рис. 13.31).

Р и с . 1 3 .3 1 . Удаление базы данных через контекстное меню

После выбора Delete появляется окно Delete Object (рис. 13.32), где под­
тверждается запрос на удаление выбранной базы данных.
С помощью Transact-SQL база данных удаляется в одну команду:
DROP DATABASE <имя базы данны х>

13.2.6. Создание таблиц
Итак, мы создали базу данных VeterBD, разместили ее файлы и указали па­
раметры роста файлов по умолчанию. Теперь приступим к созданию таблиц.
Для создания таблицы нужно сделать следующее:
□ задать имя таблицы;
□ задать имена столбцов и определить тип данных для каждого из них;
□ определить или использовать заново заданный по умолчанию режим ра­
боты со значением Null (для каждого столбца);
□ определить условия на значения для столбцов и, прежде всего, первич­
ный и внешний ключи.
Для проведения данных операций SQL Server Management Studio предостав­
ляет удобный интерфейс с богатыми возможностями.
Для того чтобы начать процесс создания таблицы, выделите нужный сервер
баз данных в консоли управления, раскройте ветвь дерева, содержащую ин­
тересующую вас базу данных. Выделите компонент Tables и в его контекст­
ном меню выберите New Table. Также можно нажать кнопку New, находя­
щуюся на панели инструментов.
После этого появится несколько окон-панелей, отражающих все свойства
новой таблицы.
П Непосредственно само содержание: колонка-тип и свойства колонок
(рис. 13.33). Параметры столбцов задаются не только в табличной части
окна, куда вынесены обязательные параметры столбца, но и на вкладке
Column Properties.
К обязательным параметрам таблицы относятся:
• имя столбца (Column Name);
• тип данных, ему соответствующий (Data Туре);
• длина (Length).
После задания типа данных автоматически определяется и его длина.
Впрочем, этот атрибут можно отредактировать и вручную.
Кроме того, для каждого столбца можно задать следующие параметры:
• Allow Nulls — в случае установки этого флажка при добавлении новой
записи допускается использование Null-Значения;

Р и с . 1 3 .3 3 . Создание таблицы. Панель новой таблицы

• Default Value — значение по умолчанию, записываемое в столбец, если
для него не задано никакое конкретное значение;
• Identity — этот флажок может быть установлен только при создании;
он говорит, что значение данного столбца получается автоматически,
путем сложения значения в предыдущем столбце с приращением, ука­
занным в свойстве Identity Increment;
• IsRowGuid — сообщает о том, что столбец используется как глобаль­
ный уникальный идентификатор;
• Formula — выражение, используемое при вычислении значения столбца.

□ Окно Properties панели инструментов, где можно увидеть и отредактиро­
вать остальные свойства и атрибуты таблицы (рис. 13.34).

Р и с . 1 3 .3 4 . Создание таблицы.
Вспомогательная панель свойств новой таблицы

Для сохранения таблицы необходимо выбрать пункт меню File и Save
ТаЫе_1. После нажатия этой кнопки SQL Server запросит имя создаваемой
таблицы.
Для создания таблиц Owner, Pets и Journal выбираем созданную базу данных
VeterBD, выделяем пункт Tables и из контекстного меню выбираем New Table.

Поля таблицы Owners состоят из: id_owner (тип Numeric) — уникального
ключа Владельца; owner, tel и address (тип nchar) — имени, телефона и ад­
реса Владельца соответственно (рис. 13.35). Ключ id_owner образует связь
"один ко многим” с таблицей Pets.
/ Table - dbo.Owners |

Column Name
№ idjDwner
owner

Data Type

Allow Nulls

numeric

□

nchar

□

tel

nchar

и

address

nchar

0
□

Рис. 13.35. Поля таблицы Owners

Таблица Pets (рис. 13.36) содержит: id_pet (тип Numeric) — уникальный
ключ Животного; паше и genue (тип nchar) — имя и тип Животного соот­
ветственно; id_owner (тип Numeric) — идентификационный номер Владельца
и birth (тип DateTime) — дата рождения Животного. Ключ id_owner таблицы
Pets связан с уникальным ключом id_owner таблицы Owners, а уникальный
ключ id_pet свяжет данную таблицу с таблицей Journal.
table - dbo.Pets j Table - dbo.Owners j

Column Name

Data Type

Allow Nulls

numeric

□

nchar

□

id_owner

numeric

□

genue

nchar

□

birth

datetime

0

w j id_pet
name

□

Рис. 13.36. Поля таблицы Pets

Вновь созданная таблица Journal (рис. 13.37) включает поля: id_visit (тип
— уникальный ключ записи в Журнале ветеринара; id j e t (тип
Numeric) — ключ животного, связываемый с уникальным ключом id_pet
таблицы Pets; visitdate (тип DateTime) — дата визита; reason и result (тип
nchar) — причина и результат визита соответственно.
После того как таблицы созданы, устанавливаем отношения между ними.
Для связи "один ко многим" таблиц Owners с Pets и Pets с Journal вызываем
команду Relationships (рис. 13.38).

Numeric)

Table - dbo.Journal
Column Name

Table - dbo.Pets

\

Data Type

Table - dbo.Owners j
| Allow Nulls

№ j idj/isit

numeric

□

id_pet

numeric

□

visitdate

datetime

□

reason

nchar

и

result

nchar

0
f

□

Рис. 13.37. Поля таблицы Journal

Рис. 13.38. Установление связей таблиц

Нажимая кнопку Add появившегося окна, добавляем новые отношения, м<
няем им имя на FK_Journal_Pets и в графе Tables And Columns Specificatic
указываем связь Pets.id_pet — Journal.id_pet, после чего нажимаем OK. Зг
крываем окно Foreign Key Relationships.
Выбираем таблицу Pets и вновь создаем связь "один ко многим" по отнс
шению к таблице Owner (т. е. Owner к Pets как "один ко многим”): им
для новой связи FK_Pets_Owner, связь Owner.id_owner — Pets.id_owm
(рис. 13.39).

Рис. 13.39. Установление связи "один ко многим" таблиц Owners и Pets

13.2.7. Заполнение таблиц данными
Для заполнения таблицы данными посредством Transact-SQL используется
оператор i n s e r t :
INSERT INTO [имя БД] . [имя пользователя] . [имя таблицы]
([поле1]
, [поле2]
, [полеЗ]

, [полеЭД )
VALUES
(<поле1>
,<поле2>
,<полеЗ>

,<поле№> )

Выборка значений из таблицы осуществляется оператором
SELECT [поле1]
, [поле2]

select:

,

[полеЗ]

, [полеКГ]
FROM [имя БД].[имя пользователя].[имя таблицы]

Кроме этого, можно использовать графические средства, предоставляемые
SQL Server Management Studio. Для того чтобы просмотреть имеющиеся
данные в таблице и отредактировать их или добавить новые, достаточно вы­
брать интересующую таблицу и, щелкнув правой кнопкой мыши на ней,
выбрать в контекстном меню команду Modify, либо список команд Script
Table as для создания запроса (рис. 13.40). После этого с помощью команды
на языке Т-SQL можно добавить, просмотреть, модифицировать или уда­
лить данные из таблицы.
New Table,,.
Modify Table
|

Script ra b ie s
View Dependencies
Full-Text index
Rename
Delete
Refresh
Properties

>

CREATE To

►

ALTER To

*

DROP To

►

►
1 SELECT To
INSERT To
UPDATE To
DELETE To
EXECUTE To

»
►
►
►

New Query Editor Window
File,..
Clipboard

>

Рис. 13.40. Создание запроса к выбранной таблице

Сценарий добавления информации о владельцах в таблицу Owners приведен
на рис. 13.41. Если добавление происходит во все поля таблицы, то перечень
полей можно не вводить.
Аналогично заполняются данные о животных в таблицу Pets (рис. 13.42).

Р и с . 1 3 .4 2 . Ввод данных в таблицу P e ts

После чего информация о посещениях животными ветеринара заносится
в Журнал таблицы Journal (рис. 13.43). В данном примере не все живот­
ные посетили ветеринара, а некоторые из животных посещали его неод­
нократно.
Если в ходе заполнения таблиц транслятор выдал ошибку, то следует прове­
рить, удовлетворяют ли вводимые данные типам полей и их параметрам;
нужно также проверить уникальность ключей, связывающих таблицы.
После успешного заполнения таблиц данными можно группировать запро­
сы, обращаясь к произвольной таблице и указывая произвольные параметры
группировки.

Р и с . 1 3 .4 3 . Заполнение таблицы Jo u rn al

Создадим запрос к таблице Pets, чтобы узнать, какое животное кому при­
надлежит:
SELECT P e t s .id _ p e t , P ets.nam e, P e ts.g e n u e , P e t s .b ir t h ,
Owners. owner
FROM P e t s , Owners
WHERE P e t s . id_owner=Owners. id_owner
GO

Результаты запроса l приведены на рис. 13.44.

id_pet

name

geme

| birth

owner

1

h

I Мурка

Кошка

2004-12-04 0000...

2

2

Рэме

Собака

2003-11432 0000...

Иханох

3

3

Флиппер

Рыбка

2005-12-21 0000...

Петрох

4

4

Алекс

Лех

2001-03-050000...

Дурох

5__

5

Шерхан

Тигр

2002-07-15 0000...

Дурох

6___ б

Соня

Хомяк

2005-09-14 0000...

Сндорох

2 ___ 7

Кеша

Попутай

2004-10-14 0000...

Сидорох

т Results UJ Messages:1
у/ Query executed successfully.

Duron (9.0 В2)

sa (56)

Ихаиох

VeterBD

00:00:00

7 rows

Р и с . 1 3 .4 4 . Результат простого запроса 1

Можно создать запрос к данным таблицы Journal, чтобы узнать, кто из жи­
вотных проходил курс лечения до 10 февраля (рис. 13.45):
SELECT Journal.id_visit, Journal.visitdate,
Journal.reason, Journal.result,
Pets.Name, Owners.owner
FROM Journal, Pets, Owners
WHERE (Journal.id_pet=Pets.id_pet) AND
(Pets.id_owner=Owners.id_owner) AND
(Journal.visitdate<='02.10.2006')
GO

J|v m td a te
|2

| 2 0 06-01-09...

2____ 3

2 006-01-15...

l

| W üon

| ow ner

г» naît

N am e

Б ол езн ь п ередн и х пап. О с м о тр

Т р е б у е т с я п о в т о р н о е пе ченге

Рькс

И ванов

Б ол езн ь п е р ед н и х лап. П о в т о р н ы й о с м о т р

П р о п и с а н курс вптамгосов

Р эис

И ванов

3

4

!2 0 0 6 -0 2 0 7 ...

Б ол езн ь п о ч ек. П о в т о р к ы и о с м о т р

Т р е б у е т е я по в т о р н о е пе ченге

М урка

И ван ов

4

5

2 0 0 6 -0 2 0 9 ...

О б щ ее и сто щ ен и е. О см о тр

П р о п и с а н курс ви там и н ов

Алекс

Дуров

5

6

2 0 0 6 -0 2 0 9 ...

Б ол езн ь з у б о в . О см отр

Т р е б у е т с я п о в т о р н о е пе ченге

Ш ерхан

Д уров

OH Results j

у/ Query executed successfully.

Duron (9.0 В2)

sa (56)

VeterBD

00:00:01

5 rows

Как видно из рис. 13.45, у животного по имени Мурка с болезнью почек
осмотр осуществлялся вторично, а первичный осмотр при просмотре всего
журнала датирован 5 июня 2006, значит, информация визита не верна. Чтобы
исправить неточность, нужно изменить дату первичного осмотра данного
животного, для чего необходимо воспользоваться командой u p d a t e :
UPDATE J o u r n a l
SET J o u r n a l . v i s i t d a t e =

'01.01.2006'

WHERE ( J o u r n a l . v i s i t d a t e = ' 0 6 . 0 5 . 2 0 0 6 ' )

AND

(J o u r n a l. id _ p e t = l)
GO

После этого запроса все данные о визитах животных к ветеринару до
10 февраля при повторном запросе окажутся согласованными.

13.2.8. Архитектура системы безопасности
SQL Server 2005
Система безопасности SQL Server 2005 базируется на пользователях и учет­
ных записях.
Пользователи проходят следующие два этапа проверки системой безо­
пасности. На первом этапе пользователь идентифицируется по имени учет­
ной записи и паролю, т. е. проходит аутентификацию.
Если данные введены правильно, пользователь подключается к SQL Server.
Подключение к SQL Server, или регистрация, не дает автоматического досту­
па к базам данных. Для каждой базы данных сервера регистрационное имя
(или учетная запись — login) должно отображаться в имя пользователя базы
данных (user).
На втором этапе, на основе прав, выданных пользователю как пользователю
базы данных (user), его регистрационное имя (login) получает доступ к соот­
ветствующей базе данных. В разных базах данных login одного и того же
пользователя может иметь одинаковые или разные имена user с разными
правами доступа.
Для доступа приложений к базам данных им также понадобятся права. Чаще
всего приложениям выдаются те же права, которые предоставлены пользо­
вателям, запускающим эти приложения. Однако для работы некоторых прило­
жений необходимо иметь фиксированный набор прав доступа, не зависящих от
прав доступа пользователя. Новая версия SQL Server позволяет предоставить
такие права с применением специальных ролей приложения.
Итак, на уровне сервера система безопасности оперирует следующими по­
нятиями:
□ аутентификация (authentication);

□ учетная запись (login);
□ встроенные роли сервера (fixed server roles).
На уровне базы данных используются следующие понятия:
□ пользователь базы данных (database user);
□ фиксированная роль базы данных (fixed database role);
□ пользовательская роль базы данных (users database role);
□ роль приложения (application role).
Для создания нового пользователя необходимо в контекстном меню узла
Security — Users дерева вашей базы данных выбрать New user, после чего
появится окно добавления нового пользователя (рис. 13.46).

Р и с . 1 3 .4 6 . Добавление нового пользователя

В новом окне страницы General необходимо ввести User name и Login name
пользователя, а также выбрать роли, закрепленные за ним. Начиная с 7 версии
SQL Server, за одним пользователем может быть закреплено несколько ролей.

13.3. Access 2003
Microsoft Access 2003 — удобное визуальное средство создания и управления
базами данных с интуитивно понятным интерфейсом и простым использо­
ванием.
Microsoft Access 2003 является одним из компонентов пакета Microsoft
Office 2003. Основная функция MS Access — работа со структурированной
в виде таблиц информацией. Access позволяет обеспечивать ввод данных
в таблицы базы данных, их сопровождение и хранение, а также получать из
совокупности этой информации необходимые данные для принятия важных
решений.

13.3.1. Историческая справка
Microsoft Access 1.0 был представлен в ноябре 1992 года. Благодаря исходной
поддержке языка SQL и легкости в использовании он быстро завоевал сим­
патии пользователей. Возможность применения мыши в сочетании с "горя­
чими клавишами" и удобные в использовании средства помощи до сих пор
остаются одними из главных достоинств программы.
В версию Access 95 были добавлены возможность вставки элементов ActiveX
и новые мастера по созданию баз данных, облегчена защита баз данных и
внесено большое количество других небольших изменений.
Access 97 претерпел значительные изменения как в пользовательском ин­
терфейсе, так и во внутренней структуре. Из-за возросшей популярности
Internet была добавлена возможность Web-публикаций в HTML-файлы и
доступ к FTP- и HTTP-серверам. Появился новый тип данных — гипер­
ссылка. При нажатии на поле гиперссылки Access выполнит переход на объ­
ект, документ, страницу Web или другое место назначения. Как и во все
компоненты Office 97, в MS Access был добавлен "помощник"
Изменения, появившиеся в Access 2000 касались, в основном, интерфейса
пользователя: "плоские кнопки", скрывающиеся меню и т. д. Во внутрен­
нюю часть было добавлено новое ядро баз данных — "Страницы Доступа
к Данным" (Data Access Pages), однако старое ядро Jet 4.0 было сохранено.
Большинство изменений носило косвенный характер, и многие пользовате­
ли не стали переходить на новую программу.
Программа Access 2002 ориентирована на создание настольных приложений
и приложений "клиент-сервер"
Основная цель при разработке Access 2002 состояла в упрощении построе­
ния и применения баз данных, а также в упрощении доступа к важной ин­
формации и ее анализа, независимо от места расположения соответствующих
данных. В приложении Access 2002 расширены возможности пользователя

по доступу к информации баз данных корпоративного уровня, например,
Microsoft SQL Server. Кроме того, в нем усовершенствованы способы анали­
за пользователями этих данных с помощью динамических сводных таблиц
и сводных диаграмм, ранее имевшихся только в приложении Excel, а также
с помощью страниц доступа к данным, позволяющих пользователям рас­
пространять приложения корпоративных баз данных в Internet.
Одно из главных нововведений в Access 2002 — возможность импорта и
экспорта в XML для передачи по сетям Internet/intranet.

13.3.2. Требования к системе
Все версии Microsoft Office в 2003 году обладали приблизительно одинако­
выми минимальными требованиями к системе.
П р оц ессор

Pentium 2 3 3 MHz и выше. Р еком ендуется Pentium III

О перационная
си стем а

M icrosoft W indows 2 0 0 0 с пакетом обновления 3 или б о л е е п о зд ­
няя версия. Р еком ендуется W indows ХР или б о л е е поздняя версия

Память

6 4 Мбайт RAM (минимум). Рекомендуется 128 Мбайт RAM

Д и ск ов ое
пространство

2 4 5 Мбайт, включая 115 Мбайт пространства на ж естком ди ск е
под операционную систем у. В зависим ости от конфигурации объ­
ем испол ьзуем ого пространства на жестком д и ск е м ож ет менять­
ся. Локальному источнику установки н еобходи м о в п р о ц ессе у с ­
тановки приблизительно 2 Гбайт пр остр анства ж естк ого диска;
л о к ал ьн ом у источнику установки на компьютерах пользователей
нужно вплоть д о 2 4 0 Мбайт пространства пом им о пространства,
отводим ого для Office

Монитор

Super VGA (8 0 0 x 6 0 0 ) или б о л е е высокое р азр еш ен и е
с 2 5 6 цветами

Д и ск ов од

для компакт-дисков

Указы ваю щ ее
устройство

M icrosoft M ouse, Microsoft IntelliMouse или со в м ест и м о е указы­
ваю щ ее устройство

(

Примечание

)

Ни о д н а из версий Microsoft Office в 2 0 0 3 году не р а б о та л а с операционны ми
си стем ам и Microsoft W indow s ME/98/NT. Если на клиентских компьютерах уста­
н ов лен а одн а из этих операционны х систем , п е р е д инсталяцией Microsoft Office
е е н ео б х о д и м о обновить.

Некоторым программам Microsoft Office System необходимы дополнитель­
ные элементы или службы.
О Для распознавания речи нужен Pentium II 400 МГц или выше.

□ Для Microsoft Office InfoPath 2003 необходим Microsoft Internet Explorer 6.0
или выше.
□ Для создания рукописных заметок в Microsoft Office OneNote 2003 требу­
ется устройство ввода "перо" Tablet PC.
□ Для использования дополнительных возможностей совместной работы
в Microsoft Office Outlook 2003 может потребоваться Microsoft Exchange
Server 2003.
□ Для работы в Internet необходимо отдельное телефонное соединение или
широкополосный доступ в Internet.
□ Для передач Microsoft Office PowerPoint 2003 требуется кодировщик
Windows Media (совместимая видеокамера для передачи, включая видео);
сервер Microsoft Exchange Chat для обмена информацией в режиме ре­
ального времени; сервер Microsoft Windows Media для многоканального
вещания в реальном времени (свыше 10 членов аудитории).

13.3.3. Новые возможности Access 2003
В этом разделе приведен перечень некоторых новых возможностей системы,
появившихся в Access 2003, которые упрощают процесс работы с приложе­
ниями.
Просмотр информации о зависимостях объектов. Microsoft Office Access 2003
позволяет просматривать сведения о зависимостях между объектами базы
данных. Просмотр списка объектов, используемых указанным объектом,
помогает осуществлять поддержку базы данных и предотвращать ошибки,
связанные с потерей источников записей.
Проверка ошибок в формах и отчетах. В Microsoft Office Access 2003 можно
включить автоматическую проверку распространенных ошибок в формах
и отчетах, позволяющую находить и исправлять ошибки.
Распространение свойств поля. В предыдущих версиях Microsoft Access все­
гда при изменении наследуемого свойства поля приходилось вручную изме­
нять свойства соответствующего элемента управления у всех форм и отче­
тов. Теперь при изменении наследуемого свойства поля Microsoft Access
отображает предложение изменить свойства всех или некоторых элементов
управления, связанных с этим полем.
Смарт-теги. В Microsoft Office Access 2003 можно использовать свойство
Смарт-теги для добавления смарт-тегов в любое поле таблицы, запрос, фор­
му, отчет или на страницу доступа к данным базы данных.
Создание резервной копии базы данных или проекта. Можно создать резерв­
ную копию текущей базы данных или проекта перед внесением серьезных

изменений. Резервная копия будет сохранена в папке для резервных копий,
используемой по умолчанию, или в текущей папке.
Поддержка темы Windows ХР. В операционной системе Microsoft Windows ХР
существует несколько тем. При выборе темы, отличной от темы по умолча­
нию, она будет применена ко всем режимам, диалоговым окнам и элемен­
там управления.
Параметры автозамены. В Microsoft Office Access 2003 можно осуществлять
контроль над средствами автозамены. Кнопка Параметры автозамены появ­
ляется рядом с автоматически исправленным текстом.
Расширенные возможности выбора шрифтов в режиме SQL. В режиме SQL
и в режиме конструктора запросов базы данных Microsoft Access и проекта
Microsoft Access можно изменять шрифт и размер шрифта текста.
Контекстная справка в режиме SQL. В режиме SQL-запроса базы данных
Microsoft Access можно получить справку, относящуюся к ключевым словам
Jet SQL, функциям VBA и к функциям Access.
Импорт, экспорт и связь:
□ со списком Microsoft Windows SharePoint Services из Microsoft Access;
□ c Windows SharePoint Services.
Создание локальной таблицы с помощью связанной таблицы. В Microsoft
Office Access 2003 можно создать локальную копию структуры или данных
и структуры связанной таблицы.
Поддержка языка XML. Используя усовершенствованную поддержку языка
XML, Microsoft Office Access 2003 позволяет определять файл преобразова­
ния при импорте или экспорте данных в формат XML. При этом преобразо­
вание происходит автоматически.
Усовершенствованная защита. Усовершенствованная защита позволяет осу­
ществлять:
□ безопасность макросов;
□ блокировку потенциально опасных функций.

13.3.4. Работа в Access 2003
После запуска MS Access главное окно программы будет выглядеть пример­
но так, как показано на рис. 13.47.
На панелях инструментов могут отображаться как общие команды для всех
компонентов (работа с буфером обмена, печать и т. д.), так и специфичные
операции для определенных условий.

Рис. 13.47. Главное окно программы Microsoft Access 2003

Создание базы данных

Как видно из окна создания базы (рис. 13.47), новую базу можно создать
несколькими способами:
□ создание пустой базы данных с последующим ручным заполнением;
□ создание базы путем копирования данных из имеющейся базы;
□ создание с помощью шаблона.
Рассмотрим кратко эти варианты.

Создание новой базы из сущ ествующ его файла

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

Создание новой базы с помощью шаблона

В стандартной поставке MS Access 2003 имеются десять общих шаблонов,
предназначенных для создания самых распространенных видов баз данных.
Дополнительные шаблоны можно скачать с узла Microsoft прямо из про­
граммы, выбрав пункт Шаблоны на Microsoft.com.
После выбора пункта Общие шаблоны в окне создания базы данных появит­
ся окно, представленное на рис. 13.48.

Рис. 13.48. Общие шаблоны для создания новой базы данных

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

Для создания новой базы данных выберем пункт Новая база данных в окне
Создание. После запроса на сохранение окно базы должно выглядеть так,
как это показано на рис. 13.49.
I7 Зак. 3303

Рис. 13.49. Окно новой базы данных

Рис. 13.50. Диаграмма базы данных

Для создания базы данных рассмотрим упрошенную EER-диаграмму учета
сотрудников университета, показанную на рис. 13.50.
В реляционную модель, которая соответствует концептуальной модели, по­
казанной на рис. 13.50, должны входить следующие таблицы: Факультет,
Кафедра, Сотрудники, ИнжЛабСостав, Преподаватели (табл. 13.6)«
Таблица 13.6. Таблицы базы данных

Описание

Ключ

КодФакультета Целый

К од факультета

Первичный

Название

Текстовый

Название факультета

ДатаСозд

Д ата/
Время

Д ата создани я

КодКафедры

Целый

Код кафедры

Название

Текстовый

Н азвание каф едры

Адрес

Текстовый

А дрес

Зав

Целый

К од заведую щ его

Название

Поля

Факультет

Кафедра

Сотрудники

ИнжЛабСостав

Преподаватели

Тип

Первичный

КодФакультета Целый

Код факультета

Внешний

ТабНомер

Целый

Табельный ном ер
сотрудника

Первичный

ФИО

Текстовый

Фамилия, имя, отче­
ство сотрудника

Адрес

Текстовый

А др ес проживания

КодКафедры

Целый

Код каф едры

Внешний

ТабНомер

Целый

Табельный ном ер
сотрудника

Первичный

Стаж

Целый

Стаж работы (в ча­
сах)

ТабНомер

Целый

Табельный ном ер
сотрудника

КолНаучРаб

Целый

Количество научных
работ

Должность

Текстовый

Зан им аем ая д ол ж ­
ность

ПрепСтаж

Целый

П реподавательский
стаж (в часах)

Первичный

Для проверки работоспособности может также потребоваться ввести проб­
ные данные. Эти данные приведены в табл. 13.7—13.11.
Таблица 13.7. Факультет

Код факультета

Название

Дата создания

1102001

КТАС

01.08.1970

2135004

АДФ

12.01.1962

4115009

ТПП

24.09.1950

6748001

ЭФ

01.09.1967

Т аб лица 13.8. Каф едра

Код кафедры

Название

Адрес

Заведующий

Код факультета

324

ВТиАСУ

Полевая, 16

200034

1102001

632

Информатики

Полевая, 16

200103

1102001

443

Графики

Ленина, 231

2 0 0221

2135004

532

Аппараты ПП

Маркса, 117

200357

4115009

76 8

Экономики

Ленина, 231

200402

6748001

Т аб лица 13.9. Сотрудники

Табельный номер

ФИО

Адрес

Код кафедры

200034

Иванов А. Л.

Полковая, 3 4

324

200035

Волков П. Е.

П оселковая, 251

324

200044

С ем ен ова Е. 3 .

Весенняя, 2

324

200103

Лихой В. И.

Ленина, 173

632

200105

Б ондарев Г О:

Красная, 17

632

200221

М ихайлова Н. И.

Морская, 24

443

200234

Л еванов К. Д.

Ночная, 52

443

200357

Курочкина О. П.

Солнечный, 2

532

200359

С ем енов Л. 3 .

Мартовская, 102

532

200402

Лучкова М. И.

Волгоградский, 16

768

200403

Петров М. Е.

Полевая, 21

768

Таблица 13.10. Преподаватели
Т абел ьн ы й н о м е р

К о л и ч ест в о
научны х р а б о т

Д олж ность

П р еп о д а в а т ел ь ск и й
с т а ж (в д н я х )

200034

21

П р о ф ессо р

7201

200035

4

Ассистент

105

200103

17

П р о ф ессор

5032

200105

10

Ст. преподаватель

1010

200221

23

П р о ф ессо р

8501

200357

15

Д оцент

3340

200359

6

Ассистент

359

200402

20

П р о ф ессо р

6601

Таблица 13.11. ИнжЛабСостав
Т абельны й н о м е р

С таж

200044

1024

200234

1154

200403

512

Теперь можно приступить к созданию таблиц, форм и отчетов.
Создание таблиц

Доступ к таблицам осуществляется выбором раздела Таблицы путем нажатия
кнопки с одноименным названием в окне базы данных. Новую таблицу
можно создать тремя способами:
□ в режиме конструктора;
□ с помощью мастера;
□ путем ввода данных.
Создание таблицы путем ввода данных довольно неэффективно и здесь рас­
сматриваться не будет.
Создание новой таблицы в режиме конструктора

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

Рис. 1 3 .5 1 . Создание таблицы в режиме конструктора

Введем поля таблицы Факультет в строки окна конструктора и укажем их
тип и описание. По умолчанию тип данных для нового поля — текстовый.
Для его изменения достаточно выбрать нужный тип из раскрывающегося
списка в данной ячейке. Для создания первичного ключа выберем строку
с нужным полем, нажмем правую кнопку мыши и выберем пункт Ключевое
Поле из выпадающего меню. Слева от строки должен появиться значок
ключа. Именно так обозначаются первичные ключи в MS Access.
Ниже таблицы полей в окне конструктора находится панель свойств теку­
щего поля. Большинство свойств понятно из названия. Введем в ячейку
Подпись более подробное название каждого поля. Теперь эти данные будут
отображаться на формах и отчетах вместо имен полей.
После ввода всех данных закроем окно конструктора и на запрос о сохране­
нии ответим положительно. В появившемся окне ввода имени таблицы на­
берем Факультет. Созданная таблица должна появиться в текущем разделе.
Аналогично создадим таблицы: Кафедра, Сотрудники, ИнжЛабСостав и
Преподаватели.

Создание таблиц с помощ ью мастера

Мастер для создания таблиц применяется для быстрого и удобного создания
распространенных таблиц. Для создания новой таблицы дважды щелкнем
мышью на соответствующем пункте раздела Таблицы. В появившемся окне
(рис. 13.52) выберем таблицу Сотрудники. Из списка полей выберем поля,
приведенные на рисунке, и нажмем Далее. В следующем окне мастера из­
меним название таблицы на Сотрудники и выберем способ самостоятельного
определения первичного ключа. Далее выберем поле ТабельныйНом в каче­
стве ключа и зададим Числа, вводимые пользователем как способ ввода дан­
ных в ключевое поле. Окно создания связей в мастере оставим без измене­
ний и в последнем окне выберем пункт Изменить структуру таблицы. После
нажатия Готово появится конструктор таблиц, где следует изменить назва­
ние поля КодОтдела на КодКафедры, Фамилия на ФИО и ввести описания
полей.
Создание таблиц
Выберите образцы таблиц для применения при создании собственной таблицы.
Выберите категорию и образец таблицы, а затем нужные образцы полей. Допускается
выбор полей из нескольких таблиц. Если заранее неясно, будет ли использоваться поле
или нет, лучше добавить это поле в таблицу. Его несложно будет удалить позднее.
Образцы полей:

® Ледовые
ОЛичные
Образцы таблиц:
Список рассылки
Контакты
Клиенты

ш

С отрудники

Товары
Заказы

!

ÏJ

Поля новой таблицы:

Город
А
ОбластьКрайРеспубли
Область
ПочтовыйИндекс
Страна/регион
ДомашнийТелефон
РабочийТелефон
КодОтдела
Д атаРож дения
г 1й
С Л атаН дйм а.............. . ......"ïl.

Отмена

Т

Ц Н азад

И
GD
CD
0

ТабельныйНомер
А д р ес

Фамилия
КодОтдела

Переименовать поле...

Далее >

Готово

Рис. 13.52. Мастер создания таблиц

Создание связей между таблицами

Access 2003 обладает гибким и удобным визуальным средством создания и ре­
дактирования связей между таблицами. Для его активации выберем Главное
меню | Сервис | Схема Данных. Добавим в открывшееся окно все имеющиеся
таблицы (рис. 12.53). Для создания связи типа "один ко многим" между табли­
цами Факультет и Кафедра щелкнем мышью на поле КодФакультета таблицы
Факультет и перетащим его на поле с тем же названием таблицы Кафедра.

*-•>*'***'■
м

а

М

и

\

г

I КодФакул>тета
Название
ДатаСозд

1
|

\

\

КодКафедры
Название
Адрес
Зав
КодФакультета

1

ШШà й

j 1

1 gf

ФИО
\оо Адрес
КодКафедры

agi
ТабНонер
КолНаучРаб
Должность
ПрепСтаж

Добавление таблицы
Таблицы j Запросы jj Таблицы^ запросы

Добавить

|ИнжЛабСостав
Кафедра
Преподаватели
Сотрудник
Факультет

Р и с. 1 3 .5 3 . Окно схемы данных

Появится окно изменения связей, показанное на рис. 13.54. В центральной
таблице указаны поля главной и связанной таблиц. Установим флажок
Обеспечение целостности данных, означающий жесткую связь между табли­
цами, и флажки каскадного удаления и обновления данных. Аналогично
свяжем таблицы Кафедра и Сотрудники, для которых установим связь типа
"один ко многим", а также свяжем таблицы Сотрудники и ИнжЛабСостав,
Сотрудники и Преподаватели.
Связи между таблицами Сотрудники и ИнжЛабСостав, Сотрудники и Препо­
даватели относятся к типу суперкласс/подкласс и будут определены как
"один к одному"
В результате должна получиться картина, показанная на рис. 13.55. Закроем
окно и сохраним все изменения.
Созданные связи можно проверить тестовым вводом данных. Откроем таб­
лицу Факультет двойным щелчком мыши. При вводе первых данных слева
появится поле с крестиком в центре. Нажав на него, можно вводить данные
в подчиненную таблицу Кафедра. При этом поле КодФакультета в этой таб­

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

Рис. 13.54. Окно создания и изменения связей между таблицами

Рис. 13.55. Окончательная схема базы данных

Создание запросов

Запросы являются главным инструментом управления базами
В Access для создания запросов удобно использовать визуальные
Работа в них осуществляется посредством задания образцов значений
не запроса, предусматривающем тот тип доступа к базе данных,

данных.
средства.
в шабло­
который

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

Рис. 13.56. Конструктор запросов

Поля запроса

Таблица полей запроса нужна для ввода полей, условий отбора, групповых и
агрегатных функций, способа сортировки.
Любое поле в строке Поле содержит раскрывающийся список доступных
полей всех таблиц, участвующих в запросе. Поля в строке Имя таблицы
также имеют раскрывающийся список, содержащий имена доступных таб­
лиц. Поля в строке Сортировка предназначены для выбора способа сорти­
ровки записей в запросе. Вывод поля на экран можно отключить, отключив
значок Вывод на экран. В поле Условие отбора можно ввести любое условие,
касающееся данного поля. Например: > 1 0 , b e t w e e n l a n d ю . Е с л и условие
является равенством, то знак = можно не вводить, оставив лишь параметр

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

Пусть требуется выбрать все факультеты, созданные не раньше 01.01.1960.
Запустим конструктор запросов и добавим в него таблицу Факультет. Таб­
лица должна появиться в виде окошка со списком полей. Перенесем поля
КодФакультета, Название и ДатаСозд в таблицу полей. Поставим для поля
ДатаСозд условие >=#oi.01.1960#, означающее дату выше набранной, а также
сортировку по убыванию. Из выпадающего меню в схеме данных досту­
пен режим SQL. Созданный SQL-аналог запроса будет выглядеть пример­
но так:
SELECT Факультет.КодФакультета, Факультет.Название, Факультет.ДатаСозд
FROM Факультет
WHERE Факультет.ДатаСозд)>=#1/1/1960#
ORDER BY Факультет.ДатаСозд DESC;

Закроем и сохраним запрос. Теперь при его открытии (рис. 13.57) можно не
только просматривать данные таблицы, но и вводить их. Эта функция дос­
тупна для всех однотабличных запросов, в которых присутствуют все обяза­
тельные поля.

Ф Запрос1

: запрос на выборку

К о д ф акультет:)

Н азвание

ШШМ1102001шхтшШШ
674800Ц ЭФ
2 1 3 5 0 0 4 |Д Ц Ф
*

Д атаС озд
0 1 .0 8 .1 9 7 0
0 1 .0 9 .1 9 6 7
( 1 2 .0 1 .1 9 6 2

0)

1_Ш 0@ ю З
Рис. 13.57. Результат выполнения однотабличного запроса

Создание многотабличных запросов

Допустим, необходимо показать все данные о преподавателях в одной таб­
лице. Для этого создадим многотабличный запрос на выборку данных. За­
пустим мастер запросов и добавим в конструктор необходимые таблицы:
Кафедра, Сотрудники и Преподаватели. Заметим, что при добавлении таблиц

отображаются все связи между ними. Эти связи будут учитываться при кон­
струировании запроса. Выберем поле Название из таблицы Кафедра, поля
ТабельныйНом, ФИО и Адрес из таблицы Сотрудники, поля КолНаучРаб,
Должность, ПрепСтаж из таблицы Преподаватели. Остальные пункты оста­
вим по умолчанию. На рис. 13.58 представлен результат созданного масте­
ром запроса.

ы оорку
Н азв а н и е каф едры
► =Й2235
ВТиАСУ

Т а б е л ь н ы й но ь!
200034

ФИО
И в а н о в А .Л .

2 0 0 0 3 5 ; В о л к о в П .Е .

И нф орм ати ки

2 0 0 1 0 3 Л и х о й В И.

И нф орм ати ки

2 0 0 1 0 5 Б ондарев Г О

i

Адрес

| К о л -в о н а у ч н ы

П олковая, 34
;П осел ко в ая, 2f

21

Д ол ж н ость

I П репод стаж

П роф ессор

4 А ссистент

7201
105

Л е н и н а ,17 3

17 П р о ф е с с о р

5032

К р а с н а я , 17

10 С т. П р е п о д а в а

1010

23 П роф ессор

8501

15 Д о ц е н т

3340

Граф ики

200221

А ппар аты П П

2 0 0 3 5 7 К у р о ч к и н а О .П С о л н е ч н ы й , 2

М ихайлова Н >: М о рская . 24

А ппар аты П П

20 0 3 5 9 С ем енов Л 3

: М а р т о в с к а я . 1C

6 А ссистент

Э коном ики

2 0 0 4 0 2 Л у ч к о в а М .И .

В о л го гр а д с ки й

20 П роф ессор

359
6001

■и>>й>*; >ng
Р и с . 1 3 .5 8 . Результат многотабличного запроса

Для создания запросов в Access имеется несколько дополнительных конст­
рукторов, выбрать которые можно, указав пункт Запрос в подменю В ставк а
главного меню.
Создание запросов на изменение данных

Запросы на обновление данных служат для создания, изменения, удаления
групп записей из одной или нескольких таблиц. Существуют четыре типа
запроса на обновление данных.
□ Создание таблицы. Создание новой таблицы с данными, полученными из
других таблиц.
□ Обновление. Изменение групп записей в одной или нескольких таблицах.
□ Добавление. Добавление групп записей в таблицу из других таблиц.
□ Удаление. Удаление записей из одной или нескольких таблиц.
Единственное отличие запроса на создание таблиц от запроса на выборку
состоит в том, что результат выборки будет сохранен в предварительно соз­
данную таблицу, имя которой будет запрошено при задании типа запроса.

При запросе на обновление данных появится новое поле с названием
Обновление, в которое следует помещать данные для замены.
При запросе на добавление необходимо указать названия полей, в которые
будут помещаться результаты выборки.
Запрос на удаление подразумевает удаление записей при заданном условии
из одной таблицы или из нескольких, если при этом в связях между табли­
цами установлено каскадное удаление.
При работе в конструкторе создание запросов на изменение данных произ­
водится в специальном режиме. Для этого необходимо выбрать стрелку
в пункте Тип запроса выпадающего меню и указать на "обновление" Следу­
ет обратить внимание на то, что при этом в таблице полей исчезли Группи­
ровка, Вывод на экран и Сортировка. Однако добавилась новая строка —
Обновление. Добавив к полям запроса поле Название, введем в поле Обнов­
ление строку Лаборант, а в поле Условие отбора — Оператор. После сохра­
нения запроса, при его запуске, все найденные записи Лаборант в таблице
будут заменены на Оператор.
С оздан и е ф о р м
Формы в Access служат для удобного отображения данных из одной или
нескольких таблиц и ввода данных пользователем. Получить информацию
о формах, содержащихся в базе данных, можно, нажав кнопку с одноимен­
ным названием в окне базы данных. Создать новую форму можно всего
двумя способами: конструктором и мастером.
Создание форм с помощью мастера является самым распространенным спо­
собом создания форм благодаря простоте и удобству использования.
С о зд а н и е ф орм ы Факультет

Запустим мастер и из раскрывающегося списка таблиц и запросов выберем
таблицу Факультет. Перенесем вправо все доступные поля. Аналогично пе­
ренесем все поля таблицы Кафедра, кроме поля КодФакультета. Вид пред­
ставления данных и внешний вид подчиненной формы оставим без измене­
ний. Выберем требуемый стиль для формы, имена форм оставим без
изменений. Выберем пункт Изменить макет формы и подтвердим окончание.
Откроется конструктор форм и панель элементов формы. Ознакомимся
с ними более подробно.
Панель элем ентов

Панель элементов (рис. 13.59) включает 18 элементов формы и 2 кнопкипереключателя. Основные функции элементов представлены в табл. 13.12.

Па ▼

Выоор объектов

*

Надпись
Группа переключателе»!
Переключатель
Поле со списком

л\

Аа ab|

Поле

У

{‘”1
У е
€> 0 , .
ËI

Кнопка

Мастера

х

Флажок
Список

т

-л Щ

Разрыв страницы
Подчиненная форма/отчет.
Прямоугольник -

Р и с . 1 3 .5 9

□

Рисунок
Присоединенная рамка объекта

Свободная рамка объекта

ш м
Г1»А,
Ш Q

Выключатель

Вкладка

ш

Линия
Другие элементы

Ш

Панель элем ентов формы

Таблица 13.12. Функции основных элементов формы
Н а зв а н и е

Ф ункции

Вы бор объектов

Отмена выбранного объекта и возврат к обычным функциям
выбора. Установлен по умолчанию

М астер а

Включение/отключение м астеров создан и я сложных э л е м е н ­
тов, таких как Группа п е р е к л ю ч а т е л е й , С п и со к и П о л е с о
списк ом

Н адп и сь

О писание или пояснение к другим эл ем ен там

П ол е

Поле редактирования значений данных. С о зд а ется с при­
соеди н ен н ой надписью, которую потом можно удалить

Группа п е р е к л ю ч а ­
т ел ей

Рамка для разм ещ ения выключателей, ф лаж ков и переклю ­
чателей (только один по выбору)

В ы клю чатель

Кнопка с состоянием "включено/выключено"

П ер ек л ю ч а т ел ь

Кнопка, аналогичная выключателю, чащ е всего и сп о л ь зу е­
мая в группе переключателей

Ф лаж ок

Аналог выключателя. Флажок с состояниями "включено/
выключено"

П ол е с о сп и с к о м

Поле для ввода значения и список выбора значений

С п и сок

Список выбора значений. Значения списка могут быть полу­
чены из таблиц или зап р осов

Таблица 13.12 (окончание)

Название

Функции

Кнопка

Кнопка, при нажатии которой выполняется какое-либо собы ­
тие

Рисунок

Н еизменяемы й растровый рисунок

Свободная рамка
объекта

Объект OLE, созданны й прилож ением -сервером OLE (на­
пример, MS Paint)

Присоединенная
рамка объекта

О тображ ение поля OLE записи (рисунок, звуковой ф рагм ент
и т. д.)

Разрыв страницы

При печати ф орм ы или отчета переводит принтер на новую
страницу. В обычном реж им е не отображ ается

Вкладка

Н абор вкладок, в которых могут располагаться любые д а н ­
ные (например, подчиненные ф ормы и отчеты)

Подчиненная
форма/отчет

Подчиненная ф о р м а или отчет

Линия

Линия

Прямоугольник

Прямоугольник

Другие элементы

Д ругие элементы ActiveX

Конструктор формы Факультет будет выглядеть примерно так, как показано
на рис. 13.60.
Ввод заведующего по табельному номеру не очень удобен для работы. Создадим
поле со списком для выбора заведующего.
1. Убедимся, что на панели элементов отмечен пункт Мастера (кнопка вы­
делена прямоугольником). Если это не так, нажмем ее.
2. Теперь прокрутим подчиненную форму Кафедра вниз, пока не появится
примечание.
3. Выделим поле Заведующий и удалим его.
4. Выберем элемент Поле со списком на панели элементов и нажмем курсо­
ром мыши на поле формы. Появится мастер создания полей со списком.
5. Выберем способ получения значений из таблицы или запроса и нажмем
Далее.
6. Выберем таблицу Сотрудники в следующем окне мастера.
7. В окне выбора полей выберем ТабельныйНом и ФИО. Установим тре­
буемую ширину поля.

8. В окне сохранения значений выберем Запомнить в поле и укажем на Зав.
Укажем название поля и подтвердим окончание.
9. Закроем конструктор формы.

Рис. 13.60. Конструктор формы Факультет

С о зд а н и е с л ож н ой ф орм ы

Создадим более сложную форму, куда поместим информацию из двух таб­
лиц: Кафедра и Сотрудники. Для этого выполним ряд действий.
1. После запуска мастера выберем таблицу Кафедра и перенесем вправо все
ее поля.
2. Выберем вид формы в один столбец и укажем на изменение макета фор­
мы. Увеличим область данных формы и перенесем элемент Вкладка.
3. Выберем пункт Свойства из выпадающего меню на вкладках и изменим
имя на Преподаватели.
4. Выберем вторую вкладку и аналогично изменим имя на ИнжЛабСостав.
5. Снова выберем первую вкладку и перенесем элемент Подчиненная форма/
отчет.
6. В появившемся мастере выберем пункт Имеющиеся таблицы и запросы.

7. Перенесем вправо все поля таблицы Сотрудники и все, кроме ТабельныйНом, поля таблицы Преподаватели.
8. Выберем самостоятельное определение связи и укажем КодКафедры
в обоих полях.
9. Удалим поле КодКафедры.
10. Аналогично добавим подчиненную форму ИнжЛабСостав.
В результате должно получиться окно, показанное на рис. 13.61.

Р и с . 1 3 .6 1 . Конструктор формы К а ф е д р а

Из выпадающего меню формы кафедры выберем пункт Свойства. Если
в окне свойств указан объект не Форма, а Область данных, выберем форму
из раскрывающегося списка. В свойстве Разрешить добавление поставим
значение Нет. Закроем окно свойств и конструктор.
Снова откроем форму Факультет в режиме конструктора. Немного увеличим
размер области данных и перенесем элемент Кнопка. В появившемся маете-

ре выберем категорию Работа с формой и действие Открыть форму. Далее
выберем форму Кафедра и пункт Открыть форму для отобранных записей.
Укажем КодФакультета в качестве связи. Введем текст Сотрудники. Под­
твердим завершение работы мастера. Закроем конструктор и сохраним все
изменения.
С о зд а н и е главной ф орм ы

Выберем пункт Создание формы в режиме конструктора в разделе Формы.
В появившуюся пустую форму перенесем кнопку. Выберем в качестве дей­
ствия открытие формы Факультет с показом всех записей и дадим ей назва­
ние Изменение данных о факультетах. Перенесем еще две кнопки. Для пер­
вой укажем действие и имя Закрыть форму, для второй — Выйти из
приложения (рис. 13.62). Откроем окно свойств формы. Отключим области
прокрутки, кнопки перехода, область выделения и разделительные линии.
Выберем тип границы Тонкая. Закроем и сохраним форму как Главная. Вы­
берем пункт Главное меню | Сервис | Параметры запуска и укажем в поле
Вывод формы/страницы главную форму. Закроем и заново откроем базу
данных. Для окончательной готовности желательно добавить создание отче­
тов, которые будут рассмотрены далее.

Р и с . 1 3 .6 2 . Главная ф орм а базы данных

Приложение можно скомпилировать и распространять на любые компьюте­
ры, даже если у них не установлен Access, но для этого необходимо приоб­
рести версию для разработчиков (Microsoft Office ХР Developer Edition).
Создание отчетов

Организация процесса создания отчетов является одним из главных досто­
инств Access. Широкие возможности по изменению свойств позволяют со­
здавать самые разнообразные отчеты. В версии 2003 появилась возможность

создания безбумажных отчетов. В Access все отчеты подразделяются на
шесть категорий.
□ Одностолбцовые отчеты. В одном длинном столбце перечисляются зна­
чения всех полей таблицы или запроса.
□ Ленточные отчеты. Значения каждой записи помещаются в отдельную
строку.
□ Многостолбцовые отчеты. Они создаются из одностолбцовых отчетов.
Информация, не помещающаяся в первый столбец, переходит в верхнюю
часть второго столбца и т. д.
□ Отчеты с группировкой данных. Позволяют вычислять итоговые значения
для групп записей и представляют информацию в удобном для использо­
вания виде.
□ Почтовые наклейки. Используются для печати имен и адресов.
□ Свободные отчеты. Содержат подчиненные отчеты, при этом каждый
подчиненный отчет создается на основе независимых источников дан­
ных.
Для примера рассмотрим создание простого отчета с группировкой данных
с помощью мастера.
Создание отчета с помощью мастера

Перейдем в раздел Отчеты базы данных и запустим мастер отчетов. Добавим
все поля таблицы Факультет, все поля, кроме внешних ключей, таблиц Ка­
федра и Сотрудники, поля КолНаучРаб, Должность и ПрепСтаж таблицы
Преподаватели. В следующем окне выберем Факультет в качестве вида
представления данных. Выберем сортировку записей по фамилиям, вид ма­
кета — по левому краю и требуемый стиль печати. Зададим имя отчета как
Преподаватели. После завершения работы мастера будет показан отчет
с введенными данными. Если данные еще не были введены, попробуем за­
нести в базу данных пару факультетов и кафедр, и посмотрим, что получит­
ся. Хотя отчет и готов к печати, он содержит неприятные мелочи — отобра­
жение табельного номера как числа в экспоненциальном формате,
неполные названия некоторых заголовков и т. д. Откроем отчет в конструк­
торе и перестроим поля, как это показано на рис. 13.63.
После внесения изменений отчет можно связать с главной формой. Добавим
в форму две кнопки: Просмотр отчета "Преподаватели" и Печать отчета
"Преподаватели" и зададим им одноименные действия (рис. 13.64).
После запуска просмотра отчет будет выглядеть примерно так, как показано
на рис. 13.65.

Рис. 13.63. Конструктор отчетов

Рис. 13.64. Главная форма базы после добавления отчетов

Р и с . 1 3 .6 5 . Вывод результатов отчета

Литература

1. Базиян, Менахем и др. Использование Visual FoxPro 6. Специальное из­
дание.: Пер. с англ. — М.: Издательский дом "Вильямс", 2000, 928с.
2. Базы и банки данных и знаний / Под ред. Наумова Б. H. — М.: Высшая
школа, 1992, 430 с.
3. Гарсиа-Молина Г., Ульман Д. Д., Уидом Д. Системы баз данных. Пол­
ный курс.: Пер. с англ. — М.: Издательский дом "Вильямс", 2003. — 1088
с.: ил. — парад, тит. англ.
4. Горев А., Макашарипов С., Владимиров Ю. Microsoft SQL Server 6.5 для
профессионалов. — СПб.: Питер, 1998, 464 с.
5. Дейт, К., Дж. Введение в системы баз данных. — 6-е изд.: Пер. с англ. —
М.: Издательский дом "Вильямс", 1999, 848 с.
6. Джексон Г. Проектирование реляционных баз данных для использова­
ния с микроЭВМ. — М.: Мир, 1991, 251 с.
7. Дженнингс Р. Использование Microsoft Access 2002. Специальное изда­
ние: Пер. с англ. — М.: Издательский дом "Вильямс", 2002, 1012 с.
8. Зеймер Р., Сотел Р. Освой самостоятельно Microsoft SQL Server 2000 за 21
день.: Пер. с англ. — М.: Издательский дом "Вильямс", 2001, 704 с.
9. Кагаловский М. Р. Технология баз данных на персональных ЭВМ. —
М.: Финансы и статистика, 1992, 224 с.
10. Каратыгин С. А., Тихонов А. Ф., Тихонова Л. H. Visual FoxPro 6.0. — М.:
Бином, 1999, 784 с.
11. Карпова Т. Базы данных: модели, разработка, реализация. — СПб.: Пи­
тер, 2001, 304 с.
12. Каюров Ю. А. Проектирование баз данных. — Ижевск, 1994, 220 с.
13. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реали­
зация и сопровождение. Теория и практика. — 2-е изд.: Пер. с англ. —
М.: Издательский дом "Вильямс", 2001, 1120 с.
14. Малыхина М. П. Базы данных / Учеб, пособие. — Краснодар: Изд-во
КубГТУ, 1999, 143 с.

15. Мамаев Е., Шкарина Л. Microsoft SQL Server 2000 для профессиона­
лов. — СПб: Питер, 2001, 525 с.
16. Мейер Д. Теория реляционных баз данных. — М.: Мир, 1987, 608 с.
17. Озкарахан Э. Машины баз данных и управление базами данных. — М.:
Мир, 1989, 696 с.
18. Риккарди С. СУБД для ПК как средства работы с запросами. PC Maga­
zine, September 26, 1995, р. 239
19. Тихомиров Ю. В. Microsoft SQL Server 7.0. — СПб.: БХВ — СактПетербург, 1999, 720 с.
20. Ульман Дж. Основы систем баз данных. — М.: Финансы и статистика,
1983, 420 с.
21. Хансен Г., Хансен Д. Базы данных: разработка и управление. — М.: Би­
ном, 1999, 704 с.
22. Хомоненко А. Д., Цыганков В. М., Мальцев М. Г. Базы данных: Учеб­
ник для высших учебных заведений / Под ред. проф. А. Д. Хомоненко. —
СПб.: КОРОНА принт, 2000, 416 с.
23. Хоторн Р. Разработка баз данных, Microsoft SQL Server 2000: Пер. с англ. —
М.: Издательский дом "Вильямс", 2001, 720 с.
24. Шарон Б., Мэйбл Г. SQL Server 2000. Энциклопедия программиста. —
ДиаСофт, 2001, 789 с.
25. Справочная система Microsoft Access 2002.
26. Microsoft Access 2002 (приложение Office XP). Руководство пользователя.
27. Codd S. В. Codd С. Т. Salley. Providing OLAP (On-Line Analytical Process­
ing) to User-Analysts: An IT Mandate. — E.F.Codd & Associates, 1993.
28. Guide to OLAP Terminology. — Kenan Systems Corporation, 1995.
29. Омельченко Л. H., Шевякова Д. А. Самоучитель Visual FoxPro 9.0. —
СПб.: БХВ-Петербург, 2005, 608 с.
30. Лебедев А. И. Visual FoxPro 9.0. — М.: HT Пресс, 2005, 328 с.
31. Тимошок T. В. Microsoft Access 2003. Краткое руководство. — М.: Изда­
тельский дом "Вильямс", 2005, 320 с.
32. Мак-Федрис П. Формы, отчеты и запросы в Microsoft Access 2003.: Пер.
с англ. — М.: Издательский дом "Вильямс", 2005, 416 с.
33. Байдачный С., Маленко Д., Лозинский Ю. SQL Server 2005: Новые воз­
можности для разработчиков. — М.: СОЛОН-Пресс, 2006, 208 с.
34. Волоха А. В. Microsoft SQL Server 2005. Новые возможности. — СПб:
Питер, 2006, 304 с.

Сетевые ресурсы
http://www.csu.ac.ru/osp/os/1994/04/source/43.html
http://www.microsoft.com/rus/
http://www.firststeps.ru
http://www.sql.ru
http://www.nsvisual.com
http://referat.ru/document/2703
http://fortecya.com.ua/RLinux/osbd/glava~ 13(11,12,...) .html
http://www.osp.ru/os/2001/03/047.htm
http://inftech.webservis.ru/it/ii/ar4.html
http://aIpha.netis.ruAoi/db/ch_6_3.html
http://synthesis.ipi.ac.ru/synthesis/publications/odmg93Atml
http://www.cfin.ru
http://www.iso.ru/
http://www.iso.ru/journal/articles/184.html
http://www.iso.ru/journal/articles/archive/17
http://www.iso.ru/journal/articles/185.html
http://www.iso.ru/journal/articles/183.html
http://www.getinfo.ru/article237.html

Предметный указатель

с
C A S E -и н ст р у м е н т ы 75
C O D A S Y L 34

F, О, Q
F -зав и си м о ст ь 161
O L A P 393
Q B E 49, 131, 310

D
D D L 49
D M L49

Е

S
S Q L 28, 40, 131
встр о ен н ы й 303
SY STEM R 50

E R -д и а гр ам м а 22
E R -м о д е л ь 70, 109

A
А вто м ати зи р о в ан нал
и н ф о р м а ц и о н н а я си с т е м а 8
А грегат д ан н ы х 112
А грегатны е ф у н к ц и и 274, 279
А д м и н и стр ато р Б Д 19, 29
А д м и н и стр ато р ы д ан н ы х 28
А к си о м а вы вод а 163
А к ти в н ы е за п р о с ы д о б а в л е н и я
за п и с ей 326
А ктивн ы е зап р о сы о б н о в л ен и я 326
А к ти в н ы е за п р о с ы с о зд ан и я
т аб л и ц 324

А кти вн ы е зап р о сы уд ал ен и я 325
А н ом ал и я
в кл ю ч ен и я 155
м о д и ф и к ац и и 157
о б н о в л ен и я 155
уд ал ен и я 156
А п п ар атн о е о б есп еч ен и е 27
А рхитектура 59
А рхитектура трехуровневой
м одели 60
А трибут 81, 135
п о ст о р о н н и й 169
простой 82
составн ой 82
А трибуты об ъектов 80

Б
Б аза д ан н ы х 8, 13, 20
Б а н к д ан н ы х 8, 18
БД:
б езо п асн о сть 24
восстан ав л и в аем о сть 24
п р ед ел ьн ы е р азм ер ы
и эк с п л у а та ц и о н н ы е
о г р а н и ч е н и я 24
п р о е к ти р о в а н и е 24
ц ел о стн о сть 24
э ф ф е к т и в н о с т ь 24
Б у ф е р и за ц и я д ан н ы х 41

В
В ектор 113
В и три н ы д ан н ы х 404
В л ож ен н ы е зап р о сы 280
В л ож ен н ы е т р а н за к ц и и 375
В нутренн яя схема 34
В торая н о р м а л ь н а я ф о р м а 169
В тори ч н ы е ф а й л ы д ан н ы х 233
В ы ч и сл и тел ьн ая с и с т е м а 20

Г
Г ен ер ал и зац и я 95
Г л обал ьн ы е х р а н и л и щ а
д ан н ы х 401
Граф 122
Г р аф и к за п у с к а 346
п о сл ед о в ател ьн ы й 346
ч ер ед у ю щ и й ся 346
Г руп п и р у ю щ и й за п р о с 276

д
Д а н н ы е 7 ,’27
агр е ги р о в а н н ы е 417
и н те гр и р о в а н н ы е 20
и ст о р и ч е с к и е 417
о б щ и е 20

о п ер ат и в н ы е 419
п р о гн о зи р у ем ы е 418
Д е к л ар ати в н ы е я зы к и
м ан и п у л и р о в ан и я д ан н ы м и 48
Д е т е р м и н а н т 160
Д л и н н ы е т р а н за к ц и и 374
Д о м ен 136

Ж
Ж и зн е н н ы й ц и к л 66
Ж у рн ал 334
Ж у рн ал т р а н за к ц и й 334

3
З а в и си м ая часть 160
З а го л о в о к ст р ан и ц ы 213
Зад ачи об раб отки д ан н ы х 8
З а п и с ь 112
З ап рос:
*
м н о го стр о ч н ы й 304
м н о го таб л и ч н ы й 284
о д н о стр о ч н ы й 304

И
И зб ы то ч н о сть и н ф о р м а ц и и 21
И н в е р т и р о в а н н ы е с п и с к и 229
И н д ек с н еп л о т н ы й 224
И н д е к с н о -п р я м ы е ф ай л ы 222
И н д е к с н ы й ф а й л 221
И н ф о р м а ц и о н н а я си ст ем а 8, 20
И нф орм ация 7

К
К а р д и н ал ьн о е ч и сл о 137, 150
К аталог д ан н ы х 19
К атегори я 96
К атегорн ая ц ел о ст н о сть 148
К в ан то р всео б щ н о сти 256
К вантор' су щ ество ван и я 254
К л и ен т 53

К лю ч 83
ал ь те р н а ти в н ы й 84, 140
в н е ш н и й 140
вто р и ч н ы й 92
п ер в и ч н ы й 84, 140
п о т е н ц и а л ь н ы й 139
со ста в н о й 84, 140
К о л л и зи и 218
К о м п и л я т о р я зы к а о п р е д е л ен и я
д ан н ы х 44
К о н тр о л л ер :
б азы д ан н ы х 45
б уф ер а 45
во с с та н о в л е н и я 45
сл о в ар я 44
т р а н за к ц и й 45
ф ай л о в 45
К о н тр о л ь пр ав д о сту п а 45
К о н т р о л ь п р о и зв о д и те л ь н о с ти
си стем ы 78
К о н ц еп ту ал ь н ая м о дел ь базы
д ан н ы х 435
К о н ц еп ту ал ь н ая сх ем а 34
К о р о т к и е б л о к и р о в к и 375
К о р о т к и е т р а н за к ц и и 374
К о р п о р а т и в н ы е о гр а н и ч е н и я
ц ел о стн о сти 150
К ортеж 137
К ри тер и й о тбора 314
К урсо р 304

м
М етад ан н ы е 21
М н о го зн а ч н а я за в и с и м о с т ь 182
М н ож ество о то бр аж ен и й 137
М о д е л и р о в а н и е р а зм е р н о с т е й 410
М одель:
и ер а р х и ч е с к а я 122
сетевая 111
т е о р е т и к о -гр а ф о в а я 109
т ео р е т и к о -м н о ж е с т в е н н а я 110
М од ель д ан н ы х 108
М од ель т р а н за к ц и и 332

М о щ н о сть связей 86
М у л ьти х р ан и щ а д ан н ы х 402

н
Н абор 113
м н о го ч л ен н ы й 119
о д н о ч л ен н ы й 119
си н гу л я р н ы й 119
Н еп роц ед урн ы е я зы к и
м ан и п у л и р о ван и я д ан н ы м и 48
Н о р м ал и зац и я 154
Н о р м ал и зац и я о т н о ш ен и й 160
Н о р м ал ьн ая ф о р м а 160
Н о р м ал ьн ая ф о р м а
Б о й са — К одда 178
Н р м ал и зо в ан н ы й п л ан 356

О
О бсл уж и ваю щ и й п ерсо н ал 20
О бъект 21, 81
со ставн о й 85, 102
О бъект-ти п 81
О б ъ ектн ая м одель д ан н ы х 372
О б ъ ек т н о -о р и ен т и р о в ан н ая б аза
д ан н ы х 80
О гр ан и ч ен и е д о м е н а 147
О п р ед ел ен и е тр еб о в ан и й к
си стем е 68
О п ти м и зато р зап р о со в 45
О тн о ш ен и е:
базовое 139
и м ен о в ан н о е 139
п р о и зв о д н о е 139

п
П ар ал л ел ьн ы й доступ 41
П ервая норм ал ьн ая ф орм а 166
П ер ви ч н ы е ф ай л ы д ан н ы х 232
П л ан и р о в ан и е разр аб о тк и базы
д ан н ы х 67
П л а н и р о в щ и к 45
П л о тн ы й и н д ек с 222

П о д кл асс 93
П о д ъ я зы к и д ан н ы х 45
П о к а за т е л ь к а р д и н ал ь н о с ти 87
П о л е д ан н ы х 121
П о л н а я д е к о м п о зи ц и я
о т н о ш е н и я 176
П ол ьзо в ател и 30
П ол я за п и с е й 11
П р ед м етн ая о б ласть 8
П р ед став л ен и е 139
П р еп р о ц ес с о р я зы к а
м а н и п у л и р о в а н и я д а н н ы м и 44
П р и к л а д н ы е п р о гр а м м и с т ы 30
П р и к л а д н ы е п р о гр ам м ы 28
П рилож ен ия 9
внеш ние 9
СУБД 9
П р о гр а м м н о е о б ес п е ч е н и е 13, 28
П р о д о л ж и тел ь н ы е
б л о к и р о в к и 375
П роектирован ие таблиц
р азм е р н о с т е й 414
П р о е к т и р о в а н и е таб л и ц ы
ф ак т о в 412
П роцедурны е язы ки
м анипулирования д ан н ы м и 48
П р о ц е с с о р за п р о с о в 44
П р о ц е с с о р к о м а н д 45
П я тая н о р м а л ь н а я ф о р м а 184

Р
Р азр аб о тч и к и :
б аз д ан н ы х 29
л о ги ч ес к о й б азы д ан н ы х 29
ф и зи ч е с к о й б азы д ан н ы х 29
Р ед у ц и р о в ан н ая ф у н к ц и о н а л ь н а я
за в и с и м о с т ь 169
Результат за п р о с а 139
Р ек у р си в н ая с в я зь 89
Р е л я ц и о н н а я ал геб р а 236
Р е л я ц и о н н а я м одель
д ан н ы х К о д да 15
Р е л я ц и о н н о е и с ч и с л е н и е 236, 248
Р азр е ш ен и е с с ы л о к 355

С
С б ал ан си р о в ан н ы е д ер евья 226
С бои:
ж ест к и е 40
м ягки е 40
С в я зь 22
С ел ек ц и я 120
С ервер 53
С ер вер ы б аз д ан н ы х 17, 61
С ериализац ия параллельно
вы полняю щ ихся тран закц и й 340
С е р и ал ьн ы й п л ан в ы п о л н е н и я
см еси т р а н за к ц и й 340
С етевая м одел ь д ан н ы х 115
С и н о н и м ы 218
С и стем а у п р ав л ен и я б азам и
д ан н ы х 8
С л о вар ь д ан н ы х 19, 40
С л оты 214
С н и м к и 139
С п ец и ал и зац и я 94
С п и с к и 118
С ред ства к о н тр о л я ц ел о ст н о сти 45
С т еп ен ь д р о б л ен и я
б л о к и р о в о к 348
С т еп ен ь о т н о ш ен и я 137, 150
С т р а н и ц а д ан н ы х 213
С т р ан и ц ы Blob 213
С т р ан и ц ы д ан н ы х 213
С т р ан и ц ы п е р е п о л н ен и я 215
С У Б Д 13, 25
об щ его н а зн а ч е н и я 25
сп ец и ал и зи р о в ан н ы е си стем ы 25
С у п ер к л асс 93
С у п ер к л ю ч и 139
С у щ н о сть 21
С хем а о тн о ш ен и я 135

т
Т ел о о т н о ш ен и я 137
Т ести р о ван и е:
восходящ ее 77
и н т е н си в н о е 77
н и сх о д я щ ее 77
п о т о к о в 77

Т ип :
за п и с е й 113
н аб о р а 113
о б ъ екто в 80
св я зей 80
с егм ен та 121
Т р а н за к ц и я 39, 73, 331
и зв л е ч е н и я 73
о б н о в л е н и я 73
с м е ш а н н а я 74
Т р етья н о р м а л ь н а я ф о р м а 173
Т ри ггер 57, 351
уд ал ен и я 353

У
У даленное уп р авл ен и е д ан н ы м и 55

Ф
Ф ай л ы ж у р н ал о в т р а н за к ц и й 233
Ф и зи ч е с к а я м о дел ь д ан н ы х ПО
Ф и н а н с о в ы е х р а н и л и щ а д ан н ы х
399
Ф ункции:
ввода и о то бр аж ен и я д ан н ы х 54
обработки д ан н ы х 54
п р и к л а д н ы е 54
сл у ж еб н ы е 54
управления и н ф орм аци онны м и
р есу р сам и 54

X
Х еш и р о в а н и е 218
Х еш -п о л е 218
Х е ш -ф у н к ц и я 219
Х р а н и л и щ а д ан н ы х 394, 395
в об ласти с т р ах о в ан и я 399
в об ласти
т е л е к о м м у н и к а ц и й 400

д л я у п р авл ен и я л ю д ск и м и
ресурсам и 400
на о сн ове техн ол оги и D ata
M ining и E xploration 401
Х р ан и м о е о т н о ш ен и е 139
Х р ан и м ы е п роц едуры 355
п о л ьзо вател ьски е 355
с и стем н ы е 355

ц
Ц елостн ость:
д ан н ы х 42
н а уровн е сс ы л о к 148

ч
Ч а н к 213
Ч етвертая н о р м ал ьн ая ф о р м а 181

э
Э к зем п л я р об ъ екта 137
Э к ст ен т 213
Э кстен ты :
о д н о р о д н ы е 232
с м еш ан н ы е 232
Э л ем ен т д ан н ы х 112
Э л ем ен т д о м е н а 136

Я
Я дро С У Б Д 44
Я зы к:
зап р о со в 49
м ан и п у л и р о в ан и я
д ан н ы м и 46, 47, 131
об ъ ектн ы х зап р о со в 371
о п р ед ел ен и я д ан н ы х 46
о п р ед ел ен и я о б ъ ектов 371
у п р авл ен и я д ан н ы м и 26