Text
                    DATABASE PROCESSING
Eighth Edition
David M. Kroenke
PH PTR
Prentice Hall PTR Upper Saddle River, New Jersey 07458 www.phptr.com
КЛАССИКА COmPUTEA SCIENCE
Д. КРЁНКЕ
ТЕОРИЯ И ПРАКТИКА ПОСТРОЕНИЯ
БАЗ ДАННЫХ
8-е ИЗДАНИЕ
СОЛИТЕР
Москва  Санкт-Петербург  Нижний Новгород • Воронеж Ростов-на-Дону  Екатеринбург  Самара.
Киев  Харьков  Минск
2003
ББК 32.973.233я7
УДК 681.31.016(075)
К79
К79 Теория и практика построения баз данных. 8-е изд. / Д. Крёнке. — СПб.:
Питер, 2003. — 800 с.: ил. — (Серия «Классика computer science»).
ISBN 5-94723-275-8
В книге, написанной в форме учебного пособия для студентов, специализирующихся в области информационных технологий, освещается широкий круг теоретических и практических вопросов, связанных с разработкой и использованием баз данных.
К особенностям восьмого издания книги относится, в частности, появление материала, посвященного новым технологиям публикации баз данных (XML) и обработки баз данных масштаба предприятия (ODBC, ASP, JDBC, JSP).
Книгу отличает продуманность структуры, живой и доступный язык изложения, а также большое количество примеров, моделирующих типичные ситуации из практики делового мира
ББК 32.973.233Я7
УДК 681.31.016(075)
Информация, содержащаяся в данной книге, получена из источников, рассматриваемых издательством как надежные. Тем не менее, имея в виду возможные человеческие или технические ошибки, издательство не может гарантировать абсолютную точность и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги.
©2002, 2000, 1998, 1995 and 1992 by Pearsen Education, Inc.
ISBN 0-13-064839-6 (англ.)	© Перевод на русский язык, ЗАО Издательский дом «Питер», 2003
ISBN 5-94723-275-8	© Издание на русском языке, оформление, ЗАО Издательский дом «Питер», 2003
Краткое содержание
Предисловие.....................................................18
Часть I. Введение
Глава 1. Введение в базы данных.................................24
Глава 2. Введение в разработку баз данных.......................52
Часть II. Моделирование данных
Глава 3. Модель «сущность—связь» ...............................82
Глава 4. Семантическая объектная модель........................118
Часть III. Проектирование баз данных
Глава 5. Реляционная модель и нормализация.....................166
Глава 6. Проектирование баз данных в рамках модели «сущность—связь» . . 206
Глава 7. Проектирование баз данных в рамках семантической объектной модели ..............................................245
Часть IV. Построение реляционных баз данных
Глава 8. Основы построения реляционных баз данных..............274
Глава 9. Язык SQL..............................................304
Глава 10. Проектирование приложений баз данных.................330
Часть У. Обработка многопользовательских баз данных
Глава 11. Многопользовательские базы данных....................378
Глава 12. Работа с базами данных в Oracle......................422
Глава 13. Работа с базами данных в SQL Server 2000 ........... 467
Часть VI. Обработка организационных баз данных_____________________
Глава 14. Сети, многоуровневые архитектуры и XML...............516
Глава 15. ODBC, OLE DB, ADO и ASP..............................559
Глава 16. JDBC, Java Server Pages и MySQL......................606
Глава 17. Совместное использование данных предприятия .........645
Часть VII. Работа с объектно-ориентированными базами данных________
Глава 18. Объектно-ориентированные базы данных.................692
Приложение А. Структуры данных.................................729
Приложение Б. Создание семантических объектных моделей в программе Tabledesigner......................................756
Алфавитный указатель ..........................................785
Содержание
Предисловие........................................................18
Особенности настоящего издания.....................................19
Последовательный обзор глав книги..................................20
Благодарности .................................................... 21
От издательства....................................................22
Часть I. Введение
Глава 1. Введение в базы данных....................................24
Четыре примера применения баз данных...............................24
Малярная фирма Мэри Ричардс......................................25
Бюро проката музыкальных инструментов Treble Clef Music..........28
Бюро лицензирования и регистрации................................30
Туристический информационный центр ..............................30
Сравнение четырех типов баз данных ..............................32
Отношения между прикладными программами и СУБД.....................33
Системы обработки файлов ..........................................35
Разделенные и изолированные данные...............................35
Дублирование данных .............................................36
Зависимость прикладных программ от форматов файлов...............36
Несовместимость файлов...........................................37
Трудность представления данных в удобном для пользователя виде...37
Системы обработки баз данных .	 37
Данные интегрированы.............................................38
Меньшее количество дублирующихся данных..........................38
Независимость программ от данных.................................38
Представление данных в удобном для пользователя виде.............38
Определение термина «база данных»..................................39
Самодокументированность..........................................39
База данных — это собрание интегрированных записей...............39
База данных является моделью модели .............................40
История баз данных.................................................41
Организационный контекст.........................................41
Реляционная модель ............................................. 42
Коммерческие СУБД для микрокомпьютеров...........................43
Содержание
7
Клиент-серверные приложения баз данных .........................44
Базы данных с использованием интернет-технологий...............45
Распределенные базы данных......................................46
Объектно-ориентированные СУБД..................................47
Резюме.............................................................47
Вопросы группы I...................................................49
Проекты ...........................................................50
Вопросы к проекту FiredUp.........................................50
Глава 2. Введение в разработку баз данных ........................52
База данных.......................................................52
Данные пользователя.............................................52
Метаданные......................................................54
Индексы.........................................................55
Метаданные приложений...........................................57
СУБД...............................................................57
Подсистема средств проектирования...............................57
Подсистема обработки............................................58
Ядро СУБД.......................................................58
Создание базы данных...............................................59
Пример схемы базы данных .......................................59
Создание таблиц.................................................61
Определение связей..............................................61
Компоненты приложения..............................................63
Формы ..........................................................63
Запросы.........................................................66
Отчеты .........................................................68
Меню............................................................69
Прикладные программы ...........................................70
Процесс разработки базы данных.....................................72
Общие стратегии................................................72
Моделирование данных...........................................73
Резюме............................................................76
Вопросы I группы..................................................77
Вопросы II группы.................................................78
Вопросы к проекту FiredUp.........................................79
Часть 11. Моделирование данных
Глава 3. Модель «сущность—связь»..................................82
Элементы модели «сущность—связь» .................................82
Сущности.......................................................82
Атрибуты.......................................................83
Идентификаторы.................................................84
8
Содержание
Связи............................................................84
Подтипы сущностей................................................92
Пример ER-диаграммы..............................................94
Документирование делового регламента.............................95
Модель «сущность—связь» и CASE-средства..........................96
Диаграммы «сущность—связь» в стиле UML..............................96
Сущности и связи в UML..........................................97
Конструкции ООП, введенные языком UML............................99
Роль UML в базах данных на сегодняшний день.....................101
Примеры ...........................................................102
Пример 1: танцевальный клуб Джефферсона.........................102
Пример 2: бюро проката парусных яхт Сан-Хуана...................107
Базы данных как модели моделей.....................................110
Резюме.............................................................111
Вопросы группы I...................................................112
Вопросы группы II..................................................114
Проекты............................................................114
Вопросы к проекту Firedllp ........................................116
Глава 4. Семантическая объектная модель............................118
Семантические объекты..............................................119
Определение семантических объектов..............................119
Атрибуты........................................................120
Объектные идентификаторы........................................124
Домены атрибутов................................................125
Представления семантических объектов ...........................125
Создание семантических объектных моделей данных....................127
Пример: база данных администрации университета Highline.........127
Спецификация объектов...........................................133
Типы объектов......................................................137
Простые объекты ................................................138
Композитные объекты.............................................138
Составные объекты...............................................141
Гибридные объекты...............................................144
Ассоциативные объекты...........................................148
Объекты вида родитель/подтип....................................151
Объекты вида архетип/версия.....................................154
Сравнение семантической объектной модели и модели «сущность—связь». . . 156
Резюме.............................................................159
Вопросы группы I...................................................160
Вопросы группы II..................................................162
Проекты............................................................162
Вопросы к проекту Firedllp ........................................163
Содержание
9
Часть 111. Проектирование баз данных Глава 5. Реляционная модель и	нормализация...............166
Реляционная модель ...............................................166
Функциональные зависимости.....................................168
Ключи..........................................................169
Функциональные зависимости, ключи и	уникальность...............171
Нормализация......................................................172
' Аномалии модификации............................................172
Суть нормализации..............................................174
;	Классы отношений...............................................175
Нормальные формы от первой до пятой...............................176
<	Вторая нормальная форма (2НФ)..................................176
,	Третья нормальная форма (ЗНФ)..................................177
ч	Нормальная форма Бойса-Кодда (НФБК)............................178
ч Четвертая нормальная форма (4НФ) ...............................180
Пятая нормальная форма (5НФ)...................................183
Доменно-ключевая нормальная форма (ДКНФ)..........................183
Определение ...................................................184
Первый пример доменно-ключевой нормальной формы ...............185
Второй пример доменно-ключевой нормальной формы................186
Третий пример доменно-ключевой нормальной формы................188
Синтез отношений..................................................190
Атрибутивная связь «один к одному» ............................191
Атрибутивная связь «многие к одному»...........................193
Атрибутивная связь «многие ко многим» .........................194
Многозначные зависимости: часть вторая.........................195
Оптимизация.......................................................196
Денормализация ............................................... 196
Преднамеренная избыточность....................................198
Резюме............................................................199
Вопросы I группы..................................................200
Вопросы II группы.................................................202
Вопросы к проекту Firedllp .......................................204
Глава 6. Проектирование баз данных в рамках модели «сущность—связь............................................206
Преобразование моделей «сущность—связь» в реляционные конструкции . . . 206
Представление сущностей с помощью реляционной модели...........206
Представление связей типа «ИМЕЕТ»..............................211
Представление тернарных связей и связей высших порядков .......221
Представление связей типа «ЕСТЬ» (подтипов)....................225
Пример проекта....................................................226
Деревья, сети и списки материалов.................................228
Деревья........................................................229
Простые сети ..................................................231
10
Содержание
Сложные сети....................................................231
Списки материалов...............................................232
Суррогатные ключи...............................................234
Пустые значения.................................................238
Резюме............................................................239
Вопросы I группы..................................................240
Вопросы II группы...............................................  243
Проекты...........................................................243
Вопросы к проекту Firedllp .......................................243
Глава 7. Проектирование баз данных в рамках семантической объектной	модели..................245
Преобразования семантических объектов в реляционные конструкции...245
Простые объекты ................................................245
Композитные объекты.............................................246
Составные объекты...............................................249
Представление составных объектов	со связью 1:1 ............. 249
Представление связей «один ко	многим» и «многие к одному».......250
Представление связей «многие	ко многим»................252
Гибридные объекты...............................................253
Ассоциативные объекты...........................................257
Объекты вида родитель/подтип................................... 258
Объекты вида архетип/версия.....................................261
Примеры объектов .................................................262
Подписной абонемент.............................................263
Описание продукта ..............................................264
Акт о нарушении правил дорожного движения ......................266
Резюме............................................................268
Вопросы I группы..................................................269
Вопросы II группы.................................................270
Проекты...........................................................272
Вопросы к проекту Firedllp .......................................272
Часть IV. Построение реляционных баз данных
Глава 8. Основы построения реляционных баз данных . . 274
Описание реляционных данных......................................274
Обзор терминологии ............................................274
Реализация реляционной базы данных............................ 277
Манипулирование реляционными данными............................ 281
Категории языков манипулирования реляционными данными .........281
Интерфейсы языков манипулирования данными .....................283
Реляционная алгебра..............................................287
Реляционные операторы..........................................287
Выражение запросов в терминах реляционной алгебры .............295
Содержание
11
Резюме.............................................................300
Вопросы I группы...................................................301
Глава 9. Язык SQL..................................................304
Запрос одиночной таблицы...........................................305
Проектирование в SQL............................................307
Выборка в SQL...................................................308
Сортировка .....................................................311
Встроенные функции SQL..........................................312
Встроенные функции и группировка................................313
^Запрос нескольких таблиц..........................................315
Вложенные запросы...............................................315
Соединение с помощью SQL .......................................317
Сравнение вложенного запроса и соединения ......................319
Внешнее соединение..............................................320
Операторы EXISTS и NOT EXISTS .....................................321
Изменение данных ..................................................323
Вставка данных..................................................323
Удаление данных ................................................324
Модификация данных..............................................324
Резюме ............................................................325
Вопросы I группы...................................................325
Вопросы II группы..................................................328
Вопросы к проекту FiredUp .........................................328
Глава 10. Проектирование приложений баз данных . . . 330
Функции приложения базы данных.....................................330
Пример приложения: галерея View Ridge..............................332
Требования к приложению.........................................332
Проектирование базы данных......................................333
Создание, чтение, обновление и удаление экземпляров представлений .... 336
Чтение экземпляров представлений................................338
Создание новых экземпляров представлений........................339
Обновление экземпляров представлений............................342
Удаление экземпляров представлений..............................343
Проектирование форм................................................344
Структура формы должна отражать структуру представления.........345
Семантика данных должна быть графически очевидна................346
Структура формы должна побуждать к правильным действиям.........347
Формы в среде графического интерфейса пользователя..............348
Передвижение курсора и единообразная семантика клавиш...........351
Проектирование отчетов ............................................352
Структура отчета................................................352
Подразумеваемые объекты.........................................354
Реализация ограничений.............................................356
Ограничения доменов.............................................357
12
Содержание
Ограничения уникальности ......................................359
Ограничения связей.............................................359
Ограничения делового регламента................................366
Безопасность и контроль...........................................366
Безопасность ................................................. 367
Контроль.......................................................368
Логика приложения................................................ 370
Резюме............................................................370
Вопросы I группы..................................................372
Вопросы II группы.................................................374
Проекты...........................................................375
Вопросы к проекту Firedllp ...................................... 375
Часть У. Обработка многопользовательских баз данных
Глава 11. Многопользовательские базы данных .... 378
Администрирование баз данных......................................379
Управление структурой базы данных..............................380
Управление параллельной обработкой................................382
Необходимость в атомарных транзакциях..........................382
Блокировка ресурсов............................................387
Оптимистическая и пессимистическая блокировка..................390
Объявление характеристик блокировки............................393
Согласованные транзакции ......................................394
Уровень изоляции транзакции....................................395
Безопасность базы данных..........................................398
Права и обязанности по обработке...............................399
Обеспечение безопасности средствами СУБД.......................400
Обеспечение безопасности средствами приложения.................406
Восстановление базы данных........................................407
Восстановление путем повторной обработки.......................408
Восстановление через откат-накат...............................409
Управление СУБД...................................................412
Поддержание репозитория данных....................................413
Резюме............................................................415
Вопросы I группы..................................................417
Вопросы II группы.................................................419
Проекты...........................................................420
Вопросы к проекту FiredUp ........................................420
Глава 12. Работа с базами данных в Oracle.........................422
Установка Oracle................................................. 423
Создание базы данных Oracle.......................................423
Работа с SQL Plus..............................................424
Создание таблиц ...............................................428
Создание связей................................................433
Содержание
13
Создание индексов................................................435
Изменение структуры таблицы .................................... 435
Контрольные ограничения..........................................436
Использование оператора ALTER TABLE с контрольными ограничениями . . 437
Представления....................................................437
Логика приложения...................................................440
Обработка файлов PL/SQL..........................................440
Хранимые процедуры...............................................440
Триггеры.........................................................448
Словарьданных ..................................................... 452
Управление параллельной обработкой..................................453
Уровень изоляции «завершенное чтение»............................455
Уровень изоляции «сериализуемость»...............................455
Уровень изоляции «только чтение» ................................456
Дополнительные замечания о блокировках.........................  456
Oracle и безопасность...............................................457
Резервное копирование и восстановление в Oracle...................  457
Средства восстановления Oracle...................................457
Типы сбоев ......................................................458
Вопросы, незатронутые в данной главе................................460
Резюме..............................................................460
Вопросы I группы....................................................462
Проекты.............................................................465
Вопросы к проекту FiredUp ..........................................465
Глава 13. Работа с базами данных в SQL Server 2000 . . 467
Установка SQLServer 2000........................................... 467
Создание базы данных SQL Server.....................................468
Создание таблиц .................................................469
Определение связей...............................................479
Представления....................................................482
Индексы..........................................................485
Логика приложения...................................................486
Хранимые запросы ................................................487
Хранимые процедуры...............................................488
Триггеры.........................................................495
Управление параллельной обработкой..................................499
Уровень изоляции транзакции......................................500
Поведение курсора................................................501
Блокировочные подсказки..........................................502
Безопасность....................................................... 503
Резервное копирование и восстановление..............................503
Типы резервных копий.............................................504
Модели восстановления SQL Server.................................505
Восстановление базы данных.......................................506
План обслуживания базы данных....................................507
14
Содержание
Вопросы, не затронутые в этой главе...............................507
Резюме............................................................508
Вопросы I группы..................................................510
Проекты...........................................................512
Вопросы к проекту Firedllp .......................................513
Часть VI. Обработка организационных баз данных
Глава 14. Сети, многоуровневые архитектуры и XML . . 516
Разновидности сетевого окружения..................................516
Интернет....................................................... 516
Интрасети.......................................................517
Беспроводной доступ в сети......................................518
Многоуровневая архитектура........................................519
Web-сервер под управлением Windows 2000 ....................... 522
Web-сервер под управлением Unix и Linux ........................523
Многоуровневая обработка........................................524
Языки разметки и DHTML............................................526
Стандарты языков разметки.......................................526
Проблемы, связанные с HTML......................................527
DHTML...........................................................528
XML —расширяемый язык разметки ...................................530
XML как язык разметки ..........................................530
XML-документ и DTD..............................................531
Материализация ХМL-документов...................................533
Терминология и стандарты XML....................................538
XML Schema......................................................540
Протокол WAP....................................................548
Значение XML для приложений баз данных..........................549
Пример применения XML в электронной коммерции...................552
Поддержка XML в Oracle и SQL Server.............................553
Резюме............................................................554
Вопросы I группы..................................................556
Вопросы II группы.................................................557
Вопросы к проекту FiredUp ........................................558
Глава 15. ODBC, OLE DB, ADO и ASP ................................559
Окружение web-сервера.............................................559
Стандарт ODBC.....................................................563
Архитектура ODBC................................................563
Уровни соответствия.............................................565
Задание имени источника данных ODBC ............................567
OLE DB ...........................................................568
Цели создания OLE DB ...........................................571
Основные конструкции OLE DB.....................................572
Содержание
15
ADO.................................................................574
Вызов ADO из ASP-страниц.........................................574
Объектная модель ADO.............................................575
Примеры использования ADO...........................................580
Пример 1 — чтение таблицы .......................................581
Пример 2 — чтение таблицы обобщенным способом....................584
Пример 3 — чтение любой таблицы..................................586
Пример 4 — обновление таблицы....................................591
Пример 5 — вызов хранимой процедуры............................. 595
Резюме..............................................................601
Вопросы I группы................................................... 602
Вопросы II группы...................................................604
Вопросы к проекту Firedllp .........................................605
Глава 16. JDBC, Java Server Pages и MySQL...........................606
JDBC................................................................606
Типы драйверов...................................................607
Использование JDBC...............................................608
Примеры использования JDBC . . . ................................611
Java Server Pages...................................................618
JSP-страницы и сервлеты..........................................618
Apache Tomcat....................................................619
Настройка Tomcat для обработки JSP...............................619
Примеры JSP-страниц..............................................620
MySQL...............................................................632
£	Ограничения MySQL................................................633
;	Работа с MySQL...................................................634
-	Настройка разрешений на доступ для JDBC..........................636
Управление параллельной обработкой ..............................637
Резервное копирование и восстановление...........................639
Заключительное слово о MySQL.....................................639
Резюме..............................................................639
Вопросы I группы....................................................641
Вопросы II группы...................................................643
Проекты.............................................................643
Вопросы к проекту Firedllp .........................................644
Глава 17. Совместное использование данных предприятия..................................................645
Архитектуры организационных систем обработки данных.................645
Системы удаленной обработки......................................646
Клиент-серверные системы.........................................647
Системы совместного использования файлов.........................648
Системы обработки распределенных баз данных......................650
Загрузка данных.....................................................655
Компания Universal Equipment.....................................655
16
Содержание
Процесс загрузки.............................................657
Потенциальные проблемы при обработке загруженных баз данных..658
Оперативная аналитическая обработка данных (OLAP)...............660
Информационные хранилища........................................669
Компоненты информационного хранилища.........................670
Требования к информационному хранилищу.......................671
Проблемы разработки и эксплуатации информационных хранилищ .... 672
Информационные лавки.........................................677
Администрирование данных........................................678
Потребность в администрировании данных.......................679
Проблемы администрирования данных............................679
Задачи отдела администрирования данных.......................681
Резюме..........................................................684
Вопросы I группы................................................687
Вопросы II группы...............................................690
Часть VII. Работа с объектно-ориентированными базами данных
Глава 18. Объектно-ориентированные базы данных . . . 692
Введение в объектно-ориентированное программирование ...........693
Терминология ООП ............................................693
Пример ООП......................................................695
Постоянное хранение объектов....................................699
Постоянное хранение объектов в традиционной файловой системе .... 701
Постоянное хранение объектов с помощью СУБД..................701
Постоянное хранение объектов с использованием ООСУБД ........703
Постоянное хранение объектов в Oracle...........................704
Типы объектов и коллекции....................................705
Объекты Oracle ..............................................710
Стандарты ООСУБД................................................714
SQL3.........................................................714
ODMG-93 .................................................... 721
Резюме..........................................................725
Вопросы I группы................................................726
Вопросы II группы...............................................728
Приложение А. Структуры данных..................................729
Плоские файлы...................................................729
Обработка плоских файлов в различном порядке.................729
Замечание по поводу адресации записей........................730
Упорядочение с помощью связных списков.......................731
Упорядочение с помощью индексов..............................734
Бинарные деревья.............................................735
Резюме по структурам данных..................................737
Представление бинарных связей...................................738
Обзор видов связей между записями............................738
Содержание
17
Представление деревьев ................................................740
Представление простых сетей............................................743
Представление сложных сетей ...........................................745
Представление вторичных ключей............................................748
Представление вторичных ключей с помощью связных списков ..............749
Представление вторичных ключей с помощью индексов......................750
Резюме..........................................................753
Вопросы I группы................................................754
Вопросы II группы...............................................755
Приложение Б. Создание семантических объектных моделей в программе Tabledesigner.........................................756
Создание семантической объектной модели.........................758
Реконструкция семантической объектной модели по имеющейся базе данных .	. 766
Публикация базы данных в Web....................................775
Следующие шаги..................................................783
Упражнения......................................................783
Алфавитный указатель......................................................785
Предисловие
По словам Алена Гринспена (Alan Greenspan), главы Федеральной резервной системы США, внедрение информационных технологий сделало возможным беспрецедентный прирост эффективности в экономике. Хотя главная заслуга в этом традиционно приписывается сети Интернет, жизненно важную роль за кулисами процесса играют технологии баз данных. В конце концов, Интернет — всего лишь коммуникационная система; значительная часть его ценности определяется информацией и данными, передаваемыми от базы данных к пользователю и в обратном направлении.
Новости о происходящих то и дело банкротствах в электронном бизнесе могут заставить студентов задуматься о том, не снизится ли в связи с этим ценность упомянутых технологий. Однако нет ничего более далекого от истины, чем подобное предположение. Лу Гестнер (Lou Gestner), глава корпорации IBM, несколько лет назад высказал идею, что реальная выгода от использования Интернета и связанных с этим технологий появится только после того, как эти технологии возьмет на вооружение традиционная, корпоративная Америка — предприятия так называемой «старой» экономики. Главные перспективы для технологий баз данных (и для будущих специалистов в этой области) лежат в применении этих технологий во всех сферах бизнеса и разновидностях экономической деятельности.
Все вышесказанное означает, что нет более подходящего момента для изучения теории баз данных, чем теперь. От персональных баз данных, хранящихся на настольных компьютерах, до больших баз данных для многих организаций, разбросанных по всему миру по множеству компьютеров, — важность всех видов баз данных в качестве экономических активов непрерывно растет. Маркетинг, торговля, производство, финансы, бухгалтерский учет, менеджмент и, разумеется, все экономические дисциплины используют базы данных для повышения эффективности соответствующих видов деятельности.
Далее, после бурного всплеска развития новых технологий и видов продукции, произошедшего в последние годы, стали ясны ключевые элементы успешного управления базой данных в современных условиях. Знание концепций моделирования данных и принципов организации баз данных по-прежнему является определяющим фактором; в той же мере, что и ранее, сохраняют свою важность реляционная модель и SQL. Возросло значение администрирования баз данных, и особенно технологий, поддерживающих управление многопользовательскими базами данных, поскольку все базы данных, где применяются новые технологии, являются многопользовательскими.
Особенности настоящего издания
19
Что касается публикации баз данных, то победителями в конкурентной борьбе между разнообразными технологиями оказались технологии web-публикации, в частности, трехуровневая и многоуровневая архитектуры, XML, ASP (Active Server Pages) и JSP (Java Server Pages). В сочетании с ними свое значение сохраняют и ODBC с OLE DB, и JDBC.
Говоря коротко, технология баз данных оказывается сегодня важной как никогда, и основные технологии, которые необходимо осваивать в этой связи, стали яснее, чем когда бы то ни было за последние пять лет.
Особенности настоящего издания
В соответствии со сделанными выше замечаниями, вторая половина книги была полностью переписана. Почти весь материал в главах с И по 16 является новым. Основные задачи администрирования баз данных рассмотрены в главе 11, а затем проиллюстрированы для Oracle в главе 12 и для SQL Server в главе 13. В главе 14 приведен обзор основных технологий публикаций баз данных в Web, после чего в главе 15 дана иллюстрация этих технологий для ODBC, OLE DB, IIS и ASP, а в главе 16 — для JDBC, JSP и MySQL. Глава 17 содержит информацию по поводу OLAP, а глава 18 знакомит читателя с новыми объектно-реляционными конструкциями в Oracle.
Рассмотреть все эти темы в течение одного семестра представляется затруднительным, и, по моему мнению, следует серьезно подумать о том, чтобы посвятить курсу теории баз данных целый год. Между тем, если у вас есть только один семестр и времени не хватает, это издание подготовлено с тем расчетом, чтобы позволить выбрать один из трех наборов альтернативных технологий.
В частности, в книге дается описание двух моделей данных: модели «сущность-связь» и модели семантических объектов. Если времени мало, стоит изучить первую из них как намного более популярную. Аналогичным образом, для изучения многопользовательских баз данных можете выбрать либо Oracle (глава 12), либо SQL Server (глава 13) — все зависит от того, что требуется от молодых специалистов в вашем регионе. Наконец, касаясь вопросов веб-публикации, если ваш курс ограничен по времени, выберите либо IIS, ASP и ODBC (глава 15), либо Java, JDBC и JSP (глава 16). Последовательность изложения пи в коей мере не пострадает, если вы выберете один вариант в каждой из трех предлагаемых пар. Разумеется, если время не является для вас проблемой, стоит уделить внимание всем перечисленным темам.
Концепция	Вариант 1	Вариант 2
Моделирование данных	Модель “Сущность—связь»	Модель семантических объектов
	Главы 3 и 6	Главы 4 и 7
Многопользовательские	Oracle	SQL Server
СУБД	Глава 13	Глава 14
web-публикация	IIS, ASP, ODBC	Java, JDBC, JSP
	Глава 15	Глава 16
20
Предисловие
В это издание включены также новые серии упражнений, которые можно найти в конце каждой главы. Речь в них идет о небольшой компании, занимающейся продвижением, продажей, производством и обслуживанием походных горелок. Цель этих упражнений — дать студентам возможность применить знания, почерпнутые из каждой главы, для решения небольшой реальной задачи, требующей, однако, известного напряжения.
Последовательный обзор глав книги
Настоящий текст состоит из семи частей. Часть I представляет собой введение в теорию баз данных. В главе 1 приводятся примеры использования баз данных, вводятся основные термины и кратко излагается история вопроса. В главе 2 описывается процесс разработки простой базы данных и приложения с использованием Microsoft Access 2002.
Во второй части книги рассматриваются вопросы моделирования данных. Глава 3 знакомит читателя с моделью «сущность—связь» и демонстрирует, каким образом эта модель была интегрирована с UML — унифицированным языком моделирования. В главе 4 описывается модель семантических объектов — альтернативный модели «сущность—связь» способ моделирования данных. Принципам организации баз данных посвящена часть III. В главе 5 рассматривается реляционная модель и нормализация. Далее в главе 6 с помощью идей, развитых в главах 3 и 5, модели «сущность—связь» трансформируются в конкретные варианты организации реляционной базы данных. В главе 7 описывается процесс преобразования моделей семантических объектов в конкретные структуры реляционных баз данных, для чего используются идеи, изложенные в главах 4 и 5.
Следующая часть книги посвящена основам реализации баз данных. Глава 8 является обзорной, в главе 9 описывается процедурный язык SQL, а в главе 10 рассматриваются структура и функции приложений реляционных баз данных. Часть V посвящена управлению многопользовательской базой данных. В главе 11 рассматривается администрирование баз данных и обсуждаются важнейшие вопросы функционирования многопользовательских баз данных, включая управление конкуренцией, безопасность, резервное копирование и восстановление. Идеи, изложенные в главе И, иллюстрируются затем для Oracle в главе 12 и для SQL Server в главе 13. Помимо того, глава 12 демонстрирует использование SQL для определения данных.
Вопросам публикации баз данных в Web посвящена часть VI. В главе 14 излагаются основы сетевой обработки, многоуровневая архитектура и XML. В главе 15 описывается практическое применение этих концепций на базе технологии Microsoft с использованием ODBC, OLE, IIS и ASP. В главе 16 также реализуются идеи главы 14, но уже на базе Java, для чего используется JDBC, JSP и MySQL. Обсуждаемые концепции иллюстрируются примером с использованием Linux и Apache Tomcat. Глава 17 обращается к проблемам администрирования данных и знакомит читателя с технологией OLAP.
Благодарности
21
Часть VII состоит всего из одной главы, которая посвящена работе с объектно-ориентированными базами данных. Новым в этой главе является описание объектно-реляционных возможностей Oracle. Приложение А содержит краткий обзор структур данных, а приложение Б демонстрирует использование программы Tabledesigner — средства, позволяющего разрабатывать модели семантических объектов и преобразовывать их в реальные структуры баз данных и ASP-страницы.
Благодарности
Серьезными изменениями, которые претерпела вторая половина настоящего издания, я обязан конструктивным и полезным дискуссиям с моим редактором, Бобом Хораном (Bob Horan), а также исключительно ценным и вдумчивым отзывам, поступившим от следующих людей:
4 Джек Беккер (Jack Becker), Университет Северного Техаса
* 4 Уильям Д. Берг (William D. Burg), Университет Алабамы в Бирмингеме
'	4 Бхушан Капур (Bhushan Kapoor), Калифорнийский государственный уни-
верситет — Фуллертон
ч 4 Дональд Р. Москейто (Donald R. Moscato), Иона Колледж
4 Нэнси Л. Руссо (Nancy L. Russo), Университет Северного Иллинойса
4 Бехруз Сагафи (Behrooz Saghafi), Чикагский государственный университет
4 Джозеф Л. Сессум (Joseph L. Sessum), Государственный университет Кеннесо
4 Ашраф Ширани (Ashraf Shirani), Государственный университет Сан-Хосе
4 Людвиг Слуски (Ludwig Slusky), Калифорнийский государственный университет — Лос-Анджелес.
Кроме того, Марти Мюррей (Marty Murray) из Общественного колледжа Портленда вдохновил меня на разработку материала по Oracle для главы 12 и оказал в этом неоценимую помощь. Идеей включить в главу 16 материал, посвященный JSP и MySQL, я обязан Уорнеру Скайереру (Warner Schyerer) из корпорации SoundDev, Сиэтл. Спасибо также Джуд Столлер (Jude Stoller) из корпорации SoundDev, которая предоставила отзыв на этот материал. Я особенно благодарю Криса Уилкенса (Chris Wilkens) из SafariDog.com, который помог мне настроить Linux, Apache и Tomcat.
Спасибо Oracle и Microsoft за предоставление студенческих версий своих продуктов. Также спасибо Торстену Ганцу (Thorsten Ganz), президенту Cool-strategy.com, который предоставил программу Tabledesigner студентам, использующим в обучении эту книгу, и Кендзи Каваи (Kenji Kawai), продолжающему играть решающую роль в разработке продуктов, базирующихся на модели семантических объектов. Отдельное спасибо Кайл Хэннон (Kyle Hannon) из Prentice-Hall, занимавшейся обработкой текста и различных вспомогательных компонен
22
Предисловие
тов и обеспечившей их успешную сборку, а также Ванессе Наттри (Vanessa Nuttry) из Prentice-Hall, умело управлявшей производственным процессом. Наконец, я благодарю Линду (Lynda) за ее любовь, поддержку и воодушевление.
Теория баз данных — захватывающая область, которая развивалась и эволюционировала в течение более чем тридцати лет. Я верю в то, что это ее развитие продолжится еще как минимум столько же времени, и желаю вам успехов в исследовании многочисленных возможностей, открывающихся перед вами!
Дэвид Крёнке (David Kroenke)
Сиэтл, штат Вашингтон
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу электронной почты comp@piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
Все исходные тексты, приведенные в книге, вы можете найти по адресу http://www.piter.com/download.
На web-сайте издательства http://www.piter.com вы найдете подробную информацию о наших книгах.
Часть I
Введение
Часть I книги, состоящая из двух глав, посвящена знакомству с базами данных. В главе 1 описаны четыре типичных варианта применения баз данных и рассмотрены преимущества баз данных над использовавшимися ранее системами обработки файлов. Кроме того, в ней определен термин база данных и кратко изложена история вопроса. В главе 2 описаны элементы базы данных и дан обзор функций системы управления базами данных (СУБД). В качестве заключения к вводной части книги в главе 2 перечислены задачи, которые приходится решать в процессе разработки базы данных и ее приложений.
Часть I дает представление о назначении баз данных и природе их компонентов и приложений. Цель этой части — заложить необходимые основы для подробного изучения концепций и технологий баз данных, представленных в последующих главах.
Глава 1
Введение в базы данных
Базы данных всегда были важной темой при изучении информационных систем. Но именно в последние годы, благодаря бурному развитию Интернета и связанному с этим технологическому прорыву, знание технологии баз данных стало одним из наиболее популярных путей к карьере. Технология баз данных позволяет сделать интернет-приложение чем-то большим, чем просто средство для публикации брошюр, что было характерно для ранних приложений. В то же время интернет-технологии обеспечивают стандартизированный и доступный способ доставки содержимого базы данных пользователям. Ни одно из этих новых обстоятельств не отменяет необходимости в классических приложениях баз данных, которые были незаменимы в бизнесе до появления Интернета, — они лишь усиливают важность знаний о базах данных.
Многие студенты находят этот предмет интересным и увлекательным, хотя порой он может быть трудным. Проектирование и разработка баз данных требуют одновременно и искусства, и инженерных навыков. Понимание требований пользователя и воплощение этих требований в эффективной логической структуре базы данных является искусством. Преобразование логической структуры в физическую базу данных с функционально завершенными, высокопроизводительными приложениями представляет собой инженерную задачу. Оба эти аспекта сулят множество трудных и увлекательных интеллектуальных головоломок.
Из-за крайне высокой востребованности технологии баз данных навыки и знания, полученные вами в процессе изучения этого курса, будут иметь огромный спрос. Цель этой книги — заложить в вас твердые знания основ технологии баз данных, чтобы вы могли начать успешную карьеру в этой области, если таков будет ваш выбор.
Четыре примера применения баз данных
Задача базы данных состоит в том, чтобы помочь людям в учете различного рода вещей. В классических приложениях баз данных ведется учет заказов, клиентов, выполненных работ, сотрудников, телефонных звонков и многих других вещей, представляющих интерес для предпринимателя. В последнее время технология баз данных используется в Интернете не только для этих традиционных нужд, но и для новых приложений, к которым относится, например, реклама, настроенная
Четыре примера применения баз данных
25
на характеристики потребителей, и отслеживание предпочтений клиентов при просмотре веб-страниц и покупке товаров. Такие базы данных, наряду с традиционными числовыми данными — именами, датами и номерами телефонов, включают в себя картинки, а также аудио- и видеоинформацию. Следующие четыре примера иллюстрируют применение технологии баз данных в широком спектре областей.
Малярная фирма Мэри Ричардс
Мэри Ричардс — профессиональный маляр, владеет и управляет небольшой компанией, состоящей из нее самой, еще одного профессионального маляра и, когда это необходимо, наемных работников. Мэри занимается этим бизнесом уже 10 лет и приобрела за это время репутацию высококвалифицированного маляра, работающего за умеренную плату. Большую часть заказов она получает от постоянных клиентов, нанимающих ее для покраски домов, а также от их знакомых. Кроме того, некоторое количество заказов Мэри получает от строительных подрядчиков и профессиональных дизайнеров интерьера.
Клиенты помнят Мэри намного лучше, чем она их. Порою она бывает смущена, когда клиент звонит ей и говорит что-нибудь такое: «Здравствуйте, Мэри, это Джон Мэплз. Вы красили мой дом три года назад». При этом звонящий подразумевает, что Мэри вспомнит его и работу, которую она для него сделала; но если учесть, что Мэри красит более 50 домов в год, для нее это будет затруднительно. Ситуация становится еще хуже, когда клиент заявляет: «Моей соседке понравилось, как вы покрасили наш дом, и она хочет, чтобы вы и у нее сделали что-нибудь вроде этого».
Чтобы несколько разгрузить свою память и лучше организовать учет деятельности фирмы, Мэри наняла консультанта для разработки базы данных, которую она могла бы хранить на своем персональном компьютере. В базе данных должны храниться записи о клиентах, заказах и поставщиках клиентов, представленные в форме таблиц (рис. 1.1).
Записью и получением данных из этих таблиц занимается специальная программа, называемая системой управления базой данных (database management system), или СУБД (DBMS). К сожалению, эти данные, будучи представлены в форме таблиц, не слишком полезны для Мэри. Ей скорее хотелось бы знать, как клиенты и заказы связаны друг с другом, — например, какие работы были выполнены ею для конкретного клиента или какие клиенты были направлены к ней конкретным человеком.
Чтобы предоставить Мэри такую возможность, консультант создал прикладную программу (application program), которая обрабатывает формы (forms) для ввода данных и формирует отчеты (reports). Рассмотрим пример, представленный на рис. 1.2. В изображенную здесь форму Мэри вводит личные данные клиента — имя, телефон и адрес. Далее она вводит сведения о работах, выполненных для клиента, и указывает, кто направил этого клиента к ней. Эти данные могут быть затем отражены в отчете, пример которого показан на рис. 1.3. Другие функции этой базы данных включают оценку стоимости заказа, учет поставщиков клиентов и создание наклеек с адресом для рекламных буклетов, которые Мэри время от времени рассылает.
26
Глава 1. Введение в базы данных
В Microsoft Access

Ffe Edit < View- < । Irisert Tsc^s W^indow  Hbtp
-' ей
SBS8B
- ] Xj

'£] < В j Ш £ 0
Create table in Design view Create table by using wizard Create table by entering data CUSTOMER (joe;
SOURCE
I sourcejof
3
2
3
| F^honehJurnbgt P03) 549-8879 (303) 776-8899 (303) 767-7783
Queries
Forms
13 ('-:-
Name '
1 Valley Designs
2 Aspen Construction
3 Mary Engers Design (AutoNumber)
Рис. 1.1. Таблицы данных для малярной фирмы Мэри Ричардс
__________	-io; x!
2 Wu, Jason
3 Maples Marilyn
4 Jackson. Chns (AuloNumber)
1 H.Lli....“ f >.bi.Mld
123 E Elm Denver CO :60210-7786 (303) 555-0089
2518 S Link Lane Denver CO 80243-
4700 Latayelte Eoulder CO
..........--------------------—.-----------—-----------_
JOBJD ( Jp-bDate (	pescnpbon
3/3Z2000 Pamt exterior in 794 White
7/7/2000 Paint dining room and kitchen
3/15/2001 Prep and paint upstairs bath
4/3/2001 Pamt exterior doors in 633 Red
7/14Z2001 Prep and pamt interior wood trim
5 (AutoNumber)
® CUSTOMER
►
Customer ffrVu Jason
Phone
Street

((303j 555-йОЗТ jl23 E 'Elm...
jOenvei
(303) 777-6898
81237-3484 (549) 388-1243

jmAmounlSilieil-L AmoantPanj [‘CUSJOME^O
$2,750 00
$1,778.00 .
’ $550 00
$885 00
’ $1,299 00
$0 00

$2,750 00 $1,778 00 .
$550 00
$885 00 •
$1.299 00 $0 00
1B12S1
Referral Source
Phone 303
^О2То-778б‘
-State
Рис. 1.2. Пример формы для ввода данных для малярной фирмы Мэри Ричардс
Четыре примера применения баз данных
27
вжш
’ - 5 ' X '
Customer Job History
Customer-Name	Wu, Jason
PhoneNumber	(303) 555-008
	JobDate Description	AmouniBilled AmountPaid	
	3/3/2000 Pont exterior n 794 Whte	$2,750	$2,750
	7/7/2000 Pant dring room end kitcEen	$1,778	$1,778
	315/2001 Prepand part cpstairsbAh	$660	$550
Total		$5,078	$5,078
CustomerNanK	Maples, Marilyn
PhoneNumber	(303) 777-689
JabDaie Description	AmouniBilled AmountPad
7Л4/2001 Prep and pent interior'«oodtrim	$1,299	$1,299
Tatal	$1,299	$1,299
CustomerName	Jackson, Chns
PhoneNumber	(549) 388-124
JobDaie Description AmouniBilled AmounlPad
47372001 Paint e^enor doors r 633 Red	$865	$865
Grand Total
Thursday, Marek 01,2001
Reado
Igfistart] i	Excel'
$385
j ^Jasc Pant Shop Pro : I	Я Customer job HtsL..	: ,3.58
Рис. 1.3. Пример отчета для малярной фирмы Мэри Ричардс
Прикладная программа и СУБД обрабатывают заполненную форму и переписывают данные из нее в таблицы, подобные изображенным на рис. 1.1. Аналогичным образом прикладная программа и СУБД извлекают данные из этих таблиц для создания отчетов, таких как представленные на рис. 1.3.
Еще раз вернувшись к рис. 1.1, обратите внимание, что строки таблицы содержат перекрестные ссылки и поэтому оказываются связанными друг с другом. Для каждой работы (JOB) указан номер клиента (CUSTOMER_ID), заказавшего эту работу, и для каждого клиента (CUSTOMER) указан номер поставщика клиента (SOURCE_ID), то есть человека, направившего этого клиента к Мэри. Эти ссылки используются для объединения данных в формы и отчеты.
Как вы можете догадаться, Мэри вряд ли имеет представление о том, как проектировать таблицы, создавать их с помощью СУБД и разрабатывать прикладную программу для создания форм и отчетов. Но ваших знаний технологии баз данных к моменту окончания этого курса должно хватить для того, чтобы суметь разработать такую базу данных и прикладную программу для работы с ней. Вы должны будете также уметь проектировать таблицы и манипулировать ими для создания довольно сложных форм и отчетов.
28
Глава 1. Введение в базы данных
Бюро проката музыкальных инструментов Treble Clef Music
База данных Мэри Ричардс называется однопользовательской (single-user), поскольку в каждый конкретный момент времени к ней обращается только один пользователь. В некоторых случаях такое ограничение неприемлемо: иногда требуется, чтобы одновременно к базе данных могли обращаться несколько человек с различных компьютеров. Такие многопользовательские (multi-user) базы данных являются более сложными, поскольку СУБД и прикладные программы должны заботиться о том, чтобы действия одного пользователя не противоречили действиям другого.
Бюро проката Treble Clef Music использует базу данных для учета сдаваемых в аренду музыкальных инструментов. Для этого требуется многопользовательская база данных, поскольку в периоды наплыва клиентов выдачей музыкальных инструментов могут одновременно заниматься несколько служащих. Кроме того, менеджер также должен иметь доступ к базе данных, чтобы определить момент, когда необходимо будет заказать большее количество определенных инструментов. При этом менеджер не хочет мешать процессу выдачи инструментов.
Бюро Treble Clef Music имеет локальную сеть, соединяющую несколько персональных компьютеров с сервером, на котором находится база данных (рис. 1.4). У каждого из служащих есть доступ к прикладной программе, позволяющей работать с тремя видами форм. Форма CUSTOMER (рис. 1.5, а) содержит информацию о клиенте, форма RENTAL AGREEMENT (рис. 1.5, б) представляет договор аренды и используется для учета выдачи и возврата инструментов, а форма INSTRUMENT (рис. 1.5, е) содержит сведения об инструменте и историю его аренды.
Сервер базы данных
Рис. 1.4. Локальная сеть бюро проката Treble Clef Music
Четыре примера применения баз данных
29
Рис. 1.5. Формы, используемые бюро Treble Clef: а — информация о покупателе; б — договор аренды; в — сведения об инструменте
30
Глава 1. Введение в базы данных
Чтобы уяснить проблемы, которые необходимо преодолеть в многопользовательской базе данных, представьте себе, что произойдет, если два клиента одновременно попытаются взять напрокат один и тот же кларнет си бемоль. СУБД и прикладная программа должны каким-то образом обнаружить эту ситуацию и сообщить служащим, что им следует выбрать другой инструмент.
Бюро лицензирования и регистрации
Рассмотрим теперь еще более обширное приложение технологии баз данных — государственное бюро регистрации автомобилей и выдачи водительских прав. В него входят 52 центра, где принимаются экзамены по вождению и осуществляется выдача и продление прав, а также 37 офисов, занимающихся регистрацией транспортных средств.
Персонал этих офисов использует в своей работе базу данных. Прежде чем конкретному лицу будут выданы или продлены права, в базе данных просматриваются сведения об этом лице на предмет наличия нарушений правил дорожного движения, ДТП или задержаний. На основе этих данных принимается решение, могут ли права быть продлены, и если да, то будут ли в них какие-либо ограничения. Аналогичным образом, персонал в отделе регистрации автомобилей обращается к базе данных, чтобы определить, был ли автомобиль зарегистрирован ранее, а если был, то на чье имя, и нет ли каких-либо из ряда вон выходящих причин, по которым в регистрации следует отказать.
У этой базы данных сотни пользователей, включая не только персонал, занимающийся регистрацией и выдачей прав, но и служащих финансового управления, а также сотрудников правоохранительных органов. Неудивительно, что база является большой и сложной и имеет более 40 таблиц, причем некоторые из них содержат сотни тысяч строк данных.
Большие организационные базы данных, подобные только что рассмотренной нами, были первыми приложениями технологии баз данных. Подобные системы находятся в эксплуатации уже в течение 20 или 30 лет и за этот период неоднократно модифицировались в соответствии с менявшимися требованиями времени. Существуют организационные базы данных, предназначенные для ведения счетов в банках и других финансовых институтах, учета готовой продукции и комплектующих на складах больших предприятий, обработки медицинской документации в госпиталях и страховых компаниях, а также для правительственных нужд.
Сегодня многие организации модифицируют прикладные программы своих баз данных, чтобы дать клиентам возможность обращаться к этим данным и даже вносить в них изменения через Интернет. Если вы работаете на большую организацию, то вас вполне могут подключить к подобному проекту.
Туристический информационный центр
Калверт-Айленд — это прекрасный, но малоизвестный остров на западном побережье Канады. Для продвижения острова на мировой туристический рынок Совет по коммерции Калверт-Айленда разработал сайт, преследующий три цели:
Четыре примера применения баз данных
31
4 ♦ рекламу природных условий Калверт-Айленда, а также мест отдыха и раз-«	влечений;
♦	запись имен и адресов посетителей сайта для последующей рассылки им *	рекламной информации;
♦	прием запросов на бронирование мест в гостиницах, аренду коттеджей и туристическое обслуживание, а также направление этих запросов соответствующим фирмам.
Для поддержки этого сайта используются две базы данных. Первая из них — рекламная — содержит данные, фотографии, видеоклипы и звуковые фрагменты, дающие представление о природе Калверт-Айленда, возможностях острова в сфере отдыха и развлечений и происходящих событиях. У этой базы данных есть два типа пользователей. Обычные пользователи имеют доступ к ней только для чтения. Пользуясь стандартными браузерами, эти пользователи могут исследовать сайт в поисках интересующих их сведений об острове. В этом им помогает прикладная программа, извлекающая данные и мультимедийные элементы из рекламной базы данных (рис. 1.6).
4* 1 1/fM h ₽ «» И»Ъ'ч 1 '»»!♦• ,t •*»« •*»»♦<»	41 |< it
j fto	grip	__________________________________ш
I . 4 ,	21 Й Si ££ V ! id ’
J Back '<	Stop Refiesh Roma Search Fevontet Hislop Channels Ft&cref
:j-Adcfre» htlp./Zlocrihos(/crii$Vbome.a$p	————
Calvert Island Reservation Centre Application |view/Edit Д
Facility:: Activity Center
Рис. 1.6. Web-страница туристического информационного центра Калверт-Айленда
32
Глава 1. Введение в базы данных
Другой тип пользователей рекламной базы данных — это сотрудники Совета по коммерции, осуществляющие поддержку сайта. Сотрудники могут добавлять, изменять и удалять данные и мультимедийные файлы из базы данных, по мере того как сменяется реклама, фирмы присоединяются к программе и покидают ее, а также удовлетворяются пожелания пользователей.
Кроме рекламной базы данных, прикладные программы сайта обращаются к базе данных клиентов. В ней хранятся сведения, предоставляемые посетителями сайта при заполнении анкеты и при запросе на бронирование или обслуживание. Сюда относятся имя клиента, почтовый и электронный адреса, интересы, предпочтения и предмет запроса. Когда посетитель вводит запрос, прикладная программа пересылает его по электронной почте соответствующей фирме. Время от времени фирмам рассылаются сводки всех запросов, поступивших за определенный период, для контроля за их выполнением и других управленческих целей.
Есть три основных аспекта, отличающих базу данных острова Калверт-Айленд от рассмотренных нами ранее приложений. Во-первых, рекламная база данных в значительной своей части содержит не только структурированные данные, такие как имена и адреса фирм, но также неструктурированные потоки битов в мультимедийных файлах. Во-вторых, прикладная программа доставляет информацию пользователю посредством стандартного браузера. Вид форм, которые используются в малярной фирме Мэри Ричардс, бюро проката музыкальных инструментов и бюро лицензирования и регистрации, определяется проектировщиком и изменяется только при модификации приложения. То, в каком виде формы предстают перед пользователями базы данных Калверт-Айленда, определяется не только приложением, но и маркой, версией и локальными настройками их браузеров.
Третья характеристика, отличающая базу данных Калверт-Айленда, — это применение стандартной web-ориентированной технологии для передачи данных между браузером, приложением и базой данных. При этом используются протокол передачи гипертекста (HTTP), динамический язык разметки гипертекстовых документов (DHTML) и расширяемый язык разметки (XML). Использование этих стандартов означает, что доступ к этому приложению может получить любой пользователь, имеющий браузер. Предварительной установки какого-либо программного обеспечения не требуется. Следовательно, возможности для использования этого приложения практически не ограничены. В главах 14-16 мы обсудим роль, которую играют HTTP, DHTML и XML в работе с базами данных, в которых:
♦	присутствуют как структурированные, так и мультимедийные данные;
♦	формы и отчеты отображаются с помощью стандартного браузера;
♦	для передачи данных применяются стандарты Интернета — HTTP, DHTML и XML.
Сравнение четырех типов баз данных
Приведенные примеры демонстрируют возможные варианты использования технологии баз данных. Есть сотни тысяч баз данных, похожих на ту, что имеется в малярной фирме Мэри Ричардс, — однопользовательские базы данных с относи
Отношения между прикладными программами и СУБД
33
тельно небольшим количеством данных, скажем, менее 10 Мбайт. Формы и отчеты для этих баз данных имеют обычно довольно простой вид.
У других баз данных, подобных той, что используется в бюро проката Treble Clef Music, несколько пользователей, но общее их количество обычно не превышает 20-30 человек. Они содержат умеренное количество данных — например, 50 или 100 Мбайт. Формы и отчеты должны быть достаточно сложными, чтобы поддерживать несколько различных деловых функций.
Самые большие размеры у баз данных, подобных той, что мы рассматривали для случая бюро регистрации автомобилей, — у них сотни пользователей и триллионы байтов данных. Для работы с этими базами данных используется множество различных приложений, у каждого из которых свои собственные формы и отчеты. Наконец, некоторые базы данных применяют интернет-технологии и обрабатывают как символьные, так и мультимедийные данные — изображения, звуки, анимацию, видео и т. п. Сравнительные характеристики перечисленных типов баз данных приведены в табл. 1.1.
Прочтя книгу, вы сможете проектировать и реализовывать базы данных наподобие тех, что используются в малярной фирме Мэри Ричардс и в бюро проката Treble Clef Music. Возможно, вы будете еще не в состоянии создавать такие большие и сложные базы данных, как та, что используется в бюро регистрации транспортных средств, но, тем не менее, сможете быть полезным членом команды по разработке и созданию такой базы данных. Вы также сможете создавать небольшие или средних размеров базы данных, использующие интернет-технологии.
Таблица 1.1. Характеристики различных типов баз данных
Тип	Пример	Типичное количество одновременно работающих пользователей	Типичный размер базы данных
Персональная	Малярная фирма Мэри Ричардс	1	<10 Мбайт
Коллективная	Бюро проката музыкальных инструментов Treble Clef Music	< 25	<100 Мбайт
Организационная	Бюро лицензирования и регистрации автомобилей	Сотни-тысячи	> 1 Тбайт
Сетевая (Интернет)	Туристический информационный центр Калверт-Айленда	Сотни-тысячи	Любой
Отношения между прикладными программами и СУБД
Все предыдущие примеры и, разумеется, все приложения технологии баз данных имеют общую структуру, показанную на рис. 1.7, — пользователь взаимодействует с прикладной программой, которая, в свою очередь, взаимодействует с СУБД, обращающейся к данным в базе.
34
Глава 1. Введение в базы данных
Когда-то граница между прикладной программой и СУБД была четко определена. Приложения писались на языках третьего поколения, таких как COBOL, и обращались к СУБД за услугами по обработке данных. Фактически, так дело обстоит до сих пор, чаще всего в базах данных, располагающихся на больших ЭВМ.
Рис. 1.7. Отношения между пользователями, приложениями базы данных, СУБД и базой данных
Сегодня, однако, возможности и функции многих коммерческих СУБД расширились настолько, что СУБД могут самостоятельно выполнять значительную часть функций, ранее находившихся в ведении прикладных программ. Например, в большинстве коммерческих СУБД есть генераторы отчетов и форм, которые можно встраивать в приложения. Этот факт важен для нас по двум причинам. Во-первых, хотя основной объем этого текста посвящен проектированию и разработке баз данных, мы часто будем уделять внимание проектированию и разработке приложений. В конце концов, ни одному пользователю не нужна база данных как таковая. Пользователям скорее нужны формы, отчеты и запросы по их данным.
Во-вторых, время от времени вы будете замечать, что материал этого курса в чем-то пересекается с материалом курса системного программирования, поскольку разработка эффективных приложений баз данных требует многих навыков из тех, что вы приобрели или приобретете в ходе изучения курса системного программирования. И наоборот, в большинство современных курсов системного программирования входит такая тема, как проектирование баз данных. Различие между двумя курсами заключается в расстановке акцентов: здесь мы делаем упор на проектирование, построение и обработку базы данных, а в курсе системного программирования — на разработку информационных систем, большинство из которых использует технологию баз данных.
Системы обработки файлов
35
Системы обработки файлов
Лучший способ уяснить общую природу и свойства современных баз данных — рассмотреть характеристики систем, существовавших до появления технологии баз данных. При эксплуатации такого рода систем возникал ряд проблем, которые технология баз данных помогла решить.
В первых деловых информационных системах группы записей хранились в отдельных файлах; такие системы назывались системами обработки файлов (fileprocessing systems). На рис. 1.8 приведены в качестве примера две системы обработки файлов, которые можно было бы использовать в бюро проката Treble Clef Music. Одна система обрабатывает данные клиентов, а другая — информацию о прокате.
Хотя системы обработки файлов являются огромным усовершенствованием по сравнению с ведением записей вручную, у них есть значительные ограничения:
♦ данные разделены и изолированы;
4 ♦ значительная часть данных дублируется;
♦ прикладные программы зависят от форматов файлов;
| ♦ зачастую файлы несовместимы друг с другом;
♦ представление данных в виде, удобном для пользователя, оказывается затруднительным.
файла клиентов
Приложение, обрабатывающее информацию о прокате
Пользователь файла клиентов
Рис. 1.8. Две системы обработки файлов
Разделенные и изолированные данные
Служащие бюро Treble Clef Music должны ассоциировать клиентов с инструментами, которые те берут в аренду. Для системы, изображенной на рис. 1.8, нужно каким-то образом извлечь данные из файлов клиентов и проката и скомбинировать их в третий файл. В системах обработки файлов это вызовет сложности. Во-первых, системные аналитики и программисты должны определить, какие части каждого из файлов для этого требуются, а затем решить, как файлы должны относиться друг к другу; наконец, они должны скоординировать обработку
36
Глава 1. Введение в базы данных
файлов таким образом, чтобы извлечение данных происходило корректно. Даже для двух файлов эта задача довольно сложна, а вообразите себе, что необходимо скоординировать 10 или более файлов!
Дублирование данных
В примере с бюро проката Treble Clef Music часто возникает ситуация, когда имя клиента, его адрес и другие данные записываются несколько раз. А именно, эти данные записываются один раз в файл клиентов, а затем каждый раз, когда с данным клиентом заключается договор аренды, — в файл проката. То, что при этом впустую тратится дисковое пространство, — еще не самая большая проблема: главная проблема, возникающая при дублировании данных, касается целостности данных (data integrity).
Совокупность данных обладает целостностью, если данные в ней логически согласованы. Когда данные дублируются, это зачастую нарушает их целостность. Например, если клиент сменит фамилию или адрес, то все файлы, содержащие эти данные, необходимо будет обновить, но существует опасность, что обновлены будут не все файлы, и между ними появятся несоответствия. В случае Treble Clef Music может оказаться, что в разных записях в файле проката клиент имеет разные адреса.
Проблемы целостности данных являются серьезными. Если данные противоречат друг другу, это приведет к несогласованным результатам и неопределенности. Если отчет одного приложения не согласуется с отчетом другого приложения, то кто сможет сказать, какой из них является правильным? Когда результаты не согласованы, достоверность хранимых данных и даже само функционирование административной информационной системы ставятся под сомнение.
Зависимость прикладных программ от форматов файлов
При обработке файлов прикладные программы зависят от форматов файлов. Обычно в системах обработки файлов физические форматы файлов и записей являются частью кода приложения. В языке COBOL, например, форматы файлов записываются в разделе DATA DIVISION. Проблема заключается в том, что при внесении изменений в форматы файлов приходится также менять и прикладные программы.
Например, если в записи о клиенте поле почтового индекса будет расширено с пяти цифр до девяти, все программы, работающие с этой записью, необходимо будет модифицировать, даже если они не используют это поле. Поскольку файл клиентов может обрабатываться двадцатью программами, такое изменение означает, что программист должен обнаружить все затронутые программы, внести в них изменения и затем заново протестировать их; все это требует значительных временных затрат и является дополнительным источником ошибок. Кроме того, требовать от программистов модификации программ, не использующих то поле, формат которого изменился, — значит просто бросать деньги на ветер.
Системы обработки баз данных
37
Несовместимость файлов
Одним из следствий зависимости прикладных программ от форматов файлов является то, что сами форматы файлов зависят от языка или средства, используемого для их генерации. Так, формат файла, созданного программой на языке COBOL, отличается от формата файла, созданного программой на Visual Basic, который, в свою очередь, отличается от формата файла, созданного программой на C++.
В результате, оперативно комбинировать или сравнивать файлы оказывается невозможно. Пусть, например, в файле под названием FILE-A хранятся данные о клиенте, содержащие поле Номер_Клиента, а в файле под названием FILE-B хранятся данные об аренде, также содержащие поле Номер_Клиента. Пусть нам требуется скомбинировать записи, у которых значение этого поля одинаково. Если FILE-A обрабатывается программой на Visual Basic, a FILE-B обрабатывается программой на C++, то прежде чем мы сможем комбинировать записи из них, нам придется преобразовать оба файла к некоторому общему формату. Это требует времени, а иногда вызывает затруднения. С увеличением количества комбинируемых файлов растет и число таких проблем.
Трудность представления данных в удобном для пользователя виде
В системе обработки файлов нелегко представить данные в естественном для пользователя виде. Пользователи хотят видеть данные об аренде в формате, аналогичном изображенному на рис. 1.5, б. Но для того чтобы вывести данные в таком виде, необходимо извлечь данные из нескольких файлов, скомбинировать их и представить вместе. Причина возникшего затруднения в том, что в системах обработки файлов связи между записями не представлены в явной форме и не обрабатываются. Поскольку система обработки файлов не может быстро определить, какие клиенты взяли напрокат какие инструменты, то создание отчета, демонстрирующего, например, предпочтения клиента, представляется крайне трудной задачей.
Системы обработки баз данных
Технология баз данных была разработана для того, чтобы преодолеть ограничения, свойственные системам обработки файлов. Чтобы понять, каким образом это было сделано, сравните систему обработки файлов (см. рис. 1.8) с системой обработки базы данных (database processing system) (см. рис. 1.7). Программы обработки файлов обращаются непосредственно к файлам данных. В отличие от них, программы обработки баз данных для доступа к данным вызывают СУБД. Это отличие важно тем, что оно упрощает прикладное программирование: программистам больше не нужно задумываться о том, как физически организовано хранение данных, и они могут смело сконцентрироваться на вопросах, представляющих важность для пользователя, а не для компьютерной системы.
38
Глава 1. Введение в базы данных
Данные интегрированы
В системе базы данных все данные хранятся в едином месте, называемом базой данных. Прикладная программа может попросить СУБД обратиться к данным о клиентах или о продажах, или к тем и другим. Если нужны данные обоих типов, программист задает только способ комбинирования данных, а СУБД выполняет все необходимые для этого операции. Таким образом, в задачи программиста не входит написание программ для объединения данных, что требовалось для системы на рис. 1.8.
Меньшее количество дублирующихся данных
В базе данных дублирование данных минимально. Например, для базы данных бюро Treble Clef Music номер, имя и адрес клиента записываются только один раз. Когда эти данные потребуются, СУБД может получить их, а для их модификации необходимо будет только одно обновление. Поскольку данные хранятся в одном месте, проблемы их целостности стоят не так остро: вероятность разночтений между несколькими копиями одного и того же элемента данных снижается.
Независимость программ от данных
База данных уменьшает зависимость программ от форматов файлов. Все форматы записей хранятся в самой базе данных (вместе с данными), и обращение к данным производит СУБД, а не прикладные программы. В отличие от программ обработки файлов, в прикладные программы базы данных не требуется включать формат всех файлов и записей, которые они обрабатывают. Прикладные программы должны содержать лишь описание (длину и тип) каждого элемента данных, который требуется им в базе данных. СУБД преобразует элементы данных в записи и выполняет другие подобные преобразования.
Независимость программ от форматов данных минимизирует влияние изменения формата данных на прикладные программы. Изменения формата вводятся в СУБД, а та, в свою очередь, обновляет информацию о структуре базы данных. По большей части прикладные программы не осведомлены о смене формата. Это также означает, что при добавлении, изменении или удалении каких-либо элементов данных из базы данных модификации требуют только те программы, которые непосредственно используют эти данные. Для приложений, состоящих из множества программ, это может дать существенную экономию времени.
Представление данных в удобном для пользователя виде
Как вы неоднократно обнаружите на всем протяжении данной книги, технология баз данных дает возможность непосредственно представить объекты, существующие в мире пользователя. Формы, подобные изображенным на рис. 1.5, легко по
Определение термина «база данных^
39
лучить на основании информации из базы данных, поскольку сведения о связях между записями также хранятся в базе данных.
Определение термина «база данных»
Термин база данных (database) страдает от обилия различных интерпретаций. Он использовался для обозначения чего угодно — от обычной картотеки до многих томов данных, которые правительство собирает о своих гражданах. В этой книге мы будем использовать данный термин в конкретном значении: база данных — это самодокументированное собрание интегрированных записей. Важно понять обе части этого определения.
Самодокументированность
База данных является самодокументированной (self-describing): она содержит, в дополнение к исходным данным пользователя, описание собственной структуры. Это описание называется словарем данных (data dictionary), каталогом данных (data directory) или метаданными (metadata).
В этом смысле база данных напоминает библиотеку, которую можно представить как самодокументированный набор книг. Кроме книг в библиотеке имеется каталог с их описанием. Точно так же словарь данных (являющийся частью базы данных, подобно тому, как каталог является частью библиотеки) описывает данные, содержащиеся в базе данных.
Почему самодокументированность является столь важной характеристикой базы данных? Во-первых, она обусловливает независимость программ от данных. Иначе говоря, она дает возможность определить структуру и содержимое базы данных путем обращения к самой базе данных. Нам не придется делать предположения о том, что содержит база данных, а также отпадет необходимость как-либо внешне документировать формат записей и файлов (как это делается в системах обработки файлов).
Во-вторых, если мы изменим структуру данных в базе (например, добавим новые элементы данных к существующей записи), то эти изменения мы внесем только в словарь данных. Лишь небольшую часть программ необходимо будет изменить (если таковые вообще будут). В большинстве случаев модификации потребуют только те программы, которые непосредственно обрабатывают элементы данных, претерпевшие изменения.
База данных — это собрание интегрированных записей
Стандартная иерархия данных выглядит следующим образом: биты объединяются в байты, или символы; символы группируются в поля; из полей формируются записи; записи организуются в файлы (рис. 1.9, а). Есть соблазн последовать
40
Глава 1. Введение в базы данных
этому образцу и сказать, что файлы объединяются в базу данных. Хотя это утверждение будет верным, оно, тем не менее, отразит суть недостаточно полно.
В базе данных действительно содержатся файлы данных пользователя, однако ими все не исчерпывается. Как уже упоминалось ранее, в разделе метаданных база данных содержит описание самой себя. Кроме того, база данных содержит индексы (indexes), которые представляют связи между данными, а также служат для повышения производительности приложений базы данных. Наконец, зачастую база данных содержит данные о приложениях, использующих эту базу данных. Структура форм для ввода данных и отчетов иногда является частью базы данных. Эту последнюю категорию данных мы называем метаданными приложений (application metadata). Таким образом, база данных содержит четыре типа данных, представленных на рис. 1.9, б: файлы данных пользователя, метаданные, индексы и метаданные приложений.
Биты >
Байты, или символы
Поля > Записи > Файлы
Записи > Файлы + Метаданные + > Индексы + Метаданные приложенияJ
База данных
б
Рис. 1.9. Иерархия элементов данных: а — в системах обработки файлов и б — в системах баз данных
База данных является моделью модели
База данных представляет собой модель. Возникает соблазн сказать, что база данных — это модель реальности или некоторой части реальности, относящейся к бизнесу. Однако это неверно. База данных не моделирует реальность или какую-либо ее часть, но является моделью пользовательской модели (user model). Например, база данных Мэри Ричардс представляет собой модель того, как Мэри видит свой бизнес. С ее точки зрения, ее бизнес состоит из клиентов, работ и поставщиков клиентов. Поэтому в ее базе данных представлены факты, касающиеся этих объектов. Имена и адреса клиентов, описание и временные рамки производимых работ, имена поставщиков клиентов — все это данные, являющиеся важными для ведения бизнеса в представлении Мэри.
Базы данных различаются по уровню детализации. Некоторые их них просты и примитивны. Список клиентов и сумм, которые они должны заплатить, — вот
История баз данных
41
приблизительное представление модели, существующей в голове Мэри. Более детализированное представление включает виды работ, имена поставщиков клиентов и путь, проделанный до места проведения каждой из работ. Очень подробное представление может включать вид и количество использованной краски, требуемое количество малярных кистей и количество часов, ушедшее на каждую фазу работ — измерения, окраску дерева и стен, зачистку и т. п.
Степень детализации, которая должна присутствовать в базе данных, зависит от того, какого рода информация необходима. Ясно, что чем больше требуется информации, тем более подробной должна быть база данных. Выбор подходящей степени детализации является важной частью работы по проектированию базы данных. Как вы обнаружите, основополагающим критерием здесь является уровень детализации, имеющийся в голове пользователя.
База данных представляет собой динамическую модель, поскольку бизнес имеет свойство меняться: люди приходят и уходят, продукты появляются и устаревают, деньги зарабатываются и тратятся. По мере этих изменений данные, представляющие бизнес, также должны меняться. В противном случае они будут устаревать и представлять бизнес неадекватно.
Транзакции (transactions) являются представлением событий. Когда происходят какие-то события, с базой данных должны быть выполнены соответствующие транзакции. Для этого кто-либо (например, оператор ввода данных, продавец или кассир в банке) запускает программу обработки транзакций и вводит данные для транзакций. Программа затем вызывает СУБД для внесения изменений в базу данных. Обычно программа обработки транзакций выдает на дисплей или распечатывает на бумаге отчет — например, подтверждение заказа или чек.
История баз данных
Базы данных изначально использовались в больших корпорациях и крупных организациях как основа для больших систем обработки транзакций. В качестве примера можно привести бюро лицензирования и регистрации транспортных средств, рассмотренное нами выше. Позднее, по мере того как популярность завоевывали микрокомпьютеры, технология баз данных также мигрировала в этом направлении и стала использоваться для однопользовательских, персональных приложений, подобных тому, которым пользуется Мэри Ричардс. Затем, когда микрокомпьютеры начали объединять в рабочие группы, технология баз данных была модифицирована с учетом этой тенденции, примером чего может служить бюро проката Treble Clef. Наконец, в настоящее время базы данных используются в приложениях для Интернета и интрасетей.
Организационный контекст
Исходное предназначение технологии базы данных заключалось в том, чтобы преодолеть трудности с системами обработки файлов, речь о которых шла ранее в этой главе. В середине 1960-х годов большие корпорации накапливали данные
42
Глава 1. Введение в базы данных
в системах обработки файлов с феноменальной скоростью, но работать с этими данными становилось все сложнее, и все более затруднительной оказывалась разработка новых систем. Более того, менеджеры хотели иметь возможность соотносить данные из одной файловой системы с данными из другой системы.
Ограничения файловой обработки препятствовали простой интеграции данных. Технология баз данных, однако, выполнила обещание решить эти проблемы, и крупные компании начали разрабатывать организационные базы данных. В этих базах данных централизованно хранились и обрабатывались данные о заказах, товарах и счетах предприятия. Эти приложения представляли собой главным образом системы обработки транзакций организационного масштаба.
На первых порах, когда технология была еще несовершенной, приложения баз данных были сложны в разработке и выдавали много ошибок. Даже успешно работающие приложения были медленными и ненадежными: аппаратное обеспечение того времени было не в состоянии быстро справиться с объемом выполняемых транзакций, разработчики еще не изобрели более эффективные способы хранения и извлечения данных, а программисты еще не освоили работу с базами данных, и иногда их программы работали некорректно.
Обнаружен был и еще один недостаток баз данных — их уязвимость. Если произойдет сбой в системе обработки файлов, из строя выйдет только одно конкретное приложение. Если же сбой случится в базе данных, то выйдут из строя все ее приложения.
Постепенно ситуация улучшилась. Разработчики аппаратного и программного обеспечения научились создавать системы, достаточно мощные, чтобы поддерживать большое количество параллельно работающих пользователей, и достаточно быстродействующие, чтобы справляться с требуемым объемом транзакций. Были разработаны новые способы контроля, защиты и резервного копирования баз данных. Усовершенствовались стандартные процедуры обработки данных, а программисты научились писать более эффективный и легкий для поддержания код. К середине 1970-х базы данных были в состоянии эффективно и надежно обрабатывать организационные приложения. Многие из этих приложений используются до сих пор, более чем через 25 лет после их создания!
Реляционная модель
В 1970 г. Э. Ф. Кодд (Е. F. Code!) опубликовал свою эпохальную статью1, в которой он применил концепции раздела математики, называемого реляционной алгеброй, к проблеме хранения больших объемов данных. Статья Кодда положила начало движению в сфере проектирования баз данных, которое привело несколько лет спустя к созданию реляционной модели базы данных (relational database model). Эта модель представляет собой определенный способ структурирования и обработки базы данных, и мы будем подробно обсуждать ее в главе 5, а также в главах 9-14.
1 Е. Е. Codd, «А Relational Model of Data for Large Shared Databanks», Communications of the ACM, 06.1970, c. 377-387.
История баз данных
43
Преимущество реляционной модели заключается в способе хранения данных, который минимизирует их дублирование и исключает определенные типы ошибок обработки, возникающие при других способах хранения данных. Данные хранятся в виде таблиц со столбцами и строками, как показано на рис. 1.1.
Согласно реляционной модели, не все виды таблиц одинаково приемлемы. С помощью процесса, называемого нормализацией (normalization), нежелательная таблица может быть преобразована в две или более приемлемых. Более подробно о процессе нормализации вы узнаете из главы 5.
Другое преимущество реляционной модели состоит в том, что в столбцах содержатся данные, связывающие одну строку с другой. Например, на рис. 1.1 столбец CUSTOMER_ID в таблице JOB связан со столбцом CUSTOMER_ID в таблице CUSTOMER. Это делает связи между строками видимыми для пользователя.
Поначалу считалось, что реляционная модель позволит пользователям извлекать информацию из баз данных без помощи профессионалов MIS (административно-информационной системы). Доля истины в этом есть, так как таблицы представляют собой простые и интуитивно понятные конструкции. Кроме того, поскольку связи хранятся вместе с данными, пользователи могут при необходимости комбинировать нужные строки. Например, чтобы получить запись о конкретном договоре аренды, пользователь базы данных бюро проката Treble Clef Music мог бы скомбинировать строку таблицы CUSTOMER со строками таблицы RENTAL.
Оказалось, что этот процесс слишком сложен для большинства пользователей. По этой причине ожидания, что реляционная модель предоставит пригодный для неспециалистов способ доступа к базам данных, не оправдались. Оглядываясь назад, можно резюмировать: ключевым преимуществом реляционной модели оказалось то, что она дает специалистам (таким, как вы!) стандартный способ структурирования и обработки баз данных.
Коммерческие СУБД для микрокомпьютеров
В 1979 г. небольшая компания под названием Ashton-Tate представила новый программный продукт для микрокомпьютеров, dBase II, и назвала его реляционной СУБД. Применяя чрезвычайно успешную рыночную тактику, Ashton-Tate почти бесплатно распространила более 100 000 копий своего продукта среди покупателей новых в то время микрокомпьютеров Osborne. Многие из тех, кто приобрел эти компьютеры, были пионерами микрокомпьютерной индустрии. Они начали создавать приложения для микрокомпьютеров с использованием dBase, и число dBase-приложений быстро росло. В результате Ashton-Tate стала одной из первых крупных корпораций в индустрии микрокомпьютеров. Позднее она была приобретена компанией Borland, которая в настоящее время продает продукты линии dBase.
Успех этого продукта, однако, вызвал неразбериху и путаницу в мире баз данных. Проблема была в следующем: в соответствии с определением, которое стало преобладать в конце 70-х годов, продукт под названием dBase II вообще не являлся СУБД, а тем более реляционной. Фактически это был язык программиро
44
Глава 1. Введение в базы данных
вания с расширенными возможностями для обработки файлов. Системы, разработанные на базе dBase II, гораздо более напоминали то, что изображено на рис. 1.8, чем то, что на рис. 1.7. Около миллиона пользователей dBase II были уверены, что используют реляционную СУБД, хотя в действительности это было не так.
Таким образом, термины система управления базами данных (database management system) и реляционная база данных (relational database) в начале бума микрокомпьютеров использовались достаточно произвольно. Большинство тех, кто работал с базами данных на микрокомпьютерах, на самом деле занимались обработкой файлов и не получали тех преимуществ, которые характерны для баз данных (хотя они и не замечали этого). Сегодня, когда рынок микрокомпьютеров стал более зрелым и искушенным, ситуация стала иной. dBase IV и последующие продукты линии dBase, такие как FoxPro, являются по-настоящему релями-отыми СУБД.
Хотя продукты dBase действительно были первым ориентированным на микрокомпьютеры приложением технологии баз данных, примерно в это же время другие производители начали переносить свои продукты с больших ЭВМ на микрокомпьютеры. В качестве примеров коммерческих СУБД, перенесенных на микрокомпьютеры, можно упомянуть Oracle, Focus и Ingress. Они действительно являются СУБД, и многие также согласятся с тем, что они действительно реляционные.
Одним из следствий переноса технологии баз данных на микрокомпьютеры явилось резкое улучшение пользовательского интерфейса СУБД. Пользователи микрокомпьютеров не стали бы мириться с неуклюжим и неудобным интерфейсом, который характерен для СУБД, работающих на больших ЭВМ. Таким образом, с разработкой коммерческих СУБД, ориентированных на микрокомпьютеры, интерфейс этих программ стал удобнее в использовании. Это стало возможным потому, что микрокомпьютерные СУБД работают на приспособленных под эти задачи компьютерах, а также потому, что больше вычислительных ресурсов стало доступно для обработки пользовательского интерфейса. Сегодняшние СУБД богаты возможностями, надежны и имеют графический пользовательский интерфейс.
Сочетание микрокомпьютеров, реляционной модели и значительно улучшенного пользовательского интерфейса позволило перенести технологию баз данных из контекста организации в контекст персональных компьютеров. Когда это произошло, число мест, где используется технология баз данных, увеличилось на порядки. В 1980 г. в США было около 10 000 мест, где использовались СУБД, сегодня же их более 40 миллионов!
Клиент-серверные приложения баз данных
В середине - конце 1980-х годов конечные пользователи начали объединять свои компьютеры в локальные сети (local area networks, LAN). Эти сети сделали возможной передачу данных между компьютерами с невиданными до тех пор скоростями. Первые приложения этой технологии обеспечивали совместное использование периферийных устройств, таких как быстродействующие дисковые накопители большой емкости, дорогие принтеры и плоттеры, и осуществляли связь
История баз данных
45
между компьютерами посредством электронной почты. В перспективе, однако, пользователи хотели совместно использовать свои базы данных, что привело к развитию многопользовательских приложений баз данных для локальных сетей.
Многопользовательская архитектура, применяемая в локальных сетях, значительно отличается от многопользовательской архитектуры, применявшейся на больших ЭВМ (mainframe). В случае последних в обработке приложения базы данных участвовал только один процессор, а в локальных сетях для этого могут использоваться несколько процессоров. Поскольку эта ситуация, помимо очевидной выгоды (большая производительность), влечет за собой и новые трудности (координация действий независимых процессоров), возник новый стиль многопользовательской обработки баз данных, называемый клиент-серверной архитектурой баз данных (client-server database architecture).
Не все базы данных в локальных сетях используют клиент-серверную архитектуру. Более простой, но менее устойчивый режим обработки баз данных называется архитектурой с совместным использованием файлов (file-sharing architecture). Компания, подобная Treble Clef Music, могла бы, скорее всего, использовать любую из этих двух архитектур, поскольку она представляет собой небольшую организацию с умеренными требованиями к обработке. Однако для рабочих групп большего размера потребуется клиент-серверная архитектура. Эти подходы будут подробно описываться и обсуждаться в главе 17.
Базы данных с использованием интернет-технологий
Как было показано на примере туристического информационного центра Калверт-Айленда, технология баз данных применяется в настоящее время в сочетании с технологией публикации данных в Web. Эта же технология используется и для публикации приложений в корпоративных и организационных интрасетях. Некоторые эксперты полагают, что в будущем все приложения баз данных будут доставляться пользователям при помощи браузеров и связанных с этим интернет-технологий — даже персональные базы данных, которые «публикуются» для одного человека.
Существует две категории приложений, использующих интернет-технологии. Первая категория включает в себя чистые web-приложепия баз данных, как это было в случае с островом Калверт-Айленд. Вторая категория — традиционные персональные, коллективные и организационные базы данных, которые не публикуются в Интернете, но используют браузеры и технологии, подобные DHTML и XML. Поскольку называть последнюю категорию интериет-базами данных было бы некорректно, в этой книге обе категории объединены под термином базы данных с использованием интернет-технологий.
Эта категория находится сегодня на переднем крае технологии баз данных. Как вы узнаете из главы 14, язык XML исключительно хорошо отвечает потребностям приложений баз данных и служит основой для многих новых продуктов и услуг в этой сфере.
46
Глава 1. Введение в базы данных
Распределенные базы данных
Прежде чем мы завершим этот исторический обзор, необходимо обсудить два аспекта технологии баз данных, которые теоретически представляют важность, но еще не получили широкого применения. Этими аспектами являются распределенные и объектно-ориентированные базы данных. Мы обсудим их более подробно в главах 17 и 18 соответственно.
Организационные базы данных решают проблемы, характерные для систем обработки файлов, и обеспечивают более целостную обработку данных организации. Персональные и коллективные базы данных переносят технологию баз данных еще ближе к пользователям, так как управляются локально. Распределенные базы данных (distributed databases) сочетают в себе эти два типа, позволяя объединять между собой персональные, коллективные и организационные базы данных в целостные, но распределенные системы. Как таковые, они теоретически обеспечивают более гибкие варианты доступа к данным и их обработки, но в то же время ставят проблемы, многие из которых не решены до сих пор.
Сущность распределенных баз данных заключается в том, что все данные организации распылены между многими компьютерами — микрокомпьютерами, серверами локальных сетей и большими ЭВМ, которые взаимодействуют между собой в процессе обработки базы данных. Цель этих систем в том, чтобы у каждого пользователя возникало ощущение, что он — единственный пользователь данных организации, и чтобы при этом обеспечивались такие же согласованность, точность и быстродействие, какие были бы, если бы этой распределенной базой данных больше никто не пользовался.
Среди наиболее актуальных проблем распределенных баз данных можно упомянуть проблемы безопасности и контроля. Обеспечить доступ к базе данных для столь большого количества пользователей (а конкурирующих пользователей могут быть сотни) и проконтролировать, какие действия они выполняют с распределенной базой данных, — это непростые задачи.
Координация и синхронизация обработки могут вызывать затруднения. Если одна группа пользователей загружает и обновляет часть базы данных, а затем передает модифицированные данные обратно на большую ЭВМ, то как может система в это же время предотвратить попытку другого пользователя использовать старую версию данных, находящуюся в настоящий момент на большой ЭВМ? Представьте себе, что в этот процесс вовлечено огромное количество файлов, сотни пользователей и множество различного компьютерного оборудования.
Если переход от организационных баз данных к персональным и затем к коллективным происходил достаточно легко, то трудности, стоящие перед проектировщиками и разработчиками распределенных СУБД, монументальны. По правде говоря, даже при том, что работа над распределенными системами баз данных ведется вот уже более 25 лет, значительные проблемы все еще остаются. Корпорация Microsoft разработала архитектуру распределенной обработки данных и набор поддерживающих ее продуктов под названием Microsoft Transaction Server (MTS) и сейчас занимается ее построением. Хотя MTS является многообещающим проектом и среди всех компаний именно у Microsoft имеются ресурсы
Резюме
47
для разработки и продвижения на рынок подобной системы, до сих пор остается неясным, действительно ли распределенные базы данных смогут удовлетворить каждодневные потребности организаций в сфере обработки данных. Более подробную информацию по этой теме вы найдете в главе 15, в той ее части, где идет обсуждение OLE DB.
Объектно-ориентированные СУБД
В конце 1980-х годов началось использование нового стиля программирования под названием объектно-ориентированное программирование (object-oriented programming), или ООП (OOP), который, как будет объяснено в главе 18, имел существенно иную ориентацию, чем традиционное программирование. Если говорить вкратце, то структуры данных, которые обрабатываются в ООП, являются значительно более сложными, чем те структуры, с которыми приходится иметь дело в традиционных языках программирования. Кроме того, сложно обеспечить хранение этих структур с помощью существующих коммерческих СУБД. Как следствие возникает новая категория СУБД — объектно-ориентированные СУБД (object oriented DBMS), предназначенные для хранения и обработки структур данных ООП.
По множеству причин ООП еще не получило широкого применения в деловых информационных системах. Во-первых, оно является сложным в использовании, а разработка приложений ООП стоит очень дорого. Во-вторых, у большинства организаций миллионы или миллиарды байтов данных организованы в реляционные базы данных, и они не желают брать на себя риск и расходы, связанные с преобразованием этих баз данных в формат объектно-ориентированных СУБД. Наконец, большинство объектно-ориентированных СУБД были разработаны для поддержки инженерных приложений, и они просто не обладают возможностями и функциями, подходящими или быстро адаптируемыми для нужд деловых приложений.
Следовательно, в обозримом будущем объектно-ориентированные СУБД, скорее всего, не будут широко использоваться в приложениях коммерческих информационных систем. Мы обсудим ООП, объектно-ориентированные базы данных и принадлежащий Oracle Corporation гибрид под названием объектно-реляционные базы данных (object-relational databases) в главе 18, но в основном этот рассказ будет посвящен реляционной модели, поскольку она связана с технологиями, которые вы наверняка будете использовать в течение первых пяти лет вашей карьеры.
Резюме
Базы данных — один из наиболее важных курсов, связанных с информационными системами. Навыки и знания, приобретаемые в ходе изучения этого курса, пользуются большим спросом не только для традиционных приложений, но также для приложений, использующих интернет-технологию в открытых и закрытых сетях.
48
Глава 1. Введение в базы данных
Технология баз данных используется во множестве приложений. Некоторые из них предназначены для единственного пользователя с единственным компьютером, другие используются рабочими группами в количестве 20-30 человек через локальную сеть, третьи служат сотням пользователей и содержат триллионы байтов данных. В последнее время технология баз данных применяется в сочетании с интернет-технологией для поддержки мультимедийных приложений в открытых и закрытых сетях.
Компонентами приложения базы данных являются сама база данных, система управления базой данных (СУБД) и прикладные программы. Иногда прикладные программы действуют полностью независимо от СУБД, а иногда значительная часть функциональности приложения обеспечивается за счет возможностей и функций СУБД.
Системы обработки файлов хранят данные в отдельных файлах, каждый из которых содержит свой тип данных. Эти системы имеют несколько ограничений. Данные, хранимые в отдельных файлах, трудно комбинировать, поскольку они зачастую дублируются в разных файлах, что приводит к нарушениям целостности данных. Прикладные программы зависят от форматов файлов, что вызывает проблемы при обслуживании: когда форматы меняются, файлы становятся несовместимыми, и требуется их преобразовывать. Трудно также представить данные в удобном для пользователя виде.
Системы обработки баз данных были разработаны для того, чтобы преодолеть эти ограничения. В базе данных СУБД служит интерфейсом между прикладными программами и базой данных. Данные интегрированы, и они не дублируются столь часто. Изменение физических форматов файлов затрагивает только СУБД. Если элементы данных изменяются, добавляются или удаляются, лишь немногие из прикладных программ требуют модификации. Технология баз данных упрощает представление данных в удобном для пользователя виде.
База данных — это самодокументированное собрание интегрированных записей. Она является самодокументированной, так как содержит описание самой себя в словаре данных. Словарь данных известен также как каталог данных, или метаданные. База данных является собранием интегрированных записей, поскольку связи между записями также хранятся в базе данных. Такая организация позволяет СУБД конструировать даже весьма сложные объекты, комбинируя данные на основании хранимых связей. Связи часто хранятся как избыточные данные. Таким образом, три составляющие базы данных — это данные приложений, словарь данных и избыточные данные.
Технология баз данных развивалась в несколько стадий. Ранние базы данных фокусировались на обработке транзакций с данными организации. Затем появление реляционной модели и микрокомпьютеров привело к созданию персональных приложений баз данных. С появлением локальных сетей началась разработка коллективных баз данных с клиент-серверной архитектурой. Сегодня традиционные приложения баз данных доставляются пользователю с помощью интернет-технологий. Важными направлениями в отрасли баз данных являются распределенные и объектно-ориентированные базы данных. Сегодня, однако, ни одно из этих двух направлений не стало коммерчески успешным и не получило широкого применения в деловых приложениях.
Вопросы группы I
49
Вопросы группы I
1.	В чем состоит важность изучения баз данных?
2.	Опишите сущность и характеристики приложений однопользовательских баз данных, применяемых отдельными пользователями, такими как Мэри Ричардс.
3.	Опишите сущность и характеристики приложений коллективных баз данных, используемых рабочими группами, такими как бюро проката Treble Clef Music.
4.	Опишите сущность и характеристики приложений баз данных, используемых такими организациями, как Государственное бюро выдачи водительских прав и регистрации транспортных средств.
5.	Опишите сущность и характеристики приложений баз данных, используемых такими организациями, как туристический информационный центр острова Калверт-Айленд.
6.	Объясните сущность и функции каждого компонента на рис. 1.7.
7.	Как со временем меняются взаимоотношения между прикладными программами и СУБД?
8.	Перечислите ограничения систем обработки файлов, как они описаны в этой главе.
9.	Объясните, каким образом технология баз данных преодолевает ограничения, перечисленные вами в ответе на вопрос 8.
10.	Определите термин база данных.
И. Что такое метаданные? Что такое индексы? Что такое метаданные приложений?
12.	Объясните, почему база данных является моделью. Опишите различие между моделью реальности и моделью пользовательской модели реальности. Почему важно это различие?
13.	Дайте пример приложения персональной базы данных, отличный от приведенного в этой главе.
14.	Дайте пример приложения коллективной базы данных, отличный от приведенного в этой главе.
15.	Дайте пример приложения базы данных для большой организации, отличный от приведенного в этой главе.
, 16. Перечислите недостатки, которыми обладали ранние приложения организационных баз данных.
. 17. Каковы два основных преимущества реляционной модели?
• 18. Опишите вехи развития микрокомпьютерных СУБД.
‘ 19. Что было основным фактором, давшим толчок развитию приложений коллективных баз данных?
50
Глава 1. Введение в базы данных
20.	Чем клиент-серверная архитектура отличается от многопользовательской архитектуры, применявшейся на больших ЭВМ?
21.	В чем состоит различие между интернет-приложением базы данных и приложением базы данных, использующим интернет-технологию?
22.	Дайте общую характеристику распределенной обработки данных. Перечислите некоторые наиболее серьезные проблемы, которые предстоит решить.
23.	Сформулируйте цель объектно-ориентированной базы данных. Почему такие базы данных не получили большего распространения в приложениях информационных систем?
Проекты
1. Зайдите на сайт какого-нибудь производителя компьютеров, например Dell (www.dell.com). С помощью этого сайта определите, какую модель ноутбука вы могли бы порекомендовать за сумму до $2500. Как вы думаете, сколько баз данных используется для поддержки этого сайта — одна или несколько? Какими возможностями и функциями данный сайт, по вашему мнению, в наибольшей степени обязан технологии баз данных, если иметь в виду определение базы данных и преимущества обработки баз данных?
2. Зайдите на сайт какой-нибудь книготорговой компании, например Amazon (www.amazon.com). Найдите с помощью этого сайта наиболее свежую из опубликованных автобиографий Уильяма Вордсворта (William Wordsworth). Как вы думаете, сколько баз данных используется для поддержки этого сайта — одна или несколько? Какими возможностями и функциями данный сайт, по вашему мнению, в наибольшей степени обязан технологии баз данных, если иметь в виду определение базы данных и преимущества обработки баз данных?
Вопросы к проекту Firedllp
FiredUp, Inc. — небольшая компания, владельцами которой являются Керт и Джули Роубэрдс. Эта компания, находящаяся в Брисбэйне, Австралия, производит и продает легкие походные горелки под названием FireNow. Керт, работавший раньше аэрокосмическим инженером, изобрел и запатентовал сопло, которое не дает огню в горелке погаснуть даже при очень сильном ветре — до 90 миль в час. Джули, промышленный дизайнер по образованию, разработала элегантную складную конструкцию, которая имеет небольшой вес и габариты, проста в установке и весьма устойчива. Семья Роубэрдс производит горелки в своем гараже и продает клиентам напрямую, принимая заказы через Интернет, по факсу и по почте.
Вопросы к проекту Firedllp
51
Владельцы FiredUp хотели бы отслеживать проданные горелки на тот случай, если им понадобится войти в контакт с покупателями относительно дефектов в изделиях и по другим вопросам, связанным с качеством изделий. Они также думают, что смогут использовать список покупателей для рекламы других изделий, если когда-нибудь разработают что-либо еще.
1. Как вы думаете, подойдет ли база данных FiredUp для хранения данных о проданных горелках и их покупателях? Опишите условия, при которых, по вашему мнению, база данных будет подходящим средством, а при каких — неподходящим. Сформулируйте, при каких условиях им подойдет персональная база данных. При каких условиях им может понадобиться коллективная база данных? Интернет-база данных?
2. Решите ту же задачу применительно к регистрации кофейных автоматов, продаваемых компанией Starbucks. Пусть, например, Starbucks хочет иметь возможность хранить сведения о клиентах, которые приобрели в магазинах этой компании автоматы для продажи кофе «эспрессо». Как изменятся ответы па вопросы первого пункта?
Глава 2
Введение в разработку баз данных
В этой главе в общих чертах рассматривается процесс разработки базы данных и ее приложений. Мы начнем с описания элементов базы данных и обсуждения характерных особенностей и функций СУБД. Далее мы проиллюстрируем процесс создания базы данных и приложения для работы с ней. В заключение мы обсудим популярные стратегии разработки баз данных. Цель этой главы состоит в том, чтобы заложить основу для детального описания этой технологии, которое последует в дальнейших главах.
База данных
На рис. 2.1 показаны основные компоненты системы базы данных. Базу данных обрабатывает СУБД, которая используется разработчиками и пользователями, обращающимися к СУБД напрямую или косвенно, через прикладные программы. Данный раздел посвящен базе данных, а СУБД и прикладные программы обсуждаются в следующих разделах.
Как вам уже известно из главы 1, база данных состоит из четырех основных элементов: данных пользователя, метаданных, индексов и метаданных приложений.
Данные пользователя
Сегодня большинство баз данных представляют данные пользователя в виде отношений (relations). Формальное определение термина отношение мы дадим в главе 5. На данный же момент будем рассматривать отношение как таблицу данных. Столбцы таблицы содержат поля, или атрибуты, а строки содержат записи о конкретных объектах делового мира.
Не все отношения являются одинаково желательными; некоторые отношения структурированы лучше, чем другие. В главе 5 описан процесс, называемый нормализацией (normalization), с помощью которого получаются хорошо структурированные отношения. Чтобы получить представление о разнице между плохо и хорошо структурированными отношениями, рассмотрим отношение R1 (ИмяСту-
База данных
53
дента, ТелефонСтудента, ИмяРуководителя, ТелефонРуководителя), содержащее имена и телефоны студентов и их руководителей:
ИмяСтудента	ТлфСтудента	ИмяРуковод	ТлфРуковод
Бейкер, Рекс	232-8897	Паркс	236-0098
Чарлз, Мэри	232-0099	Паркс	236-0098
Джонсон, Бет	232-4487	Джонс	236-0110
Скотт, Гленн	232-4444	Паркс	236-0098
Зилог, Фрита	232-5588	Джонс	236-0110
Средства проектирования
Средство для создания таблиц
База данных
Я д р о
Средство для создания формул
Средство для создания запросов
Разработчик
Средство для создания отчетов
Прикладные программы
С
Подсистема обработки
Б д
База данных содержит
Данные пользователей
Метаданные
Индексы
Метаданные приложений
Процессор форм
Процессор запросов
Генератор отчетов
Пользователи

Средства обработки, реализованные на процедурных языках
Прикладные программы
СУБД
Рис. 2.1. Компоненты системы базы данных
Недостаток этого отношения состоит в том, что оно содержит данные, принадлежащие двум различным темам — студентам и руководителям. Такая структура отношения порождает определенные проблемы при его обновлении. Например, если у руководителя по фамилии Паркс изменится номер телефона, необходимо будет изменить три строки данных. По этой причине было бы лучше представить данные в виде двух отношений. Первое из них, R2 (ИмяСтудента, ТелефонСтудента, ИмяРуководителя), будет содержать имя и телефон студента и фамилию его руководителя:
ИмяСтудента	ТлфСтудента	ИмяРуковод
Бейкер, Рекс	232-8897	Паркс
Чарлз, Мзри	232-0099	Паркс
продолжение#
54
Глава 2. Введение в разработку баз данных
		
ИмяСтудента	ТлфСтудента	ИмяРуковод
Джонсон, Бет	232-4487	Джонс
Скотт, Гленн	232-4444	Паркс
Зилог, Фрита	232-5588	Джонс
Второе отношение, R3 (ИмяРуководителя, Телефон Руководителя), будет содержать фамилию и телефон руководителя:
ИмяРуковод	ТлфРуковод
Паркс	236-0098
Джонс	236-0110
Теперь, если у руководителя изменится номер телефона, необходимо будет изменить только одну строку в отношении R3. Разумеется, чтобы сформировать отчет, в котором были бы представлены имена студентов вместе с именами их руководителей, нужно будет объединить строки этих двух таблиц. Оказывается, однако, что гораздо лучше хранить отношения раздельно и объединять их при составлении отчета, чем хранить их в виде одной комбинированной таблицы.
Метаданные
Как было указано в главе 1, база данных является самодокументированной, то есть одной из ее составляющих является описание собственной структуры. Это описание называется метаданными (metadata). Так как СУБД предназначены для хранения таблиц и манипуляции ими, большинство из них хранят метаданные в форме таблиц, иногда называемых системными таблицами (system tables).
В табл. 2.1 представлены два примера хранения метаданных в системных таблицах. В таблице SysTables перечислены все таблицы, имеющиеся в базе данных, и для каждой таблицы указаны количество столбцов и имена одного или нескольких столбцов, служащих первичным ключом. Такой столбец или набор столбцов является уникальным идентификатором строки. В таблице SysColumns перечислены столбцы, имеющиеся в каждой таблице, а также тип данных и ширина каждого столбца. Эти две таблицы представляют собой типичные образцы системных таблиц; в других подобных таблицах хранятся списки индексов, ключей, хранимых процедур и т. п.
Таблица 2.1. Примеры метаданных
Таблица SysTables Имя таблицы	Число столбцов	Первичный ключ
Студент	4	НомерСтудента
Руководитель	3	ИмяРуководителя
Дисциплина	3	НомерДисциплины
УчебныйПлан	3	{НомерСтудента, НомерДисциплины}
База данных
55
Таблица SysColumns Имя столбца	Имя таблицы	Тип данных	Длина1
НомерСтудента	Студент	Integer	4
Имя	Студент	Text	20
Фамилия	Студент	Text	30
Специальность	Студент	Text	10
ИмяРуководителя	Руководитель	Text	25
Телефон	Руководитель	Text	12
Кафедра	Руководитель	Text	15
НомерДисциплины	Дисциплина	Integer	4
Название	Дисциплина	Text	10
КоличествоЧасов	Дисциплина	Decimal	4
НомерСтудента	УчебныйПлан	Integer	4
НомерДисциплины	УчебныйПлан	Integer	4
Курс	УчебныйПлан	Text	2
Хранение метаданных в таблицах не только эффективно для СУБД, но и удобно для разработчиков, поскольку для запроса метаданных они могут использовать те же самые средства, что и для запроса пользовательских данных. В главе 9 мы обсудим язык под названием SQL, который используется для запроса и обновления таблиц метаданных и пользовательских данных.
В качестве возможного примера использования SQL представьте, что вы разработали базу данных с 15 таблицами и 200 столбцами. Вы помните, что некоторые столбцы имеют тип данных currency, но не можете вспомнить, какие именно. С помощью SQL можно обратиться к таблице SysColumns и по ней определить, какие столбцы имеют указанный тип данных.
Индексы
Третий тип данных, которые хранятся в базе данных, призван улучшить ее производительность и доступность. Эти данные, называемые иногда избыточными данными (overhead data), состоят главным образом из индексов (indexes), хотя в ряде случаев используются и другие структуры данных, такие как связанные списки (индексы и связанные списки обсуждаются в приложении А).
В табл. 2.2 приведены данные о студентах и два индекса к ней. Чтобы уяснить, какая может быть польза от индексов, представьте себе, что данные в таблице СТУДЕНТ расположены в порядке возрастания значения поля НомерСтудента, а пользователь хотел бы создать из этих данных отчет, отсортированный по полю Фамилия. Для этого можно было бы извлечь все данные из таблицы и отсортировать, но, если размеры таблицы не слишком малы, этот процесс может занять много времени. В качестве альтернативы можно создать индекс Фамилия, приведенный в табл. 2.2. Записи в этом индексе отсортированы по полю Фамилия,
1 Длины приведены в байтах или, что то же самое, в символах (для текстовых данных).
56
Глава 2. Введение в разработку баз данных
поэтому достаточно считать записи из индекса в порядке следования, чтобы затем получать данные из таблицы СТУДЕНТ, отсортированные в нужном порядке.
Таблица 2.2. Примеры индексов
Таблица СТУДЕНТ			
НомерСтудента	Имя	Фамилия	Специальность
100	Джеймс	Бейкер	Бухгалтерский учет
200	Мэри	Абернати	Информационные системы
300	Бет	Джексон	Бухгалтерский учет
400	Элдридж	Джонсон	Маркетинг
500	Крис	Тафт	Бухгалтерский учет
600	Джон	Сматерс	Информационные системы
700	Майкл	Джонсон	Бухгалтерский учет
Индекс Фамилия Фамилия	НомерСтудента
Абернати Бейкер Джонсон Джонсон Сматерс Тафт	200 100 300 400, 700 600 500
Индекс Специальность Специальность	НомерСтудента
Бухгалтерский учет Информационные системы Маркетинг	100, 300, 500, 700 200, 600 400
Теперь представьте, что требуется получить данные о студентах, отсортированные по полю Специальность. Опять-таки, можно извлечь эти данные из таблицы СТУДЕНТ и отсортировать, а можно создать индекс Специальность и использовать его, как показано выше.
Индексы используются не только для сортировки, но и для быстрого доступа к данным. Пусть, например, пользователю нужны сведения только о тех студентах, чьей специальностью являются информационные системы. Без индекса пришлось бы проводить поиск по всей таблице. Имея же индекс, можно найти в нем соответствующую запись и использовать ее для нахождения нужных строк в таблице. На самом деле, если количество строк невелико, как в таблице СТУДЕНТ, индексы не нужны, но представьте себе таблицу, которая содержит 10 000 или 20 000 строк. В этом случае сортировка или поиск по всей таблице работали бы слишком медленно.
Индексы удобны для сортировки и поиска, но за их использование приходится платить свою цену. Каждый раз, когда обновляется строка в таблице СТУДЕНТ,
СУБД
57
индексы также необходимо обновлять. Это не обязательно плохо — это означает только, что индексы не даются даром и поэтому должны использоваться только в тех случаях, когда это действительно оправдано.
Метаданные приложений
Четвертый и последний тип информации в базе данных — это метаданные приложений (application metadata), которые описывают структуру и формат пользовательских форм, отчетов, запросов и других компонентов приложений. Не все СУБД поддерживают компоненты приложений, а из тех СУБД, где такая возможность предусмотрена, не все хранят структуру этих компонентов в виде метаданных приложений в базе данных. Однако большинство современных СУБД хранят эту информацию в базе данных. Вообще говоря, ни разработчики баз данных, ни пользователи не обращаются к метаданным приложений напрямую, а пользуются соответствующими средствами, которые предоставляет СУБД.
СУБД
СУБД значительно различаются по своим характеристикам и функциям. Первые продукты такого рода были разработаны для больших ЭВМ в конце 1960-х годов и были весьма примитивны. С тех пор СУБД постоянно совершенствовались, а функции их расширялись. Усовершенствования касались не только обработки баз данных: СУБД также снабжались функциями, упрощающими создание приложений баз данных.
В этой главе для иллюстрации возможностей СУБД мы будем использовать Microsoft Access 2002. Это обусловлено тем, что Access 2002 обладает всеми типичными характеристиками и функциями современной СУБД. Однако Access 2002 не является единственной СУБД такого рода, и наш выбор ни в коей мере не предполагает какого-либо предпочтения перед другими подобными продуктами, например Lotus Approach.
Как видно из рис. 2.1, характеристики и функции СУБД можно разделить на три подсистемы: подсистему средств проектирования, подсистему средств обработки и ядро СУБД.
Подсистема средств проектирования
Подсистема средств проектирования (design tools subsystem) представляет собой набор инструментов, упрощающих проектирование и реализацию баз данных и их приложений. Как правило, этот набор включает в себя средства для создания таблиц, форм, запросов и отчетов. В СУБД имеются также языки программирования и интерфейсы для них. Например, в Access есть два языка: макроязык, не требующий глубокого знания программирования, и версия языка BASIC под названием Visual Basic.
58
Глава 2. Введение в разработку баз данных
Подсистема обработки
Подсистема обработки (run-time subsystem)1 занимается обработкой компонентов приложения, созданных с помощью средств проектирования. Например, в Access 2002 имеется компонент, материализующий формы и связывающий элементы форм с данными таблиц. Представьте себе форму с текстовым полем, где отображается значение столбца НомерСтудента из таблицы СТУДЕНТ. В процессе работы приложения при открытии формы процессор форм (form processor) извлекает значение поля НомерСтудента из текущей строки таблицы и отображает его в форме. Все это делается автоматически — ни пользователю, ни разработчику не требуется ничего делать, если имеется готовая форма. Другие процессоры подсистемы обработки предназначены для выполнения запросов и вывода отчетов. Кроме того, в подсистеме обработки имеется компонент, обрабатывающий запросы прикладных программ на чтение и запись данных в базу.
Хотя это не показано на рис. 2.1, СУБД должны также предоставлять интерфейс для стандартных языков программирования, таких как C++ и Java. Дальнейшую информацию об этом вы получите из глав 15 и 16.
Ядро СУБД
Третий компонент СУБД — это ее ядро (DBMS engine), которое выполняет функцию посредника между подсистемой средств проектирования и обработки и данными. Ядро СУБД получает запросы от двух других компонентов, выраженные в терминах таблиц, строк и столбцов, и преобразует эти запросы в команды операционной системы, выполняющие запись и чтение данных с физического носителя.
Кроме того, ядро СУБД участвует в управлении транзакциями, блокировке, резервном копировании и восстановлении. Как будет показано в главе И, действия с базой данных должны выполняться как единое целое. Например, при обработке заказа изменения в таблицах КЛИЕНТ, ЗАКАЗ и СКЛАД должны производиться согласованно: либо выполняются все, либо не выполняется ни одно. Ядро СУБД помогает координировать действия, с тем чтобы либо выполнялись все действия в группе, либо не выполнялись ни одного.
Microsoft предоставляет два различных ядра для Access 2002: Jet Engine и SQL Server. Ядро Jet Engine используется для небольших персональных и коллективных баз данных. Ядро SQL Server, представляющее собой независимый продукт Microsoft, предназначено для крупных баз данных уровня отдела и небольших
1 В английском языке подсистема обработки обозначается термином run-time subsystem. Не следует путать его с похожим термином run-time product, который имеет несколько другое значение. Этим термином некоторые производители обозначают урезанный вариант комплектации СУБД, куда входят подсистема обработки и ядро, но не входит подсистема средств проектирования. Такой вариант позволяет лишь запускать готовое приложение. Назначение таких продуктов в том, чтобы снизить стоимость приложения для конечного пользователя. Обычно СУБД без подсистемы средств разработки стоит намного дешевле, чем полноценная СУБД, а иногда и вовсе бесплатна. Следовательно, полную версию продукта покупает только разработчик, а конечные пользователи покупают сокращенную версию.
Создание базы данных
59
или среднего размера организационных баз данных. Когда вы создаете базу данных с помощью встроенных в Access 2002 средств генерации таблиц (такие базы данных хранятся вместе с suffix.mdb), вы используете Jet Engine. Создавая проект Access 2002 (с suffix.adp), вы тем самым создаете прикладной интерфейс для ядра SQL Server.
Создание базы данных
Схема базы данных (database scheme) определяет структуру базы данных, ее таблиц, связей и доменов, а также деловой регламент. Схема базы данных — это проект, основа, на которой строятся база данных и ее приложения.
Пример схемы базы данных
Чтобы уяснить себе, что такое схема базы данных и зачем она нужна, рассмотрим пример. Колледж Highline — небольшой колледж свободных искусств на Среднем Западе США. Отдел студенческого досуга колледжа финансирует локальные спортивные секции, но испытывает проблемы с учетом спортивного инвентаря, выданного капитанам различных команд. Схема базы данных для системы учета спортинвентаря будет содержать следующие компоненты.
Таблицы
База данных имеет две таблицы1: CAPTAIN (CaptainName, Phone,Street, City, State, ZIP), содержащую сведения о капитанах, и ITEM (Quantity, Description, Datein, DateOut), содержащую данные об инвентаре. Здесь перед скобками даны имена таблиц, а в скобках указываются имена столбцов.
Ни CaptainName (имя капитана), ни Description (описание) не обязаны быть уникальными, поскольку вполне может быть два капитана по имени Мэри Смит, и уж наверняка имеется много инвентаря под названием «футбольные мячи». Чтобы обеспечить однозначную идентификацию каждой строки (важность этого будет объяснена в последующих главах), мы добавим в каждую из этих таблиц столбец с уникальным номером, как показано ниже:
CAPTAIN(CAPTAIN_ID, CaptainName, Phone, Street, City, State, ZIP)
ITEM(ITEM_ID, Quantity, Description, Datein, DateOut)
Связи
Две представленные здесь таблицы имеют следующие связи: одна строка таблицы CAPTAIN связана с несколькими строками таблицы ITEM, но одна строка таблицы ITEM связана с одной и только одной строкой таблицы CAPTAIN. Такая связь обозначается 1:Nи произносится «один kN» или «один ко многим». Обозначение
1 Как будет показано в главах 3-7, наиболее важной и сложной задачей при разработке баз данных , является проектирование структуры таблиц. Начав этот пример с уже готовых таблиц, мы опустили большую часть проекта.
60
Глава 2. Введение в разработку баз данных
1:N следует понимать так, что одна строка в первой таблице связана с несколькими строками во второй таблице.
По тем обозначениям таблиц, которые даны выше, невозможно сказать, какая строка таблицы CAPTAIN связана с какими строками таблицы ITEM. Поэтому, чтобы обозначить их связь, мы добавим в таблицу ITEM столбец CAPTAIN_ID. Полная структура двух таблиц выглядит следующим образом:
CAPTAIN(CAPTAIN_ID, CaptainName, Phone, Street, City, State, ZIP) ITEM(ITEM_ID, Quantity, Description, Datein, DateOut, CAPTAINJD)
При такой структуре легко определить, какому капитану был выдан данный инвентарь. Например, чтобы узнать, кому был выдан инвентарь за номером 1234, в соответствующей строке таблицы ITEM мы найдем значение CAPTAINJD. По этому номеру мы сможем определить имя и номер телефона данного капитана.
Домены
Домен1 (domain) — это множество значений, которые может принимать столбец. Рассмотрим домены для столбцов таблицы ITEM. Предположим, что ITEMJD и Quantity (количество) — целые числа, Description — текст с максимальной длиной 25 символов, Datein и DateOut (даты выдачи и возврата) имеют тип «дата», a CAPTAIN_ID также является целым числом. Кроме задания физического формата, нам также необходимо решить, будут ли какие-либо из доменов уникальными для данной таблицы. В нашем примере мы хотим, чтобы столбец ITEM_ID был уникальным, поэтому необходимо указать это в определении домена. Поскольку капитану может быть выдано более одной единицы инвентаря, столбец CAPTAIN_ ID не является уникальным для таблицы ITEM.
Необходимо также задать домены для столбцов таблицы CAPTAIN. CAPTAINJD является целым числом, а все остальные столбцы — это текстовые поля различной длины. CAPTAIN_ID должен быть уникальным для таблицы CAPTAIN.
Деловой регламент
Последний элемент схемы базы данных — это деловой регламент (business rules), представляющий собой ограничения на возможные действия пользователя, которые необходимо отразить в базе данных и ее приложениях. Примером делового регламента для колледжа Highline может служить следующий набор правил:
1.	Чтобы капитан мог получить на руки какой-либо инвентарь, у него должен быть местный телефон.
2.	Ни за одним капитаном не должно числиться более семи футбольных мячей.
3.	По окончании каждого семестра капитаны обязаны возвратить весь инвентарь в течение пяти дней.
4.	Капитан не может получить на руки новый инвентарь, если у него имеется задолженность по ранее взятому инвентарю.
1 Это определение значительно упрощено, с тем чтобы сконцентрироваться на компонентах системы базы данных. Более полное обсуждение доменов происходит в главе 4.
Создание базы данных
61
Деловой регламент является важной частью схемы, поскольку он задает такие ограничения на возможные значения данных, которые должны выполняться в любом случае, независимо от того, каким образом изменения достигают ядра СУБД. Не важно, что является источником запроса на изменение данных — пользователь формы, запрос на обновление/чтение или прикладная программа: СУБД должна позаботиться о том, чтобы эти изменения не нарушили никаких правил.
К сожалению, реализация делового регламента осуществляется в различных СУБД по-разному. В Access 2002 некоторые правила могут задаваться в схеме и выполняться автоматически. В таких продуктах, как SQL Server и Oracle, деловой регламент реализуется с помощью так называемых хранимых процедур (stored procedures). В некоторых случаях СУБД оказывается неспособной реализовать выполнение требуемых правил, и их приходится закладывать в прикладные программы. Мы обсудим эту тему более подробно в главе 10.
Создание таблиц
Следующим шагом после разработки схемы базы данных является создание таблиц. Для этого используются специализированные средства, предоставляемые СУБД. На рис. 2.4 показан вид окна, используемого Microsoft Access при создании таблицы ITEM. Имя каждого столбца создаваемой таблицы указывается в столбце Field Name (Имя поля), а тип данных задается в столбце Data Туре (Тип данных). В столбце Description (Описание), не обязательном к заполнению, даются описания столбцов таблицы и комментарии. Дополнительные данные по каждому столбцу — количество символов, формат, заголовок и прочее — указываются в полях ввода группы Field Properties (Свойства поля), расположенной в нижней части окна.
На рис. 2.2 фокус ввода находится на столбце ITEM_ID. Обратите внимание, что свойство Indexed (Индексируется) в нижней части окна установлено в значение Yes (No Duplicates), что означает, что для столбца ITEM_ID должен быть создан индекс из уникальных значений. Таблица CAPTAIN создается аналогичным образом.
Определение связей
Связь между таблицами CAPTAIN и ITEM имеет вид 1:N, что изображается на схеме путем помещения ключа таблицы CAPTAIN в таблицу ITEM. Столбец, играющий ту же роль, что и столбец CAPTAIN_ID в таблице ITEM, называется иногда внешним ключом (foreign key), поскольку он является ключом таблицы, внешней по отношению к той таблице, в которой он находится. При создании форм, запросов и отчетов СУБД может оказать большую помощь разработчику, если она знает, что столбец CAPTAIN_ID в таблице ITEM является внешним ключом таблицы CAPTAIN. В различных СУБД статус внешнего ключа объявляется по-разному. В Microsoft Access для этого рисуется связь между ключом и внешним ключом, как показано на рис. 2.3. Столбец CAPTAINJD основной таблицы (CAPTAIN) соответствует столбцу CAPTAINJD в связанной с ней таблице (ITEM).
62
Глава 2. Введение в разработку баз данных

В ITEM: Table
-l~i х|
ITEM.ipl Quantity....
Description DateOut Patein CAPTAINjb'
Fiehwam»
AutoNumber Number Text Date/Time Date/Time.
Number
: Surrogate key j Quantity checked out......................
• Desertion of item : Date checked out . Date checked in..........................
= Foreign key for i :N relationship to CAPTAIN
Genetti j Lookup | Feld Size Г MewValues Format :- ?
Caption й |Г indexed..:
c-.rg Integer
Increment
'A Field name can. be up L 64 chahacce-rs long,
. ^Juding. spaces. Press
? Fl on Field
; names.
Рис. 2.2. Создание таблицы в Microsoft Access 2002
|Edk ReialMinsliipi
Enforce Referent (ntegtty 
Tabe?Query-. Plated Table IQuerv
[CAPTAIN	-^llTEM	'
CAPTMNJD	LlJ CAPTAIN._ID ~	7*

Relationship Type;: ; Qne-To-Wany
Рис. 2.3. Объявление связи в Microsoft Access 2002
Одним из преимуществ объявления связи для СУБД является то, что когда данные из столбцов двух таблиц считываются в форму, запрос или отчет, СУБД знает, как связаны строки этих таблиц. Хотя эту связь можно указать для каждой конкретной формы, запроса или отчета, однократное объявление экономит время и снижает вероятность ошибок. На прочие элементы в окне Edit Relationship (Редактировать связь) мы пока не будем обращать внимания: о них
Компоненты приложения
63
вы узнаете в ходе дальнейшего изложения. Когда определены таблицы, столбцы и связи, следующим шагом является построение компонентов приложения.
Компоненты приложения
Приложение базы данных состоит из форм, запросов, отчетов, меню и прикладных программ. Как показано на рис. 2.1, формы, запросы и отчеты можно создавать с помощью средств, поставляемых в комплекте с СУБД. Прикладные программы должны быть написаны либо на входном языке СУБД, либо на одном из стандартных языков и затем посредством СУБД соединены с базой данных.
Формы
На рис. 2.4 изображены три различных представления данных, содержащихся в таблицах CAPTAIN и ITEM. На рис. 2.4, а данные представлены в табличном формате. Щелкнув мышью на знаке «плюс», имеющемся в начале каждой строки, пользователь может увидеть записи из таблицы ITEM, связанные с конкретной строкой таблицы CAPTAIN. Это было проделано во второй строке для капитана с фамилией Abernathy. Обратите внимание, что со строкой Abernathy связаны две строки таблицы ITEM.
На рис. 2.4, б показан второй вид представления — в виде формы для ввода данных (data entry form). В этой форме в каждый момент времени отображаются данные для одного капитана. Неопытные пользователи, скорее всего, найдут это представление более простым в использовании, чем табличный формат.
К странице регистрации капитанов, показанной на рис. 2.4, в, можно обращаться через Интернет или университетскую интрасеть, используя браузер Microsoft Internet Explorer. Для этого страница должна храниться на web-сервере, подобном Internet Information Server. Дальнейшую информацию об этом вы получите из глав 14-16. На данный момент следует просто знать, что такие формы можно создавать с помощью средств, входящих в состав Access 2002.
Табличное представление автоматически генерируется Access 2002 для каждой таблицы, определенной в схеме базы данных. Формы для ввода данных, однако, должны создаваться с помощью генераторов форм. На рис. 2.5 показан один из способов создания такой формы. В качестве источника данных для новой формы заявлена таблица CAPTAIN (не показана на рисунке). Access выводит окно, называемое списком полей (field list), в котором перечислены все столбцы таблицы CAPTAIN. На рисунке пользователь перетащил (drag-n-drop) поле CaptainName из списка полей в форму. В ответ на это Access создал метку с названием CaptainName и поле ввода, куда будут вводиться значения CaptainName. Теперь поле ввода привязано (bound) к столбцу CaptainName таблицы CAPTAIN. Другие столбцы таблицы привязываются аналогичным образом; столбцы таблицы ITEM привязываются к форме с помощью средства, называемого субформой (subform). В Access имеется также мастер форм, позволяющий создавать формы наподобие той, что изображена на рис. 2.4, б.
64
Глава 2. Введение в разработку баз данных
 CAPTAIN: Table
Street;
а
+ Miyamoto, Mary '398 232 1770 McGiIvra Hall #644	Campus
“ ДЬетЭ{Ьу....Магу Заупе _: 223 768.3378 777 East Fiftieth	Chicago
____I^^sHEIiZ^ZZZZIZinZZnsZiES^ZZEZIZZZZI^EIlInZZZZZ
____	14 Soccer Shirts	3/22/2001	6/3/2001
____	__	5 Soccer Balls	3/22/2001	6Z3/2Q01 * • • - 
+ Jackson Stephen :331.442.1454 300 East Centerview Apt 22 Evanston

323398
'IL 2234?
Ж
Recwd: l<|  Il Г > |»>|>*1 of 3
Рис. 2.4. Представление данных из таблиц CAPTAIN и ITEM: а — табличный формат; б — форма для ввода данных; в — форма для ввода данных в браузера
Ни в одной из представленных форм не отображаются столбцы CAPTAIN_ID и ITEMJD. Эти идентификаторы скрыты от пользователя. Но СУБД автоматически присваивает им новые значения, когда пользователь создает новые строки в таблицах CAPTAIN или ITEM. Так, когда пользователь открывает пустую фор
Компоненты приложения
65
му, СУБД автоматически создает новую строку в таблице CAPTAIN и присваивает значение столбцу CAPTAIN_ID этой строки. Каждый раз, когда пользователь создает для капитана новую строку в таблице ITEM, СУБД присваивает значение столбцу ITEM_ID этой строки, а в столбец CAPTAIN_ID новой строки помещает текущее значение CAPTAIN_ID. Обратимся вновь к рис. 2.2. Для столбца ITEM_ID был заявлен тип данных AutoNumber (Автонумерация). Это предписывает Access автоматически присваивать ITEM_ID новые значения всякий раз, когда создаются новые строки в таблице ITEM. При создании таблицы CAPTAIN (не показана на рисунке) аналогичный вариант был выбран и для CAPTAIN_ID. Заметьте, однако, что для столбца CAPTAIN_ID в таблице ITEM автоматическая нумерация не задается. Это обусловлено тем, что новое значение CAPTAIN_ID присваивается при добавлении строки в таблицу CAPTAIN; это значение затем копируется в поле CAPTAINJD таблицы ITEM, когда строка этой таблицы привязывается к определенному капитану.
Рис. 2.5. Создание формы в Microsoft Access 2002
Почему же эти идентификаторы скрыты от пользователей? Дело в том, что для пользователей они не имеют смысла. Колледж Highline не присваивает идентификаторы капитанам или выдаваемому на руки инвентарю (в противном случае, если бы пользователи как-то работали с этими идентификаторами, их
66
Глава 2. Введение в разработку баз данных
необходимо было бы сделать видимыми). Идентификаторы введены здесь только для того, чтобы каждая строка однозначно определялась Access, следовательно, пользователям нет нужды их видеть. Такие идентификаторы называются суррогатными ключами (surrogate keys).
Запросы
Время от времени пользователям нужно запрашивать (query) данные из базы, чтобы отвечать на вопросы, идентифицировать проблемы или обнаруживать определенные ситуации. Представьте себе, например, что один из пользователей хочет знать, имеется ли по состоянию на начало осеннего семестра 2001 г. какой-либо инвентарь, выданный до 1 сентября 2001 г., но еще не возвращенный назад. Если да, то пользователь хочет знать вид и количество такого инвентаря, а также имена капитанов, у которых он находится.
Существует множество способов реализации такого запроса. Один из способов — обратиться к помощи языка запросов (SQL), который описывается в главе 9. Другой способ заключается в том, чтобы использовать запрос по образцу (query by example, QBE). На рис. 2.6 показан процесс создания запроса по образцу в Microsoft Access. Пользователь помещает в окно запросов имена таблиц, из которых предстоит запрашивать данные. Это уже проделано в верхней части формы, изображенной на рис. 2.6. Поскольку связь между CAPTAIN и ITEM уже определена для Access (см. рис. 2.3), то Access знает, что две эти таблицы связаны через CAPTAIN_ID, как показывает линия на рис. 2.6 между двумя прямоугольниками, символизирующими таблицы.
Рис. 2.6. Создание запроса в Microsoft Access 2002
Компоненты приложения
67
Далее указывается, какие столбцы данных следует возвращать в запросе. В Access это делается путем перетаскивания имен столбцов из прямоугольников, символизирующих таблицы, в ячейки в нижней части формы. На рис. 2.8 в запрос помещены столбцы CaptainName, Phone, Quantity, Description, DateOut и Datein. После этого в строке Criteria (Критерии) указываются критерии запроса. Критерии сейчас заключаются в том, что данные должны датироваться числами, предшествующими (<) 1 сентября 2001 г. (9/1/2001 в американских обозначениях). Знак «#» в форме — это символ, который окружает даты в Access. Кроме того, значение Datein должно быть равно нулю (Is Null); это означает, что для Datein значение не задано. Результат этого запроса приведен на рис. 2.7. Обратите внимание, что весь показанный здесь инвентарь был выдан до 1 сентября 2001 г., что и требовалось в определении запроса.
В Access и большинстве других СУБД запросы можно хранить как часть приложения, так что впоследствии при необходимости они могут быть выполнены повторно. Кроме того, запросы могут быть параметризованными, то есть построенными так, чтобы значения параметров для них можно было задавать прямо перед выполнением. Например, можно параметризовать запрос, изображенный на рис. 2.6, так, чтобы пользователь вводил значение DateOut непосредственно перед выполнением запроса. В результате будет показан весь инвентарь, выданный на руки до указанной даты, ио до сих пор не возвращенный.
Третий тип запроса, более легкий для пользователей, называется запросом из формы (query by form). В этом случае пользователь вводит критерии запроса в форму для ввода данных и нажимает кнопку поиска. СУБД находит все данные, соответствующие заданным критериям. В нашем случае в форме на рис. 2.4 пользователь ввел бы <#9/1/2001# в поле DateOut и Is Null в поле Datein, после чего нажал бы кнопку QueryByForm (Запрос по форме). СУБД нашла бы записи для всех капитанов, отвечающие указанным критериям запроса. Запрос по форме является более новым и современным способом запроса данных, чем запрос по образцу, и, скорее всего, заменит его во многих приложениях.
QMicrosoft Access
151*1
Elie Edit View Insert Fgrrnat Records loots JjJfindow gelp й Щ	< 41 ll
► Miyamoto, Магу
Query 1: Select Query
CaptainName | Phune ] Quantity |..........Description | DateOut | DateirT
398 232.1770-	1 Coaches Manual	4/1/2001
NUM
-1П|х|
Е

Record; н | < |f
Date thedsd m
Рис. 2.7. Результат запроса, приведенного на рис. 2.6
68
Глава 2. Введение в разработку баз данных
Отчеты
Отчет (report) — это форматированное отображение информации из базы данных. Отчет на рис. 2.8 содержит по одному разделу на каждого капитана команды, и в каждом таком разделе приведен список инвентаря, выданного на руки данному капитану. Например, инвентарь, выданный капитану по имени Мэри Миямото (Mary Miyamoto), показан в первом разделе отчета.
Captain Equipment Report
i CaptainName	Miyamoto, Mary
\Phone	398.232.1770
j	DateOut Quantity Description	Dateln
<4/1/2001	1	Coaches Manual
4/1/200 1	7	Soccer Balls	6/10/2001
4/10/200 1	25	Blue Soccer Shirts	6/10/2001
j CaptainName	Abernathy, Mary Jayne
iPhone	223.768.3378
DateOut Quantity	Description	Dateln
3/22/2001	5	Soccer Balls	6/3/2001
3/22/2001	14	Soccer Shirts	6/3/2001
Рис. 2.8. Пример отчета для колледжа Highline
Разработка отчета напоминает разработку формы для ввода данных, хотя в некоторых случаях разработать отчет легче, поскольку он используется только для отображения данных. Иногда отчеты строить труднее, так как зачастую они имеют более сложную структуру, чем формы.
На рис. 2.9 показан процесс разработки отчета, изображенного на рис. 2.8, в Microsoft Access. Перед вами образец полосного генератора отчетов (banded report writer), который называется так потому, что отчет делится на разделы, или полосы (bands). Как видно из рисунка, в отчете имеется полоса заголовков (header band), полоса содержимого (detail band) и полоса колонтитулов (footer band). Полоса заголовка отчета (report header) содержит название отчета, а в полосе колонтитулов отображается время, когда отчет был напечатан, номер страницы и общее число страниц. Заголовок страницы (page header) пуст, а заголовок CAPTAIN_ID содержит персональные данные капитана и метки для раздела содержимого. В разделе содержимого отображается инвентарь, выданный капитану.
Компоненты приложения
69
E Microtoft Access-(Captam Equipment Repwt : Repot ГI
♦ Report Header
.Pho^
Phene
:й
J
«FageF-;
<ftepotr Fo.yer
Destgn View
Cut? Ид . LQuanH'
4 Paije Header
4 CAPTAINED Header Captain^asne
Рис. 2.9. Разработка отчета в Microsoft Access 2002
Captain Equipment Report

D<MeOu£^&intit;f Descrtplian
Недостаток этого отчета в том, что два поля с датами оказываются разделенными. Отчет выглядел бы лучше, если бы мы поместили поле DateOut между полями Description и Dateln. Это делается путем элементарного перетаскивания меток и текстовых полей, и именно таковы типичные изменения, которые делаются с помощью подобных инструментов.
Вообще говоря, отчеты могут иметь много разделов. В более сложном примере, таком как распределение студентов по курсам, отчет мог бы быть сгруппирован по таблицам КОЛЛЕДЖ, КАФЕДРА, ДИСЦИПЛИНА и СТУДЕНТ. В этом случае он имел бы три полосы заголовков и строку содержимого.
Меню
Меню (menus) предназначены для того, чтобы сделать компоненты приложения более доступными для конечного пользователя, а также для контроля действий пользователя. На рис. 2.8 показан пример меню для колледжа Highline. В полосе, находящейся в верхней части формы, изображены пункты меню верхнего уровня: File (Файл), Forms (Формы), Queries (Запросы), Reports (Отчеты) и Help (Помощь). Подчеркнутые буквы представляют «горячие» клавиши (hotkeys). Если удерживать клавишу <ALt>, нажимая при этом клавишу с подчеркнутой буквой, откроется соответствующее подменю.
На рис. 2.10 пользователь нажал клавиши <ALt> + <S>. Выбранное подменю состоит из следующих пунктов: Select ALL Records (Выбрать все записи), Select by Name (Выбрать по имени) и Select by Phone (Выбрать по номеру телефона). В свою очередь, каждый из этих пунктов можно выбрать с помощью «горячих» клавиш, нажимая <ALt> и нужную клавишу. Меню делают приложение более доступным
70
Глава 2. Введение в разработку баз данных
для пользователя, показывая существующие варианты выбора и помогая выбрать желаемое действие. Меню могут также использоваться для управления доступом пользователей к формам, отчетам и программам. Некоторые приложения пользуются этим, динамически изменяя меню после того, как пользователь зарегистрируется (sign on).
Прикладные программы
Последний компонент приложения базы данных — это прикладные программы (application programs). Как мы уже упоминали ранее, такие программы могут быть написаны на входном языке СУБД или на стандартном языке, работа которого с СУБД обеспечивается через специальный программный интерфейс. Здесь мы будем пользоваться Microsoft Visual Basic в сочетании с Access 2002.
at Htghlini Inltammal Equipment Application
£ite
flueriss R«fK»>s Нф:
> Select fill йесокЬ
SeftqtbySw®
w 
Рис. 2.10. Пример меню
Рис. 2.11. Перехват события в форме Captain Checkout Form
Пусть деловой регламент колледжа Highline содержит правило, гласящее, что капитаны, которые не живут в общежитии, не могут получать на руки руковод-
Компоненты приложения
71
ство тренера. Мы не знаем, чем обусловлено такое правило, — возможно, руководство тренера содержит секретные инструкции, которые дают Highline преимущество в соревнованиях, и колледж хочет контролировать, кому выдается это руководство. А может быть, руководства дорогие, и студентам, живущим в общежитии, легче предъявить счет в случае потери. Какой бы ни была причина, Highline хочет, чтобы приложение базы данных обеспечивало выполнение этого правила.
Есть много способов сделать это. Один из способов, показанный на рис. 2.11,— перехват события, заключающегося в изменении текстового поля Description (Описание) в субформе Item (Инвентарь) формы Captain Checkout Form, и обеспечение соблюдения указанного правила всякий раз, когда описание меняется. На рис. 2.9 разработчик открыл окно свойств для текстового поля Description и указал, что в случае изменения содержимого поля (On Change) следует перейти к процедуре обработки события (Event Procedure). После этого Access открыл окно для ввода процедуры, изображенное на рис. 2.12.
Microsoft Visual Bask - CH2DB1
Fife - £dit Vie» Insert Debug Run Tools лсИ-lns	Window< Help
it;•	ac wzmain (ACWZMAIN)
S IH2DB1 (CH2DB1)
Microsoft Access Class Object--
ES FwfnJTEMSutrfai'm
J____________________________121

|Description Textbox Alphabetic | Categorized |
ColumnWidth	:2310
< Controlsource	:Descrpt»on
A ControlTipText
; Controllype	;i09
) DecmaPfaces	;0
:) Defaultvalue
ф DisplayWhen 0
у Enabled	iTrue
EnterKevBehavior :False
j EventProcPrefix
.«131*1
► ii	О тз,сои
Рис. 2.12. Код Visual Basic, реализующий положение делового регламента
Разработчик написал фрагмент кода на Visual Basic, который будет запускаться при изменении описания. Сначала процедура определяет ситуацию, когда значение поля City (Город) не равно строке «Campus» («Общежитие»), В этом случае вызывается функция InStr, проверяющая, содержится ли в поле описания инвентаря (Description.Text) строка «Coac2hes Manual» («Руководство Тренера»). Если да, то генерируется звуковой сигнал и выдается предупреждающее сообщение, а поле Description очищается.
Этот код запускается всякий раз, когда пользователь изменяет значение текстового поля Description. Есть и другие, более эффективные способы выполнения этого правила, но здесь нашей целью было показать, как код приложения может быть связан с формами базы данных.
72
Глава 2. Введение в разработку баз данных
Разумеется, можно также написать код, работающий независимо от каких-либо форм или отчетов. Можно написать программы, читающие и обновляющие данные в базе точно так же, как это делается с файлами других типов. Примеры подобных программ вы увидите далее в этой книге, в частности в главе 15, где мы продемонстрируем использование Microsoft ADO для чтения и обновления данных на web-сервере, и в главе 16, где будет показано использование Java для той же цели.
Процесс разработки базы данных
Многие тома были посвящены разработке информационных систем вообще и приложений баз данных в частности, поэтому здесь нам нет нужды сколько-нибудь глубоко обсуждать процессы системной разработки. В завершение этой главы мы лишь кратко рассмотрим процессы, используемые для разработки баз данных и их приложений.
Общие стратегии
База данных — это модель пользовательской модели деловой активности. Поэтому, для того чтобы построить эффективную базу данных и ее приложения, команда разработчиков должна ясно представить себе пользовательскую модель. Для этого команда строит модель данных, идентифицирующую объекты, которые должны храниться в базе данных, и определяет их структуру и связи между ними. Это понимание должно быть достигнуто на ранней стадии процесса разработки путем опроса пользователей и составления технического задания (statement of requirements). Большинство таких технических заданий включают использование прототипов (prototypes) — шаблонных баз данных и приложений, представляющих различные аспекты создаваемой системы.
Есть две общих стратегии разработки баз данных: сверху вниз и снизу вверх. Разработка сверху вниз (top-down database development) идет от общего к частному. Она начинается с изучения стратегических целей организации, способов, при помощи которых эти цели ,могут быть достигнуты, требований к информации, которые должны быть удовлетворены для достижения этих целей, и систем, необходимых для предоставления такой информации. Результатом такого исследования является абстрактная модель данных.
Отталкиваясь от этой общей модели, команда разработчиков двигается «вниз», к все более и более подробным описаниям и моделям. Модели промежуточного уровня также постоянно детализируются, пока не воплотятся в конкретные базы данных и их приложения. Одно или более из этих приложений берется затем в разработку. В конце концов вся высокоуровневая модель данных трансформируется в низкоуровневые модели, после чего реализуются все указанные системы, базы данных и приложения.
Процесс разработки базы данных
73
При разработке снизу вверх (bottom-up database development) уровень абстракции меняется в обратном направлении: исходным пунктом является необходимость в конкретной системе. Способ выбора первой системы варьируется от организации к организации. В одних организациях приложение выбирается правлением, в других пользователи могут выбирать его самостоятельно, в третьих побеждает мнение того, кто в администрации громче всех кричит.
Так или иначе, для разработки выбирается конкретная система. Команда разработчиков затем составляет техническое задание, рассматривая выходы и входы существующих компьютерных систем, анализируя формы и отчеты, используемые в существующих системах с ручной записью, и опрашивая пользователей с целью определения их потребностей в новых отчетах, формах и запросах, а также других требований. Исходя из этого всего, команда программистов разрабатывает информационную систему. Если система включает в себя базу данных, команда на основании технического задания строит модель данных, а имея модель данных, она проектирует и реализует базу данных. Когда создание данной системы завершается, запускаются другие проекты, целью которых является построение дополнительных информационных систем.
Сторонники разработки сверху вниз утверждают, что этот подход имеет преимущество перед разработкой снизу вверх, поскольку модели данных (и соответствующие им системы) строятся с глобальной перспективой. Они считают, что такие системы гораздо лучше взаимодействуют между собой, являются более согласованными и требуют намного меньше переделок.
Сторонники разработки снизу вверх говорят, что такой подход работает быстрее и сопряжен с меньшим риском. Они утверждают, что моделирование сверху вниз выливается в большое количество трудновыполнимых исследований и что процесс планирования часто заходит в тупик. Хотя моделирование снизу вверх не обязательно имеет своим результатом оптимальный набор систем, тем не менее, с его помощью можно быстро создать работающую систему. Такие системы начинают давать прибыль гораздо быстрее, чем системы, смоделированные сверху вниз, и это более чем компенсирует любые переделки и модификации, которые придется сделать, чтобы настроить систему на глобальную перспективу.
В этой книге описываются средства и способы, которые можно использовать при любом стиле системной разработки. Например, хотя и модель «сущность-связь» (глава 3), и семантическая объектная модель (глава 4) работают при разработке как сверху вниз, так и снизу вверх, модель «сущность—связь» более эффективна при разработке сверху вниз, а семантическая объектная модель — при разработке снизу вверх.
Моделирование данных
Как уже говорилось, наиболее важная цель на стадии разработки технического задания — это создание модели данных пользователя (user data model), или моделирование данных (data modeling). Как бы это ни делалось — сверху вниз или
74
Глава 2. Введение в разработку баз данных
снизу вверх, — это включает в себя опрос пользователей, документирование требований и построение модели данных и прототипов на основе этих требований. Такая модель показывает, какие объекты должны храниться в базе данных, и определяет их структуру и связи между ними.
Рассмотрим, например, рис. 2.13, а — список заказов, выполненных продавцом за определенный период времени. Чтобы приложение базы данных могло выдать такой отчет, база данных должна содержать информацию, представленную в этом отчете, поэтому разработчики базы данных должны исследовать этот отчет и на его основании определить, какие данные должны храниться в базе. В нашем случае должны быть данные о продавцах (имя и регион) и данные о заказах (компания, дата заказа и количество товара).
Разработка баз данных осложняется тем, что требований может быть несколько и они обычно перекрываются. Отчет на рис. 2.13, б также содержит данные о продавцах, но вместо заказов в нем перечислены комиссионные. Глядя на этот отчет, мы можем предположить, что существуют различные типы заказов и для каждого из них определен свой процент комиссионных.
Список заказов продавца 03 октября 2001				
Имя	Регион	НазваниеКомпании	ДатаЗаказа	Сумма
Kevin Dougherty Магу В. Wu	Западный Западный	Cabo Controls Ajax Electric	9/12/2001 9/17/2001	$2,349,88 $2,349,88
				$23,445,00
		American Maxell	9/24/2001	$17,339,44 $40,784,44
			Общая сумма:	$43,134,32
а
Отчето комиссионных продавца 03 октября 2001			
Имя	МестныйНомер	ДатаВыпискиЧека ТипКомиссионных		СуммаКомиссионных
Kevin Dougherty 232-9988 Магу В. Wu	232-9987	9/30/2001 9/30/2001	XZ	$487,38 $487,38
		с	$237,44
	9/30/2001	А	$1,785,39 $2,022,83
		Общая сумма:	$2,510,21
б
Рис. 2.13. Примеры двух связанных отчетов: а — отчет о продажах и б — отчет о комиссионных
Процесс разработки базы данных
75
Заказы, перечисленные в отчете на рис. 2.13, б, каким-то образом связаны с заказами, перечисленными на рис. 2.13, а, но каким именно, остается не слишком ясным. Команда разработчиков должна определить эти связи, делая выводы из отчетов и форм, интервьюируя пользователей, используя собственные знания по данному вопросу и другие источники.
Моделирование данных как делание выводов
Когда пользователи говорят, что им нужны формы и отчеты с определенными данными и структурами, это подразумевает, что у них в голове имеется некая модель, представляющая вещи в их мире. Однако пользователи могут быть не в состоянии точно описать эту модель. Если бы разработчик спросил типичного пользователя: «Как вы себе представляете структуру модели данных, касающихся продавцов?», то мир пользователя выглядел бы по меньшей мере загадочным, поскольку большинство пользователей не мыслят такими категориями.
Вместо того чтобы задавать подобные вопросы, разработчики должны из высказываний пользователя о формах и отчетах делать выводы о структуре и связях объектов, которые должны храниться в базе данных. Затем разработчики воплощают эти выводы в модели данных, которая трансформируется в проект базы данных, который, в свою очередь, реализуется при помощи СУБД. Затем конструируются приложения, генерирующие отчеты и формы для пользователей.
Таким образом, построение модели данных — это процесс делания предположений. Отчеты и формы напоминают тени на стене. Пользователи могут описать тени, но не могут описать формы тел, отбрасывающих эти тени. Поэтому разработчикам приходится делать предположения, решать обратную задачу, и реконструировать из этих теней структуры и связи.
Этот процесс является, к сожалению, в большей степени искусством, чем наукой. Можно изучить все средства и способы моделирования данных (фактически эти средства и способы являются предметом разговора в следующих двух главах), но их использование представляет собой искусство, которое требует опыта, направляемого интуицией.
Качество модели является важным аспектом. Если документированная модель данных адекватно отображает модель данных, присутствующую в воображении пользователя, есть отличный шанс, что разработанные на ее основании приложения будут отвечать потребностям пользователей. Если же пользовательская модель данных отображена в документированной модели неадекватно, то приложение вряд ли приблизится к тому, что действительно нужно пользователям.
Моделирование в многопользовательских системах
Процесс моделирования данных еще больше усложняется в многопользовательских коллективных и организационных базах данных, поскольку различные пользователи могут представлять себе различные модели данных. Эти модели
76
Глава 2. Введение в разработку баз данных
могут оказаться несогласованными, хотя в большинстве случаев несоответствия между ними могут быть устранены. Например, пользователи могут употреблять один и тот же термин для разных вещей или различные термины для одной и той же вещи.
Но иногда имеющиеся различия не дают возможности согласованного решения. В таких случаях разработчик базы данных должен документировать эти различия и помочь пользователям разрешить их, а это, как правило, означает, что некоторым людям придется изменить свой взгляд на мир.
Недоразумения по поводу термина «модель»
В следующих двух главах представлены два альтернативных средства для построения моделей данных: модель «сущность—связь» и семантическая объектная модель. Обе модели представляют собой структуры для описания и документирования требований пользователя к данным. Чтобы избежать недоразумений, обратите внимание на различное использование термина модель. Команда разработчиков анализирует требования и строит пользовательскую модель данных, или модель требований к данным (requirements data model). Эта модель является представлением требований пользователя к структуре и связям объектов, которые должны храниться в базе данных. Для создания пользовательской модели данных команда разработчиков использует средства, которые называются моделью «сущность—связь» и семантической объектной моделью. Эти средства состоят из языковых и изобразительных стандартов для представления пользовательской модели данных. Их роль в разработке баз данных подобна той роли, которую выполняют алгоритмы и псевдокод в программировании.
Резюме
Компонентами системы базы данных являются база данных, СУБД и прикладные программы, с которыми работают как пользователи, так и разработчики. База данных состоит из данных, метаданных, индексов и метаданных приложения. Большинство современных баз данных представляют данные в виде отношений, или таблиц, хотя не все отношения одинаково желательны. Нежелательные отношения могут быть преобразованы в два или более желательных с помощью процесса, называемого нормализацией. Метаданные часто хранятся в специальных таблицах, которые называются системными таблицами.
Характеристики и функции СУБД можно сгруппировать в три подсистемы. С помощью подсистемы средств проектирования определяется структура базы данных, приложений и их компонентов. Функцией подсистемы обработки является материализация форм, отчетов и запросов путем чтения или записи данных в базу. Ядро СУБД является посредником между двумя другими подсистемами и операционной системой. Она принимает запросы, выраженные в терминах таблиц, строк и столбцов, и преобразует их в запросы на физическое чтение и запись.
Вопросы I группы
77
Схема — это описание структуры базы данных. Она включает в себя описание таблиц, связей и доменов, а также деловой регламент. Строки одной таблицы могут быть связаны со строками других таблиц. В этой главе проиллюстрирована связь вида 1:N между двумя таблицами; как вы увидите из следующей главы, есть и другие типы связей.
Домен — это множество значений, которые может иметь столбец. Мы должны указывать домен для каждого столбца каждой таблицы.
Наконец, деловой регламент — это ограничения на виды деловой активности, которые должны быть отражены в базе данных и ее приложениях.
Для создания табличных структур, определения связей и создания форм, запросов, отчетов и меню используются средства, предоставляемые СУБД. СУБД также включают в себя средства для взаимодействия с прикладными программами, написанными либо на входном языке СУБД, либо на стандартных языках, таких как Java.
Поскольку база данных является моделью пользовательской модели деловой активности, разработка базы данных начинается с изучения и записи этой модели. Иногда она выражается в форме прототипов будущего приложения или компонентов приложения.
Два общих стиля разработки таковы: разработка сверху вниз, которая идет от общего к частному, и разработка снизу вверх, которая идет от частного к общему. В первом случае приложения разрабатываются с глобальной перспективой, зато во втором случае разработка идет быстрее. Иногда используется комбинация этих двух подходов.
Модели данных конструируются путем делания выводов из высказываний пользователя. Собираются формы, отчеты и запросы, и на их основании разработчики делают вывод о структурах, существующих в воображении пользователей. Это необходимо, поскольку большинство пользователей не способны непосредственно описать свои модели данных. Моделирование данных может быть особенно затруднительным в многопользовательских приложениях, где представления различных пользователей могут противоречить друг другу, и ни один пользователь не может представить себе всю картину деловой активности.
Термин модель данных используется двояко: он может означать как модель пользовательских представлений о данных, так и средства, используемые для описания этих представлений.
Вопросы I группы
1.	Назовите основные компоненты системы базы данных и кратко поясните функцию каждого из них.
2.	Приведите пример отношения (отличный от представленного в этой главе), обновление которого может быть сопряжено с проблемами. В качестве образца используйте отношение R1.
78
Глава 2. Введение в разработку баз данных
3.	Преобразуйте отношение из вашего ответа на вопрос 2 в два или более отношения, для которых проблем при обновлении не возникнет. В качестве образца используйте отношения R2 и R3.
4.	Поясните роль, которую играют метаданные и системные таблицы.
5.	Какова функция индексов? В каких случаях их применение оправдано и чем приходится за них платить?
6.	Какова функция метаданных приложения? В чем их отличие от метаданных?
7.	Дайте описание характеристик и функций подсистемы средств разработки СУБД.
8.	Дайте описание характеристик и функций подсистемы обработки СУБД.
9.	Дайте описание характеристик и функций ядра СУБД.
10.	Что такое схема базы данных? Перечислите ее компоненты.
11.	Как представляются связи в проекте реляционной базы данных? Приведите пример двух таблиц, имеющих связь вида 1:N, и объясните, каким образом эта связь отражается на данных.
12.	Что такое домены и зачем они нужны?
13.	Что такое деловой регламент? Приведите пример делового регламента для отношений из вашего ответа на вопрос 11.
14.	Что такое внешний ключ? Какой столбец (или столбцы) отношений из вашего ответа на вопрос 11 является внешним ключом?
15.	Опишите назначение форм, отчетов, запросов и меню.
16.	Поясните разницу между запросом по образцу и запросом по форме.
17.	Какова первая важнейшая задача при разработке базы данных и ее приложений?
18.	Какую роль играют прототипы?
19.	Опишите процесс разработки базы данных сверху вниз. Каковы его преимущества и недостатки?
20.	Опишите процесс разработки базы данных снизу вверх. Каковы его преимущества и недостатки?
21.	Дайте два различных толкования термина модель данных.
Вопросы II группы
22.	Реализуйте базу данных с отношениями CAPTAIN и ITEM в любой СУБД, к которой у вас есть доступ. Используйте средства, предлагаемые данной СУБД, для ввода данных в каждое из этих двух отношений. С помощью средств, предоставляемых СУБД, создайте и обработайте запрос, который показывает список инвентаря, выданного на руки до 1 сентября 2001 г., но
Вопросы к проекту Firedllp
79
еще не возвращенного. Распечатайте для такого инвентаря имя капитана, его номер телефона, а также количество и описание.
. 23. Поговорите с профессиональным разработчиком приложений баз данных и выясните, какой процесс он использует для разработки баз данных. Разработка ли это сверху вниз, снизу вверх или какая-то другая стратегия? Как этот разработчик строит модели данных и какие средства он для этого использует? Каковы главные проблемы, возникающие при разработке базы данных?
24. Проанализируйте утверждение: «База данных —- это модель пользовательской модели реальности». В чем его отличие от утверждения «База данных — это модель реальности»? Представьте себе, что у двоих разработчиков возник спор по поводу модели данных, и один из них заявляет: «Моя модель лучше представляет реальность». Что этот разработчик подразуме-> вает в действительности? Какие отличия могут возникнуть, если разработчик более склонен верить первому утверждению, чем второму?
Вопросы к проекту FiredUp
Рассмотрим ситуацию с компанией FiredUp, с которой вы познакомились в первой главе. С каждой горелкой покупатель получает бланк регистрации продукта, содержащий следующие данные: имя покупателя, почтовый адрес (улица, дом, квартира, город, штат, почтовый индекс, страна), адрес электронный почты, телефон, дата покупки и серийный номер.
Предположим, что FiredUp решает создать персональную базу данных со следующими таблицами: КЛИЕНТ (Имя, Улица, Дом, Квартира, Город, Штат, ПочтовыйИн-декс, Страна, ЭлектронныйАдрес, Телефон) и ПОКУПКА (ДатаПокупки, СерийныйНомер).
1.	Создайте таблицу с данными, структура которой будет соответствовать таблице КЛИЕНТ. В таблице должно быть по меньшей мере четыре строки. (Для ответа на вопросы 1-7 достаточно ввести данные в текстовом редакторе.)
2.	Какой из столбцов таблицы КЛИЕНТ можно использовать для однозначной идентификации строки в таблице? Такой столбец иногда называется первичным ключом, как вы позже узнаете из этой книги.
3.	Создайте таблицу с данными, структура которой будет соответствовать таблице ПОКУПКА. В таблице должно быть по меньшей мере четыре строки.
4.	Какой из столбцов таблицы ПОКУПКА можно использовать в качестве первичного ключа для этой таблицы?
5.	Имея определенные выше таблицы, невозможно связать конкретного покупателя с его горелкой. Один из способов сделать это — добавить столбец СерийныйНомер из таблицы ПОКУПКА в таблицу КЛИЕНТ. После этого таблица КЛИЕНТ будет выглядеть следующим образом: КЛИЕНТ (Имя, Улица, Дом, Квартира, Город, Штат, ПочтовыйИндекс, Страна, ЭлектронныйАдрес, Телефон).
80 Глава 2. Введение в разработку баз данных
Скопируйте данные из таблицы КЛИЕНТ и добавьте к ним столбец Серий-ныйНомер. Назовите получившуюся таблицу КЛИЕНТ1.
6.	Связь двух таблиц можно представить и по-другому: поместить столбец ЭлектронныйАдрес из таблицы КЛИЕНТ в таблицу ПОКУПКА. После этого таблица ПОКУПКА будет выглядеть следующим образом: ПОКУПКА (ДатаПо-купки, СерийныйНомер, ЭлектронныйАдрес). Скопируйте данные из таблицы ПОКУПКА и добавьте к ним столбец ЭлектронныйАдрес из таблицы КЛИЕНТ. Назовите получившуюся таблицу П0КУПКА1.
7.	Теперь у вас имеются три возможные структуры: КЛИЕНТ1+П0КУПКА, КЛИЕНТ+П0КУПКА1 и КЛИЕНТ1+П0КУПКА1. При каких условиях вы могли бы рекомендовать первую структуру? Вторую структуру?
8.	При каких условиях вы могли бы порекомендовать третью структуру?
Часть II
Моделирование данных
Моделирование данных — это процесс создания логического представления структуры базы данных. Правильно сконструированная модель данных должна поддерживать все пользовательские представления данных. Моделирование данных является наиболее важной задачей при разработке эффективных приложений баз данных. Если база данных будет неверно отражать пользовательское представление данных, то пользователи найдут ее приложения неудобными, неполными и не оправдывающими ожиданий. Моделирование данных — основа для всей последующей работы при разработке баз данных и их приложений.
Часть II описывает два различных подхода к моделированию данных. В главе 3 рассматривается модель «сущность—связь» (entity-relationship model), имеющая значительное количество сторонников среди профессиональных разработчиков баз данных. В главе 4 описывается семантическая объектная модель, которая обладает меньшим числом приверженцев, однако некоторые считают ее более богатой и простой в использовании, чем модель «сущность—связь».
Эти модели представляют собой языки для описания структуры данных и их связей в представлении пользователей. Моделирование данных отражает логическую структуру данных, так же как блок-схемы алгоритмов отражают логическую структуру программы.
Глава 3
Модель «сущность—связь»
Эта глава описывает и иллюстрирует использование модели «сущность—связь» (entity-relationship model), введенной Питером Ченом (Peter Chen) в 1976 г'. В этой статье Чен заложил основу модели, которая с тех пор расширялась и модифицировалась самим Ченом и многими другими1 2. Кроме того, модель «сущность-связь» вошла в состав множества CASE-инструментов, которые также внесли свой вклад в ее эволюцию. На сегодняшний день не существует единого общепринятого стандарта для модели «сущность—связь», зато есть набор общих конструкций, которые лежат в основе большинства вариантов этой модели. Описанию этих общих конструкций и демонстрации их применения и посвящена данная глава. Символы, применяемые для графического представления модели «сущность—связь», весьма различны. Мы обсудим не только традиционные символы, но и символы языка UML (Unified Model Language, унифицированный язык моделирования) — средства проектирования, завоевывающего все большую популярность среди программистов ООП и включающего в себя модель «сущность—связь».
Элементы модели «сущность—связь»
Ключевыми элементами модели «сущность—связь» являются сущности, атрибуты, идентификаторы и связи. Рассмотрим каждый из них по очереди.
Сущности
Сущность (entity) — это некоторый объект, идентифицируемый в рабочей среде пользователя, нечто такое, за чем пользователь хотел бы наблюдать. Примерами сущностей могут служить СОТРУДНИК Мэри Доу, КЛИЕНТ 12345, ЗАКАЗ 1000, ПРОДАВЕЦ Джон Смит или ПРОДУКТ А4200. Сущности одного и того же типа группируются в классы сущностей (entity classes). Так, класс сущностей СОТРУДНИК
1 Р. Р. Chen, «The Entity-Relationship Model — Towards a Unified View of Data», ACM Transactions on Database Systems, январь 1976, c. 9-36.
2 Thomas A. Bruce, Designing Quality Databases with IDEF1X Information Models (New York: Dorset House Publishing, 1992).
\	Элементы модели «сущность—связь»	83
является совокупностью всех сущностей СОТРУДНИК. В тексте книги классы сущностей обозначаются заглавными буквами.
Важно уяснить разницу между классом сущностей и экземпляром сущности. Класс сущностей — это совокупность сущностей, и описывается он структурой или форматом сущностей, составляющих этот класс. Экземпляр сущности (entity instance) представляет конкретную сущность, такую как КЛИЕНТ 12345; он описывается значениями атрибутов данной сущности. Обычно класс сущностей содержит множество экземпляров сущности. Например, класс КЛИЕНТ содержит множество экземпляров — по одному на каждого клиента, для которого имеется запись в базе данных. Пример класса сущностей и двух экземпляров сущности показан на рис. 3.1.
КЛИЕНТ
сущность содержит: НомерКлиента ИмяКлиента
Адрес Город Штат ПочтовыйИндекс ИмяДоверенногоЛица НомерТелефона
Два экземпляра сущности КЛИЕНТ:
12345
Ajax Manufacturing 123 Elm St Memphis TN 32455 P. Schwartz 223-5567
67890
Jefferson Dance Club 345-1 Oth Avenue Boston MA 01234
Frita Bellingsley 210-8896
Рис. 3.1. КЛИЕНТ: пример сущности
Атрибуты
У сущностей есть атрибуты (attributes), или, как их иногда называют, свойства (properties), которые описывают характеристики сущности. Примерами атрибутов могут служить ИмяСотрудника, ДатаНайма и КодКвалификации. В тексте этой книги атрибуты обозначаются как прописными, так и строчными буквами. В модели «сущность—связь» предполагается, что все экземпляры данного класса сущностей имеют одинаковые атрибуты.
Исходное определение модели «сущность—связь» включает в себя композитные атрибуты (composite attributes) и многозначные атрибуты (multi-valued attributes). В качестве примера композитного атрибута можно привести атрибут Адрес, состоящий из группы атрибутов {Улица, Город, Штат, Индекс}. Примером многозначного атрибута может служить атрибут ИмяДоверенногоЛица сущности КЛИЕНТ, который может содержать имена нескольких доверенных лиц данного клиента. Атрибут может быть одновременно и композитным, и многозначным —
84
Глава 3. Модель «сущность—связь
например композитный атрибут Телефон, состоящий из группы атрибутов {Код-Региона, МестныйНомер}, может быть многозначным, что позволит иметь в базе данных несколько телефонных номеров одного и того же лица. В большинстве реализаций модели «сущность—связь» однозначные композитные атрибуты игнорируются, и требуется, чтобы многозначные атрибуты (будь они составные или нет) преобразовывались в сущности, как будет показано ниже.
Идентификаторы
Экземпляры сущностей имеют идентификаторы (identifiers) — атрибуты, с помощью которых эти экземпляры именуются, или идентифицируются. Например, экземпляры сущностей класса СОТРУДНИК могут идентифицироваться по атрибутам НомерСоциальнойСтраховки, ТабельныйНомерСотрудника или ИмяСотрудника. Такие атрибуты, как Зарплата или ДатаНайма, вряд ли могут служить идентификаторами экземпляров сущностей класса СОТРУДНИК, поскольку обычно эти атрибуты не используются для однозначного указания па конкретного сотрудника. Подобно этому, сущности класса КЛИЕНТ могут идентифицироваться по атрибутам НомерКлиента или ИмяКлиента, а сущности класса ЗАКАЗ могут идентифицироваться по атрибуту НомерЗаказа.
Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным (unique) либо неуникалъным (nonunique). Если идентификатор является уникальным, его значение будет указывать на один и только один экземпляр сущности. Если идентификатор является неуникальным, его значение будет указывать на некоторое множество экземпляров. ТабельныйНомерСотрудника является, скорее всего, уникальным идентификатором, а ИмяСотрудника — неуникальным (например, может быть несколько сотрудников по имени Джон Смит).
Идентификаторы, состоящие из нескольких атрибутов, называются композитными идентификаторами (composite identifiers). Примерами могут служить совокупности вида {КодРегиона, МестныйНомер}, {НазваниеПроекта, НазваниеЗадачи} и {Имя, Фамилия, ДобавочныйНомерТелефона}.
Связи
Взаимоотношения сущностей выражаются связями (relationships). Модель «сущность-связь» включает в себя классы связей и экземпляры связей'. Классы связей (relationship classes) — это взаимоотношения между классами сущностей, а экземпляры связи (relationship instances) — взаимоотношения между экземплярами сущностей. У связей могут быть атрибуты.
Класс связей может затрагивать несколько классов сущностей. Число классов сущностей, участвующих в связи, называется степенью связи (relationship degree). Изображенная на рис. 3.2, а связь ПРОДАВЕЦ-ЗАКАЗ имеет степень 2, поскольку
' Для краткости мы будем иногда опускать слово экземпляр в тех случаях, когда из контекста будет очевидно, что подразумевается именно экземпляр сущности, а не класс сущностей.
Элементы модели «сущность—связь;
85
в ней участвуют два класса сущностей: ПРОДАВЕЦ и ЗАКАЗ. Связь РОДИТЕЛЬ на рис. 3.2, б имеет степень 3, так как в ней участвуют три класса сущностей: МАТЬ, ОТЕЦ и РЕБЕНОК. Связи степени 2 весьма распространены, их часто называют еще бинарными связями (binary relationships).
а	б
Рис. 3.2. Различные степени связей: а — связь степени 2; б — связь степени 3
Три типа бинарных связей
На рис. 3.3 показаны три типа бинарных связей. В связи 1:1 («один к одному») одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. На рис. 3.3, а связь СЛУЖЕБНЫЙ_АВТОМОБИЛЬ связывает одиночную сущность класса СОТРУДНИК с одиночной сущностью класса АВТОМОБИЛЬ. В соответствии с этой диаграммой, ни за одним сотрудником не закреплено более одного автомобиля, и ни один автомобиль не закреплен более чем за одним сотрудником.
СЛУЖЕБНЫЙ-АВТОМОБИЛЬ
ОБЩЕЖИТИЕ-ЖИЛЕЦ б
СТУДЕНТ-КЛУБ
г
Рис. 3.3. Три типа бинарных связей: а — бинарная связь 1:1; б — бинарная связь 1:N; в — бинарная связь N:M; г — представление связи с помощью разветвлений
На рис. 3.3, б изображен второй тип связи, 1:N («один к N» или «один ко многим»). В этой связи, которая называется ОБЩЕЖИТИЕ-ЖИЛЕЦ, единичный экземпляр сущности класса ОБЩЕЖИТИЕ связан со многими экземплярами сутцно-
86
Глава 3. Модель «сущность—связь:
сти класса СТУДЕНТ. В соответствии с этим рисунком, в общежитии проживает много студентов, но каждый студент живет только в одном общежитии.
Позиция, в которой стоят 1 и N, имеет значение. Единица стоит на той стороне связи, где располагается ОБЩЕЖИТИЕ, a N стоит на той стороне связи, где располагается СТУДЕНТ. Если бы 1 и N располагались наоборот, и связь записывалась бы как N:l, получилось бы, что в общежитии живет один студент, причем каждый студент живет в нескольких общежитиях. Это, разумеется, не так.
На рис. 3.3, в показан третий тип бинарной связи, N:M (читается «N к М» или «многие ко многим»). Эта связь называется СТУДЕНТ-КЛУБ, и она связывает экземпляры сущностей класса СТУДЕНТ с экземплярами сущностей класса КЛУБ. Один студент может быть членом нескольких клубов, а в одном клубе может состоять много студентов.
Числа внутри ромба, символизирующего связь, обозначают максимальное количество сущностей на каждой стороне связи. Эти ограничения называются максимальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью (maximum cardinality) связи. Например, о связи, изображенной на рис. 3.3, б, говорят, что она обладает максимальной кардинальностью 1:N. Кардинальные числа могут иметь и другие значения, а не только 1 и N. Например, связь между сущностями БАСКЕТБОЛЬНАЯ_КОМАНДА и ИГРОК может иметь кардинальность 1:5, что говорит нам о том, что в баскетбольной команде может быть не более пяти игроков.
Связи трех типов, представленных на рис. 3.3, называются иногда связями типа «ИМЕЕТ», или связями обладания (HAS-A relationships). Такой термин используется потому, что одна сущность имеет (has) связь с другой сущностью. Например: сотрудник имеет автомобиль, студент имеет общежитие, клуб имеет студентов.
Диаграммы «сущность—связь»
Схемы, изображенные на рис. 3.3, называются диаграммами «сущность—связь», или ER-диаграммами (entity-relationship diagrams, ER-diagrams). Такие диаграммы стандартизированы, но не слишком жестко. В соответствии с этим стандартом, классы сущностей обозначаются прямоугольниками, связи обозначаются ромбами, а максимальное кардинальное число каждой связи указывается внутри ромба1. Имя сущности указывается внутри прямоугольника, а имя связи указывается рядом с ромбом.
ОБЩЕЖИТИЕ-СТУДЕНТ
Рис. 3.4. Связь с указанной минимальной кардинальностью
1 Описываемые здесь графические символы, которые берут начало в этой модели, не являются лучшим способом отображения модели в системе с графическим интерфейсом пользователя, подобной Macintosh или Microsoft Windows. Фактически модель «сущность—связь» была разработана задолго до того, как какая-либо система графического интерфейса приобрела популярность. Символы языка UML, которые будут представлены позже в этой главе, легче использовать в графической среде.
Элементы модели «сущность—связр;
87
Хотя в некоторых ER-диаграммах имя связи указывается внутри ромба, получающаяся при этом диаграмма может выглядеть ужасно, поскольку ромбы приходится делать большого размера и вне масштаба, чтобы в них поместилось имя связи. Чтобы избежать этого, имена связей иногда пишут над ромбом. Когда имя помещается внутрь или поверх ромба, кардинальность связи изображается с помощью разветвлений на линиях, соединяющих сущность (или сущности) с множественной стороной связи. На рис. 3.3, г показаны связи ОБЩЕЖИТИЕ-ЖИЛЕЦ и СТУДЕНТ-КЛУБ с такими разветвлениями.
Как мы уже говорили, максимальная кардинальность показывает максимальное число сущностей, которые могут участвовать в связи. Каково же минимальное число таких сущностей, приведенные диаграммы не сообщают. Например, рис. 3.3, б показывает, что студент может проживать максимум в одном общежитии, однако из него не ясно, обязан ли студент проживать в каком-либо общежитии.
Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Один из них, продемонстрированный на рис. 3.4, заключается в следующем: чтобы показать, что сущность обязана участвовать в связи, па линию связи помещают перпендикулярную черту, а чтобы показать, что сущность может (но не обязана) участвовать в связи, на линию связи помещают овал. Соответственно, рис. 3.4 показывает, что сущность ОБЩЕЖИТИЕ должна быть связана как минимум с одной сущностью СТУДЕНТ, однако сущность СТУДЕНТ не обязана иметь связь с сущностью ОБЩЕЖИТИЕ. Полный набор накладываемых на связь ограничений состоит в том, что ОБЩЕЖИТИЕ имеет минимальное кардинальное число, равное единице, и максимальное кардинальное число, равное «многим» сущностям СТУДЕНТ. СТУДЕНТ имеет минимальное кардинальное число, равное нулю, и максимальное кардинальное число, равное одному экземпляру сущности ОБЩЕЖИТИЕ.
Может существовать связь между сущностями одного и того же класса. Например, для сущностей класса СТУДЕНТ может быть определена связь СОСЕД_ ПО_КОМНАТЕ. Такая связь показана на рис. 3.5, а, а на рис. 3.5, б изображены экземпляры сущностей, охваченных этой связью. Связи между сущностями одного и того же класса называются иногда рекурсивными связями (recursive relationships).
Изображение атрибутов в диаграммах «сущность—связь»
В некоторых версиях ER-диаграмм атрибуты обозначаются эллипсами, соединенными с сущностью или связью, которой они принадлежат. На рис. 3.6, а показаны сущности ОБЩЕЖИТИЕ и СТУДЕНТ и связь ОБЩЕЖИТИЕ-ЖИЛЕЦ с принадлежащими им атрибутами. Как видно из рисунка, сущность ОБЩЕЖИТИЕ имеет атрибуты НазваниеОбщежития, Местоположение и КоличествоКомнат, а сущность СТУДЕНТ имеет атрибуты НомерСтудента, ИмяСтудента и Курс. Связь ОБЩЕЖИТИЕ-ЖИЛЕЦ имеет атрибут Плата, который показывает внесенную студентом плату за проживание в конкретном общежитии.
Если сущность имеет много атрибутов, такое их перечисление в ER-диаграмме может сделать ее чересчур громоздкой и трудной для восприятия. В подобных случаях
88
Глава 3. Модель «сущность—связь;
список атрибутов сущностей дается отдельно, как показано на рис. 3.6, б. Многие CASE-средства показывают такие атрибуты в раскрывающихся окнах.
а
ОБЩЕЖИТИЕ-ЖИЛЕЦ
ОБЩЕЖИТИЕ содержит
НазваниеОбщежития Местоположение КоличествоКомнат
СТУДЕНТ содержит
НомерСтудента ИмяСтудента Курс
ОБЩЕЖИТИЕ-ЖИЛЕЦ содержит
Плата
б
Рис. 3.6. Изображение свойств на диаграммах «сущность—связь»: а — указание на диаграмме; б — отдельное перечисление
Элементы модели «сущность—связь;
89
Слабые сущности
В модели «сущность—связь» определен особый тип сущности, называемый слабой сущностью (weak entity). К слабым сущностям относятся такие сущности, которые могут существовать в базе данных только в том случае, если в ней присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой, называется сильной сущностью (strong entity).
Чтобы разобраться в том, что такое слабые сущности, рассмотрим базу данных отдела кадров с классами сущностей СОТРУДНИКИ ПОДЧИНЕННЫЙ. Предположим, что, в соответствии с деловым регламентом, экземпляр сущности СОТРУДНИК может существовать, не будучи связанным ни с одной сущностью класса ПОДЧИНЕННЫЙ, но сущность ПОДЧИНЕННЫЙ не может существовать вне связи с какой-либо сущностью класса СОТРУДНИК. Тогда сущность ПОДЧИНЕННЫЙ является слабой. Это означает, что данные о сущности ПОДЧИНЕННЫЙ могут появиться в базе данных только в том случае, если эта сущность имеет связь с какой-либо сущностью класса СОТРУДНИК.
подчиненный]
Идентификатор:
НазваниеДома
Идентификатор:
{НазваниеДома
НомерКвартиры}
Рис. 3.7. Слабые сущности: а — пример слабой сущности; б — пример идентификационно-зависимой сущности
Как показано на рис. 3.7, б, слабые сущности обозначаются прямоугольниками со скругленными углами. Кроме того, связь, от которой зависит существование сущности, обозначается ромбом со скругленными углами. В качестве альтернативы, в некоторых ER-диаграммах (не показано здесь) прямоугольники для слабых сущностей рисуются двойной линией, а связи, от которых зависит существование этих сущностей, изображаются двойными ромбами.
В модели «сущность—связь» имеется особый тип слабых сущностей, называемый идентификационно-зависимыми сущностями (ID-dependent entities). Это такие сущности, идентификаторы которых содержат идентификатор другой сущности. Рассмотрим сущности ДОМ и КВАРТИРА. Пусть идентификатором сущности ДОМ является атрибут НазваниеДома, а идентификатором сущности КВАРТИРА является композитный идентификатор {НазваниеДома, НомерКвартиры}. Поскольку идентификатор сущности КВАРТИРА содержит в себе идентификатор сущности ДОМ (НазваниеДома), то сущность КВАРТИРА является идентификационно-зависимой от сущности ДОМ. Сравните рис. 3.7, б с рис. 3.7, а. По-другому можно представить это так, что, как логически, так и физически, квартира не может существовать, если не существует соответствующего здания.
90 Глава 3. Модель «сущность—связь»
Идентификационно-зависимые сущности встречаются часто. Еще одним примером может служить сущность ВЕРСИЯ в связи с сущностью ПРОДУКТ, где ПРОДУКТ — это некоторый программный продукт, а ВЕРСИЯ — номер его версии. Идентификатором продукта является атрибут НазваниеПродукта, а идентификатором версии является совокупность {НазваниеПродукта, НомерВерсии}. Третий пример — это сущность ИЗДАНИЕ в связи с сущностью УЧЕБНИК. Идентификатором сущности УЧЕБНИК является атрибут Заглавие, а идентификатором издания является совокупность {Заглавие, ПорядковыйНомерИздания}.
К сожалению, в определении термина слабая сущность есть скрытая неоднозначность, и она по-разному интерпретируется различными проектировщиками баз данных (а также различными авторами книг). Эта неоднозначность заключается в следующем: в строгом смысле, слабая сущность определяется как любая сущность, чье присутствие в базе данных зависит от другой сущности; тогда любая сущность, участвующая в связи минимальной кардинальности 1 с другой сущностью, является слабой. Таким образом, рассматривая базу данных образовательного учреждения, можно заключить следующее: если у студента должен быть руководитель, то сущность СТУДЕНТ является слабой, поскольку опа не может быть записана в базу данных без связи с какой-либо сущностью класса РУКОВОДИТЕЛЬ. Это толкование, однако, кажется некоторым людям слишком широким. Студент физически не зависит от руководителя (в отличие от случая с квартирой и домом), как не зависит от него и логически (что бы по этому поводу ни думали студент и руководитель!), поэтому сущность СТУДЕНТ должна считаться сильной сущностью.
Чтобы избежать подобных ситуаций, некоторые интерпретируют определение слабой сущности более ограниченно. Чтобы сущность можно было отнести к разряду слабых, она должна логически зависеть от другой сущности. Согласно данному определению, сущности ПОДЧИНЕННЫЙ и КВАРТИРА должны считаться слабыми, а сущность СТУДЕНТ — нет. Подчиненный не был бы подчиненным, если бы не находился в подчинении у кого-то, а квартира не может существовать без здания, в котором она могла бы располагаться. Студент же может логически существовать и без руководителя, даже если деловой регламент этого не допускает.
Чтобы проиллюстрировать эту интерпретацию, рассмотрим несколько примеров. Пусть модель данных включает в себя связь между сущностями ЗАКАЗ и АГЕНТ (рис. 3.8, а). Хотя можно сказать, что для каждого заказа должен быть указан агент, в действительности это не обязательно (заказ может быть, к примеру, продажей за наличные, при которой имя агента не записывается). Следовательно, минимальное кардинальное число, равное 1, проистекает из делового регламента, а не из логической необходимости. Таким образом, сущность ЗАКАЗ, хотя и требует наличия сущности АГЕНТ, не зависит от существования последней, поэтому ЗАКАЗ следует рассматривать как сильную сущность.
Теперь рассмотрим связь между сущностями ПАЦИЕНТ и РЕЦЕПТ, изображенную на рис. 3.8, б. Здесь рецепт не может логически существовать без пациента. Следовательно, помимо того, что минимальное кардинальное число сущности РЕЦЕПТ равно 1, эта сущность также зависит от существования сущности ПАЦИЕНТ. Отсюда следует, что РЕЦЕПТ — это слабая сущность. Наконец, рассмотрим сущность
Элементы модели «сущность—связь:
91
НАЗНАЧЕНИЕ, изображенную на рис. 3.8, в. Идентификатор этой сущности содержит идентификатор сущности ПРОЕКТ. Здесь, кроме того, что сущность НАЗНАЧЕНИЕ имеет минимальную кардинальность 1 и зависит от существования сущности ПРОЕКТ, она является еще и идентификационно-зависимой от последней, поскольку ее ключ содержит ключ сущности ПРОЕКТ. Таким образом, сущность НАЗНАЧЕНИЕ является слабой.
ПАЦИЕНТ 4-Q:N>-e{ РЕЦЕПТ
б
Идентификатор:	Идентификатор:
{НазваниеПроекта,	НазваниеПроекта
Название задачи}
в
Рис. 3.8. Примеры обязательных сущностей
В этой книге мы определяем слабые сущности как логически зависящие от существования другой сущности. Следовательно, не все сущности, имеющие минимальную кардинальность 1 в связи с другой сущностью, являются слабыми. Только логически зависимые сущности квалифицируются нами как слабые. Это определение также подразумевает, что слабыми являются все идентификационно-зависимые сущности. Кроме того, любая слабая сущность имеет минимальное кардинальное число 1 в связи с сущностью, от которой зависит, но произвольно взятая сущность с минимальным кардинальным числом, равным 1, не обязательно должна быть слабой1.
Представление многозначных атрибутов при помощи слабых сущностей
Многозначные атрибуты представляются в модели «сущность—связь» путем создания новой слабой сущности и построения связи вида «один ко многим». В качестве примера на рис. 3.9, а изображено представление многозначного атрибута ДоверенноеЛицо сущности КЛИЕНТ. Создается новая сущность под с именем ДОВЕРЕННОЕ_ЛИЦО с единственным атрибутом ДоверенноеЛицо. Связь между сущностями Д OB Е РЕ НН ОЕ_Л И ЦО и КЛИЕНТ имеет вид «один ко многим». Созданная таким образом сущность должна быть слабой, поскольку она логически зависит от сущности, имеющей многозначный атрибут.
1 Здесь не упоминаются случаи, когда минимальная кардинальность оказывается больше единицы. Логика аналогична, но сущность теперь зависит от набора сущностей.
92
Глава 3. Модель «сущность—связь;
На рис. 3.9, б изображено представление многозначного составного атрибута Адрес. Новая слабая сущность АДРЕС содержит всю совокупность атрибутов, а именно атрибуты Улица, Город, Штат и ПочтовыйИндекс.
КЛИЕНТ
имя_доверенного_лица]
КЛИЕНТ содержит:	ИМЯ_ДОВЕРЕННОГО_ЛИЦА содержит:
ИмяДоверенногоЛица
НомерКлиента ИмяКлиента прочие атрибуты...
а
КЛИЕНТ содержит:	АДРЕС содержит:
НомерКлиента	Улица
ИмяКлиента	Город
прочие атрибуты...	Штат
Индекс б
АДРЕС
Рис. 3.9. Представление многозначных атрибутов с помощью слабых сущностей
Подтипы сущностей
Некоторые сущности имеют необязательные наборы атрибутов; эти сущности часто представляются с помощью подтипов (subtypes)1. Рассмотрим, например, сущность КЛИЕНТ с атрибутами НомерКлиента, ИмяКлиента и СуммаКОплате. Предположим, что клиент может быть физическим лицом, товариществом или корпорацией и что необходимо указывать некоторую дополнительную информацию, зависящую от типа клиента. Пусть эта информация имеет следующее содержание:
ФИЗИЧЕСКОЕ_ЛИЦО: Адрес, НомерСоциальнойСтраховки
ТОВАРИЩЕСТВО: ИмяУправляющегоПартнера, Адрес, ИдентификационныйНалоговый-Номер
КОРПОРАЦИЯ: КонтактноеЛицо, Телефон, ИдентификационныйНалоговыйНомер
Одна из возможностей — отнести все эти атрибуты к сущности КЛИЕНТ, как показано на рис. 3.10, а. В этом случае, однако, некоторые атрибуты будут неприменимы. Например, такой атрибут, как имя управляющего партнера, не имеет смысла для индивидуального или корпоративного клиента, и таким образом, он не может иметь какого-либо значения.
В модели, более близкой к реальной ситуации, вместо этого будет определено три подтипа сущностей, как показано на рис. 3.10, б. Здесь сущности ФИЗИЧЕСКОЕ_ ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ изображены как подтипы сущности КЛИЕНТ. Последняя, в свою очередь, является надтипом (supertype) для сущностей ФИЗИЧЕСКОЕ_ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ.
1 Подтипы были добавлены в модель «сущность—связь» после публикации оригинальной статьи Чена, и они являются частью того, что называется расширенной моделью ^сущность—связь*.
Элементы модели «сущность—связь;
93
Символ е рядом с линиями связи указывает, что сущности ФИЗИЧЕСКОЕ_ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ являются подтипами сущности КЛИЕНТ. Каждый подтип должен принадлежать надтипу КЛИЕНТ. Кривая линия с цифрой 1 рядом показывает, что сущность КЛИЕНТ должна принадлежать к одному и только одному подтипу. Это означает, что подтипы являются взаимоисключающими и что требуется только один из них.
КЛИЕНТ содержит:
НомерКлиента
ИмяКлиента
СуммаКОплате
Адрес
НомерСоциальнойСтраховки
ИмяУправляющегоПартнера
ИдентификационныйНалоговыйНомер ДоверенноеЛицо
PhoneK Телефон
а
ФИЗИЧЕСКОЕ ЛИЦО содержит:
КЛИЕНТ содержит:
НомерКлиента ИмяКлиента
СуммаКОплате
Адрес
НомерСоциальнойСтраховки
ТОВАРИЩЕСТВО содержит:
ИмяУправляющегоПартнера
Адрес
ИдентификационныйНалоговыйНомер
КОРПОРАЦИЯ содержит:
ДоверенноеЛицо
Телефон
ИдентификационныйНалоговыйНомер
б
в
Рис. 3.10. Подтипы сущностей: а — КЛИЕНТ без подтипов; б — КЛИЕНТ с подтипами; в — невзаимоисключающие подтипы с необязательным надтипом
Сущности со связью типа «ЕСТЬ» должны иметь один и тот же идентификатор, поскольку они представляют различные аспекты одного и того же. В данном
94
Глава 3. Модель «сущность—связь;
случае таким идентификатором является НомерКлиента. Сравните эту ситуацию со связью типа «ИМЕЕТ», показанной на рис. 3.3, где сущности представляют различные вещи.
Иерархии генерализации имеют специальную характеристику, называемую наследованием (inheritance), которая означает, что подтипы классов сущностей наследуют атрибуты от надтипа. Сущность ТОВАРИЩЕСТВО, к примеру, наследует атрибуты Имя Клиента и СуммаКОплате от сущности КЛИЕНТ.
Причины, по которым подтипы используются в моделировании данных, отличаются от причин, по которым они используются в объектно-ориентированном программировании. Фактически, в модели данных они применяются с единственной целью: избежать ситуаций, при которых некоторые атрибуты должны иметь нулевые значения. Например, на рис. 3.10, а, если атрибуту НомерСоциальнойСтра-ховки присвоено значение, то остальные четыре атрибута должны быть равны нулю. Эта ситуация наиболее ярко проявляется в медицинских приложениях: представьте себе, например, что пациенту мужского пола задается вопрос о количестве беременностей. Нулевые значения более детально обсуждаются в главе 6.
Пример ER-диаграммы
На рис. 3.11 показан пример ER-диаграммы, содержащей все элементы модели «сущность—связь», о которых шла речь до сих пор. Она изображает сущности и связи для инженерной консалтинговой компании, которая занимается анализом строительства и состояния домов и других зданий и сооружений.
КЕМ_ПРИВЕДЕН
Рис. 3.11. Пример диаграммы «сущность—связь»
На диаграмме есть класс сущностей, представляющий сотрудников компании. Поскольку некоторые сотрудники являются инженерами, сущность СОТРУДНИК
Элементы модели «сущность—связь»
95
связана с сущностью ИНЖЕНЕР как подтип. Каждый инженер должен быть сотрудником; сущность ИНЖЕНЕР имеет связь 1:1 с сущностью ГРУЗОВИК; каждый грузовик должен быть закреплен за каким-то инженером, но не у всех инженеров есть грузовики.
Инженеры выполняют работы (сущность РАБОТА) для клиентов (сущность КЛИЕНТ). Инженер может не выполнять никаких работ (иначе говоря, выполнять ноль работ) или выполнять много работ, но каждая отдельно взятая работа может выполняться только одним конкретным инженером. Для одного и того же клиента может выполняться много различных работ, и один и тот же вид работы может выполняться для множества клиентов. Клиент должен оплатить как минимум одну работу, но различные виды работ существуют независимо от клиентов. Связь КЛИЕНТ-РАБОТА имеет атрибут Плата, который показывает сумму, уплаченную конкретным клиентом за конкретную работу. (Прочие атрибуты сущностей и связей не показаны на этой диаграмме.)
Иногда одни клиенты приводят других, что показывается с помощью рекурсивной связи КЕМ_ПРИВЕДЕН. Клиент может привести одного или нескольких других клиентов. Клиент не обязан быть приведен другим клиентом, но каждого клиента может привести только один клиент.
Сущность СЕРТИФИКАЦИЯ-ИНЖЕНЕРА показывает, что данный инженер получил образование и прошел тестирование, требуемое для получения конкретного сертификата. Инженер может иметь сертификаты (сущность СЕРТИФИКАТ). Существование сущности СЕРТИФИКАЦИЯ_ИНЖЕНЕРА зависит от сущности ИНЖЕНЕР через связь ИНЖЕНЕР-КВАЛИФИКАЦИЯ. СЕРТИФИКАТ — это сущность, описывающая конкретный сертификат.
Документирование делового регламента
В главе 2 в качестве элементов схемы базы данных были введены таблицы, связи, домены и деловой регламент. Первые три элемента присутствуют в модели «сущность-связь» или логически выводятся из нее, но деловой регламент в этой модели никак не упомянут. Таким образом, правила, составляющие деловой регламент, иногда добавляются к ER-модели на стадии моделирования данных.
ER-модель разрабатывается исходя из анализа требований, сформулированных пользователями. В процессе этого анализа часто возникает вопрос о деловом регламенте, и, разумеется, системные аналитики должны взять себе за правило спрашивать о нем пользователей.
Рассмотрим сущности ГРУЗОВИК и ИНЖЕНЕР на рис. 3.11. Имеются ли в деловом регламенте правила, касающиеся того, за кем может быть закреплен грузовик? Если имеющегося количества грузовиков недостаточно для того, чтобы закрепить грузовик за каждым инженером, то какие правила будут определять то, кому достанется грузовик? Быть может, приложение базы данных должно назначать грузовики в пользование тем инженерам, в графике которых стоит наибольшее количество работ в течение определенного периода времени или наибольшее количество работ вне офиса; возможны и другие варианты.
Другой пример — распределение работ между инженерами. Могут существовать правила, определяющие то, каким набором сертификатов должен обладать
96
Глава 3. Модель «сущность—связь
инженер, чтобы быть допущенным к выполнению определенных видов работ. К примеру, может быть, что для инспектирования многоквартирного дома инженер должен иметь лицензию профессионального инженера. Даже если закона, предписывающего такой порядок, не существует в природе, данное правило может быть продиктовано политикой компании.
Выполнение правил делового регламента может (но не обязано) обеспечиваться средствами СУБД, а может быть организовано в прикладной программе. Иногда деловой регламент формулируется в виде процедур, которым должны следовать пользователи приложения базы данных. На данный момент способ, с помощью которого организуется выполнение правил делового регламента, не имеет значения. Важно документировать эти правила, чтобы они стали частью системных требований.
Модель «сущность—связь» и CASE-средства
Разработка моделей данных в рамках модели «сущность—связь» значительно упростилась в последние годы, поскольку теперь инструменты для построения ER-диаграмм входят в состав многих популярных CASE-средств. К таким продуктам относятся, в частности, IEW, IEF, DEFT, ER-WIN и Visio. Эти продукты также объединяют сущности с отношениями, с помощью которых эти сущности представлены в базе данных, что может облегчить администрирование, управление и обслуживание базы данных.
Мы не предполагаем работать с CASE-средствами в рамках данной книги. Но если в вашем университете имеется такое средство, всеми способами используйте его для создания ER-диаграмм при выполнении назначенных вам упражнений. ER-диаграммы, созданные с помощью CASE-средств, обычно имеют более красивый вид, и их гораздо легче изменять и адаптировать.
Диаграммы «сущность—связь» в стиле UML
Унифицированный язык моделирования (UML) — это набор структур и методик для моделирования и проектирования объектно-ориентированных программ (ООП) и приложений. UML — это одновременно и методология разработки систем ООП, и набор инструментов для разработки таких систем. UML получил известность стараниями группы OMG (Object Management Group) — организации, которая занимается разработкой ООП-моделей, технологии и стандартов с 1980-х годов. Этот язык стал также находить широкое применение в среде профессионалов ООП. На UML базируются инструменты для объектно-ориентированного проектирования, разработанные компанией Rational Systems.
Будучи методологией разработки приложений, UML является предметом курса системной разработки и поэтому представляет для нас лишь ограниченный интерес. Вам могут, однако, встретиться диаграммы «сущность—связь», выполненные в стиле UML, поэтому представление об этом стиле следует иметь.
Диаграммы «сущность—связь» в стиле UML
97
Нужно просто осознать, что когда дело касается проектирования баз данных, обращение с этими диаграммами происходит точно так же, как и с традиционными ER-диаграммами.
Сущности и связи в UML
На рис. 3.12 приведено UML-представление структур, изображенных на рис. 3.3. Каждая сущность представлена классом сущностей, который изображен в виде прямоугольника с тремя сегментами. В верхнем сегменте указано имя сущности и другие данные, о которых мы будем говорить далее. Во втором сегменте перечислены имена атрибутов сущности, а в третьем описаны ограничения и методы (программные процедуры), относящиеся к данной сущности.
ъ	СОТРУДНИК	СЛУЖЕБНЫЙ_АВТОМОБИЛЬ 0..1	1..1	АВТОМОБИЛЬ
	НомерСотрудника Имя Должность Телефон КодКвалификации		НомерЛицензии VINHoMep Производитель Модель ГодВыпуска
	Ограничения и методы перечисляются здесь		Ограничения и методы перечисляются здесь
		а	
Ь Г I.	ОБЩЕЖИТИЕ	ОБЩЕЖИТИЕ-ЖИЛЕЦ 1..1	0..*	СТУДЕНТ
	Название МестныйАдрес КоличествоМест Телефон		НомерСтудента ИмяСтудента Телефон Группа Комната
	Ограничения и методы перечисляются здесь		Ограничения и методы перечисляются здесь
СТУДЕНТ	СТУДЕНТ-КЛУБ 0..*	0..*	КЛУБ
НомерСтудента ИмяСтудента Телефон Группа Комната		НомерКлуба КодИсточникаФинансирования Описание Президент ТелефонПрезидента
		
Ограничения и методы перечисляются здесь		Ограничения и методы перечисляются здесь
в
Рис. 3.12. Представления различных типов связей в UML: а — связь 1:1; б — связь 1 :N; а — связь N:M
98
Глава 3. Модель «сущность—связь-
Связи показаны линиями, соединяющими две сущности. Кардинальность представлена в формате х..у, где х — это необходимый минимум, az/ — допустимый максимум. Так, 0..1 означает, что наличие данной сущности необязательно, а максимально допустимое количество — одна. Звездочка представляет неограниченное количество. Например, запись 1..* означает, что требуется одна сущность, а допускается неограниченное количество. Найдите на-рис. 3.12, а, б примеры связей с максимальной кардинальностью 1:1, 1:N и N:M.
Представление слабых сущностей
На рис. 3.13 изображено UML-представление слабых сущностей. На линии связи рядом с родителем слабой сущности (то есть рядом с сущностью, от которой зависит слабая сущность) помещается закрашенный ромб. На рис. 3.13, а сущность РЕЦЕПТ является слабой сущностью, а сущность ПАЦИЕНТ — ее родителем. Все слабые сущности имеют родителя, поэтому их кардинальность в связи с родителем всегда 1..1. Исходя из этого, кардинальность на родительской стороне обозначается просто как 1.
ПРОЕКТ	ПРОЕКТ-НАЗНАЧЕНИЕ «идентифици рующая» 1..1	0..‘	НАЗНАЧЕНИЕ
НазваниеПроекта ДатаНачала ДатаЗавершения КодИсточникаФинансирования		НазваниеЗадачи НачалоРаботы Предпола: аемоеКоличествоЧасов ДействительноеКоличествоЧасов ИмяСотрудника
		
Идентификатор: НазваниеПроекта Методы		Ограничения и методы перечисляются здесь
б
Рис. 3.13. Представление слабых сущностей в UML: а — слабая сущность, не являющаяся идентификационно-зависимой; б — идентификационно-зависимая слабая сущность
На рис. 3.13, а показана слабая сущность, не являющаяся идентификационнозависимой. Это обозначается выражением <non-identifying> (не идентифицирующая) на связи ПАЦИЕНТ-РЕЦЕПТ. На рис. 3.13, б изображена идентификационнозависимая слабая сущность. На это указывает ярлык «identifying» (идентифицирующая).
Диаграммы «сущность—связь» в стиле UML
99
Представление подтипов
Способ представления подтипов в UML показан на рис. 3.14. На этом рисунке допустимыми подтипами сущности КЛИЕНТ являются ФИЗИЧЕСКОЕ_ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ. В соответствии с рисунком, каждый клиент может иметь один, два или все три указанных подтипа. Для данной ситуации это не имеет смысла: клиент должен быть одного и только одного типа. Текущая версия UML не предоставляет способов для документирования взаимоисключаемости. Можно, однако, добавить в диаграмму соответствующее обозначение.
Рис. 3.14. Представление подтипов в UML
На рис. 3.15 представлена UML-версия диаграммы «сущность—связь», показанной ранее на рис. 3.11. Поскольку связь между сущностями РАБОТА и КЛИЕНТ имеет атрибут Плата, для несения этого атрибута выделена специальная сущность РАБОТА_ДЛЯ_КЛИЕНТА. Такова стандартная практика при использовании средств UML. Обратите также внимание на представление рекурсивной связи КЕМ_ПРИВЕДЕН.
Конструкции ООП, введенные языком UML
Так как UML является объектно-ориентированной технологией, к классам сущностей UML были добавлены некоторые конструкции ООП. Здесь мы только коснемся этих идей, а развитие им дадим в главе 18. Во-первых, классы всех сущностей, которые должны храниться в базе данных, помечаются стереотипом
100
Глава 3. Модель «сущность—связь;
«Persistent» (устойчивый). Это означает, что существование данных должно продолжаться даже после того, как будет разрушен объект, их обрабатывавший. Проще говоря, это значит, что класс сущности должен храниться в базе данных.
Рис. 3.15. UML-версия диаграммы «сущность—связь» с рис. 3.11
Далее, UML допускает назначение атрибутов классам сущностей. Атрибуты класса (class attributes) отличаются от атрибутов сущностей тем, что они принадлежат всему классу сущностей данного типа. Так, на рис. 3.16 атрибут Число-Пациентов сущности ПАЦИЕНТ является атрибутом всей совокупности сущностей этого типа, имеющихся в базе данных. ИсточникПоступления — это атрибут, документирующий источник поступления всех пациентов, присутствующих в базе данных.
Как вы позже узнаете, в рамках реляционной модели такие атрибуты классов просто негде хранить. Вместо того чтобы хранить атрибуты вроде ЧислоПаци-ентов в базе данных, они иногда вычисляются на этапе выполнения программы. В других случаях для хранения этих атрибутов выделяется специальный класс сущностей. Для класса сущностей ПАЦИЕНТ, изображенного на рис. 3.16, можно создать новую сущность под названием ИСТОЧНИК_ПОСТУПЛЕНИЯ_ПАЦИЕНТА, имеющую атрибуты ЧислоПациентов и ИсточникПоступления. В таком случае все сущности класса ПАЦИЕНТ будут связаны с сущностью ИСТОЧНИК_ПОСТУПЛЕНИЯ_ ПАЦИЕНТА.
Диаграммы «сущность—связь» в стиле UML
101
Рис. 3.16. Представление классов сущностей в UML с помощью конструкций ООП
Третьей новой особенностью является то, что UML использует объектно-ориентированную нотацию для обозначения видимости атрибутов и методов. Атрибуты, именам которых предшествует знак «+», являются открытыми, атрибуты со знаком «#» являются защищенными, а со знаком «-» — закрытыми. На рис. 3.16 атрибут Имя сущности ПАЦИЕНТ является защищенным.
Эти термины имеют корни в объектно-ориентированном программировании. Открытым (public) называется такой атрибут, который может читаться и изменяться любым методом любого объекта. Термин защищенный (protected) означает, что атрибут или метод доступен только для методов данного класса и его подклассов, а термин закрытый (private) указывает на то, что соответствующий атрибут или метод доступен только для методов данного класса.
Наконец, в UML задаются ограничения и методы, для чего служит третий сегмент прямоугольника, изображающего класс сущностей. На рис. 3.16 на значение атрибута НомерПациента налагается ограничение первичного ключа. Это означает просто, что НомерПациента является уникальным идентификатором. Кроме того, рис. 3.16 указывает, что должны быть созданы следующие методы: ПолучитьИмя() — для открытого доступа к атрибуту Имя (обратите внимание на знак «+» перед ПолучитьИмя(), ВвестиИмя() — для установки значения этого атрибута, и ПолучитьРецепт() — для перебора совокупности сущностей класса РЕЦЕПТ, связанных с данной сущностью ПАЦИЕНТ.
Роль UML в базах данных на сегодняшний день
Идеи, которые иллюстрирует рис. 3.16, представляются довольно туманными в том, что касается применимости объектного мышления к построению и функционированию баз данных. Такая объектно-ориентированная нотация не согласуется с обычаями и процедурами, принятыми в коммерческих базах данных сегодняшнего дня. Понятие о том, что атрибут сущности может быть скрыт внутри объекта, не имеет смысла, если только база данных не обрабатывается исключительно объектно-ориентированными программами; но даже если так, эти программы должны
102
Глава 3. Модель «сущность—связь;
обрабатывать данные в соответствии с этой политикой. За исключением специализированных объектно-ориентированных СУБД (ООСУБД) и их приложений, так никогда не делается.
Напротив, большинство коммерческих СУБД позволяют всем видам программ обращаться к базе данных и обрабатывать любые данные, в отношении которых у этих программ имеются соответствующие полномочия. Более того, с такими средствами, как генератор запросов в Microsoft Access 2002 (см. рис. 2.6), просто не существует способов ограничить доступ к значениям атрибутов отдельного объекта.
Итак, все сводится к необходимости знания о том, как интерпретировать диаграммы «сущность—связь», выполненные в стиле UML. Они точно так же пригодны для проектирования баз данных, как и традиционные ER-диаграммы. Однако на текущий момент объектно-ориентированная нотация, которая в них вводится, имеет весьма ограниченную практическую ценность. Дальнейшую информацию по этой теме вы найдете в главе 18.
Примеры
Лучший способ приобрести навыки работы с любым средством для моделирования — изучать примеры и использовать это средство для создания своих собственных моделей. В оставшейся части этой главы описаны два примера, которые помогут вам справиться с вашей первой задачей. Проработав эти примеры, займитесь решением задач, приведенных в конце главы.
Пример 1: танцевальный клуб Джефферсона
Танцевальный клуб Джефферсона производит обучение танцам и предлагает индивидуальные и групповые занятия. Плата составляет $45 в час с человека или пары при индивидуальных занятиях и $6 в час с человека при групповых занятиях. Индивидуальные занятия проводятся на протяжении всего дня, с полудня до 22 часов, шесть дней в неделю. Групповые занятия проводятся по вечерам.
В танцевальном клубе работают два вида инструкторов: постоянные и приходящие. Постоянные инструкторы еженедельно получают фиксированную зарплату, а приходящие получают установленную сумму либо за вечер, либо за работу с конкретным классом.
Кроме занятий, танцевальный клуб Джефферсона два раза в неделю организует танцевальные вечеринки с музыкальными записями. Входная плата составляет $5 с человека. Танцевальный вечер в пятницу пользуется большей популярностью и собирает в среднем около 80 человек; воскресный вечер собирает около 30 посетителей. Цель этих танцевальных вечеров — предоставить ученикам место для практики. Еда и напитки не предусматриваются.
Танцевальный клуб хотел бы разработать информационную систему, которая позволяла бы вести учет проведенных занятий и учеников. Помимо того, менеджеры клуба хотели бы знать количество и типы занятий, проведенных каждым
Примеры
103
инструктором, а также иметь возможность подсчитать среднюю стоимость занятия у каждого инструктора.
Сущности
Лучше всего начать построение модели «сущность—связь» с определения потенциальных сущностей. В документах или беседах сущности обычно представляются существительными (места, люди, концепции, события, оборудование и т. п.). Исследовав предыдущий пример на предмет важных словосочетаний, относящихся к информационной системе, мы получим следующий список:
♦	индивидуальное занятие;
♦	групповое занятие;
♦	инструктор;
+	постоянный инструктор;
♦	приходящий инструктор;
♦	вечер танцев;
♦	клиент.
Ясно, что словосочетания индивидуальное занятие и групповое занятие имеют между собой нечто общее, как и словосочетания постоянный инструктор и приходящий инструктор. Одним из возможных решений будет определить сущность под названием ЗАНЯТИЕ с подтипами ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ и ГРУППОВОЕ_ ЗАНЯТИЕ, а также сущность ИНСТРУКТОР с подтипами ПОСТОЯННЫЙ_ИНСТРУКТОР и ПРИХОДЯ ЩИ Й_ИНСТРУКТОР. Кроме этих сущностей, в модели будут присутствовать сущности ВЕЧЕР_ТАНЦЕВ и КЛИЕНТ.
Как было отмечено в главе 2, в моделировании данных есть столько же от искусства, сколько от науки. Решение, описанное только что, является лишь одним из возможных. Второе решение состоит в том, чтобы исключить сущности ЗАНЯТИЕ и ИНСТРУКТОР из списка, приведенного в предыдущем абзаце, и удалить все подтипы. Третье возможное решение — это исключить сущность ЗАНЯТИЕ (поскольку занятие нигде не упоминается само по себе как словосочетание), но оставить сущность ИНСТРУКТОР и ее подтипы. В данном случае мы выберем третий вариант, так как он представляется наиболее подходящим с точки зрения имеющейся у нас информации. Таким образом, список сущностей будет выглядеть следующим образом: ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ, ГРУППОВОЕ_ЗАНЯТИЕ, ИНСТРУКТОР, ПОСТОЯННЫЙ_ИНСТРУКТОР, ПРИХОДЯ ЩИ Й_ИНСТРУКТОР, ВЕЧЕР_ТАНЦЕВ и КЛИЕНТ.
Чтобы сделать правильный выбор среди этих альтернатив, необходимо проанализировать требования и выяснить, каким образом данные требования отразятся на структуре системы. Иногда полезно рассмотреть атрибуты сущностей. Если, например, сущность ЗАНЯТИЕ не имеет никаких атрибутов, кроме идентификатора, то вводить такую сущность нет необходимости.
Связи
Начнем с того, что сущность ИНСТРУКТОР имеет два подтипа: ПОСТОЯННЫЙ_ИНС-ТРУКТОР и ПРИХОДЯЩИЙ_ИНСТРУКТОР. Любой инструктор должен быть либо постоянным, либо приходящим, значит, подтипы являются взаимоисключающими.
104
Глава 3. Модель «сущность—связь;
Далее рассмотрим связи между сущностями ИНСТРУКТОР и ИНДИВИДУАЛЬНОЕ-ЗАНЯТИЕ или ГРУППОВОЕ-ЗАНЯТИЕ. Инструктор может проводить много индивидуальных занятий и, как правило, индивидуальное занятие проводится одним инструктором. Но в ходе дальнейшего разговора с менеджерами танцевального клуба выясняется, что для продвинутых танцоров, особенно тех, кто готовится к соревнованиям, к индивидуальным занятиям иногда привлекается два инструктора. Поэтому связь между сущностями ИНСТРУКТОР и ИНДИВИДУАЛЬНОЕ-ЗАНЯТИЕ должна иметь тип «один ко многим». По поводу групповых занятий мы, однако, будем полагать, что каждое из них ведет только один инструктор. Связи, описанные нами только что, изображены на рис. 3.17.
Клиенты могут посещать как индивидуальные, так и групповые занятия. Иногда индивидуальное занятие проводится с одним человеком, а иногда — с парой. Есть два способа моделирования этой ситуации. Можно определить сущность ПАРА как имеющую связь 1:2 с сущностью КЛИЕНТ, а можно допустить, что обе сущности, КЛИЕНТ и ПАРА, могут иметь связь с сущностью ИНДИВИДУАЛЬНОЕ-ЗАНЯТИЕ. Мы предполагаем, что пары не посещают групповые занятия, а если и посещают, то этот факт не настолько важен, чтобы записывать его в базу данных. Эта альтернатива показана на рис. 3.18, а.
Существование сущности ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ зависит от сущностей КЛИЕНТ и ПАРА. То есть занятие не может существовать, если оно не проводится с каким-либо клиентом или парой. Число 1 рядом с горизонтальной линией, проведенной на рисунке под сущностями КЛИЕНТ и ПАРА, показывает, что в индивидуальном занятии должны участвовать как минимум один клиент или одна пара, что разумно, поскольку индивидуальное занятие зависит от них.
Рис. 3.17. Исходная ER-диаграмма для танцевального клуба Джефферсона
Альтернатива заключается в том, чтобы не вводить пары, а указать тип связи между сущностями КЛИЕНТ и ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ как «многие ко многим». Если быть более точным, эта связь должна иметь тип «один или два ко многим», как показано на рис. 3.18, б. Хотя эта модель является не такой подробной, как модель на рис. 3.18, а, ее может быть вполне достаточно для нужд танцевального клуба Джефферсона.
Осталось рассмотреть возможные связи сущности ВЕЧЕР_ТАНЦЕВ с другими сущностями. Вечера танцев посещают как инструкторы, так и клиенты, и разработ-
Примеры
105
чики должны решить, важно ли показывать эти связи в структуре базы данных. Действительно ли для танцевального клуба важно знать, какие клиенты посетили какие танцевальные вечера? Так ли уж хотят менеджеры клуба вести запись посетителей в компьютерную информационную систему при входе в танцзал? И захочется ли посетителям, чтобы эти данные записывались? Скорее всего, эти связи не принадлежат к числу тех, которые требуется или следует хранить в базе данных.
КЛИЕНТ -О-
+- ПАРА
Гиндивидуальное занятие1
а
б
Рис. 3.18. Способы представления клиента: а — с сущностью ПАРА; б — без сущности ПАРА
Иначе обстоит дело со связью между сущностями ВЕЧЕР_ТАНЦЕВ и ИНСТРУКТОР. Хозяин клуба любит, когда на танцевальных вечерах присутствуют несколько клубных инструкторов. В связи с этим требованием правление клуба составило расписание посещения вечеров инструкторами. Составление и запись этого расписания требуют, чтобы в базе данных присутствовала связь ВЕЧЕР_ТАНЦЕВ-ИНСТРУКТОР, которая имеет тип «многие ко многим».
Окончательный вид ER-диаграммы для танцевального клуба Джефферсона
На рис. 3.19 показан окончательный вид ER-диаграммы для модели, описанной в этом разделе. Мы не стали приводить на ней имена связей: хотя это сделало бы диаграмму более правильной по форме, при имеющихся у нас данных указание имен связей мало что прибавило бы.
Существование сущности ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ зависит от сущности КЛИЕНТ, а ГРУППОВОЕ_ЗАНЯТИЕ — нет, потому что расписание групповых занятий
106
Глава 3. Модель «сущность—связь;
составляется задолго до того, как на них записывается какой-либо клиент, и эти занятия будут проводиться даже в том случае, если ни один клиент не придет. Для индивидуальных занятий, однако, дело обстоит не так — они назначаются только по запросу клиента. Обратите также внимание, что в этой модели не представлены пары.
Рис. 3.19. Окончательный вид ER-диаграммы для танцевального клуба Джефферсона
Разработав модель, подобную этой, следует проверить, насколько она точна и полна по отношению к требованиям пользователей. Обычно это делается с помощью самих пользователей.
Проверка созданной ER-модели данных
Ошибки проще и дешевле исправлять на ранних стадиях процесса разработки базы данных, чем на поздних. Например, изменение максимального кардинального числа связи с 1:N на N:M на стадии моделирования данных сводится просто к внесению соответствующего исправления в ER-диаграмму. Но когда база данных уже разработана и наполнена данными и написаны прикладные программы для ее обработки, такое изменение потребует значительной переделки, возможно, даже недель труда. Поэтому важно определить, какая модель данных требуется, прежде чем начинать ее воплощать.
Один из способов сделать это — рассмотреть ER-модель в контексте того, на какого рода запросы может ответить база данных со структурой, описываемой данной моделью. Взгляните, к примеру, на диаграмму, изображенную на рис. 3.19. На какие вопросы может дать ответ база данных, реализованная на основе данного проекта?
♦ Какие и кем были проведены индивидуальные занятия?
♦ Какие клиенты посещали индивидуальные занятия у Джека?
♦ Кто является постоянным инструктором клуба?
4- Какие инструкторы должны прийти на танцевальный вечер в пятницу?
Примеры
107
При проверке модели данных вы можете формулировать такие вопросы и задавать их пользователям, которых затем можно попросить составить свой список вопросов. Они могут задавать вопросы, касающиеся структуры базы данных, чтобы проверить ее соответствие поставленным требованиям. Например, представьте, что пользователи спрашивают, какие клиенты посетили вечер танцев в прошлую пятницу. Разработчики модели данных, изображенной на рис. 3.19, должны прийти к заключению, что их структура неверна, поскольку на поставленный вопрос с помощью данной ER-модели ответить невозможно. Если требуется ответ на этот вопрос, необходимо ввести связь между сущностями КЛИЕНТ и ВЕЧЕР_ТАНЦЕВ.
Очевидно, что посредством такого неформального и нечетко структурированного процесса невозможно доказать, что структура является правильной. Тем не менее, это прагматичный метод, пригодный для определения потенциальной правильности структуры. И даже такой метод все же лучше, чем отсутствие проверки вообще!
Пример 2: бюро проката парусных яхт Сан-Хуана
Бюро проката яхт Сан-Хуана — это посредническая фирма, занимающаяся прокатом парусных яхт. Яхты не являются собственностью фирмы — она сдает их от имени владельцев, которые хотят получать доход от своих яхт, когда не пользуются ими. За свои услуги фирма Сан-Хуана берет плату. Фирма специализируется на яхтах, которые могут использоваться для многодневных или недельных походов: самая маленькая из яхт имеет длину 28 футов, а самая большая — 51 фут.
Каждая яхта полностью экипирована на момент сдачи в аренду. Большая часть оборудования предоставляется владельцами, но некоторое оборудование добавляется фирмой. Оборудование, предоставляемое владельцами, включает в себя предметы, закрепленные на яхте, то есть радиостанции, компасы, глубиномеры и прочий инструмент, плиты и холодильники. Есть и другое оборудование, предоставляемое владельцами, но не являющееся частью яхты. Это могут быть паруса, лини, якоря, спасательные шлюпки, спасательные жилеты, а также то, что находится в каютах: блюда, столовое серебро, кухонные принадлежности, постельные принадлежности и т. д. Фирма Сан-Хуана предоставляет также расходуемый инвентарь и припасы — карты, навигационные книги, таблицы приливов и течений, мыло, полотенца для посуды, туалетную бумагу и тому подобные предметы.
Важной составляющей обязанностей фирмы Сан-Хуана является учет оборудования, имеющегося на яхтах. Многое оборудование является дорогим, а некоторое, в частности то, которое не закреплено на яхте, может легко потеряться или быть украдено. В течение срока проката яхты ответственными за оборудование являются клиенты.
Фирма Сан-Хуана ведет подробный учет клиентов и истории проката яхт. Это требуется не только для маркетинговых целей, но и для того, чтобы иметь
108
Глава 3. Модель «сущность—связь:
записи о путешествиях клиентов. Некоторые маршруты и погодные условия более опасны, чем другие, поэтому фирма желает знать об опыте своих клиентов.
По большей части фирма занимается прокатом только яхт, то есть капитан или команда не предоставляется. В некоторых случаях, однако, клиенты заказывают услуги капитана или каких-либо других членов команды, и тогда фирма нанимает соответствующий персонал на договорной основе.
Яхты часто требуют обслуживания. Контракты, заключенные фирмой Сан-Хуана с владельцами лодок, требуют от фирмы ведения тщательной записи всех операций по обслуживанию и связанных с этим расходов, включая обычные операции, такие как мойка или замена масла, а также внеплановые ремонты. Иногда ремонт может потребоваться во время рейса. Например, у яхты может отказать двигатель, когда она будет находиться далеко от доков Сан-Хуана. В этом случае клиенты вызывают по радио диспетчера фирмы, который определяет наиболее подходящее место для проведения ремонта и направляет персонал оттуда на аварийную яхту. Чтобы принимать все эти решения, диспетчерам требуется информация об имеющихся ремонтных доках, а также сведения о качестве и стоимости предыдущих ремонтов.
Прежде чем продолжить чтение, постарайтесь составить диаграмму «сущность-связь» для этого случая самостоятельно. Проанализируйте приведенный выше текст и найдите в нем существительные, которые, на ваш взгляд, являются важными для проекта. После этого определите возможные связи между сущностями. Наконец, перечислите возможные атрибуты каждой сущности и связи.
Сущности
Модель данных, требуемая для бюро аренды Сан-Хуана, более сложна, чем модель для танцевального клуба Джефферсона. Потенциальные сущности показаны на рис. 3.20, а.
Рассмотрим сначала сущности, относящиеся к оборудованию. Есть много различных типов оборудования, и это наводит нас на мысль о введении подтипов. Однако спросим себя: почему фирму Сан-Хуана должно интересовать оборудование? Фирме вовсе не нужно знать характеристики каждого предмета — например, длину цепи каждого якоря. В задачи фирмы скорее входит учет элементов оборудования и их типов, чтобы можно было определить, что из оборудования потеряно или повреждено. Таким образом, для данного случая мы отнесем все типы оборудования к одной сущности — ОБОРУДОВАНИЕ.
Принадлежность оборудования указывается путем введения связи между сущностями ОБОРУДОВАНИЕ и ВЛАДЕЛЕЦ. Если фирма Сан-Хуана может быть экземпляром сущности ВЛАДЕЛЕЦ, то все оборудование, являющееся собственностью фирмы, может быть отнесено к этой сущности. Аналогичным образом, исходя из описанной ситуации, представляется безосновательным разделение оборудования на закрепленное и не закрепленное на яхте. Точный список может быть составлен и без такого разделения. Окончательный список сущностей приведен на рис. 3.20, б.
Примеры
109
АРЕНДА
ЯХТА
КЛИЕНТ
ВЛАДЕЛЕЦ
ОБОРУДОВАНИЕ
ОБОРУДОВАН И Е_ВЛАДЕЛ ЬЦА
ЗАКРЕПЛЕННОЕ_ОБОРУДОВАНИЕ_ВЛАД ЕЛЬЦА НЕЗАКРЕПЛЕННОЕ_ОБОРУДОВАНИЕ_ВЛАДЕЛЬЦА СОБСТВЕННОЕ_ОБОРУДОВАНИЕ_ФИРМЫ
МАРШРУТ_И_ПОГОДА
РЕЙС
ВРЕМЕННАЯ_КОМАНДА
ПЛАНОВОЕТЕХОБСЛУЖИВАНИЕ
ВНЕПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ
РЕМОНТ
РЕМОНТНЫЙ_ДОК
а
Возможные сущности для бюро аренды Сан-Хуана
АРЕНДА, или РЕЙС (синонимы)
ЯХТА
КЛИЕНТ
ВЛАДЕЛЕЦ
ОБОРУДОВАНИЕ
МАРШРУТ_И_ПОГОДА
ВРЕМЕННАЯ_КОМАНДА
ПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ
РЕМОНТ, или ВНЕПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ (синонимы) РЕМОНТНЫЙ_ДОК
б
Окончательный список сущностей
Рис. 3.20. Сущности для бюро аренды яхт Сан-Хуана
Обратите внимание, что АРЕНДА и РЕЙС являются синонимами: они относятся к одной и той же транзакции. Мы приводим здесь оба имени, чтобы можно было соотнести их с описанием ситуации.
Возможно, что сущности ПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ и ВНЕПЛАНОВОЕ_ТЕХ-ОБСЛУЖИВАНИЕ следует объединить. Один из способов определить, необходимо это или нет, — проанализировать атрибуты обеих сущностей. Если они одинаковы, то два класса сущностей могут быть объединены. Заметьте также, что сущности РЕМОНТ и ВНЕПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ определены как синонимы.
Связи
На рис. 3.21 изображена диаграмма «сущность—связь» для бюро аренды Сан-Хуана. По большей части представленные на этой диаграмме связи являются очевидными, но связь между сущностями ОБОРУДОВАНИЕ и АРЕНДА может быть предметом спора. Можно было бы сказать, что определенная часть оборудования должна быть отнесена к яхте (сущность ЯХТА), а не к аренде, или что часть оборудования (а именно оборудование, которое закреплено на яхте) следует отнести к яхте, а оставшуюся часть — к аренде. Эти изменения представляют собой возможные альтернативы для структуры, показанной на рис. 3.21.
110
Глава 3. Модель «сущность—связь;
Рис. 3.21. ER-диаграмма для бюро аренды яхт Сан-Хуана
Кроме того, обратите внимание, что сущность ПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ связана с сущностью ЯХТА, в то время как сущность РЕМОНТ, или ВНЕПЛАНОВОЕ-ТЕХОБСЛУЖИВАНИЕ, связана с сущностью АРЕНДА. Это подразумевает, что когда яхта не находится в аренде, никакого ремонта для нее не требуется. Может быть, это не соответствует действительности.
Наконец, сущности АРЕНДА и ПОГОДА_И_МАРШРУТ имеют связь 1:1, и они также имеют одинаковые идентифицирующие атрибуты. В связи с этим можно, а может быть, даже нужно объединить их в один класс сущностей.
Базы данных как модели моделей
Как вы можете видеть, есть множество различных способов моделирования конкретной ситуации в деловом мире, и это множество становится все обширнее по мере того, как моделируемая ситуация усложняется. Зачастую количество возможных моделей оказывается огромным, и выбрать среди них одну может быть нелегко.
Иногда при выявлении альтернатив команда, занимающаяся проектом, углубляется в дискуссии по поводу того, какая модель данных наилучшим образом представляет реальный мир. Эти дискуссии исходят из ложных посылок. Базы данных не моделируют реальный мир, хотя распространено ошибочное мнение, согласно которому именно в этом и состоит их назначение. Базы данных являются моделями пользовательских моделей мира (или, точнее, делового мира). Вопрос, задаваемый при выявлении альтернативных моделей данных, состоит не в том, насколько точно данная модель отражает реальный мир, а в том, насколько точно она отражает имеющуюся в воображении пользователя модель среды,
111
Резюме
4
которая его окружает. Цель заключается в том, чтобы разработать структуру, которая будет соответствовать представлениям пользователей.
Иммануил Кант и другие философы могли бы возразить, что людям не дано построить модель того, что существует на самом деле, и заявили бы, что суть вещей навсегда останется тайной для человечества1. Распространяя эту аргументацию на компьютерные системы, Виноград (Winograd) и Флоре (Flores) высказали идею, что в обществах индивидуумы конструируют системы символов, которые позволяют нм успешно действовать в мире. Последовательность символов не является моделью бесконечности реального мира, а скорее представляет собой просто социальную систему, позволяющую пользователям успешно координировать свои действия; ничего более по этому поводу сказать нельзя1 2.
Таким образом, компьютерные системы должны моделировать и представлять взаимоотношения между своими пользователями. Они не моделируют ничего, кроме системы символов и связей. Поэтому научитесь задавать себе следующие вопросы: «Насколько точно данная модель отражает восприятие пользователей и имеющуюся в их воображении модель мира? Поможет ли эта модель пользователям согласованно и успешно взаимодействовать друг с другом и с клиентами?» Для аналитика бессмысленно заявлять, что его модель является лучшим представлением реальности. Суть в том, чтобы разработать модель, которая адекватно отражает модель деловой среды в представлении пользователя.
Резюме
Модель «сущность—связь» была разработана Питером Ченом. В этой модели определяются сущности — идентифицируемые объекты, представляющие важность для пользователя. Все сущности данного типа образуют класс сущностей. Отдельная сущность называется экземпляром. Сущности имеют атрибуты, которые описывают их характеристики; один или несколько атрибутов определяют сущность.
Связи отражают взаимоотношения между сущностями. В ER-модели связи определяются явным образом; у каждой связи есть имя; существуют также классы связей и экземпляры связей. У связей могут быть атрибуты.
Степень связи — это число сущностей, которые в ней участвуют. Большинство связей являются бинарными. Имеется три типа бинарных связей: 1:1, 1:N и N:M.
На диаграммах «сущность—связь» сущности изображаются прямоугольниками, а связи — ромбами. Максимальное кардинальное число связи указывается внутри ромба. Минимальное кардинальное число указывается с помощью перпендикулярной черты или овала. Связи, соединяющие сущности одного класса,
1 «Мы не можем, разумеется, за пределами всего возможного опыта составить определенное представление о том, какими являются веши сами по себе. И все же не в нашей власти совершенно устраниться от лх исследования; ибо опыт никогда ие удовлетворяет рассудок полностью, но, отвечая на вопросы, отсылает нас все дальше и дальше назад и оставляет нас неудовлетворенными относительно полного решения» (Иммануил Кант. Пролегомены к любой будущей метафизике).
2 Terry Winograd and F. Flores, Understanding Computers and Cognition (Reading, MA: Addison-Wesley, 1986).
112
Глава 3. Модель «сущность—связь;
называются рекурсивными. Атрибуты могут быть показаны на ER-диаграмме в эллипсах или в отдельной таблице.
Слабая сущность — это сущность, существование которой зависит от другой сущности; сущность, не являющаяся слабой, называется сильной сущностью. Слабые сущности изображаются с помощью прямоугольников со скругленными углами. Далее в этой книге мы определяем слабую сущность как сущность, логически зависящую от другой сущности. Сущность может иметь минимальное кардинальное число 1 в связи с другой сущностью, но при этом не быть слабой. Многозначные атрибуты представляются с помощью слабых сущностей.
Некоторые сущности имеют подтипы, которые определяют подмножества подобных сущностей. Подтипы наследуют атрибуты от своего родителя, или надтипа. Связи типа «ИМЕЕТ» соединяют сущности разных типов, и идентификаторы у этих сущностей различны. Связи типа «ЕСТЬ» — это связи подтипов с их родителями, и идентификаторы у сущностей, участвующих в такой связи, одинаковы.
Разработав модель данных, необходимо определить деловой регламент, который будет накладывать ограничения на возможные действия с сущностями. Каждая сущность в модели должна быть проанализирована на предмет возможного добавления, изменения и удаления данных. Удаления, в частности, зачастую являются источником важных ограничений на обработку. Сформулированные правила делового регламента необходимо документировать в модели данных.
Модель «сущность—связь» является важной частью многих CASE-продук-тов. Эти продукты предоставляют средства для конструирования и хранения ER-диаграмм. Некоторые из CASE-инструментов объединяют конструкции ER-модели с данными репозитория CASE. Унифицированный язык моделирования (UML) вводит новый стиль построения диаграмм «сущность—связь». Вам следует иметь представление о диаграммах, выполненных в этом стиле; однако нужно понимать, что при проектировании базы данных не существует фундаментальных различий между традиционным стилем и UML-стилем.
Завершив создание ER-модели, следует ее испытать. Один из способов это сделать — составить перечень вопросов, на которые можно ответить с помощью разработанной модели данных. Далее этот перечень показывается пользователям, которым предлагают подумать насчет дополнительных вопросов. Затем проверяется способность ER-модели ответить на эти дополнительные вопросы.
Базы данных моделируют не реальный мир, а модель делового мира, присутствующую в воображении пользователя. Правильным критерием для оценки модели данных является то, насколько эта модель соответствует пользовательской модели. Спор о том, какая модель наилучшим образом отражает реальный мир, не имеет смысла.
Вопросы группы I
1.	Дайте определение сущности и приведите пример.
2.	Поясните разницу между классом сущностей и экземпляром сущности.
3.	Дайте определение атрибута и приведите примеры атрибутов для сущности, описанной вами в ответе на вопрос 1.
Вопросы группы 1
113
I 4. Объясните, что такое композитный атрибут, и приведите пример.
5. Какой из атрибутов, приведенных вами в ответе на вопрос 3, идентифици-4 руст сущность?
' 6. Дайте определение связи и приведите пример.
, 7. Объясните, в чем разница между классом связей и экземпляром связи.
8.	Дайте определение степени связи. Приведите пример связи со степенью больше 2, отличный от того, который дан в тексте.
9.	Перечислите три типа бинарных связей и приведите примеры. Нарисуйте ER-диаграмму для каждого типа.
10.	Дайте определения терминов максимальное кардинальное число и минимальное кардинальное число, максимальная кардинальность и минимальная кардинальность.
1 И. Назовите и нарисуйте символы, используемые в диаграммах «сущность— .1 связь» для изображения: (а) сущности; (б) связи; (в) слабой сущности и ее ; связи; (г) рекурсивной связи; (д) сущности подтипа.
а 12. Приведите пример ER-диаграммы для сущностей ОТДЕЛ и СОТРУДНИК, :« имеющих связь 1:N. Сделайте допущение, что в отделе может и не быть сотрудников, но каждый сотрудник должен работать в каком-либо отделе.
; 13. Приведите пример рекурсивной связи и изобразите его на ER-диаграмме.
14.	Приведите примеры атрибутов для сущностей ОТДЕЛ и СОТРУДНИК (из от-। вета на вопрос 12) и изобразите их на ER-диграмме. Используйте для этого символы UML-стиля.
’ 15. Дайте определение термина слабая сущность и приведите пример, отличный от того, который дан в тексте.
16.	Поясните, в чем состоит неоднозначность в определении термина слабая сущность. Как этот термин интерпретируется в книге? Приведите примеры, отличные от тех, которые даны в тексте.
17.	Дайте определение термина идентификационно-зависимая сущность и приведите пример, отличный от того, который дан в тексте.
18.	Продемонстрируйте использование слабой сущности для представления 1 многозначного атрибута Квалификация сущности СОТРУДНИК. Укажите минимальное и максимальное кардинальное число на обеих сторонах связи. ’1 Используйте традиционные символы.
19.	Продемонстрируйте использование слабой сущности для представления многозначного составного атрибута Телефон, состоящего из однозначных атрибутов КодРегиона и НомерТелефона. Пусть при этом атрибут Телефон принадлежит сущности ПРОДАВЕЦ. Укажите минимальное и максимальное кардинальное число на обеих сторонах связи. Используйте символы UML-стиля.
с 20. Опишите, что такое подтипы сущностей, и приведите пример, отличный от того, который дан в тексте.
114
Глава 3. Модель «сущность—связь;
21.	Объясните значение термина наследование и покажите, как он относится к вашему ответу на вопрос 20.
22.	Поясните разницу между связью типа «ИМЕЕТ» и связью типа «ЕСТЬ» и приведите пример для каждой связи.
23.	Как документируется деловой регламент в модели «сущность—связь»?
24.	Объясните, почему важно проверять модель данных после ее создания. Опишите один из способов проверки модели данных и объясните, как с помощью этого способа можно проверить модель, изображенную на рис. 3.21.
Вопросы группы II
25.	Модифицируйте ER-диаграмму на рис. 3.19, включив в нее сущность ЗАНЯТИЕ. Пусть сущности ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ и ГРУППОВОЕ_ЗАНЯТИЕ будут подтипами сущности ЗАНЯТИЕ. Измените связи, где это необходимо. Используйте традиционные символы.
26.	Модифицируйте ER-диаграмму на рис. 3.19, исключив из нее сущность ИНСТРУКТОР. Измените связи, где это необходимо. Используйте символы UML-стиля.
27.	Какие из моделей на рис. 3.19 и из вашего ответа на вопросы 25 и 26 вы предпочитаете? Объясните причину вашего предпочтения.
28.	Модифицируйте ER-диаграмму на рис. 3.21, включив в нее подтипы оборудования. При этом допустите, что оборудование, находящееся в собственности бюро аренды Сан-Хуана, относится к сущности АРЕНДА, а прочее оборудование относится к сущности ЯХТА. Для оборудования, относящегося к яхте, смоделируйте различие между тем оборудованием, которое закреплено, и тем, которое не закреплено на яхте. Каков выигрыш от такой усложненной модели?
Проекты
Разработайте ER-диаграмму для базы данных Городского жилищного агентства — некоммерческой организации, выступающей за создание жилья для малообеспеченных граждан и улучшение его качества. Агентство работает в одном из крупных городов Среднего Запада, включая пригороды, с общим количеством населения около 2,2 миллионов человек.
Агентство ведет учет местоположения, занятости и состояния жилья для лиц с низкими доходами на 11 переписных участках города и его пригородов. В пределах этих участков имеется около 250 зданий, где предоставляется жилье малообеспеченным гражданам. В среднем в каждом здании имеется 25 квартир и других единиц жилья.
Агентство хранит информацию по каждому переписному участку — географические границы, типичные доходы населения, имена выборных лиц, основные
Проекты
115
предприятия, главных инвесторов важнейших объектов данного района, а также прочие демографические и экономические данные. Хранится также ограниченное количество информации о криминальной обстановке. Для каждого здания агентство хранит следующую информацию: наименование, адрес, размер, имя и адрес владельца, имя и адрес должника по закладной, данные о ремонте и реконструкции, а также наличие приспособлений, облегчающих жизнь инвалидов. Кроме того, агентство хранит список всех единиц жилья в здании, включая тип, площадь, число спален, число ванных комнат, наличие кухни и столовой, местоположение внутри здания и различные примечания. Агентство хотело бы иметь данные о среднем числе жильцов на квадратный метр для каждой единицы жилья, но на сегодняшний день не имеет возможностей для сбора и хранения такого рода данных. Тем не менее, агентство хранит информацию о том, является ли конкретная единица жилья занятой.
Столичное агентство жилья служит в качестве информационной палаты и предлагает три основных вида услуг. Во-первых, оно ведет работу с политиками, лоббистами и адвокатскими группами в поддержку закона, который бы поощрял развитие жилья для малообеспеченных через налоговые льготы, выделение предпочтительных зон развития и другие законодательные стимулы. Для этого агентство предоставляет информацию о жилье для граждан с низким доходом руководству штата, округа и города. Во-вторых, посредством выступлений, семинаров, выставок на съездах и другой PR-деятельности официальные лица агентства прилагают усилия к повышению осознания обществом потребности в жилье для малообеспеченных людей. Наконец, агентство предоставляет информацию о таком жилье другим агентствам, работающим с малообеспеченными и бездомными.
1. Зайдите на сайт производителя компьютеров, например Dell (www.deLL.com). Пользуясь средствами сайта, определите, какой ноутбук вы могли бы при-g5j обрести для пользователя с бюджетом $10000. Занимаясь выяснением этого вопроса, подумайте о том, какой структурой может обладать база данных по компьютерным системам и подсистемам, используемая для поддержки v.-(j данного сайта.
Разработайте ER-диаграмму для базы данных по компьютерным системам и подсистемам для этого сайта. Изобразите на ней все сущности и связи, причем у сущности должно быть минимум два атрибута. Укажите минимальное и максимальное кардинальное число для обеих сторон каждой связи. Возможными сущностями являются БА30ВАЯ_К0НФИГУРАЦИЯ, ОБЪЕМ_ ПАМЯТИ, ВИДЕОКАРТА и ПРИНТЕР. (Разумеется, в реальности возможных сущностей гораздо больше.) Введите какие-нибудь многозначные атрибуты, как показано в тексте. Используйте подтипы, где это имеет смысл. Чтобы проект не оказался чрезмерно велик, ограничьтесь тем, что требуется для человека, который точно решил купить компьютер, но еще не выбрал, какой именно.
2. Зайдите на сайт виртуального книжного магазина, например Amazon (www. amazon.com). Пользуясь средствами сайта, найдите три лучших книги по XML для человека, который только начал изучать этот предмет. Занимаясь выяснением данного вопроса, подумайте о том, какой может быть структура базы данных по книгам, авторам, предметам и родственным темам.
116
Глава 3. Модель «сущность—связь»
Разработайте ER-диаграмму для базы данных этого сайта. Изобразите на ней все сущности и связи, причем каждая сущность должна иметь не меньше двух-трех атрибутов. Укажите минимальное и максимальное кардинальное число для обеих сторон каждой связи. Возможными сущностями являются ЗАГОЛОВОК, АВТОР, ИЗДАТЕЛЬ, ЭКЗЕМПЛЯР и ТЕМА. (Разумеется, в реальности возможных сущностей гораздо больше.) Введите какие-нибудь многозначные атрибуты, как показано в тексте. Используйте подтипы, где это имеет смысл. Чтобы проект не слишком разрастался, предположим, что учет нужен только для книг. Далее ограничьтесь потребностями человека, который точно решил купить книгу, но еще не выбрал, какую. Не рассматривайте заказ клиента, выполнение заказа, заказ на поставку и другие подобные деловые операции.
Вопросы к проекту FiredUp
Рассмотрим ситуацию, обсуждаемую в конце глав 1 и 2. Предположим, что фирма FiredUp разработала линию из трех горелок: FiredNow, Fired Always и Fired At -Camp. Предположим далее, что фирма продает запасные части для каждого типа горелок, а также производит их ремонт. В одних случаях ремонт является бесплатным, поскольку выполняется в течение гарантийного срока, в других случаях взимается только стоимость деталей, в третьих взимается стоимость деталей и работы. Фирма FiredUp желает вести учет всех этих данных. Когда владельцев фирмы спросили о подробностях, они составили следующий список:
КЛИЕНТ: Имя, Улица, Дом, Квартира, Город, Штат, Индекс, Страна, ЭлектронныйАдрес, Телефон
ГОРЕЛКА: СерийныйНомер, Тип, ДатаИзготовления, ИнициалыПроверяющего
СЧЕТ-ФАКТУРА: НомерСчета, Дата, Клиент (со списком проданных товаров и указанием их стоимости), Сумма
РЕМОНТ: НомерРемонта, Клиент, Горелка, Описание (со списком деталей, использованных при ремонте, и указанием их стоимости, если таковая взимается), Сумма
ДЕТАЛЬ: Номер, Описание, Стоимость, ПродажнаяЦена
1.	Создайте диаграмму «сущность—связь» для базы данных фирмы FiredUp. Задайте на свое усмотрение минимальную и максимальную кардинальность для связей между сущностями. Дайте объяснение каждому кардинальному числу. Используйте слабые сущности там, где считаете это нужным. Не используйте подтипы. Укажите идентификационно-зависимые сущности, если таковые имеются.
2.	Модифицируйте ER-диаграмму из вашего ответа на вопрос 1, представив сущности СЧЕТ-ФАКТУРА и РЕМОНТ соответствующими подтипами. При каких условиях эта структура окажется лучше, чем предыдущая?
3.	Предположим, что фирма FiredUp хочет записывать домашний и мобильный телефон, факс и несколько адресов электронной почты своих клиентов. Модифицируйте свою ER-диаграмму, введя множественные значения атрибутов Телефон и ЭлектронныйАдрес.
Вопросы к проекту FiredUp,117
4,	Предположим, что фирма FiredUp разрабатывает различные версии одной и той же горелки, то есть FiredNow Version 1, FiredNow Version 2 и т. д. Модифицируйте необходимым образом вашу ER-диаграмму из ответа на вопрос 1, чтобы учесть эту ситуацию.
5.	Когда пользователей спрашивают о том, какие данные они хотели бы отслеживать, они не всегда помнят все, что им нужно. Пользуясь своими знаниями об операциях малого предприятия, составьте список сущностей, которые они могли забыть. Покажите потенциальные связи между этими сущностями на ER-диаграмме. Что бы вы сказали по поводу необходимости каких-либо из этих дополнительных данных для FiredUp?
Глава 4
Семантическая объектная модель
В этой главе обсуждается семантическая объектная модель (semantic object model), которая, так же как и модель «сущность—связь», описанная в главе 3, используется для моделирования данных. Как показано на рис. 4.1, команда разработчиков опрашивает пользователей, анализирует предоставленные ими отчеты, формы и запросы и на их основе строит пользовательскую модель данных. Эта модель данных в дальнейшем воплощается в структуре базы данных.
Конкретная форма модели данных зависит от конструкций, используемых для ее построения. Если используется модель «сущность—связь», конструируемая модель будет содержать сущности, связи и т. п. В случае использования семантической объектной модели конструируемая модель будет содержать семантические объекты и связанные с ними конструкции, которые описываются в данной главе.
Модель «сущность—связь» и семантическая объектная модель подобны двум различным линзам, сквозь которые смотрят разработчики баз данных при изучении и документировании пользовательских данных. Обе линзы действуют, и обе они в конечном счете воплощаются в определенной структуре базы данных. Однако, поскольку эти линзы не одинаковы и создают разные изображения, структура баз данных, полученных с их помощью, может несколько различаться. Разрабатывая базу данных, вы должны решить, какой подход применять, так же как фотографу приходится решать, какую использовать линзу. Каждый подход имеет свои сильные и слабые стороны, которые мы обсудим в конце этой главы.
Семантическая объектная модель была впервые представлена в третьем издании этой книги в 1988 г. Она основана на концепциях, разработанных и опубликованных Коддом, Хаммером и Мак-Леодом1. Семантическая объектная модель — это модель данных. Ее не следует путать с объектно-ориентированной обработкой баз данных, о которой пойдет речь в главе 18. Вы узнаете, чем цели, свойства и конструкции семантической объектной модели отличаются от объектно-ориентированных баз данных.
1 Е. F. Codd, «Extending the Relational Model to Capture More Meaning», ACM Transactions on Database Systems, декабрь 1976, c. 397-424; Michael Hammer and Dennis McLeod, «Database Description with SDM: A Semantic Database Model», ACM Transactions on Database Systems, сентябрь 1981, c. 351-386.
Семантические объекты
119
Модель «сущность—связь»
Семантическая объектная модель
Рис. 4.1. Использование различных моделей при разработке баз данных
Семантические объекты
Задача приложения базы данных состоит в том, чтобы предоставлять формы, отчеты и запросы, с помощью которых пользователи могли бы отслеживать сущности или объекты, представляющие интерес для их деятельности. Целью ранних стадий разработки базы данных является определение того, какие вещи должны быть представлены в базе данных, задание характеристик этих вещей и установление связи между ними.
В главе 3 мы называли эти вещи сущностями. В этой главе мы будем их называть семантическими объектами (semantic objects), а иногда просто объектами. Слово семантический означает «смысловой», и семантический объект — это объект, который в определенной степени моделирует смысл пользовательских данных. Семантические объекты моделируют восприятие пользователя более точно, чем модель «сущность—связь». Мы используем со словом объект прилагательное семантический, чтобы отличать объекты, о которых идет речь в этой главе, от объектов, которыми оперируют объектно-ориентированные языки программирования.
Определение семантических объектов
Сущности и объекты в некоторых отношениях схожи, но у них есть и различия. Мы начнем со сходства. Семантический объект — это представление некоторой вещи, идентифицируемой в рабочей среде пользователя. Если выражаться более формально, семантический объект — это именованная совокупность атрибутов, которая в достаточной степени описывает отдельный феномен.
120
Глава 4. Семантическая объектная модель
Подобно сущностям, семантические объекты группируются в классы. У объектного класса есть имя, которое отличает его от других классов и соответствует именам вещей, представляемых этим классом. Так, в базе данных, содержащей информацию о студентах, имеется объектный класс под названием СТУДЕНТ. Обратите внимание, что имена объектных классов, как и имена классов сущностей, пишутся заглавными буквами. Отдельный семантический объект представляет собой экземпляр класса. Например, Уильям Джонс является экземпляром класса СТУДЕНТ, а Бухгалтерия является экземпляром класса ОТДЕЛ.
Подобно сущностям, объект имеет набор атрибутов. Каждый атрибут описывает одну из характеристик представляемого феномена. Например, объект СТУДЕНТ может иметь атрибуты Имя, ДомашнийАдрес, МестныйАдрес, ДатаРождения, ДатаОкон-чанияШколы и Специальность. Этот набор атрибутов также является достаточным описанием (sufficient description), то есть он описывает все характеристики, необходимые пользователям для работы. Как было указано нами в конце главы 3, каждая вещь в мире имеет бесконечное множество характеристик, и мы не в состоянии представить всю их совокупность. Вместо этого мы представляем только те из них, которые требуются для удовлетворения информационных потребностей пользователей в той степени, чтобы они могли успешно выполнять свои функции. Достаточность описания означает также, что объекты являются самодостаточными. Например, все требуемые данные о покупателе содержатся в объекте КЛИЕНТ, так что нам нигде больше не требуется искать, чтобы найти эти данные.
Объекты представляют отдельные феномены (distinct identity), то есть в восприятии пользователей они являются чем-то независимым и самостоятельным, что требует учета. Феномены — это сущности, информация о которых необходима. Чтобы лучше уяснить значение термина отдельный феномен, вспомните, что существует разница между объектами и экземплярами объектов. КЛИЕНТ — это имя объекта, а КЛИЕНТ 12345 — имя экземпляра объекта. Когда мы говорим, что объект представляет отдельный феномен, мы имеем в виду, что пользователи считают каждый экземпляр объекта уникальным и имеющим самостоятельное значение.
Наконец, стоит отметить, что феномены, представляемые объектами, могут существовать физически, как, например, объекты класса СОТРУДНИК, а могут и не существовать, как объекты класса ЗАКАЗ. Заказ как таковой является моделью контрактного соглашения о предоставлении определенных товаров или услуг в установленном порядке и на известных условиях. Он является не физическим предметом, а представлением соглашения. Таким образом, чтобы нечто могло считаться объектом, ему не обязательно существовать физически — нужно лишь, чтобы это нечто имело самостоятельное значение в представлении пользователей.
Атрибуты
Семантические объекты имеют атрибуты, описывающие их характеристики. Есть три типа атрибутов. Простые атрибуты (simple attributes) состоят из одного элемента. Примерами могут быть атрибуты ДатаНайма, НомерНакладной и Итоговая-СуммаПродаж. Групповые атрибуты (group attributes) являют собой совокупности других атрибутов. В качестве примера можно привести атрибут Адрес, состоящий
Семантические объекты.
121
из атрибутов {Улица, Город, Штат, Индекс}. Еще один пример - атрибут ПолноеИмя, включающий в себя атрибуты {Имя, Отчество, Фамилия}. Семантические объектные атрибуты (semantic object attributes) — это атрибуты, которые устанавливают связь между двумя семантическими объектами.
Чтобы лучше понять эти определения, взгляните на рис. 4.2, а, который представляет собой пример семантической объектной диаграммы (semantic object diagram), или просто объектной диаграммы (object diagram). Такие диаграммы используются командами разработчиков для описания и визуального представления структуры объектов. Объекты изображаются в вертикально ориентированных прямоугольниках. Имя объекта указывается вверху, а атрибуты записываются по порядку после имени объекта.
Объект КАФЕДРА содержит пример каждого из трех типов атрибутов. Атрибуты НазваниеКафедры, НомерТелефона и НомерФакса являются простыми: каждый из них представляет один элемент данных. МестныйАдрес — групповой атрибут, состоящий из простых атрибутов Корпус и НомерОфиса. Наконец, КОЛЛЕДЖ, ПРЕПОДАВАТЕЛЬ и СТУДЕНТ — это семантические объектные атрибуты, то есть эти объекты связаны с объектом КАФЕДРА и логически содержатся в нем.
Смысл этих объектных атрибутов, или объектных ссылок (object links), как их иногда называют, состоит в том, что когда пользователь думает об определенной кафедре, он имеет в виду не только название кафедры, локальный адрес, номер телефона и номер факса этой кафедры, но также колледж, в котором она находится, профессоров, преподающих на ней, и студентов, занимающихся на ней. Поскольку КОЛЛЕДЖ, ПРЕПОДАВАТЕЛЬ и СТУДЕНТ также являются объектами, полная модель данных содержит диаграммы и для них. Объект КОЛЛЕДЖ несет в себе атрибуты колледжа, объект ПРЕПОДАВАТЕЛЬ — атрибуты членов профессорско-преподавательского состава, а объект СТУДЕНТ содержит атрибуты студентов.
КАФЕДРА
/о НазваниеКафедры
МестныйАдрес”
Корпус
НомерОфиса _
НомерТелефона
НомерФакса
КОЛЛЕДЖ
СР/ДЕНТ
а
КАФЕДРА
/о НазваниеКафедры
МестныйАдрес ~
Корпус 1Л
НомерОфиса 1.1_J
НомерТелефона, N
НомерФакса 0|м
рРЕП ||||Дел ь | м р яМВИИт
’ '’““Р"'--'1" "- 1 ,N
б
Рис. 4.2. Диаграмма объекта КАФЕДРА: а — объект КАФЕДРА; б — объект КАФЕДРА с кардинальными числами
122
Глава 4. Семантическая объектная модель
Кардинальное число атрибута
Каждый атрибут семантического объекта имеет максимальное и минимальное кардинальные числа. Минимальное кардинальное число показывает количество экземпляров атрибута, которые должны существовать, чтобы объект был допустимым. Обычно это число равно 0 или 1. Если оно равно 0, атрибут не обязан иметь значение, а если 1, то атрибут обязан иметь значение. Хотя это и необычно, минимальное кардинальное число иногда может быть больше единицы. Например, атрибут Игрок в объекте под названием БАСКЕТБОЛЬНАЯ_КОМАНДА может иметь минимальное кардинальное число, равное 5, поскольку таково наименьшее число игроков, требуемое для создания баскетбольной команды.
Максимальное кардинальное число показывает максимальное количество экземпляров атрибута, которое может иметь объект. Обычно оно равно 1 или N. Если оно равно 1, атрибут может иметь не более одного экземпляра; если оно равно N, атрибут может иметь много экземпляров, и предельное количество не задано. Иногда максимальное кардинальное число равно определенному числу, например 5, — это означает, что объект может иметь не более пяти экземпляров атрибута. Например, атрибут ИГРОК в объекте БАСКЕТБОЛЬНАЯ_КОМАНДА может иметь максимальное кардинальное число, равное 15, и это будет означать, что в состав команды может быть включено не более 15 игроков.
Кардинальность изображается в виде нижнего индекса атрибута в формате N.M, где N — минимальное кардинальное число, а М - максимальное. На рис. 4.2, б минимальное кардинальное число для атрибута НазваниеКафедры равно 1, и максимальное также 1; таким образом, требуется ровно один экземпляр этого атрибута. Кардинальность атрибута НомерТелефона равна 1.N, то есть кафедра обязана иметь минимум один номер телефона, но в принципе номеров у нее может быть много. Кардинальность 0.1 у атрибута НомерФакса означает, что кафедра может не иметь факса, а может и иметь, но только один.
Кардинальные числа групп и атрибутов групп, как правило, невелики. Возьмем атрибут МестныйАдрес. Его кардинальность 0.1, то есть кафедра не обязана иметь адрес, но если имеет, то только один. Теперь рассмотрим простые атрибуты, из которых состоит атрибут МестныйАдрес. Как Корпус, так и НомерОфиса имеют кардинальность 1.1. Вы можете удивиться, каким образом получается, что группа может быть необязательной, если атрибуты, составляющие эту группу, являются обязательными. Дело в том, что кардинальные числа действуют только между атрибутом и его контейнером (группой, содержащей этот атрибут). Минимальное кардинальное число атрибута МестныйАдрес показывает, что этот атрибут не обязан иметь значение, то есть кафедра не обязана иметь адрес. А минимальные кардинальные числа атрибутов Корпус и НомерОфиса показывают, что эти атрибуты должны существовать в атрибуте МестныйАдрес. Таким образом, группа МестныйАдрес не обязана существовать, но если уж она существует, то составляющие ее атрибуты Корпус и НомерОфиса должны иметь значения.
Экземпляры объектов
Объектные диаграммы для кафедры, показанные на рис. 4.2, представляют собой просто формат, общую структуру, которую можно отнести к любой кафедре. На рис. 4.3 представлен экземпляр объекта КАФЕДРА. Здесь указаны значения каждо
Семантические объекты
123
го атрибута конкретной кафедры. Кафедра имеет название «Информационные системы» и расположена в офисе № 213 корпуса социальных наук. Обратите внимание, что атрибут НомерТелефона имеет три значения: в офисе кафедры информационных систем имеется три телефонные линии. Другие кафедры могут иметь меньшее или большее количество телефонов, но у каждой кафедры есть по крайней мере один телефон.
Информационные системы Корпус социальных наук 213
491-0099
491-1182
491-0098
НазваниеКафедры МестныйАдрес
НомерТелефона
493-0100
Колледж Бизнеса
•<— НомерФакса  <- КОЛЛЕДЖ
ПРЕПОДАВАТЕЛЬ
ОДруЬ,..М...!---,
......
1 i Франклин, Дж.
Дже
I ву, Джейн
Рис. 4.3. Экземпляр объекта КАФЕДРА с рис. 4.2
СТУДЕНТ
Далее, имеется один экземпляр атрибута КОЛЛЕДЖ, со значением Колледж Бизнеса, и множество экземпляров объектных атрибутов ПРЕПОДАВАТЕЛЬ и СТУДЕНТ. Каждый из этих объектных атрибутов является полноценным объектом и имеет все атрибуты, определенные для объекта данного типа. Чтобы не усложнять диаграмму, мы указали на ней только имена экземпляров объектных атрибутов.
Объектная диаграмма — это картина восприятия пользователем объекта в рабочей среде. Таким образом, в воображении пользователя объект КАФЕДРА содержит все эти данные. Кафедра логически содержит данные о колледже, к которому она принадлежит, а также о профессорах и студентах, относящихся к этой кафедре.
Парные атрибуты
В семантической объектной модели нет однонаправленных связей между объектами. Если один объект содержит в себе другой объект, то этот другой будет, в свою очередь, содержать в себе первый. Например, если объект КАФЕДРА содержит в себе объектный атрибут КОЛЛЕДЖ, то и объект КОЛЛЕДЖ будет содержать соответствующий объектный атрибут КАФЕДРА. Эти объектные атрибуты называются иногда парными атрибутами (paired attributes), так как они всегда появляются по два.
Почему объектные атрибуты должны быть парными? Ответ заключается в том способе, каким человеческие существа представляют себе связи между объектами.
124
Глава 4. Семантическая объектная модель
Если объект А имеет связь с объектом Б, то объект Б будет иметь связь с объектом А. По крайней мере, Б связан с А как «вещь, которая связана с Б». Если этот аргумент кажется неочевидным, попробуйте вообразить однонаправленную связь между объектами. Это сделать невозможно.
Объектные идентификаторы
Объектный идентификатор (object identifier) — это один или несколько объектных атрибутов, с помощью которых пользователи идентифицируют экземпляры объектов. Такие идентификаторы представляют собой потенциальные имена семантического объекта. Для объекта КЛИЕНТ возможными идентификаторами являются НомерКлиента и ИмяКлиента. Каждый из этих идентификаторов является атрибутом, рассматриваемым пользователями в качестве допустимого имени для экземпляров объектного класса КЛИЕНТ. Сравните эти идентификаторы с атрибутами ДатаПервогоЗаказа, КурсАкций или ЧислоСотрудников. Такие атрибуты не являются идентификаторами, потому что пользователи не думают о них как об именах экземпляров объектов класса КЛИЕНТ.
Групповой идентификатор (group identifier) — это идентификатор, содержащий более одного атрибута. Примерами могут служить идентификаторы {Имя, Фамилия}, {Имя, НомерТелефона} и {Штат, НомерЛицензии}.
Объектные идентификаторы могут быть уникальными или неуникальными, в зависимости от того, как пользователи представляют себе свои данные. Например, НомерСчета является уникальным идентификатором объекта ЗАКАЗ, но Имя-Студента не является уникальным идентификатором объекта СТУДЕНТ. Может быть два студента по имени, к примеру, Мэри Смит. В таком случае пользователи будут идентифицировать с помощью атрибута ИмяСтудента группу из одного или более студентов и затем, если необходимо, использовать значения других атрибутов для указания конкретного члена этого множества.
В семантических объектных диаграммах объектные идентификаторы обозначаются с помощью букв ID перед атрибутом. Если идентификатор является уникальным, эти буквы подчеркнуты. На рис. 4.2, б, например, атрибут НазваниеКа-федры является уникальным идентификатором объекта КАФЕДРА.
Обычно, если атрибут должен использоваться в качестве идентификатора, он обязан иметь значение. Кроме того, как правило, для данного объекта имеется не более одного идентифицирующего атрибута. Поэтому в большинстве случаев кардинальность атрибута-идентификатора равна 1.1, и это значение мы используем по умолчанию.
Есть, однако, относительно небольшое число случаев, когда кардинальность идентификатора отличается от 1.1. Рассмотрим, например, атрибут Псевдоним семантического объекта ЧЕЛОВЕК. Человек не обязан иметь псевдоним, однако может иметь и несколько. Следовательно, кардинальность этого атрибута равна O.N.
Указание нижних индексов всех атрибутов загромождает семантическую объектную диаграмму. Для упрощения мы предположим, что кардинальность простых идентифицирующих атрибутов равна 1.1, а прочих идентифицирующих атрибутов — 0.1. Если кардинальность простого атрибута имеет другое значение,
Семантические объекты
125
мы укажем ее на диаграмме. В противном случае нижние индексы простых атрибутов будут опускаться.
Домены атрибутов
Домен (domain) атрибута — это описание множества его значений. Характеристики домена зависят от типа атрибута. Домен простого атрибута состоит из физического и семантического описания. Физическое описание (physical description) показывает тип данных (например, число или строка), длину данных и другие ограничения (например, требование, чтобы первый символ был буквой или чтобы значение не превышало 9999.99). Семантическое описание (semantic description) указывает функцию, или назначение данного атрибута; оно отличает этот атрибут от других атрибутов с тем же физическим описанием.
Например, домен атрибута НазваниеКафедры может быть определен как «набор строк длиной до 7 символов, представляющих наименования кафедр университета Highline». Фраза «набор строк длиной до 7 символов» представляет собой физическое описание домена, а «...представляющих имена кафедр университета Highline» — семантическое описание. Семантическое описание отличает строки из семи символов, представляющие названия кафедр, от строк такой же длины, которые представляют, скажем, названия учебных дисциплин, корпусов или какие-то еще атрибуты.
В некоторых случаях физическое описание домена простого атрибута представляет собой нумерованный список — набор отдельных значений атрибутов. Доменом атрибута ЦветДетали может быть, например, нумерованный список {«Синий», «Желтый», «Красный»}.
Домен группового атрибута также имеет физическое и семантическое описание. Физическое описание — это список всех атрибутов в группе в порядке их следования. Семантическое описание — это описание функции, или назначения, данной группы. Так, физическим описанием домена МестныйАдрес (см. рис. 4.2) является список {Корпус, НомерОфиса}; семантическим описанием является фраза «местоположение офиса в университете Highline».
Домен объектного атрибута — это набор экземпляров объектов данного типа. На рис. 4.2, например, доменом объектного атрибута ПРЕПОДАВАТЕЛЬ является совокупность всех экземпляров объектов класса ПРЕПОДАВАТЕЛЬ, представленных в базе данных. Доменом объекта КОЛЛЕДЖ является совокупность всех объектов класса КОЛЛЕДЖ, представленных в базе данных. В определенном смысле, домен атрибута — это динамически нумерованный список, который содержит все экземпляры объектов данного типа.
Представления семантических объектов
Пользователи имеют доступ к значениям объектных атрибутов через приложения базы данных, которые предоставляют формы для ввода данных, отчеты и запросы. В большинстве случаев такие формы, отчеты и запросы не требуют доступа ко всем атрибутам объекта. Например, на рис. 4.4. показаны представления
126
Глава 4. Семантическая объектная модель
объекта КАФЕДРА для двух различных приложений. Некоторые атрибуты объекта КАФЕДРА (например, НазваниеКафедры) являются видимыми в обоих представлениях. Другие атрибуты видимы только в одном из представлений. Например, атрибут СТУДЕНТ является видимым только в представлении СписокСтудентов, а атрибут ПРЕПОДАВАТЕЛЬ виден только в представлении Персонал.
Часть объекта, видимая для конкретного приложения, называется представлением семантического объекта (semantic object view), или просто представлением (view). Представление состоит из имени объекта и списка всех атрибутов, видимых в этом представлении.
Представления используются двояким образом. Когда вы разрабатываете базу данных, вы можете использовать их для разработки модели данных. Взгляните снова на рис. 4.1. Как можно видеть, при разработке модели данных разработчики базы данных и приложений двигаются в обратном направлении. То есть они начинают с форм, отчетов и запросов, которые пользователи объявляют необходимыми, и двигаются назад, к структуре базы данных. Для этого команда выбирает требуемую форму, отчет или запрос и определяет, какое представление должно существовать, чтобы можно было создать такую форму, отчет или запрос. Затем команда переходит к следующей форме, отчету или запросу и делает то же самое. Далее получившиеся два представления объединяются. Описанный процесс повторяется до тех пор, пока структура базы данных не будет полностью сформирована.
Второй аспект использования представлений возникает, когда структура базы данных уже создана. В этом случае представления создаются для поддержки новых форм, отчетов и запросов на основе существующей структуры базы данных. Примеры этого второго подхода приведены в части IV, где обсуждаются SQL Server и Oracle.
КАФЕДРА
id НазваниеКафедры
МестныйАдрес И
0.1
НомерТелефона, N
НомерФакса 0N
КОЛЛЕДЖ
Корпус1Л НомерОфисат.ц
1.N
Представление Персонал \ НазваниеКафедры
яиивы
Представление СписокСтудентов НазваниеКафедры
1.N
1.N
СТУДЕНТ

Рис. 4.4. Два представления семантического объекта КАФЕДРА — СписокСтудентов и Персонал
Создание семантических объектных моделей данных
127
Создание семантических объектных моделей данных
В этом разделе иллюстрируется процесс разработки семантических объектов, в ходе которого разработчики анализируют интерфейс приложения (формы, отчеты, запросы) и двигаются в обратном направлении, получая из этой информации структуру объектов. Например, чтобы смоделировать структуру объекта КАФЕДРА, мы сначала собираем все отчеты, формы и запросы, связанные с кафедрой. Исходя из них, мы определяем объект КАФЕДРА, который позволяет конструировать эти отчеты, формы и запросы.
Однако для абсолютно нового приложения в распоряжении разработчиков нет компьютерных отчетов, форм и запросов, которые можно было бы изучать. В этой ситуации разработчики начинают с определения того, какие объекты пользователи хотят отслеживать. Затем путем опроса пользователей команда выясняет, какие объектные атрибуты являются важными. На основе этой информации могут быть созданы прототипы форм и отчетов, с помощью которых модель данных будет далее уточняться.
Пример: база данных администрации университета Highline
Предположим, что администрация университета Highline желает вести учет данных по кафедрам, факультетам и специальностям студентов. Предположим, далее, что приложение должно генерировать четыре типа отчетов (рис. 4.5,4.7,4.9 и 4.11). Наша цель — изучить эти отчеты и, используя инженерный анализ, определить, какие объекты и атрибуты должны храниться в базе данных.
Объект КОЛЛЕДЖ
Отчет, изображенный на рис. 4.5, содержит информацию о колледже, а именно о Колледже бизнеса. Данный отчет — это только один частный пример. Университет Highline имеет подобные отчеты и о других колледжах, в частности о Колледже искусств и наук и колледже социальных наук. Создавая модель данных, важно собрать достаточное количество примеров, чтобы на их основе можно было построить образец отчета о колледже. Здесь мы предположим, что отчет на рис. 4.5 является типичным.
Исследуя отчет, мы найдем данные, специфичные для данного колледжа (название, имя декана, номер телефона и местный адрес, а также сведения о каждой из кафедр колледжа. Это наводит на мысль о том, что база данных может содержать объекты КОЛЛЕДЖ и КАФЕДРА, а также связь между ними.
Эти предварительные заключения отражены в объектных диаграммах на рис. 4.6. Обратите внимание, что мы не указали кардинальность простых атрибутов, у которых она равна 0.1.
128
Глава 4. Семантическая объектная модель
Колледж Бизнеса Мэри Джефферсон, декан			
Телефон: 232-1187		Местный адрес: Корпус бизнеса, комната 100	
Кафедра	Заведующий	Телефон	Всего студентов
Бухгалтерский учет	Джексон, Сеймур П.	232-1841	318
Финансы	Хью Тень, Сьюзен	232-1414	211
Информационные системы	Браммер, Натаниэль Д.	236-0011	247
Менеджмент	Татл, КристинА.	236-9988	184
Производство	Барнс, Джек Т.	236-1184	212
Рис. 4.5. Пример отчета о колледже
КОЛЛЕДЖ ю НазваниеКолледжа
ИмяДекана
НомерТелефона
МестныйАдрес
Корпус 1.1
НомерОфиса 11
0.1
КАФЕДРА id НазваниеКафедры
Заведующий
НомерТелефона
ВсегоСтудентов
КОЛЛЕДЖ ----------------1л
КАФЕДРА ..........1 N
Рис. 4.6. Первая версия обьектов КОЛЛЕДЖ и КАФЕДРА
Кардинальность атрибута КАФЕДРА объекта КОЛЛЕДЖ равна 1.N — это означает, что колледж должен иметь как минимум одну кафедру и кафедр может быть много. Это минимальное кардинальное число не может быть выведено из отчета на рис. 4.5. Чтобы его получить, пользователям был задан вопрос о том, может ли существовать колледж без кафедр, и их ответ был отрицательным.
Также обратите внимание, что структура объекта КАФЕДРА выведена на основе данных, представленных на рис. 4.5. Поскольку объектные атрибуты всегда являются парными, объект КОЛЛЕДЖ показан внутри объекта КАФЕДРА, хотя, строго говоря, этот факт нельзя получить из анализа рис. 4.5. Как и в ситуации с атрибутом КАФЕДРА объекта КОЛЛЕДЖ, пользователей попросили определить кардинальность атрибута КОЛЛЕДЖ. Она равна 1.1, что означает, что кафедра может быть связана с одним и только одним колледжем.
По ходу изложения мы интерпретировали отчет на рис. 4.5 таким образом, что группы повторяющихся данных относятся к объекту КАФЕДРА как к независимому объекту. Фактически наличие таких групп часто является сигналом о том, что существует некий другой объект. Однако это не всегда так. Повторяющаяся группа может быть также групповым атрибутом, у которого оказалось несколько значений.
Создание семантических объектных моделей данные
129
Вас, возможно, интересует, как различить эти два типа повторяющихся данных — те, которые представляют объект, и те, которые представляют группу. Какого-либо твердого и четкого правила на этот счет не существует, поскольку ответ зависит от того, как пользователи представляют себе свой мир. Следовательно, наилучшим выходом будет спросить самих пользователей о семантике их данных. Спросите, являются ли эти повторяющиеся группы данных частью колледжа, или они относятся к чему-то еще — чему-то самостоятельному. В первом случае они составляют групповой атрибут, во втором — семантический объект. Посмотрите также другие отчеты (или формы, или запросы). Имеются ли у пользователей отчеты по кафедрам? Если да, то предположение о том, что кафедра может быть представлена семантическим объектом, подтвердится. На самом деле персонал университета Highline работает с двумя видами отчетов по кафедрам. Этот факт еще более укрепляет нас в мысли о том, что следует ввести объект под названием КАФЕДРА.
Далее, группы атрибутов, представляющие независимый объект, обычно содержат явный идентифицирующий атрибут или несколько атрибутов. Автомобили имеют номер или номер лицензии, продукты имеют учетный номер или штрих-код (SKLJ). Заказы также имеют учетные номера. Однако группа атрибутов {ДатаИзмерения, ДавлениеВШине} не имеет явного идентификатора. Когда вы спросите пользователя об идентификаторе этой группы, он в ответ спросит вас что-нибудь вроде: «Давление в шине чего?». Это будет давление в шине легкового автомобиля или грузовика или трейлера, или какого-либо еще транспортного средства. Следовательно, такая группа представляет собой групповой атрибут некоторого другого объекта — объекта, который является ответом на вопрос «чего?».
Объект КАФЕДРА
Отчет, представленный на рис. 4.7, содержит информацию о кафедрах, а также список работающих на них преподавателей. Обратите внимание, что этот отчет содержит местный адрес кафедры. Поскольку эти данные не присутствуют в версии объекта КАФЕДРА, изображенной на рис. 4.6, их необходимо добавить к объекту, как показано на рис. 4.8. Такое уточнение является типичным для процесса моделирования данных. То есть структура семантических объектов постоянно уточняется по мере того, как идентифицируются и анализируются новые отчеты, формы и запросы.
Объект ПРЕПОДАВАТЕЛЬ
Отчет на рис. 4.7 не только указывает на необходимость введения объекта КАФЕДРА, но и наводит на мысль, что для представления данных о профессоре может понадобиться еще один объект. Соответственно, в модель добавлен объект ПРЕПОДАВАТЕЛЬ, как показано на рис. 4.8. Идентификатор объекта ПРЕПОДАВАТЕЛЬ, которым является атрибут ИмяПреподавателя, не является уникальным; на это указывает тот факт, что буквы ID на рис. 4.8 не подчеркнуты.
130
Глава 4. Семантическая объектная модель
Кафедра информационных систем Колледж бизнеса
Заведующий:	Браммер, Натаниэль Д.
Телефон: МестныйАдрес:	236-0011 Корпус социальных наук, комната 213
Преподаватель	Офис	Телефон
Джонс, Пол Д. Паркс, Мэри Б. By, Элизабет	Корпус социальных наук, комната 219	232-7713 Корпус социальных наук, комната 308	232-5791 Корпус социальных наук, комната 232	232-9112
Рис. 4.7. Пример отчета о кафедре
В соответствии с объектными диаграммами на рис. 4.8, на каждой кафедре должен быть как минимум один преподаватель, причем на одной кафедре преподавателей может быть несколько, но каждый преподаватель должен работать на одной и только на одной кафедре. Таким образом, согласно этой модели, работа по совместительству запрещена. Это ограничение является частью делового регламента, который должен определяться из опросов пользователей.
На рис. 4.9 показан второй отчет о кафедре. В нем представлена информация о кафедре и о студентах, специальность которых имеет отношение к этой кафедре. Ситуация, когда об одном объекте имеется два отчета, типична; эти отчеты просто документируют различные представления одной и той же вещи. Более того, существование второго отчета укрепляет нашу уверенность в том, что кафедра является объектом в понимании пользователей.
Объект СТУДЕНТ
Отчет на рис. 4.9 содержит данные о студентах, профилирующая специальность которых относится к области деятельности данной кафедры, что подразумевает, что студенты также являются объектами. Поэтому объект КАФЕДРА должен также содержать объекты СТУДЕНТ и ПРЕПОДАВАТЕЛЬ, как показано па рис. 4.10.
КАФЕДРА
ю НазваниеКафедры Заведующий НомерТелефона ВсегоСтудентов
ПРЕПОДАВАТЕЛЬ id И мяП реподавателя
МестныйАдрес Корпус 1.1 НомерОфиса ,,
МестныйАдрес Корпусы НомерОфиса, ,
НомерТелефона
КОЛЛЕДЖ
ПРЕПОДАВАТЕЛЬ:
1.1
1.N
КАФЕДРА
Рис. 4.8. Уточненный объект КАФЕДРА и новый объект ПРЕПОДАВАТЕЛЬ
Создание семантических объектных моделей данных
131
Список студентов Кафедра информационных систем		
Заведующий:	Браммер, Натаниэль Д. Телефон:		236-0011
Имя студента	Номер студента	Телефон
Джексон, Робин Д.	12345	237-8713
Линкольн, Фред Дж.	48127	237-8713
Мэдисон, Дженис А.	37512	237-8713
Рис. 4.9. Второй пример отчета о кафедре
Объект СТУДЕНТ на рис. 4.10 имеет атрибуты ИмяСтудента, НомерСтудента и НомерТелефона — атрибуты, перечисленные в отчете на рис. 4.9. Обратите внимание, что и ИмяСтудента, и НомерСтудента являются идентификаторами. Имена студентов не являются уникальными, а номера уникальны.
На рис. 4.11 представлен другой пример отчета о студентах — письмо-приглашение, которое университет рассылает поступившим в него студентам. Даже несмотря на то, что это письмо, оно все же является отчетом; вероятно, оно было создано в текстовом редакторе с помощью мастера стандартных писем.
Те элементы данных в письме, которые должны храниться в базе данных, напечатаны жирным шрифтом. Кроме данных, относящихся к студенту, письмо также содержит данные о профильной кафедре студента и о его руководителе. Поскольку руководитель является преподавателем, это письмо подтверждает потребность в отдельном объекте под названием ПРЕПОДАВАТЕЛЬ. Уточненные диаграммы объектов ПРЕПОДАВАТЕЛЬ и СТУДЕНТ представлены на рис. 4.12. Глядя на объект СТУДЕНТ, можно видеть, что как КАФЕДРА, так и ПРЕПОДАВАТЕЛЬ имеют единственное значение (их максимальное кардинальное число равно 1). Следовательно, студент этого университета имеет максимум одну профильную кафедру и одного руководителя, причем имеет обязательно.
Объект СТУДЕНТ на рис. 4.12 соответствует данным, изображенным на рис. 4.11. Может, однако, оказаться, что студент имеет более одной специальности, и тогда атрибуты КАФЕДРА и ПРЕПОДАВАТЕЛЬ будут многозначными. Этот факт не может быть выявлен из единственного стандартного письма, которое было представлено, поэтому требуется проанализировать другие письма и провести дополнительные опросы, чтобы определить, разрешено ли иметь несколько профилирующих специальностей. Здесь мы предполагаем, что такая специальность может быть только одна.
Имя студента дается сначала в формате Имя Фамилия в верхней строчке письма, а затем в формате Фамилия в приветствии. Если указание имен в этом формате является обязательным, то одного атрибута ИмяСтудента (на рис. 4.10) будет недостаточно, и необходимо будет ввести группу {Имя, Фамилия}. Это сделано на рис. 4.12. Заметьте также, что и имя руководителя дается в формате {Имя, Фамилия}, что означает, что имя профессора должно быть также разделено на два атрибута.
132
Глава 4. Семантическая объектная модель
КАФЕДРА
/о НазваниеКафедры Заведующий НомерТелефона ВсегоСтудентов
СТУДЕНТ id ИмяСтудента ю НомерСтудента
НомерТелефона
КАФЕДРА .....	и
Рис. 4.10. Уточненный объект КАФЕДРА и новый объект СТУДЕНТ
Мистеру Фреду Парксу
123, Эльм-Стрит
Лос-Анджелес, Калифорния 98002
Уважаемый мистер Паркс,
рад сообщить, что вы приняты на кафедру бухгалтерского учета университета Highline, начиная с осеннего семестра 2000 года. Кафедра бухгалтерского учета находится по адресу: корпус бизнеса, комната 210.
Вашим руководителем назначена профессор Элизабет Джонсон, ее номер телефона 232-8740, офис расположен в корпусе бизнеса, комната 227. Просьба назначить встречу с руководителем сразу по прибытию в университетский городок.
Поздравляю, и добро пожаловать в университет Highline!
Искренне ваш,
Ян П. Сматерс, Президент
Рис. 4.11. Письмо-приглашение
Кроме того, из письма видно, что именам в адресах и приветствиях должно предшествовать обращение «Мистер» или «Мисс». Чтобы обеспечить такую возможность, к объекту СТУДЕНТ следует добавить еще один атрибут, и на основании данного атрибута выбирать титул. Другая возможность — хранить в базе данных сам титул. Преимущество этого подхода в том, что он позволяет хранить и другие титулы, помимо «Мистер» и «Мисс», — например, «Доктор».
В текущей версии модели данных иных титулов, кроме «Мистер» и «Мисс», не требуется. Однако вполне вероятна ситуация, при которой дополнительные
Создание семантических объектных моделей данных
133
обращения могут понадобиться; следовательно, второй вариант более надежен, и поэтому к объекту СТУДЕНТ на рис. 4.12 добавлен атрибут Обращение.
ПРЕПОДАВАТЕЛЬ ~ id ИмяПреподавателя
Имя 0,
Фамилия 1Л
СТУДЕНТ
ю ИмяСтудента
Имя 01
Фамилия 11
МестныйАдрес
Корпус 1.1
НомерОфиса 1.1
0.1
НомерТелефона
КАФЕДРА
СТУДЕНТ -------------1 N
id НомерСтудента НомерТелефона ДомашнийАдрес ~
Улица 01 Город,, Штат 11 Индекс,, Обращение ДатаПоступления
КАФЕДРА
ПРЕПОДАВАТЕЛЬ .............1Л
Рис. 4.12. Уточненные объекты ПРЕПОДАВАТЕЛЬ и СТУДЕНТ
Опять-таки, эти изменения иллюстрируют итеративную природу моделирования данных. Имеющиеся решения часто приходится пересматривать и корректировать вновь и вновь. Это не означает, что процесс проектирования идет с ошибками; фактически, такие итерации являются обычными и ожидаемыми.
Спецификация объектов
На рис. 4.13 показан окончательный вариант объектных диаграмм для базы данных университета Highline. Внесено несколько дополнительных изменений: атрибуты ИмяДекана и Председатель смоделированы в формате {Имя, Фамилия}, чтобы все имена имели одинаковый формат. Далее, чтобы увеличить точность модели, атрибут ПРЕПОДАВАТЕЛЬ объекта СТУДЕНТ был переименован — теперь он называется РУКОВОДИТЕЛЬ. Экземпляр объекта ПРЕПОДАВАТЕЛЬ, связанный через этот атрибут с экземпляром объекта СТУДЕНТ, это не просто кто-то из преподавателей данного студента, а совершенно конкретный преподаватель, который является руководителем данного студента, и термин руководитель является более точным, чем термин преподаватель.
Домен этого атрибута не меняется. Атрибут РУКОВОДИТЕЛЬ имеет домен ПРЕПОДАВАТЕЛЬ, такой же домен и у атрибута ПРЕПОДАВАТЕЛЬ. Он по-прежнему указывает на экземпляры семантического объекта ПРЕПОДАВАТЕЛЬ. Смена имени — это лишь уточнение роли, которую домен ПРЕПОДАВАТЕЛЬ играет в семантических объектах СТУДЕНТ. Аналогичное изменение было сделано и в объекте ПРЕПОДАВАТЕЛЬ: атрибут СТУДЕНТ был переименован и называется теперь РУКОВОДИМЫ Й_СТУДЕНТ, но этот атрибут по-прежнему связан с объектами из домена СТУДЕНТ.
134
Глава 4. Семантическая объектная модель
КОЛЛЕДЖ
ю НазваниеКолледжа
ИмяДекана
Имя о,1
Фамилия,,	-
КАФЕДРА
Ю НазваниеКафедры
Заведующий
Имя 0.1 Фамилия ,,
НомерТелефона МестныйАдрес Корпус 1.1 НомерОфиса и
НомерТелефона ВсегоСтудентов МестныйАдрес
Корпус I , НомерОфиса , ,
КАФЕДРА ........... 1.N
КОЛЛЕДЖ ........   1.1
ПРЕПОДАВАТЕЛЬ --------------и
СТУДЕНТ
ПРЕПОДАВАТЕЛЬ -id ИмяПреподавателя
Имя 0,
Фамилия 11
.Д 1.1
МестныйАдрес
Корпуси НомерОфиса 1.1
0.1
НомерТелефона
КАФЕДрА j Г СТУДЕНТ
СТУДЕНТ
id ИмяСтудента
Имя0,
Фамилия,,
- и
id НомерСтудента НомерТелефона ДомашнийАдрес -
Улица 0,
Город,, Штат, j
Индекс,, J ,,
Обращение
ДатаПоступления
КАФЕДРА
...и
----------------,,
Рис. 4.13. Полный набор семантических объектных диаграмм
В табл. 4.1 и 4.2 представлена спецификация модели данных. Семантические объекты и атрибуты определены в спецификации семантических объектов, а домены определены в спецификации доменов. Первая таблица является альтернативным представлением информации в семантических объектных диаграммах, и ее интерпретация очевидна.
Вторая таблица, таблица доменов, содержит такую информацию о доменах, которая не может быть получена из семантических объектных диаграмм. Как было указано ранее, домен имеет как семантическое, так и физическое описание. Семантическое описание каждого объекта дается в столбце Описание, а физическое описание дается в столбце Спецификация. Содержание столбца Описание говорит само за себя.
Создание семантических объектных моделей данных
135
Таблица 4.1.	Спецификации семантических объектов для базы данных				
университета Highline					
Имя объекта	Имя свойства	Мин.	Макс.	Статус	Имя домена
		кард.	кард.	идент.	
КОЛЛЕДЖ	НазваниеКолледжа	1	1	ID	НазваниеКолледжа
	ИмяДекана	1	1		ИмяЧеловека
	Имя	0	1		Имя
Г-	Фамилия	1	1		Фамилия
	Телефон	0	1		Телефон
	МестныйАдрес	0	1		МестныйАдрес
f'	Корпус	1	1		Корпус
	НомерОфиса	1	1		НомерОфиса
ЙкфЕДРА	КАФЕДРА	1	N		КАФЕДРА
	НазваниеКафедры	1	1	ID	НазваниеКафедры
	Заведующий	1	1		ИмяЧеловека
	Имя	0	1		Имя
	фамилия	1	1		Фамилия
	Телефон	0	1		Телефон
	ВсегоСтудентов	0	1		ЧислоСтудентов
	МестныйАдрес	0	1		МестныйАдрес
	Корпус	1	1		Корпус
	НомерОфиса	1	1		НомерОфиса
	КОЛЛЕДЖ	1	1		КОЛЛЕДЖ
	ПРЕПОДАВАТЕЛЬ	1	N		ПРЕПОДАВАТЕЛЬ
	СТУДЕНТ	1	N		СТУДЕНТ
ПРЕПОДАВАТЕЛЬ ИмяПреподавателя		1	1	(D	ИмяЧеловека
	Имя	0	1		Имя
	Фамилия	1	1		Фамилия
	МестныйАдрес	0	1		МестныйАдрес
	Корпус	1	1		Корпус
	НомерОфиса	1	1		НомерОфиса
	Телефон	0	1		Телефон
	КАФЕДРА	1	1		КАФЕДРА
	РУКОВОДИМЫЙ, СТУДЕНТ	1	N		СТУДЕНТ
СТУДЕНТ	ИмяСтудента	1	1	ID	ИмяЧеловека
	Имя	0	1		Имя
	Фамилия	1	1		Фамилия
	НомерСтудента	1	1	ID	НомерСтудента
	Телефон	0	1		Телефон
	ДомашнийАдрес	1	1		Адрес
	Обращение	0	1		Обращение
	ДатаПоступления	0	1		КвартальнаяДата
	КАФЕДРА	1	1		КАФЕДРА
	РУКОВОДИТЕЛЬ	1	1		РУКОВОДИТЕЛЬ
136
Глава 4. Семантическая объектная модель
Таблица 4.2. Спецификация доменов для базы данных университета Highline
Имя домена	Тип	Семантическое описание	Физическое описание
Адрес	Групповой	Адрес в США	Улица Город Штат Индекс
Корпус	Простой	Название корпуса в университете	Text 20
МестныйАдрес	Групповой	Адрес в университете	Корпус НомерОфиса
Г ород	Простой	Название города	Text 25
КОЛЛЕДЖ	Семантический объект	Один из колледжей университета Highline	См. спецификацию семантических объектов
НазваниеКолледжа	Простой	Официальное название колледжа университета Highline	Text 25
КАФЕДРА	Семантический объект	Учебная кафедра университета	См. спецификацию семантических объектов
НазваниеКафедры	Простой	Официальное название учебной кафедры университета	Text 25
Имя	Простой	Часть группы ИмяЧеловека, представляющая имя	Text 20
Фамилия	Простой	Часть группы ИмяЧеловека, представляющая фамилию	Text 30
ЧислоСтуденто в	Формула	Число студентов на данной кафедре	Integer; значение в интервале {0-999}, формат 999
НомерОфиса	Простой	Номер офиса в университете	Text 4
ИмяЧеловека	Г рупповой	Имя и фамилия администратора, преподавателя или студента	Имя Фамилия
Телефон	Простой	Номер телефона с кодом региона	Text 4
ПРЕПОДАВАТЕЛЬ	Семантический объект	Имя постоянного члена профессорско-преподавательского состава Highline	См.спецификацию семантических объектов
Квартал ьнаяДата	Простой	Учебная четверть и год	Text 3; значения {q01}, где q = один из символов {«О», «3», «В», «Л»}, а 01 — десятичное число от 00 до 99
Типы объектов
137
Имя домена	Тип	Семантическое описание	Физическое описание
Штат	Простой	Двухбуквенная аббревиатура штата	Text 2
Улица	Простой	Название улицы	Text 30
СТУДЕНТ	Семантический объект	Лицо, принятое в университет Highline	См. спецификацию семантических объектов
НомерСтудента	Простой	Идентификатор, присвоенный студенту, принятому в университет Highline	Integer; интервал — {10000-99999}, формат 99999
Обращение	Простой	Обращение человека (для использования в обращениях)	Text 6, значения {«Мистер», «Мисс»}
Индекс	Простой	Девятизначный индекс	Text 10, формат 99999-9999
Спецификация доменов включает в себя физическое описание и в некоторых случаях множество значений и формат. Домен НомерСтудента определен, например, как целое число, принимающее значения между 10000 и 99999 в формате с пятью десятичными цифрами. (В данной таблице цифра 9 в описании формата означает десятичную цифру.) Другие домены описаны аналогичным образом. Домен Обращение является примером домена-перечисления, значениями которого являются «Мистер» и «Мисс». Физическое описание группового домена состоит из списка доменов, входящих в группу. Физическое описание домена семантического объекта — это просто ссылка на описание семантического объекта.
Домен атрибута ВсегоСтудентов являет собой пример четвертого типа домена — формулы (formula domain). Формулы представляют атрибуты, вычисленные на основе других значений. Домен ЧислоСтудентов — это число объектов типа СТУДЕНТ, связанных с данным объектом типа КАФЕДРА. Мы не будем описывать здесь способы, с помощью которых это вычисление описывается в определении домена. На данном этапе для нас важно только указать потребность в формуле и ее спецификацию.
Типы объектов
В этом разделе описываются и демонстрируются семь типов объектов. Для каждого типа объектов мы исследуем отчет или форму и покажем, как их можно представить с помощью данного объекта. Далее, в главе 7, мы трансформируем каждый из этих типов в соответствующую структуру базы данных.
В данном разделе используются три новых термина. Однозначный атрибут (single-value attribute) — это атрибут с максимальным кардинальным числом 1. Многозначный атрибут (multi-value attribute) — это атрибут, имеющий максимальное кардинальное число больше 1. Необъектный атрибут (non-object attribute) — это простой или групповой атрибут.
138
Глава 4. Семантическая объектная модель
Простые объекты
Простой объект (simple object) — это семантический объект, имеющий только однозначные, простые или групповые атрибуты. Пример такого объекта показан на рис. 4.14. В левой части этого рисунка представлены два экземпляра отчета под названием Ярлык для оборудования. Такие ярлыки, наклеиваемые на офисное оборудование, помогают вести его учет. Их можно рассматривать как отчеты.
На рис. 4.14, б изображен простой объект ОБОРУДОВАНИЕ, с помощью которого моделируется ярлык для оборудования. Атрибуты объекта включают в себя то, что указано на ярлыке: ИнвентарныйНомер, Описание, ДатаПриобретения и Стоимость. Обратите внимание, что ни один из этих атрибутов не является многозначным, как ни один из них не является и объектным. Следовательно, объект ОБОРУДОВАНИЕ является простым объектом.
ЯРЛЫК ОБОРУДОВАНИЯ:
ИнвентарныйНомер: 100 Описание: Стол
ДатаПриобретения: 2/27/2000 Стоимость: $350.00
ЯРЛЫК ОБОРУДОВАНИЯ:
ИнвентарныйНомер: 100 Описание: Лампа
ДатаПриобретения: 3/1/0200 Стоимость: $39.95
ОБОРУДОВАНИЕ
id ИнвентарныйНомер Описание
Дата П риобретения
Стоимость
а	б
Рис. 4.14. Пример простого объекта: а — отчеты, основанные на простом объекте; б — простой объект ОБОРУДОВАНИЕ
Композитные объекты
Композитный объект (composite object) — это семантический объект, содержащий один или несколько многозначных, простых или групповых атрибутов, но не имеющий объектных атрибутов. Счет за услуги гостиницы, изображенный на рис. 4.15, а, демонстрирует потребность в композитном объекте. Этот счет содержит данные, относящиеся к счету в целом: НомерСчета, ДатаПрибытия, ИмяКлиента и СуммаКОплате. Кроме того, в нем имеется повторяющаяся группа атрибутов, которая описывает предоставленные клиенту услуги. Каждая группа включает в себя атрибуты ДатаОказанияУслуги, ОписаниеУслуги и Стоимость.
На рис. 4.15, б показана диаграмма объекта СЧЕТ_ИЗ_ОТЕЛЯ. Атрибут Строка-Расходов — это групповой атрибут, имеющий максимальное кардинальное число N, что означает, что группа {ДатаОказанияУслуги, ОписаниеУслуги и Стоимость} может появляться многократно в одном и том же экземпляре семантического объекта СЧЕТ_ИЗ_ОТЕЛЯ.
Строка расходов не моделируется как самостоятельный семантический объект, а вводится как атрибут объекта СЧЕТ_ИЗ_ОТЕЛЯ. Такая организация оправдана тем, что гостиница не рассматривает каждую строку расходов в счете клиента как нечто отдельное, и строки расходов не имеют собственных идентификаторов. Служащие не вводят данные в строку расходов иначе как в контексте счета. Сна
Типы объектов
139
чала служащий вводит данные для счета № 1234, а затем, в контексте данного счета, вводит суммы. Бывает и так, что служащий берет уже существующий счет и вносит в него дополнительные расходы.
ОТЕЛЬ GRANDVIEW Си Блафс, Калифорния
Номер счета: 1234	Дата прибытия: 10/12/2001
Имя клиента: Мэри Джонс
10/12/2001 10/12/2001 10/12/2001 10/12/2001	Номер Еда Телефон Налог	$ 99.00 $ 37.55 $ 2.50 $ 15.00
10/13/2001	Номер	$99.00
10/13/2001	Еда	$ 47.90
10/13/2001	Телефон	$ 15.00
	Сумма к оплате	$ 315.95
Рис. 4.15. Пример композитного объекта: а — отчет, основанный на композитном объекте; б — композитный объект СЧЕТ_ИЗ_ОТЕЛЯ
СЧЕТ_ИЗ_ОТЕЛЯ
ю НомерСчета
ДатаПри бытия id ИмяКлиента
СтрокаРасходов
ДатаОказанияУслуги 11
ОписаниеУслуги 11
Стоимость 11
--'0.N
СуммаКОплате, j
Минимальное кардинальное число атрибута СтрокаРасходов равно 0, что означает, что объект СЧЕТ_ИЗ_ОТЕЛЯ может существовать без единой строки расходов. Это позволяет открывать счет в тот момент, когда клиент вселяется в гостиницу, и до того, как появятся какие-либо расходы. Если бы минимальное кардинальное число равнялось 1, то нельзя было бы открыть счет, прежде чем будет начислена хотя бы одна сумма. Решение об этом должно приниматься в свете имеющегося делового регламента. Политика отеля может заключаться в том, чтобы не открывать счет, пока не будут начислены какие-либо расходы. В таком случае минимальное кардинальное число атрибута СтрокаРасходов должно равняться 1.
Композитный объект может иметь более одного многозначного атрибута. На рис. 4.16, а показан счет за услуги гостиницы, в котором имя клиента и стоимость услуг представлены многозначными атрибутами. Каждая из этих групп независима от другой. Например, второе имя в группе ИмяКлиента не связано логически со второй строкой расходов.
На рис. 4.16, б представлена объектная диаграмма для счета, показанного на рис. 4.16, а. Атрибут ИмяКлиента показан как многозначный. Он не помещен в скобку СтрокаРасходов, поскольку повторения имен не имеют ничего общего с повторениями услуг. Они независимы, как мы только что отметили.
И простые, и групповые атрибуты могут быть многозначными. На рис. 4.16, о, например, ИмяКлиента является простым многозначным атрибутом. Одного этого достаточно, чтобы объект можно было назвать композитным.
Многозначные атрибуты могут также быть вложенными. Представьте себе, к примеру, что требуется вести учет отдельных видов расходов в рамках одной строки. В форме на рис. 4.17, а расходы подразделяются на виды. Например, еда
140
Глава 4. Семантическая объектная модель
делится на завтрак, обед и ужин. Объектная диаграмма с такими вложенными атрибутами, представленная на рис. 4.17, б, показывает, что оплата любых услуг может быть разделена на составляющие.
ОТЕЛЬ GRANDVIEW
Си Блафс, Калифорния
Номер счета: 1234	Дата прибытия: 10/12/2001
Имя клиента: Мэри Джонс
Фред Джонс
Сэлли Джонс
10/12/2001 10/12/2001 10/12/2001 10/12/2001	Номер Еда Телефон Налог	$ 99.00 $ 37.55 $ 2.50 $ 15.00
10/13/2001	Номер	$ 99.00
10/13/2001	Еда	$47.90
10/13/2001	Телефон	$ 15.00
	Сумма к оплате	$315.95
Рис. 4.16. Композитный объект с двумя группами: а — объект СЧЕТ_ИЗ_ОТЕЛЯ многозначным именем клиента; б — объект СЧЕТ_ИЗ_ОТЕЛЯ с двумя многозначными группами
ОТЕЛЬ GRANDVIEW
Си Блафс, Калифорния
Номер счета: 1234	Дата прибытия:
Имя клиента: Мэри Джонс
10/12/2001
10/12/2001
10/12/2001
10/12/2001
10/13/2001
10/13/2001
10/13/2001
Номер
Еда q
Завтрак
Обед
Телефон
Налог
Номер
Еда
Завтрак
Закуски Обед
Телефон
Сумма к оплате
$ 99.00
$ 15.25
$ 22.30
$ 37.50
$ 2.50
$ 15.00
$ 99.00
$ 15.25
$ 5.50
$ 22.30
$ 47.90
$ 15.00
$315.95
СЧЕТ_ИЗ_ОТЕЛЯ id НомерСчета
ДатаПрибытия ю ИмяКлиента
Строка Расходов
ДатаОказанияУслуги 1
ОписаниеУслуги11
Стоимость 11
СуммаКОплате 11
СЧЕТ_ИЗ_ОТЕЛЯ
ю НомерСчета
ДатаПрибытия
id ИмяКлиента
СтрокаРасходов ДатаОказанияУслуги ОписаниеУслуги
ПодвидУслуги ! !
СтоимостьПодвидаi -Jon
СтоимостьУслуги , j
СуммаКОплате ,,
б
Рис. 4.17. Композитный объекте вложенными группами: а — объект СЧЕТ_ИЗ_ОТЕЛЯ с разновидностями услуг; б — объект СЧЕТ_ИЗ_ОТЕЛЯ с вложенными многозначными группами
Типы объектов
141
Для закрепления повторим, что композитный объект — это объект, имеющий один или несколько простых или групповых атрибутов. Объектных атрибутов он не содержит.
Составные объекты
Составной объект (compound object) имеет минимум один объектный атрибут. На рис. 4.18, а показаны две различные формы для ввода данных. Одна из них используется автомобильным парком компании для учета имеющихся транспортных средств. Во вторую форму вводятся данные о сотрудниках. Согласно этим формам, конкретное транспортное средство закрепляется не более чем за одним сотрудником, и за конкретным сотрудником может быть закреплено не более одного автомобиля.
Мы не можем определить из этих форм, должен ли каждый автомобиль закрепляться за каким-либо сотрудником и должен ли каждый сотрудник иметь автомобиль. Чтобы получить эту информацию, нам пришлось бы спросить об этом пользователей, работающих в автопарке или в отделе кадров. Предположим, мы выяснили, что сотрудник не обязан иметь транспортное средство, но каждое транспортное средство должно быть закреплено за каким-либо сотрудником.
На рис. 4.18, б представлены диаграммы для объектов СОТРУДНИК и ТРАНС-ПО РТНОЕ_СРЕДСТВО. Объект СОТРУДНИК содержит в качестве одного из атрибутов объект ТРАНСПОРТНОЕ_СРЕДСТВО, а ТРАНСПОРТНОЕ_СРЕДСТВО, в свою очередь, содержит в качестве одного из атрибутов объект СОТРУДНИК. Поскольку и СОТРУДНИК, и ТРАНСПОРТНОЕ_СРЕДСТВО имеют объектные атрибуты, оба они являются составными объектами. Более того, так как ни один из атрибутов не является многозначным, связь между объектами СОТРУДНИК и ТРАНСПОРТНОЕ_СРЕДСТВО имеет вид «один к одному» — 1:1.
На рис. 4.18, а формы ДАННЫЕ СОТРУДНИКА и ДАННЫЕ ТРАНСПОРТНОГО СРЕДСТВА включают одна другую. То есть в форме ДАННЫЕ ТРАНСПОРТНОГО СРЕДСТВА имеется поле «Закреплено за сотрудником», а в форме ДАННЫЕ СОТРУДНИКА имеется поле «Закреплен автомобиль». Но это не всегда так: иногда связь может казаться однонаправленной. Рассмотрим отчет и форму на рис. 4.19, б, в которых описываются два объекта: DORMITORY (общежитие) и STUDENT (студент). Из отчета DORMITORY OCCUPANCY REPORT (занятость общежития) мы можем видеть, что в представлении пользователей общежитие имеет атрибуты, относящиеся как к самому общежитию — название общежития, имя ответственного жильца, телефон (Dormitory, Resident Assistant, Phone), так и к проживающим в нем студентам — имя студента, номер студента, группа (Student name, Student Number, Class).
С другой стороны, форма с данными о студенте (Student Data Form) на рис. 4.19, а содержит информацию, касающуюся исключительно самого студента, — никаких данных об общежитии в этой форме не имеется. (Местный адрес может быть адресом общежития, но даже если и так, этот факт явно недостаточно важен, чтобы документировать его в форме. При разработке базы данных возможность этого следует выяснить в ходе опроса пользователей. Здесь мы предположим, что форма Student Data Form не содержит информации об общежитии.)
142
Глава 4, Семантическая объектная модель
ДАННЫЕ ТРАНСПОРТНОГО СРЕДСТВА	
Номер лицензии	Серийный номер
Производитель	Тип	| Год выпуска |	Цвет
Закреплен за сотрудником	
РАБОЧИЕ ДАННЫЕ СОТРУДНИКА			
Имя сотрудника			Номер сотрудника
Почтовый ящик			Отдел	| Телефон
Код оплаты	Код квалификации	Дата приема на работу	Закреплен автомобиль
а
СОТРУДНИК ю ИмяСотрудника id НомерСотрудника
ПочтовыйЯщик Отдел
Телефон КодОплаты КодКвалификации Дата Найма
ТРАНСПОРТНОЕ_СРЕДСТВО id ИмяПреподавателя id НомерЛицензии
СерийныйНомер Производитель Тип
Год выпуска
Цвет
СОТРУДНИК
ТРАНСПОРТНОЕ_СРЕДСтеО
о 1
б
Рис. 4.18. Составные объекты со связью вида 1:1 между свойствами: а — примеры форм для ввода данных об автомобиле и сотруднике; б — составные объекты СОТРУДНИК и ТРАНСПОРТНОЕ-СРЕДСТВО
Как мы уже отметили ранее, объектные атрибуты всегда появляются парами. Даже если формы, отчеты и запросы демонстрируют только одну сторону связи, у связи всегда имеется две стороны. Связь можно сравнить с мостом, соединяющим два острова: мост соприкасается с обоими островами, и двигаться по нему можно в обоих направлениях, даже если по обычаю или закону этот мост является однонаправленным.
Если не удается найти ни одной формы или отчета, документирующего одну из сторон связи, команда разработчиков должна спросить пользователей о кардинальных числах этой связи. В этом случае команде требуется выяснить, сколько общежитий может быть у студента и должен ли студент быть прикреплен к общежитию. Здесь мы допустим, что ответы на этот вопрос были следующими: студент может быть прикреплен максимум к одному общежитию, но может и не быть прикрепленным ни к одному. Так, на рис. 4.19, б объект DORMITORY содержит многозначный объектный атрибут STUDENT, а объект STUDENT имеет однозначный объектный атрибут DORMITORY. Таким образом, связь между объектами DORMITORY и STUDENT имеет вид «один ко многим», или 1:N.
Типы объектов
143
DORMITORY OCCUPANCY REPORT		
Dormitory Ingersoll	Resident Assistant Sarah and Allen French	Phone 3-5567
Student name	Student Number	Class
Adams, Elizabeth	710	SO
Baker, Rex	104	FR
Baker, Brydie	744	JN
Charles, Stewart	319	SO
Scott, Sally	447	SO
Taylor, Lynne	810	FR
а
DORMITORY
IB DormName id ResidentName
Phone
STUDENT '—...    1.N
STUDENT id StudentName IB StudentNumber
Major Adviser Class HighScool PriorCollege CampusAddress CampusPhone
DORMITORY
0/(
6
Рис. 4.19. Составные объекты co связью вида 1:N между свойствами: а — примеры форм для ввода данных об общежитии и студенте; б — составные объекты DORMITORY и STUDENT
Еще один пример составных объектов показан на рис. 4.20, а. Из представленных здесь форм мы можем заключить, что одна книга может быть написана несколькими авторами (форма Book Stock Data, содержащая данные об имеющихся в наличии книгах) и что один автор может написать много книг (форма Books In Stock, By Author, содержащая данные об имеющихся в наличии книгах,
144
Глава 4. Семантическая объектная модель
отсортированных по авторам). Так, на рис. 4.20 объект BOOK (книга) содержит многозначный объектный атрибут AUTHOR (автор), а объект AUTHOR имеет многозначный объектный атрибут BOOK. Следовательно, связь между объектами BOOK и AUTHOR имеет вид «многие ко многим», или N:M. Более того, книга обязана иметь автора, а автор, чтобы считаться таковым, должен написать минимум одну книгу. Поэтому оба эти объекта имеют минимальное кардинальное число 1.
а
BOOK id Title ....AUTHOR
id ISBN
Publisher Copyringht Date
AUTHOR
id AuthorName
AuthorDates
BOOK ---.... J	1 N
6
Рис. 4.20. Составные объекты co связью вида N:M между свойствами: а — примеры форм для ввода данных книжного магазина; б — объекты BOOK и AUTHOR
На рис. 4.21 изображены все четыре типа составных объектов. Вообще говоря, объект А может содержать максимум один или много объектов Б. Аналогично, объект Б может содержать один или много объектов Б. Мы будем использовать эту таблицу при обсуждении структуры базы данных в главе 7.
Гибридные объекты
Гибридные объекты (hybrid objects) — это комбинации композитных и составных объектов. В частности, гибридный объект — это семантический объект, имеющий минимум один многозначный групповой атрибут, в состав которого входит объектный атрибут.
На рис. 4.22, а изображена вторая версия отчета о занятости общежития, представленного на рис. 4.20, а. Различие заключается в том, что третий столбец
Типы объектов
145
данных студента содержит атрибут Rent (плата за проживание) вместо атрибута Class (группа). Эта разница является существенной, поскольку плата за проживание в общежитии является атрибутом не студента, а общежития, и относится к комбинации объектов STUDENT и DORMITORY.
Объект 2 может содержать
Объект 1 может содержать
	Один	Много
Один	1:1	1.N
Много	М:1	M:N
Рис. 4.21. Четыре типа составных объектов
DORMITORY OCCUPANCY REPORT
Dormitory Ingersoll	Resident Assistant Sarah and Allen French	Phone 3-5567
Student name	Student Number	Rent
Adams, Elizabeth	710	$ 175.00
Baker, Rex	104	$ 225.00
Baker, Brydie	744	$ 175.00
Charles, Stewart	319	$ 135.00
Scott, Sally	447	$ 225.00
Taylor, Lynne	810	$ 175.00
а
DORMITORY
IB DormName ResidentName Phone StudentRent
STUDENT
id StudentName
id StudentNumber
DORMiTORYfl
—....0.1
STUDENT , j
1.1 i
Rent01	__:
1.N
6
DORMITORi
io DormName ResidentName
Phone
STUDENT
STUDENT,;
id StudentName
io StudentNumber
i
'--о 1
Rent 0.1
Рис. 4.22. Гибридный объект DORMITORY: a — отчет об общежитии со свойством Плата; б — правильный вид объектов DORMITORY и STUDENT; в — неправильный вид объектов DORMITORY и STUDENT
146
Глава 4. Семантическая объектная модель
На рис. 4.22, б показана объектная диаграмма, моделирующая эту форму. Объект DDRMITORY содержит многозначную группу, включающую в себя объектный атрибут STUDENT и необъектный атрибут Rent. Это означает, что атрибуты Rent и STUDENT являются спаренными в контексте объекта DORMITORY.
Рассмотрим теперь альтернативный вариант объекта DORMITORY, представленный на рис. 4.22, в. Это неправильная модель отчета, изображенного на рис. 4.22, а, так как она показывает, что атрибуты Rent и STUDENT являются многозначными независимо друг от друга, что неверно, потому что эти атрибуты являются многозначными как пара.
На рис. 4.23, а изображена форма, основанная на другом гибридном объекте. Эта форма под названием Sales Order Form (заказ на покупку) содержит данные о заказе (Sales Order Number, Date, Subtotal, Tax, Total), данные о покупателе (CUSTOMER) и продавце (SALESPERSON), а также многозначную группу, содержащую данные о заказанных товарах. Кроме того, в этой многозначной группе представлены данные о товаре — ITEM (Item Number, Description и Unit Price).
На рис. 4.23, б показан семантический объект SALES-ORDER (заказ). Он содержит необъектные атрибуты SalesOrderNumber (номер заказа), Date (дата), Subtotal (промежуточный итог), Тах (налог) и Total (итог). Кроме того, он содержит объектные атрибуты CUSTOMER и SALESPERSON, а также многозначную группу, представляющую каждую позицию заказа. Группа содержит необъектные атрибуты Quantity (количество) и Extended Price (цена с надбавкой) и объектный атрибут ITEM.
Объектные диаграммы на рис. 4.23, б неоднозначны в одном аспекте, который может быть важен или не важен, в зависимости от приложения. Согласно объектной диаграмме, товар может быть связан более чем с одним заказом. Но поскольку многозначная группа Lineitem инкапсулирована (вложена) в объект SALES-ORDER, из этой диаграммы не ясно, может ли конкретный вид товара появляться один раз или многократно в одном и том же объекте SALES-ORDER.
В общем, есть четыре интерпретации максимального кардинального числа для спаренных атрибутов гибридного объекта SALES-ORDER:
1.	Конкретный товар может появляться только в одном заказе и только в одной строке данного заказа.
2.	Конкретный товар может появляться только в одном заказе, но во многих его строках.
3.	Конкретный товар может появляться во многих заказах, но в каждом заказе — только в одной строке.
4.	Конкретный товар может появляться во многих заказах, а в рамках заказа — во многих строках.
Когда важно различать эти случаи, нужно использовать следующую запись: в случаях 1 и 2 максимальное кардинальное число гибридного объектного атрибута следует установить равным 1. Так, для данного примера максимальное кардинальное число атрибута SALES-ORDER объекта ITEM установлено равным 1. Если конкретный товар может появляться только в одной строке заказа (случай 1), он должен быть помечен как имеющий уникальный идентификатор в данной группе. Если нет (случай 2), то помечать его не требуется. Эти два случая изображены на рис. 4.24, а и б.
Типы объектов
147
t£J Catbon River Furniture Sales Order Form
Sales Oder Number | 10843	Date 25-Sep-C'
^«ййа№й^Маям^к- Carbon R^er 9:	jJ
Addles® 1145 E$n5i^[
City CataiRi^s &a1-	-	J2234
Phone: izOifi'' J
SafetC’etswHaff® Dodi1' i- -•-* * | S ites;«5f$on Code [ £Z4:
Quantity: |
1 1 4
Item Number |_____________Detcnpjion
78 ; Executive Desk
79 J Conference Table
80 Side Chair
Unit Рисе: | Extended Prfce.
$959 00	$959.00
$1750.00	$1750.00
$99.00 ............. $396.00	’
’ Subtotal 77~t3105P°'S
I Ta» tZTZjSj© [ Total. . " ~~ S3.134.46 _
SALES-ORDER
id SalesOrderNumber
Date
CUSTOMER
ITEM
ID ItemNumber ItemDescription UnitPrice 11
SALES-ORDER
SALESPERSON
..........     1Д
Lineitem
Quantity i t
__™_,
...;:i:ii;i!:i:iii...... 1.1
ExtendePrice 1J
Subtotal !
Tax и
Totali.i
CUSTOMER
id CustomerName
Address
City
State
Zip
Phone
SALES-ORDER
L_------------—l0N
И
я
a

SALESPERSON
id SalesPersonName
SalesPersonCode
SALES-ORDER ------------- O.N
6
Рис. 4.23. Гибридный объект SALES-ORDER и связанные с ним объекты: а — форма заказа; б — объекты, моделирующие форму заказа
В случаях 3 и 4 максимальное кардинальное число гибридного объектного атрибута устанавливается равным N. Так, для данного примера максимальное
148
Глава 4, Семантическая объектная модель
кардинальное число атрибута SALES-ORDER в объекте ITEM устанавливается равным N. Далее, если конкретный товар может появляться только в одной строке заказа (случай 3), он должен быть помечен как имеющий уникальный идентификатор в данной группе. Если нет (случай 4), то помечать его не требуется. Эти два случая изображены на рис. 4.25, ап б.
SALES-ORDER ю SalesOrderNumber Date
! CUSTOMER
.—.....—А.1
SALESPERSON!< ----------------ы 1 d
Lineitem
Quantity!.1 id! ITEM ........... i.i
ExtendePrice, ,
Subtotal < , Taxu
To,al1.i
ITEM id ItemNumber
ItemDescription UnitPrice,, "SALES-ORDER .................  Q	,
SALES-ORDER
id SalesOrderNumber
Date
ITEM id ItemNumber
ItemDescription
UnitPrice, , sal: s-order -------------------0.1
Lineitem
Quantity,,
ITEM
ExtendePrice, , Subtotal,, Tax и
Tota! t1
Рис. 4.24. Примеры 1 и 2 максимальной кардинальности: а — один товар в одном заказе; б — один товар во многих строках одного и того же заказа
Ассоциативные объекты
Ассоциативный объект (association object) — это объект, который связывает два или более объекта и содержит данные, относящиеся к этой связи. На рис. 4.26 показаны отчет и две формы для ввода данных, для моделирования которых необходим ассоциативный объект. Отчет содержит данные об авиарейсе, о самолете, выполняющем этот рейс, и о пилоте, назначенном на этот рейс. Формы для ввода данных содержат данные о пилоте и о самолете.
Типы объектов
149
На рис. 4.27 объект FLIGHT (авиарейс) — это ассоциативный объект, который связывает объекты AIRPLANE (самолет) и PILOT (пилот) и хранит данные об их связи. Объект FILGHT содержит в себе по одному объектному атрибуту AIRPLANE и PILOT, но объекты AIRPLANE и PILOT содержат множество объектных атрибутов FLIGHT. Такого рода связь двух или более объектов возникает часто, особенно в приложениях, где требуется назначить друг другу две вещи или более. В качестве других примеров можно привести объект РАБОТА, связывающий объекты АРХИТЕКТОР и КЛИЕНТ, объект ЗАДАЧА, связывающий объекты СОТРУДНИК и ПРОЕКТ, и объект ЗАКАЗ, связывающий объекты ПОСТАВЩИК и УСЛУГА.
В примере, показанном на рис. 4.26, ассоциативный объект FLIGHT имеет собственный идентификатор, группу {FlightNumber, Date} (номер рейса, дата). Часто ассоциативные объекты не имеют собственных идентификаторов, и тогда идентификатор представляет собой комбинацию идентификаторов объектов, которые связаны в ассоциативном объекте.
SALES-ORDER
id SalesOrderNumber Date
" CUSTOMER
.................'1.1
SALESPERSON
Lineitem
Quantity
ip | ITEM "I
ExtendePrice, ,
Subtotal 1,
Taxti
Totai r1
ITEM
id ItemNumber ItemDescription
UnitPrice 11
SALES < RDER
-------------------iQN
SALES-ORDER id SalesOrderNumber
Date
CUSTOMER ...........и
‘SALESPERSON ---и-------------
Lineitem
Quantity,.,
HEM ------------- 1.1 ExtendePrice, , Subtotal 1, Tax и To!all.l
ITEM
id ItemNumber ItemDescription
UnitPrice I,
''45ALES-C DER
.............. J0.N
6
Рис. 4.25. Примеры 3 и 4 максимальной кардинальности: а — один товар в одной строке многих заказов; б — один товар во многих строках многих заказов
150
Глава 4. Семантическая объектная модель
FLY CHEAP INTERNATIONAL Flight Planning Data Report
FLIGHT NUMBER ORIGINATING CITY FUEL ON TAKEOFF	FC-17 DATE 7/30/2001 Seattle DESTINATION Hong Kong
WEIGHT ON TAKEOFF	
AIRPLANE Tail Number Type Capacity	N1234FI 747-SP 148
PILOT Name FI-ID Flight Hours	Micheel Nilson 32887 18,348
ЙЗ Fiy Cheap international Anplane Data Foim	  ИВЙ!
Tai/N&mlter
Manufacturer
Рис. 4.26. Пример ассоциативного объекта: отчеты и формы
Чтобы лучше понять это, рассмотрим рис. 4.28, а, на котором изображен отчет о назначении архитекторов на проект. Хотя само назначение не имеет явного идентификатора, в действительности идентификатором является комбинация
Типы объектов
151
{НазваниеПроекта, ИмяАрхитектора}. Эти атрибуты, однако, принадлежат объектам ПРОЕКТ и АРХИТЕКТОР соответственно, а не объекту НАЗНАЧЕНИЕ. Идентификатором назначения является, таким образом, комбинация идентификаторов вещей, которые назначаются друг другу.
г
FLIGHT	_
id FlightID
FlightNumber Date
OriginatingCity Destination FueOnTakeOff
WeightOnTakeOff
AIRPLANE
1,1
AIRPLANE
io TailNumber Manufacturer
Type TotalAirframeHours TatalEngineHours EngHoursPastOH Currentcapacity RangeAsConfig
PILOT -----------
FLIGHT -----------i0N
PILOT
ip FCI-ID
Name
SpocialSecurityNumber Street
City State Zip Phone EmergPhone DateOfLastCheckOut Hours
DateOfLastPhysical
FLIGHT
------------------O.N
Рис. 4.27. Объекты FLIGHT, PILOT и AIRPLANE
На рис. 4.28, 6 показаны объектные диаграммы для этого случая. И ПРОЕКТ, и АРХИТЕКТОР являются объектными атрибутами объекта НАЗНАЧЕНИЕ, а группа {ПРОЕКТ, АРХИТЕКТОР} является идентификатором объекта НАЗНАЧЕНИЕ. Это означает, что комбинация экземпляра объекта ПРОЕКТ и экземпляра объекта АРХИТЕКТОР идентифицирует конкретное назначение.
Обратите внимание, что идентификатор НомерНазначения на рис. 4.28, 6 не является уникальным; тем самым указывается, что архитектор может быть назначен на один и тот же проект несколько раз. Если это не так, идентификатор должен быть объявлен уникальным. Далее, если сотрудник может быть назначен на один и тот же проект более одного раза и если по какой-то причине важно иметь уникальный идентификатор для назначения, к группе следует добавить атрибут даты или какой-нибудь еще атрибут, указывающий время (неделя, квартал и т. д.).
Объекты вида родитель/подтип
Чтобы понять, что представляют собой объекты вида родитель/подтип (parent/ subtype objects), рассмотрим объект СОТРУДНИК на рис. 4.29, а. Некоторые атрибуты объекта СОТРУДНИК относятся ко всем сотрудникам, а некоторые — только к тем сотрудникам, которые являются менеджерами. Объект на рис. 4.29, а не слишком точно отражает действительность, поскольку атрибуты, свойственные менеджерам, не подходят для сотрудников, не являющихся менеджерами.
Более удачная модель показана на рис. 4.29, б. Здесь объект СОТРУДНИК содержит объект подтипа МЕНЕДЖЕР. Все атрибуты, относящиеся к менеджерам, перене
152
Глава 4. Семантическая объектная модель
сены в объект МЕНЕДЖЕР. Сотрудники, не являющиеся менеджерами, имеют один экземпляр объекта СОТРУДНИК и ни одного экземпляра объекта МЕНЕДЖЕР. Сотрудники-менеджеры имеют по одному экземпляру объектов СОТРУДНИК и МЕНЕДЖЕР. В этом примере объект СОТРУДНИК называется родительским объектом (parent object), или объектом надтипа (supertype object), а объект МЕНЕДЖЕР называется объектом подтипа (subtype object).
Отчет о назначении на проект
Название проекта Менеджер проекта Начало проекта Окончание проекта
Дом Абернати Дж. Смит 11/11/1999
Архитектор Телефон Номер офиса
Б. Джексон 232-8878 J-1133
Начало работы по назначению	12/15/2001
Окончание работы по назначению	3/15/2002
HoursK Максимальное количество часов в бюджете 345 Максимальная стоимость труда	$ 27,500
Максимальная стоимость материалов	$ 17,500
НАЗНАЧЕНИЕ _
id НомерНазначения i
ПРОЕКТ
1.11
liilTEKTOPi
1 ij НачалоНазначения КонецНазначения МаксимумЧасов МаксСтоимостьТруда М аксСтоимостьМатериалов
ПРОЕКТ
id НазваниеПроекта МенеджерПроекта НачалоПроекта ОкончаниеПроекта
НАЗНАЧЕНИЕ
---------------- I.N
АРХИТЕКТОР id ИмяАрхитектора
Телефон
НомерОфиса |||НАЗНАЧЕНЙ|||
1.N
б
Рис. 4.28. Ассоциативный объект НАЗНАЧЕНИЕ: а — пример отчета о назначении; б — объект НАЗНАЧЕНИЕ с семантическим объектным идентификатором
Первым атрибутом подтипа является родительский объект, обозначенный индексом Р. Указание родительского атрибута является обязательным всегда. Идентификаторы у подтипа те же, что и у родителя. На рис. 4.29 атрибуты Номер-Сотрудника и ИмяСотрудника являются идентификаторами как объекта СОТРУДНИК, так и объекта МЕНЕДЖЕР.
Атрибуты подтипа показываются с помощью индексов 0.ST или 1.ST. Первая цифра (0 или 1) — это минимальное кардинальное число подтипа. Если оно равно 0, подтип является необязательным, а если 1, то подтип является обязательным. (Обязательный подтип не имеет смысла для этого примера, но необ
Типы объектов
153
ходимость в нем появится в последующих, более сложных случаях.) Буквы ST (subtype — подтип) указывают на то, что атрибут является подтипом, или атрибутом типа «ЕСТЬ».
Объекты вида родитель/подтип обладают важной характеристикой, называемой наследованием. Подтип приобретает, или наследует, все атрибуты своего родителя, и поэтому объект МЕНЕДЖЕР наследует все атрибуты объекта СОТРУДНИК. Вдобавок родитель приобретает все атрибуты своих подтипов, и сотрудник, являющийся менеджером, приобретает все атрибуты менеджера.
Семантический объект может содержать более одного атрибута подтипа. На рис. 4.30 показан второй вариант объекта СОТРУДНИК, который имеет два атрибута подтипа — МЕНЕДЖЕР и ПРОГРАММИСТ. Поскольку оба этих атрибута являются необязательными, объект СОТРУДНИК может иметь, один или оба эти подтипа или не иметь ни одного. Это означает, что некоторые сотрудники не являются ни менеджерами, ни программистами, некоторые являются менеджерами, но не являются программистами, некоторые являются программистами, но не являются менеджерами, а некоторые одновременно являются программистами и менеджерами.
СОТРУДНИК
id НомерСотрудника ,1 id ИмяСотрудника,л
ДатаНайма
Зарплата
ДолжностьМенеджера УровеньМенеджмента НачисленнаяПремия ВыплаченнаяПремия
а
Данные сотрудника
Данные менеджера
СОТРУДНИК
id НомерСотрудника
id ИмяСотрудника
ДатаНайма
Зарплата
|||Юенед>кер :||
----- ——------' о.ST
МЕНЕДЖЕР
it СОТРУДНИК ' iSfc-------р
ДолжностьМенеджера УровеньМенеджмента НачисленнаяПремия ВыплаченнаяПремия
б
Рис. 4.29. Необходимость введения подтипа МЕНЕДЖЕР: а — объект СОТРУДНИК без подтипа; б — объект СОТРУДНИК с подтипом МЕНЕДЖЕР
Иногда подтипы исключают друг друга. То есть транспортное средство может быть легковым автомобилем или грузовиком, но не тем и другим одновременно. Клиент может быть индивидуальным клиентом, товариществом или корпорацией, но только одним из этих трех типов. Когда подтипы исключают друг друга, они помещаются в группу подтипов, и группе присваивается индекс в формате X.Y.Z. X — это минимальное кардинальное число, равное 0 или 1, в зависимости
154
Глава 4. Семантическая объектная модель
от того, является ли группа подтипов обязательной. Y и Z указывают количество атрибутов в группе, которым разрешается иметь значение. Y — минимальное количество, Z — максимальное.
На рис. 4.31, а три типа клиентов изображены как группа подтипов. Индекс группы, 0.1.1, означает, что подтип не требуется, но если он существует, в группе должен существовать минимум один и максимум один’подтип (иначе говоря, ровно один). Заметьте, что каждый из подтипов имеет индекс 0.ST, то есть все они являются необязательными, как и должно быть. Если бы все они были обязательными, максимальное количество атрибутов было бы 3, а не 1. Эта запись достаточно надежна, чтобы предусмотреть ситуации, когда обязательными являются три из пяти или семь из десяти подтипов.
СОТРУДНИК
id НомерСотрудника
id ИмяСотрудника ДатаНайма Зарплата
. МЕНЕДЖЕР
...............° ST
Г ПРОГРАММИСТ
11-------------0.ST
МЕНЕДЖЕР
СОТРУДНИК
Должность Менеджера УровеньМенеджмента НачисленнаяПремия ВыплаченнаяПремия
ПРОГРАММИСТ
СОТРУДНИК
Язык о м
ОперационнаяСистема 0 N
Рис. 4.30. Объект СОТРУДНИК с двумя подтипами
Можно смоделировать и более сложные ограничения, если ввести вложенные подтипы. Группа подтипов на рис. 4.31, б моделирует ситуацию, когда корпорация может быть либо налогооблагаемой, либо не налогооблагаемой. Если корпорация не является налогооблагаемой, это должна быть либо правительственная организация, либо школа. В этом примере показано только несколько необъектных атрибутов. В реальности, если бы требовалась такая сложная структура, в ней, скорее всего, было бы больше атрибутов.
Объекты вида архетип/версия
Последний тип объектов — это объекты вида архетип/версия (archetype/version objects). Объект-архетип (archetype object) — это семантический объект, порождающий другие семантические объекты, которые представляют версии (version objects), выпуски или издания архетипа. Например, на рис. 4.32 объект-архетип УЧЕБНИК порождает объекты-версии ИЗДАНИЕ. Согласно этой модели, атрибуты Название, Автор и Издательство принадлежат объекту УЧЕБНИК, а атрибуты Поряд-ковыйНомерИздания, ДатаВыхода и КоличествоСтраниц — объекту ИЗДАНИЕ.
Типы объектов
155
КЛИЕНТ
id НомерКлиента ИмяКлиента
ФИЗИЧЕСКОЕ ЛИЦО
КЛИЕНТ
НалоговыйНомер
Баланс
ИмяДоверенногоЛица
ТелефонДоверенногоЛица
НАЛОГООБЛАГАЕМАЯ.КОИП ]
.....................tst	;
НЕНАЛдгООБЛАГАЕМАЯ„КОРП| ;
........................6.ST	j
0.1.1
ФИЗИЧЕСК0Е_ЛИЦ0
КЛИЕНТ ----------------р
НомерСоциальнойСтраховки
СовокупнаяСтоимость
ТОВАРИЩЕСТВО
КЛИЕНТ
---------------р
НалоговыйНомер УправляющийПартнер
КОРПОРАЦИЯ
КЛИЕНТ ь""' .......... р
НалоговыйНомер
Баланс
ИмяДоверенногоЛица ТелефонДоверенногоЛица
НАЛОГООБЛАГАЕМ АЯ_КОРП
КОРПОРАЦИЯ
НалоговаяСтавка
НЕНАЛОГООБЛАГАЕМАЯ_КОРП
КОРПОРАЦИЯ .......а . .. .... . . . р
НомерОсвобождения
ПРАВИТЕЛЬСТВЕННОЕjrEHTCTBol "I
'~"7' 7 ~777 77.	°™ 7ST ।
ШКОЛА ~~	.|
O.ST i
0.1.1
ПРАВИТЕЛЬСТВЕННОЕ АГЕНТСТВО
НЕНАЛОГООБЛАГАЕМАЯ_КОРП
L- ——•••. •  т. ••• .	. р
ФедеральныйНомер
ШКОЛА
НЕНАЛОГООБЛАГАЕМАЯ„КОРП
ШкольныйОкруг
б
Рис. 4.31. Взаимоисключающие (а) и вложенные (б) подтипы
Идентификационная группа объекта ИЗДАНИЕ состоит из двух частей: УЧЕБНИК и ПорядковыйНомерИздания. Это типичный образец идентификатора объекта-версии. Одна часть идентификатора содержит объект-архетип, а вторая часть — это простой атрибут, идентифицирующий версию архетипа. На рис. 4.33 изображен еще один пример объектов вида архетип/версия.
156
Глава 4. Семантическая объектная модель
УЧЕБНИК
ID ISBN Название Автор Издательство
....ИЗДАНИЕ
ИЗДАНИЕ
IP ИденгификагорИздания
УЧЕБНИК.....
giiiatiigs ?—,
ПорядковыйНомерИздания1 1
ДатаВыхода
КоличествоСтраниц
Рис. 4.32. Пример объекта вида архетип/версия
ИЗДАНИЕ id I Название
Адрес
Улица Город Штат
Индекс -J
КоличествоЭтажей1':
КВАРТИРА 
----------------- 1.N
КВАРТИРА
!Р ИдентификаторКвартиры
ИЗДАНИЕ 1
...........J -.
НомерКвартиры 1
КоличествоКомнат -1
Площадь
Рис. 4.33. Еще один пример объекта вида архетип/версия
Сравнение семантической объектной модели и модели «сущность—связь»
Модель «сущность—связь» и семантическая объектная модель имеют как сходства, так и различия. Они похожи тем, что обе являются инструментами для уяснения и документирования структуры пользовательских данных. Обе они имеют своей целью моделирование структуры вещей в мире пользователей и связей между ними.
Принципиальное различие между двумя моделями заключается в ориентации. Модель «сущность—связь» в качестве базовой концепции рассматривает концепцию сущности. Сущности и их связи выступают, если хотите, как атомы модели данных. Эти атомы могут быть организованы в структуры, которые модель «сущность-связь» называет пользовательскими представлениями (user views). Пользовательские представления — это комбинации сущностей, строение которых напоминает строение семантических объектов.
Базовое понятие семантической объектной модели — семантический объект. Набор семантических объектов в модели данных — это карта структуры вещей, которые пользователи считают существенными. Эти объекты являются атомами мира пользователей и представляют собой наименьшие различимые единицы, которыми пользователи желают оперировать. Они могут разбиваться на более мелкие части внутри СУБД (или в приложении), но эти более мелкие части не представляют интереса для пользователей.
С точки зрения семантической объектной модели, сущности, в том виде как они определены в модели «сущность—связь», не существуют. Они являются лишь фрагментами, кусками реальных сущностей. Фактически, единственные
Сравнение семантической объектной модели
157
сущности, которые имеют смысл для пользователей, — это семантические объекты. По-другому можно выразить это, сказав, что семантические объекты являются семантически самодостаточными, или семантически завершенными. Рассмотрим пример. На рис. 4.34 представлены четыре семантических объекта: ЗАКАЗ, КЛИЕНТ, ПРОДАВЕЦ и ТОВАР. Когда пользователь говорит: «Покажите мне заказ № 2000», он имеет в виду, что следует показать объект ЗАКАЗ так, как он смоделирован на рис. 4.34. Сюда входят, среди прочего, данные о покупателе. Поскольку информация о покупателе является частью заказа, объект ЗАКАЗ содержит объект КЛИЕНТ.
ЗАКАЗ
ю НомерЗаказа
Дата
КЛИЕНТ
ПРОДАВЕЦ
СтрокаЗаказа Количество
ТОВАР
КЛИЕНТ
ID НомерКлиента ИмяКлиента Адрес
Улица
Город Штат
Индекс J ,,
ЗАКАЗ
---------------- 0.N
Стоимость
Промежуточный Итог]
Налог	1.1
Итог
ТОВАР
io НомерТовара Название Описание
ПРОДАВЕЦ
id ИмяПродавца КодПродавца
ЗАКАЗ
L-“ ------—'—1 м
3AMIIIIII
0 N
Рис. 4.34. Объект ЗАКАЗ и связанные с ним семантические объекты
Рис. 4.35. Модель «сущность—связь» для объекта ЗАКАЗ и КЛИЕНТ
158
Глава 4. Семантическая объектная модель
На рис. 4.35 изображена модель «сущность—связь» для тех же данных, которая содержит сущности ЗАКАЗ, КЛИЕНТ, ПРОДАВЕЦ, ТОВАР и СКЛАД. Сущность ЗАКАЗ имеет атрибуты НомерЗаказа, Дата, ПромежуточныйИтог, Налог и Итог. Теперь, если пользователь попросит: «Покажите мне заказ № 2000», он будет разочарован и, скорее всего, задаст вопрос: «А где же остальные данные?» То есть сущность ЗАКАЗ не соответствует пользовательскому представлению о заказе как об отдельном феномене. Эта сущность является лишь частью реального заказа.
В то же время, когда пользователь (возможно, даже тот же самый) попросит: «Покажите мне покупателя № 12345», он будет иметь в виду, что следует показать все данные, которые на рис. 4.34 относятся к покупателю, включая имя клиента, все составляющие адреса и все заказы этого покупателя. Сущность КЛИЕНТ на рис. 4.35 имеет только атрибуты ИмяКлиента, Улица, Город, Штат и Индекс. Если бы пользователю, который попросил: «Покажите мне покупателя АВС», предоставили только эти данные, он был бы снова разочарован: «Нет, это только часть того, что мне нужно».
С точки зрения семантической объектной модели, в сущностях, как они представлены в модели «сущность—связь», нет необходимости. Семантические объекты можно сразу преобразовывать в структуру базы данных, никак не рассматривая ER-сущности. Они являют собой, так сказать, недостроенные дома, воздвигнутые в процессе ухода от парадигмы компьютерных структур данных к парадигме пользователей.
Еще одно отличие состоит в том, что семантические объекты содержат в себе больше метаданных, чем сущности. В семантической объектной модели на рис. 4.34 отражено то, что НомерКлиента является уникальным идентификатором в представлении пользователей. Он может использоваться или не использоваться в качестве идентификатора в соответствующей таблице, но данный факт не существенд ля модели данных. Мы также можем видеть, что НомерКлиента является для пользователей неуникальным идентификатором. Более того, семантическая объектная диаграмма указывает на тот факт, что существует семантическая группа атрибутов под названием Адрес. Эта группа содержит другие атрибуты, составляющие вместе адрес. Существование этой группы станет для нас важным при разработке форм и отчетов. Е1аконец, семантическая объектная диаграмма показывает, что конкретный ТОВАР может быть включен более чем в один ЗАКАЗ, но в каждом заказе этот товар может появиться только в одной строке. Этот факт невозможно указать на диаграмме «сущность—связь».
Решите в конечном счете, какой из рисунков — 4.34 или 4.35 — дает вам лучшее представление о том, что должно содержаться в базе данных. Многие находят, что рамки, очерченные вокруг семантических объектов, и скобки, заключающие в себе групповые атрибуты, помогают более четко представить общую картину модели данных.
Резюме
159
Резюме
Как модель «сущность—связь», так и семантическая объектная модель используются для интерпретации требований пользователей и моделирования пользовательских данных. Эти модели похожи на линзы, сквозь которые смотрят разработчики, изучая и документируя пользовательские данные. Обе они в конечном счете воплощаются в структуру базы данных.
Семантический объект — это именованная совокупность атрибутов, которая в достаточной степени определяет отдельный феномен. Семантические объекты группируются в классы, и как у классов, так и у экземпляров семантических объектов есть имена. Например, именем класса является СОТРУДНИК, а именем экземпляра этого класса — СОТРУДНИК 2000.
Атрибуты описывают характеристики представляемых феноменов. Набор атрибутов является достаточным, если он отражает все характеристики, которые требуются пользователям для выполнения их работы. Объекты представляют отдельные феномены — вещи и явления, которые рассматриваются пользователями как независимые и самостоятельные. Отдельные феномены, представляемые объектами, могут существовать или не существовать физически — в самом деле, ведь они могут сами по себе быть представлением чего-то, как, например, контракт.
Объектные атрибуты могут быть простыми элементами данных, группами или другими семантическими объектами. Объектные диаграммы визуально представляют структуру объектов. Имена объектов пишутся заглавными буквами в верхней части диаграммы. Необъектные атрибуты записываются строчными буквами, а группы атрибутов заключаются в скобки.
Все атрибуты имеют минимальное кардинальное число, показывающее, сколько экземпляров атрибута должно существовать, чтобы объект был допустимым. Они также имеют максимальное кардинальное число, которое показывает максимально допустимое количество экземпляров атрибута. Кардинальность записывается в формате N.M, где N — это минимальное кардинальное число, а М — максимальное кардинальное число. Чтобы не загромождать объектную диаграмму, кардинальность 0.1 у простого атрибута не указывается. Но для групповых и объектных атрибутов кардинальность указывается всегда.
Объектные атрибуты всегда возникают парами. Если один объект имеет связь с другим, этот второй объект должен иметь связь с первым. Объектные идентификаторы — это атрибуты, которые служат, в представлении пользователей, для различения объектов. Идентификаторы могут быть уникальными либо неуникальными. Атрибут любого типа может быть идентификатором. Идентификаторы обозначаются буквами ID перед именем атрибута. Если атрибут является уникальным, то буквы ID подчеркиваются. Кардинальность идентификатора равна обычно 1.1.
Домен атрибута — это совокупность всех возможных значений этого атрибута. Домены имеют физическое и семантическое описание. Существует три типа доменов: простой, групповой и семантический объект.
160
Глава 4. Семантическая объектная модель
Приложения оперируют объектами через пользовательские представления. Представление объекта состоит из имени объекта и всех атрибутов, видимых из данного представления. Разработка представления и объекта зачастую представляет собой итеративный процесс.
Процесс разработки набора объектных диаграмм является итеративным. Сначала анализируются отчеты или формы, на их основе разрабатывается исходный набор объектов, а затем изучаются другие отчеты и формы, исходя из которых вводятся новые объекты и уточняются имеющиеся. Этот процесс продолжается до тех пор, пока не будут исследованы все отчеты и формы.
Существует семь типов объектов. Простые объекты не имеют многозначных и объектных атрибутов. Композитные объекты имеют многозначные атрибуты, но не имеют объектных атрибутов. Составные объекты содержат объектные атрибуты, а гибридные объекты сочетают в себе композитные и составные объекты. Ассоциативные объекты связывают два или более других объектов. Объекты подтипов представляют разновидности объектов. Наконец, объекты вида архе-тип/версия используются для моделирования объектов, содержащих базовые данные и множественные их вариации, или версии.
Модель «сущность—связь» в качестве базовых элементов рассматривает сущности, в то время как семантическая объектная модель рассматривает в качестве базовых элементов семантические объекты. Кроме того, семантическая объектная модель содержит больше информации о значении данных, чем модель «сущность-связь».
Вопросы группы I
1.	Объясните, почему модель «сущность—связь» и семантическая объектная модель похожи на линзы.
2.	Дайте определение семантического объекта.
3.	Объясните разницу между именем класса объекта и именем экземпляра объекта. Приведите примеры для обоих случаев.
4.	Что требуется для того, чтобы набор атрибутов был достаточным описанием?
5.	Объясните, что понимается под словосочетанием отдельный феномен в определении семантического объекта.
6.	Объясните, почему отдельная строка заказа не является семантическим объектом.
7.	Назовите три типа атрибутов.
8.	Приведите примеры атрибутов следующих типов:
1)	простой однозначный атрибут;
2)	групповой однозначный атрибут;
3)	простой многозначный атрибут;
4)	групповой многозначный атрибут;
Вопросы группы I
161
5)	простой объектный атрибут;
6)	многозначный объектный атрибут.
s'	9. Что такое минимальное кардинальное число? Как оно используется? Какие типы атрибутов имеют минимальное кардинальное число?
10.	Что такое максимальное кардинальное число? Как оно используется? Какие типы атрибутов имеют максимальное кардинальное число?
11.	Что такое парные атрибуты? Для чего они нужны?	s
12.	Что такое идентификатор объекта? Приведите пример простого и группового атрибута, идентифицирующего объект.
13.	Дайте определение домена атрибута. Какие бывают типы доменов атрибутов? Почему необходимо семантическое описание?
14.	Что такое представление семантического объекта? Приведите пример объекта и двух его представлений, отличный от того, который дан в тексте.
15.	Приведите пример простого объекта, отличный от того, который дан в этой главе.
„ 16. Приведите три примера композитных объектов, отличные от тех, которые приведены в этой главе. У одного объекта должен быть ровно один простой многозначный атрибут, другой объект должен иметь две независи-мых многозначных группы, а третий объект должен содержать вложенные -многозначные группы.
;;	17. Приведите примеры четырех наборов составных объектов, отличные от тех, которые даны в тексте. Один набор должен иметь связь 1:1, другой — >. 1:N, третий — М:1, и четвертый — M:N.	f
,	18. Приведите пример гибридного объекта, отличный от того, который дан ' в этой главе.	1
'	19. Приведите пример одного ассоциированного и двух составных объектов, ь отличный от тех примеров, которые даны в этой главе.
	20. Приведите пример объекта надтипа с тремя объектами подтипов, отличный от того, который дан в тексте.
21. Приведите примеры объектов вида архетип/версия, отличный от приведенных в этой главе.
,, 22. Укажите сходства модели «сущность—связь» и семантической объектной модели.
• 23. Укажите основные различия между моделью «сущность—связь» и семантической объектной моделью.
24.	Объясните, почему сущности, как они определены в модели «сущность-связь», не существуют в действительности.
25.	Покажите, как модель «сущность—связь» и семантическая объектная модель будут интерпретировать данные, содержащиеся в форме SALES-ORDER на рис. 4.23, а, и укажите основные различия.
162
Глава 4. Семантическая объектная модель
Вопросы группы II
26.	Модифицируйте семантическую объектную диаграмму на рис. 4.13, введя в нее объекты ГРУППА, ПРЕДМЕТЫ_НА_ВЫБОР и ЗАПИСЬ. Предположим, что ЗАПИСЬ — это ассоциативный объект, связывающий студента с предметом.
27.	Модифицируйте семантическую объектную диаграмму на рис. 4.13, введя в нее объект КОМИТЕТ. Допустим, что один преподаватель может быть назначен в несколько комитетов и что комитет включает в себя много преподавателей. Создайте объект ЗАСЕДАНИЯ — объект вида архетип/версия, представляющий заседания комитета.
28.	Измените свой ответ на вопрос 27, введя объект ЗАСЕДАНИЕ как многозначную группу внутри объекта КОМИТЕТ. Является ли эта модель более удачной, чем предыдущая? Обоснуйте свой ответ.
Проекты
1.	Разработайте семантическую объектную модель для Столичного агентства жилья из проекта 1 в конце главы 3.
2.	Зайдите на сайт какого-нибудь производителя компьютеров, например Dell (www.dell.corn). Пользуясь средствами сайта, определите, какой ноутбук вы могли бы приобрести для пользователя с бюджетом $10 000. Занимаясь выяснением этого вопроса, подумайте о том, какой структурой может обладать база данных по компьютерным системам и подсистемам, используемая для поддержки данного сайта.
Разработайте семантическую объектную модель для базы данных по компьютерным системам и подсистемам для этого сайта. Возможными объектами являются БА30ВАЯ_К0НФИГУРАЦИЯ, ОБЪЕМ_ПАМЯТИ, ВИДЕОКАРТА и ПРИНТЕР. Покажите связи между объектами и наделите каждый объект минимум двумя-тремя атрибутами. Укажите тип каждого семантического объекта. Чтобы проект не оказался чрезмерно велик, ограничьтесь тем, что требуется для человека, который точно решил купить компьютер, но еще не выбрал, какой именно.
3.	Зайдите на сайт виртуального книжного магазина, такого как Amazon (www. arnazon.com). Пользуясь средствами сайта, найдите три лучших книги по XML для человека, который только начал изучать этот предмет. Занимаясь выяснением данного вопроса, подумайте о том, какой может быть структура базы данных по книгам, авторам, предметам и родственным темам.
Разработайте семантическую объектную модель для базы данных этого сайта. Возможными объектами являются ЗАГОЛОВОК, АВТОР, ИЗДАТЕЛЬ и ТЕМА. Покажите связи между объектами и наделите каждый объект минимум двумя-тремя атрибутами. Укажите тип каждого семантического объекта. Чтобы проект не слишком разрастался, предположим, что учет нужен только для книг. Далее
Вопросы к проекту FiredUp
163
ограничьтесь потребностями человека, который точно решил купить книгу, но еще не выбрал, какую. Не рассматривайте заказ клиента, выполнение заказа, заказ на поставку и другие подобные деловые операции.
Вопросы к проекту FiredUp
Рассмотрим ситуацию, обсуждаемую в конце глав 1 и 2. Предположим, что фирма FiredUp разработала линию из трех горелок: FiredNow, FiredAlways и FiredAtCamp. Предположим далее, что фирма продает запасные части для каждого типа горелок, а также производит их ремонт. В одних случаях ремонт является бесплатным, поскольку выполняется в течение гарантийного срока, в других случаях взимается только стоимость деталей, в третьих взимается стоимость деталей и работы. Фирма FiredUp желает вести учет всех этих данных. Когда владельцев фирмы спросили о подробностях, они составили следующий список:
КЛИЕНТ: Имя, Улица, Дом, Квартира, Город, Штат, Индекс, Страна, ЭлектронныйАдрес, Телефон
ГОРЕЛКА: СерийныйНомер, Тип, ДатаИзготовления, ИнициалыПроверяющего
СЧЕТ-ФАКТУРА: НомерСчета, Дата, Клиент (со списком проданных товаров и указанием их стоимости), Сумма
РЕМОНТ: НомерРемонта, Клиент, Горелка, Описание (со списком деталей, использованных при ремонте, и указанием их стоимости, если таковая взимается), Сумма
ДЕТАЛЬ: Номер, Описание, Стоимость, Цена
1.	Создайте набор семантических объектов для базы данных фирмы FiredUp. Задайте на свое усмотрение минимальное и максимальное кардинальные числа для всех атрибутов. Обоснуйте каждое кардинальное число. Используйте столько типов семантических объектов, сколько считаете нужным, но не используйте подтипы. (Эта задача окажется проще, если вы загрузите Tabledesigner — средство для рисования семантических объектных диаграмм, которое описано в приложении Б. Используйте это средство для определения семантических объектов и распечатки отчетов об объектах, которые вы будете сдавать преподавателю. Однако прежде чем делать это, ознакомьтесь с приложением Б и посоветуйтесь с преподавателем.)
2.	Модифицируйте объектные диаграммы из вашего ответа на вопрос 1, представив объекты СЧЕТ-ФАКТУРА и РЕМОНТ в виде подтипов. При каких условиях эта структура окажется лучше, чем предыдущая?
3.	Предположим, что фирма FiredUp хочет записывать домашний и мобильный телефон, факс и несколько адресов электронной почты своих пользователей. Модифицируйте ответы на предыдущие вопросы, введя множественные значения атрибутов Телефон и ЭлектронныйАдрес.
4.	Предположим, что фирма FiredUp разрабатывает различные версии одной и той же горелки, то есть FiredNow V. 1, FiredNow V.2 и т. д. Модифицируйте необходимым образом свой ответ на вопрос 1, чтобы учесть эту ситуацию.
164
Глава 4. Семантическая объектная модель
5.	Когда пользователей спрашивают о том, какие данные они хотели бы отслеживать, они не всегда помнят все, что им нужно. Пользуясь своими знаниями об операциях малого предприятия, составьте список семантических объектов, которые они могли забыть. Не забудьте указать связи между объектами. Что бы вы сказали по поводу необходимости каких-либо из этих дополнительных данных для FiredUp?
6.	Если вы ответили на вопросы к проекту FiredUp в конце главы 3, сравните модель «сущность—связь», разработанную для предыдущей главы, с семантической объектной моделью, разработанной вами только что. Какую из моделей вы предпочтете? Какая из моделей, как вам кажется, будет более понятной для сотрудников FiredUp?
Часть III
Проектирование баз данных
Часть III книги посвящена вопросам проектирования баз данных. Глава 5 знакомит читателя с реляционной моделью и нормализацией. Важность реляционной модели состоит в том, что она является стандартом, в терминах которого выражена структура большинства баз данных; кроме того, на этой модели основано большинство современных СУБД. Нормализация важна тем, что она позволяет проверить качество реляционной структуры.
В главе 6 на основе материала, изложенного в главе 5, рассматривается процесс преобразования модели «сущность—связь» в независимую от СУБД реляционную структуру. Глава 7 описывает создание подобной структуры, исходя из семантической объектной модели данных.
Глава 5
Реляционная модель и нормализация
Реляционная модель важна по двум причинам. Во-первых, поскольку конструкции реляционной модели имеют широкий и общий характер, она позволяет описывать структуры баз данных независимым от СУБД образом. Во-вторых, реляционная модель является основой почти всех СУБД. Таким образом, понимание принципов этой модели существенно.
В этой главе даются основы реляционной модели (relational model) и объясняются фундаментальные принципы нормализации (normalization). Мы начнем с того факта, что не все отношения одинаковы: некоторые из них более предпочтительны, чем другие. Нормализация — это процесс преобразования отношения, имеющего некоторые недостатки, в отношение, которое этих недостатков не имеет. Что еще более важно, нормализацию можно использовать как критерий для определения желательности и правильности отношений. Вопрос о том, что такое хорошо структурированное отношение, был предметом многочисленных теоретических исследований. Термин нормализация обязан своим появлением одному из пионеров технологии баз данных, Э. Ф. Кодду (Е. F. Codd), который определил различные нормальные формы (normal forms) отношений. В этой главе мы обсудим нормализацию, включая результаты теорем, важных и полезных для разработчиков баз данных. Доказательства этих теорем и формальное, более тщательное исследование данного вопроса можно найти в работе Дейта и Ульмана (С. J. Date hJ. D. Ullman)1.
Реляционная модель
Отношение (relation) — это двумерная таблица. Каждая строка в таблице содержит данные, относящиеся к некоторой вещи или какой-то ее части. Каждый столбец таблицы описывает какой-либо атрибут этой вещи. Иногда строки называются кортежами (tuples), а столбцы — атрибутами (attributes).
1 С. J. Date, An Introduction to Database Systems, Sixth Edition (Reading, MA: Addison-Wesley, 1994); и J. D. Ullman and Jennifer Widom, A First Course in Database Systems (Upper Saddle River, NJ: Prentice Hall, 1997).
Реляционная модель
167
Термины отношение, кортеж и атрибут пришли из реляционной математики, которая является теоретическим источником этой модели. Профессионалы MIS предпочитают употреблять аналогичные термины файл (file), запись (record) и поле (field), а большинство пользователей находят более удобными термины таблица (table), строка (row) и столбец (column). Все эти термины сведены в таблицу на рис. 5.1.
Реляционная модель	Программист	Пользователь
Отношение	Файл	Таблица
Кортеж (строка)	Запись	Строка
Атрибут	Поле	Столбец
Рис. 5.1. Эквивалентная терминология реляционной модели
Чтобы таблица была отношением, она должна удовлетворять определенным ограничениям1. Во-первых, значения в ячейках таблицы должны быть одиночными — ни повторяющиеся группы, ни массивы не допускаются1 2. Все записи в столбце должны быть одного типа. Например, если третий столбец первой строки таблицы содержит номер сотрудника, то и во всех остальных строках таблицы третий столбец также должен содержать номер сотрудника. Каждый столбец имеет уникальное имя; порядок столбцов в таблице несуществен. Наконец, в отношении не может быть двух одинаковых строк, и порядок строк не имеет значения.
На рис. 5.2 представлен пример отношения. Отношение имеет семь строк, в каждой из которых четыре столбца. Если бы мы расположили столбцы в ином порядке (скажем, поместив ТабельныйНомер в крайний левый столбец) или переставили бы строки (например, по возрастанию значения столбца Возраст), мы получили бы эквивалентное отношение.
	Атрибут 1 Имя	Атрибут 2 Возраст	Атрибут 3 Атрибут 4 Пол ТабельныйНомер	
Кортеж 1	Андерсон	21	Ж	010110
Кортеж 2	Деккер	22	М	010100
	Гловер	22	м	101000
	Джексон	21	ж	201100
	Мур	19	м	111100
	Наката	20	ж	111101
Кортеж 7	Смит	19	м	111111
Рис. 5.2. Отношение СОТРУДНИК
1 Е. F. Codd, «А relational Model of Data for Large Shared Databanks», Communications of the ACM, июнь 1970, c. 377-387.
2 Это не означает, что значения должны быть фиксированной длины. Текстовое поле с записью переменной длины, например, является вполне допустимым значением. Однако ячейка может содержать лишь одно такое значение.
168
Глава 5. Реляционная модель и нормализация
Рисунок 5.2 представляет отдельный экземпляр отношения. Обобщенный формат отношения — СОТРУДНИК (Имя, Возраст, Пол, ТабельныйНомер) — называется структурой отношения, и именно это большинство людей имеет в виду, используя термин отношение.
Чтобы понять, что такое нормализация, мы должны определить два важных термина: функциональная зависимость и ключ.
Функциональные зависимости
Функциональная зависимость (functional dependency) — это связь между атрибутами. Предположим, что если мы знаем значение одного атрибута, то можем вычислить (или найти) значение другого атрибута. Например, если нам известен номер счета клиента, то мы можем определить состояние его счета. В таком случае мы можем сказать, что атрибут СостояниеСчетаКлиента функционально зависит от атрибута НомерСчетаКлиента.
Говоря более общим языком, атрибут Y функционально зависит от атрибута X, если значение X определяет значение Y. Другими словами, если нам известно значение X, мы можем определить значение Y.
Уравнения выражают функциональные зависимости. Например, если мы знаем цену и количество приобретенного товара, мы можем определить стоимость покупки по следующей формуле:
Стоимость = Цена х Количество
В этом случае мы могли бы сказать, что атрибут Стоимость функционально зависит от атрибутов Цена и Количество.
Функциональные зависимости между атрибутами в отношении обычно не выражаются уравнениями. Пусть, например, каждому студенту присвоен уникальный идентификационный номер, и у каждого студента есть одна и только одна специальность. Имея номер студента, мы можем узнать его специальность, поэтому атрибут Специальность функционально зависит от атрибута НомерСтудента. Или рассмотрим компьютеры в вычислительной лаборатории. Каждый компьютер имеет конкретный размер основной памяти, поэтому атрибут ОбъемПамяти функционально зависит от атрибута СерийныйНомерКомпьютера.
В отличие от случая с уравнением, такие функциональные зависимости нельзя разрешить при помощи арифметики; вместо этого они хранятся в базе данных. Фактически, можно утверждать, что базу данных стоит иметь только ради хранения и выдачи функциональных зависимостей.
Функциональные зависимости обозначаются следующим образом:
НомерСтудента > Специальность
СерийныйНомерКомпьютера > ОбъемПамяти
Первое выражение читается так: «атрибут НомерСтудента функционально определяет атрибут Специальность», «атрибут НомерСтудента определяет атрибут Специальность» или «атрибут Специальность зависит от атрибута НомерСтудента». Атрибуты по правую сторону от стрелки называются детерминантами (determinants).
Как уже говорилось, если номер студента определяет специальность, то каждому номеру студента соответствует только одна специальность. Между тем, од
Реляционная модель
169
ной и той же специальности может соответствовать более одного номера студента. Пусть студент под номером 123 специализируется на бухгалтерском учете. Тогда для любого отношения, где присутствуют столбцы НомерСтудента и Специальность, выполнится условие: если НомерСтудента = 123, то Специальность = Бух-галтерскийУчет. Обратное, однако, неверно: если Специальность = БухгалтерскийУчет, то атрибут НомерСтудента может принимать различные значения, так как на бухгалтерском учете может специализироваться много студентов. Следовательно, мы можем сказать, что связь атрибутов НомерСтудента и Специальность имеет вид N:l. В общем случае можно утверждать, что если А определяет В, связь между значениями А и В имеет вид N:l.
В функциональные зависимости могут быть вовлечены группы атрибутов. Рассмотрим отношение ОЦЕНКИ (НомерСтудента, Дисциплина, Оценка). Комбинация номера студента и дисциплины определяет оценку. Такая функциональная зависимость записывается следующим образом:
(НомерСтудента, Дисциплина) > Оценка
Заметьте, что для определения оценки требуется как номер студента, так и дисциплина. Мы не можем разделить эту функциональную зависимость, поскольку ни номер студента, ни дисциплина не определяют оценку сами по себе.
Обратите внимание на следующее различие. Если X > (Y, Z), то X > Y и X > Z. Например, если НомерСтудента > (ИмяСтудента, Специальность), то НомерСтудента > ИмяСтудента и НомерСтудента >Специальность. Но если (X, Y) >Z, то в общем случае неверно, что X > Y или X > Z. Следовательно, если (НомерСтудента, Дисциплина) > Оценка, то ни номер студента, ни дисциплина как таковые оценку не определяют.
Ключи
Ключ (key) — это группа из одного или более атрибутов, которая уникальным образом идентифицирует строку. Рассмотрим отношение СЕКЦИЯ (рис. 5.3), имеющее атрибуты НомерСтудента, Секция и Плата. Строка этого отношения содержит информацию о том, что студент посещает определенную секцию за определенную плату. Предположим, что студент одновременно не может посещать более одной секции. В этом случае значение атрибута НомерСтудента идентифицирует единственную строку, поэтому данный атрибут является ключом.
СЕКЦИЯ (НомерСтудента, Секция, Плата)
Ключ: НомерСтудента
Sample Data
НомерСтудента Секция Плата
100	Лыжи	200
150	Плавание	50
175	Сквош	50
200	Плавание	50
Рис. 5.3. Отношение СЕКЦИЯ
170
Глава 5. Реляционная модель и нормализация
Ключи могут также составляться из нескольких атрибутов. Например, если студентам разрешено одновременно посещать более одной секции, то один и тот же номер студента может появиться в разных строках таблицы, поэтому атрибут НомерСтудента не будет уникальным образом определять строку. Для этого потребуется какое-то сочетание атрибутов; возможно, это будет комбинация (НомерСтудента, Секция).
Попутно отметим, что в предыдущем абзаце затронут тонкий, но весьма важный аспект. Являются ли атрибуты ключами и являются ли они функционально зависимыми — это определяется не абстрактным набором правил, а моделями, присутствующими в воображении пользователей, а также деловым регламентом организации, использующей базу данных. Что в приведенном выше примере является ключом — НомерСтудента, комбинация (НомерСтудента, Секция) или какое-то еще сочетание атрибутов, — целиком и полностью определяется тем, как представляют себе ситуацию люди, работающие в организации, которая использует базу данных. Ответы на эти вопросы мы должны получить от пользователей. По ходу дальнейшего изложения имейте в виду, что все наши предположения о функциональных зависимостях, ключах, ограничениях и тому подобных вещах определяются моделями в воображении пользователей.
Допустим, в ходе опроса пользователей мы выяснили, что студентам разрешено одновременно быть записанными в несколько спортивных секций. Эта ситуация отражена в отношении СЕКЦИИ (рис. 5.4). Как мы отметили, НомерСтудента не является ключом этого отношения. В самом деле, студент с номером 100 посещает секцию гольфа и секцию лыж, и атрибут НомерСтудента со значением 100 появляется в двух различных строках. Фактически, для этого отношения ни один атрибут сам по себе не является ключом, то есть ключ должен состоять из двух или более атрибутов.
НомерСтудента Секция Плата
100	Лыжи	200
100	Гольф	65
150	Плавание	50
175	Сквош	50
175	Плавание	50
200	Плавание	50
200	Гольф	65
Рис. 5.4. Отношение СЕКЦИИ
Рассмотрим, какие комбинации из двух атрибутов возможны для данной таблицы. Таких комбинаций имеется три: (НомерСтудента, Секция), (НомерСтудента, Плата) и (Секция, Плата). Является ли какая-либо из этих комбинаций ключом? Чтобы быть ключом, группа атрибутов должна уникальным образом идентифицировать строку. Опять-таки, ответы на подобные вопросы мы должны получить от пользователей. Наше решение не должно основываться на выборочных дан
Реляционная модели
171
ных, подобных тем, которые приведены на рис. 5.4, или на наших собственных предположениях.
Допустим, поговорив с пользователями, мы пришли к выводу, что плата за абонемент в различных секциях может совпадать. Поскольку это так, комбинация (НомерСтудента, Плата) не может уникальным образом определить строку. Например, студент с номером 100 может посещать две различных секции, каждая из которых стоит $200. Это означает, что комбинация (100, $200) возникла бы в таблице дважды, поэтому такая комбинация не может быть ключом.
Может ли быть ключом сочетание (Секция, Плата)? Может ли комбинация (Лыжи, $200) уникальным образом определить строку? Нет, не может, поскольку секцию лыж может посещать много студентов. А как насчет сочетания (Номер-Студента, Секция)? Имея те сведения, которые мы получили от пользователей, можно ли сказать, что комбинация значения атрибутов НомерСтудента и Секция уникальным образом определяет строку таблицы? Да, можно, пока от нас не требуется вести записи об истории посещения секций студентом. Иными словами, должна ли эта таблица содержать сведения только о тех секциях, которые студент посещает на данный момент, или же в ней должны быть записи о секциях, которые студент посещал ранее?
И снова, чтобы ответить на этот вопрос, мы должны обратиться к пользователям. Предположим, мы выяснили, что необходимо хранить сведения только о посещаемых в настоящий момент секциях. Тогда комбинация (НомерСтудента, Секция) может уникальным образом определить строку отношения и, следовательно, эта комбинация является ключом данного отношения. Если бы пользователи указали, что должны также храниться записи о секциях, которые посещались в прошлом, то отношение на рис. 5.3 имело бы дублирующиеся строки. Поскольку это недопустимо по определению отношения, нам пришлось бы добавить другие атрибуты, например атрибут Дата.
Это приводит нас к важному заключению. Каждое отношение имеет минимум один ключ. Это утверждение должно быть верным, поскольку ни одно отношение не может иметь одинаковых строк, и, следовательно, в крайнем случае ключ будет состоять из всех атрибутов отношения.
Функциональные зависимости, ключи и уникальность
У многих студентов возникает путаница с понятиями функиональной зависимости, ключа и уникальности. Чтобы избежать этой путаницы, уясните себе следующее: детерминант функциональной зависимости может в отношении быть уникальным или неуникальным. Если нам известно, что А определяет В и что А и В находятся в одном и том же отношении, мы все равно не знаем, является ли А уникальным в этом отношении. Мы знаем только то, что А определяет В.
Например, в отношении СЕКЦИИ атрибут Секция функционально определяет атрибут Плата, но название конкретной секции может, тем не менее, фигурировать в нескольких строках отношения. Функциональная зависимость говорит
172
Глава 5. Реляционная модель и нормализация
только о том, что везде, где атрибуту Секция сопутствует атрибут Плата, конкретному значению атрибута Секция всегда соответствует одно и то же значение атрибута Плата. То есть абонемент в секцию лыж всегда стоит $200, независимо от того, сколько раз секция лыж фигурирует в таблице.
В отличие от детерминантов, ключи всегда являются уникальными. Ключ функционально определяет целую строку. Если бы значения ключей дублировались, дублировался бы и весь кортеж. Но это недопустимо, поскольку по определению строки в отношении должны быть уникальными. Таким образом, когда мы говорим, что атрибут (или комбинация атрибутов) является ключом, мы знаем, что этот атрибут или комбинация будут уникальными. Например, если сочетание (НомерСтудента, Секция) является ключом, то сочетание (100, Лыжи) может появиться в таблице только один раз.
Чтобы проверить, как вы усвоили эти понятия, попытайтесь объяснить, почему в отношении СЕКЦИЯ (см. рис. 5.3) НомерСтудента является и детерминантом, и ключом, а Секция является только детерминантом, но не ключом. (Имейте в виду, что отношение на рис. 5.3 отражает политику, когда студентам не разрешается одновременно посещать более одной секции.)
Нормализация
К сожалению, не все отношения одинаково желательны. Таблица, отвечающая минимальному определению отношения, может иметь неэффективную или неподходящую структуру. Для некоторых отношений изменение данных может привести к нежелательным последствиям, называемым аномалиями модификации (modification anomalies). Аномалии могут быть устранены путем разбиения исходного отношения на два или более новых отношения. В большинстве случаев переопределенные, или нормализованные, отношения являются более предпочтительными.
Аномалии модификации
Рассмотрим опять отношение СЕКЦИЯ на рис. 5.3. Если мы удалим строку, где записаны данные о студенте с номером 100, мы потеряем не только информацию о том, что студент с номером 100 является лыжником, но и тот факт, что абонемент в секцию лыж стоит $200. Это называется аномалией удаления (deletion anomaly) — то есть, удаляя факты, относящиеся к одной сущности (студент с номером 100 является лыжником), мы непроизвольно удаляем факты, относящиеся к другой сущности (плата за абонемент в секцию лыж составляет $200). Выполнив одну операцию удаления, мы теряем информацию о двух сущностях.
На примере того же самого отношения можно продемонстрировать аномалию вставки (insertion anomaly). Предположим, мы хотим записать в базу данных тот факт, что абонемент в секцию подводного плавания стоит $175, однако мы не можем ввести эти данные в отношение СЕКЦИЯ, пока хотя бы один студент не запишется в секцию подводного плавания. Это ограничение выглядит глупо.
Нормализация
173
Почему для того, чтобы указать стоимость абонемента, требуется ждать, когда кто-нибудь запишется в секцию? Это ограничение называется аномалией вставки. Суть его в том, что мы не можем записать в таблицу некоторый факт об одной сущности, не указав дополнительно некоторый факт о другой сущности.
Отношение в табл. 5.3 может быть использовано в некоторых приложениях, но оно имеет явные проблемы. Мы можем устранить как аномалию удаления, так и аномалию вставки, разделив отношение СЕКЦИЯ на два отношения, каждое из которых будет содержать информацию на определенную тему. Например, в одно отношение мы поместим атрибуты НомерСтудента и Секция (назовем это отношение СТУДЕНТ-СЕКЦИЯ), а в другое — атрибуты Секция и Плата (назовем это отношение СЕКЦИЯ-ПЛАТА). Эти два отношения с данными из нашего примера изображены на рис. 5.5.
СЕКЦИЯ (НомерСтудента, Секция, Плата)
Ключ: НомерСтудента
НомерСтудента Секция
100	Лыжи
150	Плавание
175	Сквош
200	Плавание
СЕКЦИЯ-ПЛАТА (Секция, Плата)
Ключ: Секция
Секция Плата
Лыжи	200
Плавание	50
Сквош	50
Рис. 5.5. Разбиение отношения СЕКЦИЯ на два отношения
Теперь, если мы удалим запись о студенте с номером 100 из таблицы СТУДЕНТ-СЕКЦИЯ, мы уже не потеряем тот факт, что абонемент в секцию лыж стоит $200. Более того, мы можем добавить в таблицу СЕКЦИЯ-ПЛАТА секцию подводного плавания с указанием стоимости абонемента, не дожидаясь, пока кто-либо запишется в эту секцию. Таким образом, аномалии удаления и вставки устранены.
Разбиение одного отношения на два имеет, однако, один недостаток. Предположим, что студент хочет записаться в несуществующую секцию. Например, студент с номером 250 хочет записаться в секцию ракетбола. Мы можем вставить соответствующую строку в отношение СТУДЕНТ-СЕКЦИЯ (строка будет содержать запись (250, Ракетбол)), но следует ли это делать? Стоит ли разрешать студенту записываться в секцию, которая отсутствует в отношении СЕКЦИЯ-ПЛАТА? Другими словами, должна ли система каким-либо образом препятствовать добавлению строк в таблицу СТУДЕНТ-СЕКЦИЯ, если название соответствующей секции отсутствует в таблице СЕКЦИЯ-ПЛАТА? Ответ на этот вопрос содержится в требованиях пользователей. Если такое действие должно быть запрещено, данное ограничение (а это не что иное, как статья делового регламента) необходимо внести в схему базы данных. Позже, на стадии реализации, выполнение этого ограничения будет возложено на СУБД, если используемая СУБД предоставляет такую возможность. Если нет, то соблюдение ограничения должно обеспечиваться прикладными программами.
Допустим, пользователи указывают, что секции могут существовать и до того, как кто-либо в них запишется, однако студент не может записаться в секцию, для которой не указан размер платы за абонемент (то есть в секцию, данные
174
Глава 5. Реляционная модель и нормализация
о которой отсутствуют в таблице СЕКЦИЯ-ПЛАТА). При проектировании базы данных мы можем задокументировать это ограничение любым из следующих способов: «множество значений атрибута Секция в таблице СТУДЕНТ-СЕКЦИЯ является подмножеством множества значений атрибута Секция в таблице СЕКЦИЯ-ПЛАТА», «СТУДЕНТ-СЕКЦИЯ [Секция] является подмножеством СЕКЦИЯ-ПЛАТА [Секция]» либо «СТУДЕНТ-СЕКЦИЯ [Секция] с СЕКЦИЯ-ПЛАТА [Секция]».
Квадратные скобки в этой записи обозначают столбец данных, извлекаемый иэ отношения. Смысл этих выражений в том, что атрибут Секция в отношении СТУДЕНТ-СЕКЦИЯ может принимать только те значения, которые имеет атрибут Секция в отношении СЕКЦИЯ-ПЛАТА. Это означает также, что прежде чем ввести название какой-то секции в отношение СТУДЕНТ-СЕКЦИЯ, мы должны проверить, что такое название уже существует в отношении СЕКЦИЯ-ПЛАТА. Ограничения, подобные этому, называются ограничениями ссылочной целостности (referential integrity constraints), или ограничениями целостности по внешнему ключу (interrelation constraints).
Суть нормализации
Аномалии, присутствующие в отношении на рис. 5.3, можно интуитивно описать следующим образом: проблемы возникают из-за того, что отношение СЕКЦИЯ содержит факты, относящиеся к двум различным темам.
1. Кто из студентов какую секцию посещает.
2. Какова плата за абонемент в каждой из секций.
Когда мы добавляем новую строку, нам приходится добавлять информацию, затрагивающую две различные темы; точно так же, когда мы удаляем строку, мы вынуждены удалять данные, относящиеся сразу к двум темам.
Помните, что учительница родного языка и литературы говорила вам, что абзац должен иметь только одну тему? Если абзац содержал более одной темы, вас учили разбивать его на два или более абзаца таким образом, чтобы каждый из получившихся абзацев содержал ровно одну тему. Аналогичные высказывания справедливы и для отношений. Каждое нормализованное отношение имеет од-ну-единственную тему. Любое отношение, содержащее две или более темы, следует разбить на два или более отношения, каждое из которых будет содержать одну тему. Этот процесс составляет суть нормализации. Когда мы обнаруживаем отношение с аномалиями модификации, мы устраняем эти аномалии, разбивая отношение на два или более новых отношения, каждое из которых содержит факты, относящиеся к одной теме.
Однако не стоит забывать, что всякий раз, когда мы разбиваем отношение, мы, возможно, порождаем ограничение ссылочной целостности. Поэтому следует обязательно проверять наличие таких ограничений каждый раз при разбиении отношения на два или более новых.
В оставшейся части этой главы вам предстоит узнать несколько правил, относящихся к нормализации. Все эти правила представляют собой частные случаи только что описанного процесса.
Нормализация
175
Классы отношений
Отношения можно классифицировать по типам аномалий модификации, которым они подвержены. В 1970-х годах теоретики реляционных баз данных постепенно сокращали количество этих типов. Кто-то находил аномалию, классифицировал ее и думал, как предотвратить ее возникновение. Каждый раз, когда это происходило, критерии построения отношений совершенствовались. Эти классы отношений и способы предотвращения аномалий называются нормальными формами (normal forms). В зависимости от своей структуры, отношение может быть в первой, во второй или в какой-либо другой нормальной форме.
В своей работе, последовавшей за эпохальной статьей 1970 г., Кодд и другие определили первую, вторую и третью нормальные формы (1НФ, 2НФ и ЗНФ). Позднее была введена нормальная форма Бойса-Кодда (НФБК), а затем были определены четвертая и пятая нормальные формы. Как показывает рис. 5.6, эти нормальные формы являются вложенными. То есть отношение во второй нормальной форме является также отношением в первой нормальной форме, а отношение в 5НФ (пятая нормальная форма) находится одновременно в 4НФ, НФБК, ЗНФ, 2НФ и 1НФ.
Первая нормальная форма (1НФ)--"''Х
Вторая нормальная форма (2НФ)-\
Третья нормальная форма (ЗНФ)-Т~	\
Нормальная форма Бойса-Кодда (НФБК) 1	I I
Четвертая нормальная форма (4НФ)	y /	/
Пятая нормальная форма (5НФ)	\	/
•Доменно-ключевая нормальная форма (ДКНФ)
Рис. 5.6. Взаимосвязь нормальных форм
Эти нормальные формы помогали, но у них было и серьезное ограничение. Не было теории, гарантирующей, что какая-либо из этих форм устранит все аномалии: каждая форма могла устранить только определенные их виды. Эта ситуация разрешилась в 1981 г., когда Р. Фагин (R. Fagin) ввел новую нормальную форму, которую он назвал доменно-ключевой нормальной формой, или ДКНФ (domain/key normal form, DK/NF). В своей важной статье Фагин показал, что отношение в ДКНФ свободно от всех аномалий модификации, независимо от их типа1. Он также показал, что любое отношение, свободное от аномалий модификации, должно находиться в ДКНФ.
До введения ДКНФ теоретикам реляционных баз данных приходилось продолжать поиск все новых и новых аномалий и нормальных форм. Доказательство Фагина упростило ситуацию. Если мы можем привести отношение к ДКНФ,
1 R. Fagin, «А Normal Form for Relational Databases That Is Based On Domains and Keys», A CM Transactions on Database Systems, сентябрь 1981, c. 387-415.
176
Глава 5. Реляционная модель и нормализация
мы можем быть уверены, что в нем не будет аномалий модификации. Вся загвоздка в том, как привести отношение к ДКНФ.
Нормальные формы от первой до пятой
О любой таблице данных, удовлетворяющей определению отношения, говорят, что она находится в первой нормальной форме (first normal form, INF). Вспомните, что для того, чтобы таблица была отношением, должно выполняться следующее: ячейки таблицы должны содержать одиночные значения и в качестве значений не допускаются ни повторяющиеся группы, ни массивы. Все записи в одном столбце (атрибуте) должны иметь один и тот же тип. Каждый столбец должен иметь уникальное имя, но порядок следования столбцов в таблице несуществен. Наконец, в таблице не может быть двух одинаковых строк, и порядок следования строк несуществен.
Отношение на рис. 5.4 находится в первой нормальной форме. Как мы видели, однако, отношения в первой нормальной форме могут иметь аномалии модификации. Чтобы устранить эти аномалии, мы разбиваем отношение на два или более новых отношения. Когда мы делаем это, новые отношения оказываются в некоторой другой нормальной форме, а в какой именно, зависит от того, какие аномалии мы устранили, а также от того, каким аномалиям подвержены получившиеся отношения.
Вторая нормальная форма (2НФ)
Чтобы понять, что такое вторая нормальная форма, рассмотрим отношение СЕКЦИИ на рис. 5.4. Это отношение имеет аномалии модификации, подобные тем, которые мы рассматривали ранее. Если мы удалим строку с данными о студенте с номером 175, мы потеряем тот факт, что абонемент в секцию сквоша стоит $50. Кроме того, мы не можем ввести информацию о секции, пока в эту секцию не запишется хотя бы один студент. Таким образом, это отношение подвержено как аномалии удаления, так и аномалии вставки.
Проблема с этим отношением состоит в том, что оно содержит зависимость, затрагивающую только часть ключа. Ключом является комбинация (НомерСтудента, Секция), но отношение содержит зависимость Секция > Плата. Детерминант этой зависимости (Секция) представляет собой лишь часть ключа (НомерСтудента, Секция). В этом случае мы можем сказать, что атрибут Плата частично зависит от ключа таблицы. Аномалий модификации не было бы, если бы Плата зависела от всего ключа. Чтобы устранить эти аномалии, мы должны разделить отношение на два отношения.
Данный пример приводит нас к определению второй нормальной формы (second normal form, 2NF): отношение находится во второй нормальной форме, если все его неключевые атрибуты зависят от всего ключа. В соответствии с этим определением, если отношение имеет в качестве ключа одиночный атрибут, то оно автоматически находится во второй нормальной форме. Поскольку ключ является одиночным атрибутом, то по умолчанию каждый неключевой атрибут за
Нормальные формы от первой до пятой.
177
висит от всего ключа, и частичных зависимостей быть не может. Таким образом, вторая нормальная форма представляет интерес только для тех отношений, которые имеют композитные ключи.
Отношение СЕКЦИИ может быть разбито на два отношения во второй нормальной форме. Это те самые отношения, которые изображены на рис. 5.5, а именно СТУДЕНТ-СЕКЦИЯ и СЕКЦИЯ-ПЛАТА. Мы знаем, что новые отношения находятся во второй нормальной форме, поскольку оба они имеют в качестве ключей одиночные атрибуты.
Третья нормальная форма (ЗНФ)
Отношения во второй нормальной форме также могут иметь аномалии. Рассмотрим отношение ПРОЖИВАНИЕ на рис. 5.7, а. Ключом здесь является НомерСтудента, и имеются функциональные зависимости НомерСтудента > Общежитие и Общежитие > Плата. Эти зависимости возникают потому, что каждый студент живет только в одном общежитии, и каждое общежитие взимает со всех проживающих в нем студентов одинаковую плату. Например, каждый живущий в общежитии Рэндольф-Холл платит $3200 за квартал.
ПРОЖИВАНИЕ (НомерСтудента, Общежитие, Плата)
Ключ: НомерСтудента
Функциональные зависимости:Общежитие -> Плата
НомерСтудента -> Общежитие -> Плата
НомерСтудента Общежитие Плата
100	Рэндольф	3200
150	Ингерсол	31 ОС
200	Рэндольф	320С
250	Питкин	31 ОС
300	Рэндольф	3200
а
СТУДЕНТ-ПРОЖИВАНИЕ (НомерСтудента, Общежитие) Ключ: НомерСтудента
НомерСтудента Общежитие
100	Рэндольф
150	Ингерсол
200	Рэндольф
250	Питкин
300	Рэндольф
ОБЩЕЖИТИЕ-ПЛАТА (Общежитие, Плата) Ключ: Общежитие
Общежитие Плата
Рэндольф	3200
Ингерсол	3100
Рэндольф	3200
Питкин	3100
Рэндольф	3200
б
Рис. 5.7. Устранение транзитивной зависимости: а — отношение с транзитивной зависимостью; б — два отношения, не имеющих транзитивных зависимостей
178
Глава 5. Реляционная модель и нормализация
Поскольку НомерСтудента определяет атрибут Общежитие, а Общежитие определяет атрибут Плата, то косвенным образом НомерСтудента > Плата. Такая структура функциональных зависимостей называется транзитивной зависимостью (transitive dependence), поскольку атрибут НомерСтудента определяет атрибут Плата через атрибут Общежитие.
Ключом отношения ПРОЖИВАНИЕ является НомерСтудента, который является одиночным атрибутом, и, следовательно, отношение находится во второй нормальной форме (и Общежитие, и Плата определяются атрибутом НомерСтудента). Несмотря на это, отношение ПРОЖИВАНИЕ имеет аномалии, обусловленные транзитивной зависимостью.
Что произойдет, если мы удалим вторую строку отношения на рис. 5.7, а? Мы потеряем не только тот факт, что студент № 150 живет в Ингерсолл-Холле, но и тот факт, что проживание в этом общежитии стоит $3100. Это аномалия удаления. А как мы можем записать тот факт, что плата за проживание в Кэр-ригг-Холле составляет $3500? Никак, пока туда не решит вселиться хотя бы один студент. Это аномалия вставки.
Чтобы удалить аномалии из отношения во второй нормальной форме, необходимо устранить транзитивную зависимость, что приводит нас к определению третьей нормальной формы (third normail form, 3NF): отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и не имеет транзитивных зависимостей.
Отношение ПРОЖИВАНИЕ можно разделить на два отношения в третьей нормальной форме. На рис. 5.7, б мы видим два отношения, получившиеся в результате этой операции: СТУДЕНТ-ПРОЖИВАНИЕ (НомерСтудента, Общежитие) и ОБЩЕЖИТИЕ-ПЛАТА (Общежитие, Плата).
Отношение СЕКЦИЯ на рис. 5.3 также содержит транзитивную зависимость. В этом отношении НомерСтудента определяет атрибут Секция, а Секция определяет атрибут Плата. Поэтому отношение СЕКЦИЯ не находится в третьей нормальной форме. Разбиение данного отношения на отношения СТУДЕНТ-СЕКЦИЯ (НомерСтудента, Секция) и СЕКЦИЯ-ПЛАТА (Секция, Плата) устраняет аномалии.
Нормальная форма Бойса-Кодда (НФБК)
К сожалению, даже отношения в третьей нормальной форме могут иметь аномалии. Рассмотрим отношение КОНСУЛЬТАНТ (рис. 5.8, а). Пусть требования к этому отношению таковы:
1.	Студент может иметь одну или несколько специальностей.
2.	Консультантами по одному и тому же предмету могут быть несколько преподавателей.
3.	Каждый преподаватель может быть консультантом только по одной специальности.
Будем также предполагать, что у преподавателей не может быть одинаковых фамилий.
Нормальные формы от первой до пятой ,	179
КОНСУЛЬТАНТ (НомерСтудента, Специальность, Преподаватель)
Ключ (первичный): (НомерСтудента, Специальность)
Ключ (вторичный): (НомерСтудента, Преподаватель)
Функциональные
зависимости: Преподаватель -> Специальность
НомерСтудента Специальность		Преподаватель
100	Математика	Коши
150	Психология	Юнг
200	Математика	Риман
250	Математика	Коши
300	Рэндольф	Перле
300	Психология	Риман
а
СТУДЕНТ-КОНСУЛЬТАНТ	КОНСУЛЬТАНТ-ПРЕДМЕТ (НомерСтудента, Преподаватель) Ключ: НомерСтудента, Преподаватель	Ключ: Преподаватель >*' НомерСтудента Преподаватель	Консультант	Предмет т	. .... . .					
г	100	Коши		Коши	Математика
	150	Юнг		Юнг	Психология
	200	Риман •		Риман	Математика
	250	Коши		Перле	Психология
	300	Перле			
	300	Риман			
			б		
Рис. 5.8. Нормальная форма Бойса-Кодда: а — отношение, находящееся в ЗНФ, но не в НФБК; б — два отношения, находящиеся в НФБК
Поскольку студенты могут специализироваться в нескольких областях, атрибут НомерСтудента не определяет атрибут Специальность. Более того, так как студент может иметь несколько консультантов, НомерСтудента не определяет и атрибут Преподаватель. Таким образом, НомерСтудента сам по себе не может быть ключом.
Комбинация (НомерСтудента, Специальность) определяет атрибут Преподаватель, а комбинация (НомерСтудента, Преподаватель) определяет атрибут Специальность. Следовательно, любая из этих комбинаций может быть ключом. Два или более атрибута или группы атрибутов, которые могут быть ключом, называются ключами-кандидатами (candidate keys). Тот из ключей-кандидатов, который выбирается в качестве ключа, называется первичным ключом (primary key).
Кроме ключей-кандидатов, есть еще одна функциональная зависимость, которую следует рассмотреть: атрибут Преподаватель определяет атрибут Специальность (любой из преподавателей является консультантом только по одному предмету; следовательно, зная имя преподавателя, мы можем определить специальность). Таким образом, Преподаватель является детерминантом.
180
Глава 5. Реляционная модель и нормализация
По определению, отношение КОНСУЛЬТАНТ находится в первой нормальной форме. Оно также находится во второй нормальной форме, поскольку не имеет неключевых атрибутов (каждый из атрибутов является частью минимум одного ключа). Наконец, это отношение находится в третьей нормальной форме, так как не имеет транзитивных зависимостей. Тем не менее, несмотря на все это, отношение имеет аномалии модификации.
Пусть студент с номером 300 отчисляется из университета. Если мы удалим строку с информацией о студенте с номером 300, мы потеряем тот факт, что Перле является консультантом по психологии. Это аномалия удаления. Далее, как мы можем записать в базу тот факт, что Кейнс является консультантом по экономике? Никак, пока не появится хотя бы один студент, специализирующийся на экономике. Это аномалия удаления.
Ситуации, подобные только что описанной, приводят нас к определению нормальной формы Бойса-Кодда (Boyce-Codd normal form, BK/NF): отношение находится в НФБК, если каждый детерминант является ключом-кандидатом. Отношение КОНСУЛЬТАНТ не находится в НФБК, поскольку детерминант Преподаватель не является ключом-кандидатом.
Как и в других примерах, отношение КОНСУЛЬТАНТ можно разбить на два отношения, не имеющие аномалий. Например, отношения СТУДЕНТ-КОНСУЛЬТАНТ (НомерСтудента, Преподаватель) и КОНСУЛЬТАНТ-ПРЕДМЕТ (Преподаватель, Специальность) не имеют аномалий.
Отношения в НФБК не имеют аномалий, относящихся к функциональным зависимостям, и некогда казалось, что вопрос с аномалиями модификации на этом исчерпан. Однако вскоре обнаружилось, что аномалии могут быть обусловлены и иными причинами, нежели функциональные зависимости.
Четвертая нормальная форма (4НФ)
Рассмотрим отношение СТУДЕНТ на рис. 5.9, которое отображает связи между студентами, специальностями и секциями. Предположим, что студенты могут иметь несколько специальностей и заниматься в нескольких различных секциях. В таком случае единственным ключом является комбинация (НомерСтудента, Специальность, Секция). Например, студентка с номером 100 специализируется на музыке и бухгалтерском учете и, кроме того, посещает секции плавания и тенниса, а студент с номером 150 специализируется только на математике и занимается бегом.
Какова связь между атрибутами НомерСтудента и Специальность? Это не функциональная зависимость, поскольку у студента может быть несколько специальностей. Одному и тому же значению атрибута НомерСтудента может соответствовать много значений атрибута Специальность. Помимо того, одному и тому же значению атрибута НомерСтудента может соответствовать много значений атрибута Секция.
Такая зависимость атрибутов называется многозначной зависимостью (multivalue dependency). Многозначные зависимости приводят к аномалиям модификации. Для начала обратите внимание на избыточность данных на рис. 5.9.
Нормальные формы от первой до пятой.
181
Студентке с номером 100 посвящено четыре записи, в каждой из которых указана одна из ее специализаций и одна из посещаемых ею секций. Если бы те же данные хранились в меньшем количестве строк (скажем, было бы две строки — одна для музыки и плавания, а другая для бухгалтерского учета и тенниса), это дезориентировало бы пользователей. Получалось бы, что студентка с номером 100 плавает только тогда, когда специализируется на музыке, а в теннис играет только тогда, когда специализируется на бухгалтерском учете. Но такая интерпретация нелогична. Специальности и секции совеершенно независимы друг от друга. Поэтому, чтобы избежать таких неверных заключений, мы храним все сочетания специальностей и секций.
СТУДЕНТ (НомерСтудента, Специальность, Секция) Ключ: (НомерСтудента, Специальность, Секция)
Многозначные
зависимости:	НомерСтудента -> -> Специальность
НомерСтудента -> -> Секция
НомерСтудента Специальность	Секция
100	Музыка	Плавание
100	Бухгалтерский учет	Плавание
100	Музыка	Теннис
100	Бухгалтерский учет	Теннис
150	Математика	Оздоровительный бег
Рис. 5.9. Отношение с многозначными зависимостями
Допустим, что студентка с номером 100 решила записаться в секцию лыж, и поэтому мы добавляем в таблицу строку [100, Музыка, Лыжи], как показано на рис. 5.10, а. В данный момент из отношения можно сделать вывод, что студентка 100 занимается лыжами только как музыкант, но не как бухгалтер. Чтобы данные имели согласованный характер, мы должны добавить столько строк, сколько имеется специальностей, и в каждой из них указать секцию лыж. Таким образом, мы должны добавить строку [100, Бухгалтерский учет, Лыжи], как показано на рис. 5.10, б. Это аномалия обновления: требуется слишком много модификаций, чтобы внести одно простое изменение.
Вообще говоря, многозначная зависимость существует, когда отношение имеет минимум три атрибута, причем два из них являются многозначными, а их значения зависят только от третьего атрибута. Другими словами, в отношении R (А, В, С) существует многозначная зависимость, если А многозначным образом определяет В и С, а сами В и С не зависят друг от друга. Как мы видели из предыдущего примера, НомерСтудента многозначно определяет атрибуты Специальность и Секция, но сами Специальность и Секция не зависят друг от друга.
Вернемся вновь к рис. 5.9. Обратите внимание на то, как обозначаются многозначные зависимости: НомерСтудента » Специальность и НомерСтудента » Секция. Это читается следующим образом: «атрибут НомерСтудента многозначно определяет атрибут Специальность» и «атрибут НомерСтудента многозначно определяет
182
Глава 5. Реляционная модель и нормализация
атрибут Секция». Данное отношение находится в НФБК (2НФ — поскольку его ключом является совокупность всех атрибутов, ЗНФ — так как отсутствуют транзитивные зависимости, и НФБК — поскольку нет неключевых детерминантов). Однако, как мы убедились, оно имеет аномалии: если студент берет дополнительную специальность, мы должны добавить в отношение столько строк, в скольких секциях данный студент занимается, и в каждой из этих строк указать новую специальность. То же самое справедливо и для случая, когда студент записывается в новую секцию. Если студент отказывается от одной из специальностей, мы должны удалить все строки, где указана данная специальность. Если студент занимается в четырех секциях, то название специальности будет содержаться в четырех строках, и все эти строки необходимо будет удалить.
СТУДЕНТ (НомерСтудента, Специальность, Секция) Ключ: (НомерСтудента, Специальность, Секция)
НомерСтудента Специальность	Секция
100	Музыка	Лыжи
100	Музыка	Плавание
100	Бухгалтерский учет	Плавание
100	Музыка	Теннис
100	Бухгалтерский учет	Теннис
150	Математика	Оздоровительный бег
а
НомерСтудента Специальность	Секция
100	Музыка	Лыжи
100	Бухгалтерский учет	Лыжи
100	Музыка	Плавание
100	Бухгалтерский учет	Плавание
100	Музыка	Теннис
100	Бухгалтерский учет	Теннис
150	Математика	Оздоровительный бег
б
Рис. 5.10. Отношение СТУДЕНТ с аномалиями вставки: а — вставка одной строки;
б — вставка нескольких строк
Чтобы устранить эти аномалии, мы должны избавиться от многозначной зависимости. Мы сделаем это, создав два отношения, в каждом из которых будут храниться данные только по одному многозначному атрибуту. Результирующие отношения не будут иметь аномалий. Это отношения СТУДЕНТ-СПЕЦИАЛЬНОСТЬ (НомерСтудента, Специальность) и СТУДЕНТ-СЕКЦИЯ (НомерСтудента, Секция), приведенные на рис. 5.11.
Доменно-ключевая нормальная форма (ДКНФ) ,	183
СТУДЕНТ-СПЕЦИАЛЬНОСТЬ (НомерСтудента, Специальность) Ключ: (НомерСтудента, Специальность)
НомерСтудента Специальность
100	Музыка
100	Бухгалтерский учет
150	Математика
СТУДЕНТ-СЕКЦИЯ (НомерСтудента, Секция) Ключ: (НомерСтудента, Секция)
НомерСтудента Секция
100	Лыжи
100	Плавание
100	Теннис
150	Оздоровительный бег
Рис. 5.11. Устранение многозначной зависимости
Исходя из сделанных нами наблюдений, мы определим четвертую нормальную форму (fourth normal form, 4NF) следующим образом: отношение находится в четвертой нормальной форме, если оно находится в НФБК и не имеет многозначных зависимостей. После обсуждения доменно-ключевой нормальной формы (далее в этой главе) мы вернемся к описанию многозначных зависимостей, но уже в другом, более интуитивном ключе.
Пятая нормальная форма (5НФ)
Пятая нормальная форма (fifth normal form, 5NF) связана с зависимостями, которые имеют несколько неопределенный характер. Речь здесь идет об отношениях, которые можно разделить на несколько более мелких отношений, как мы это делали выше, но затем невозможно восстановить. Условия, при которых возникает эта ситуация, не имеют ясной, интуитивной интерпретации. Нам неизвестно, каковы следствия таких зависимостей; мы не знаем даже, есть ли у них какие-либо практические следствия. За более подробной информацией о пятой нормальной форме обращайтесь к работе Дэйта, которая цитировалась ранее в этой главе.
Доменно-ключевая нормальная форма (ДКНФ)
Все описанные выше нормальные формы были выделены исследователями, выявившими аномалии у некоторых отношений, которые находились в нормальной форме более низкого порядка: обнаружение аномалий модификации у отношений во второй нормальной форме привело к определению третьей нормальной формы и т. д. Хотя каждая нормальная форма решала часть проблем, найденных у предыдущей нормальной формы, никто не мог сказать, какие проблемы еще не выявлены. Каждый такой шаг являлся прогрессом на пути к представлению об оптимальной структуре базы данных, однако никто не мог гарантировать, что не будет обнаружено еще каких-либо аномалий. В этом разделе мы рассмотрим нормальную форму, которая будет свободна от аномалий любого типа. Когда мы приводим отношения к этой форме, мы знаем, что в этом случае даже скрытые аномалии, связанные с пятой нормальной формой, возникнуть не могут.
184
Глава 5. Реляционная модель и нормализация
В 1981 г. Фагин опубликовал важную статью, в которой он определил доменно-ключевую нормальную форму (domain/key normal form, DKNF)1. Он показал, что отношение в ДКНФ не имеет аномалий модификации и, более того, любое отношение, не имеющее аномалий модификации, должно находиться в ДКНФ. Это открытие положило конец введению нормальных форм, и теперь в нормальных формах более высокого порядка нет необходимости — по крайней мере, для устранения аномалий модификации.
Столь же важно и то, что определение доменно-ключевой нормальной формы затрагивает только понятия домена и ключа — понятия фундаментальные и близкие сердцу специалистов в области баз данных. Они непосредственно поддерживаются существующими СУБД (или, по крайней мере, могут поддерживаться). В каком-то смысле, работа Фагина формализовала и обосновала то, во что многие специалисты верили интуитивно, но были не в состоянии точно описать.
Определение
Понятие ДКНФ весьма просто: отношение находится в доменно-ключевой нормальной форме, если каждое ограничение, накладываемое на это отношение, является логическим следствием определения доменов и ключей. Рассмотрим важные термины, фигурирующие в этом определении: ограничение, ключ и домен.
Термин ограничение (constraint) имеет в данном определении намеренно широкое толкование. Фагин определяет ограничение как любое правило, регулирующее возможные статические значения атрибутов и достаточно точное для того, чтобы можно было установить, выполняется оно или нет. Правила редактирования, ограничения взаимоотношений и структуры отношений, функциональные зависимости и многозначные зависимости являются примерами таких ограничений. Фагин явным образом исключает отсюда ограничения, относящиеся к изменениям значений данных, или ограничения, зависящие от времени. Например, правило «Зарплата продавца за текущий период не может быть меньше, чем за предыдущий период» не подпадает под определение ограничения, которое дал Фагин. За исключением ограничений, зависящих от времени, определение Фагина является широким и охватывает много случаев.
Ключ (key) — это уникальный идентификатор кортежа, как мы его уже определили. Третий важный термин в определении ДКНФ — домен (domain). В главе 4 говорилось, что домен — это описание допустимых значений атрибута. Он состоит из двух частей: физического описания и семантического, или логического, описания. Физическое описание — это множество значений, которые может принимать атрибут, а логическое описание — это смысл данного атрибута. Доказательство Фагина относится к обеим частям.
Говоря неформально, отношение находится в ДКНФ, если выполнение ограничений на домены и ключи приводит к выполнению всех ограничений. Более того, поскольку отношения в ДКНФ не могут иметь аномалий модификации,
1 R. Fagin, «А Normal Form for Relational Databases That Is Based On Domains and Keys», ACM Transactions on Database Systems, сентябрь 1981, c. 387-415.
Доменно-ключевая нормальная форма (ДКНФ)
185
СУБД может предотвратить возникновение этих аномалий, реализуя выполнение ограничений на домены и ключи.
К сожалению, пока не известен ни один алгоритм преобразования отношения к доменно-ключевой нормальной форме; неизвестно даже, какие отношения могут быть приведены к ДКНФ. Нахождение и создание отношений в ДКНФ является более искусством, чем наукой.
Несмотря на все это, при практическом проектировании баз данных ДКНФ служит в высшей степени полезным ориентиром. Если мы сможем вводить отношения таким образом, что все налагаемые на них ограничения являются логическими следствиями доменов и ключей, то в таких отношениях не будет аномалий модификации. Во многих случаях этот критерий может быть соблюден. Если же выполнить его не представляется возможным, необходимые ограничения должны быть встроены в логику прикладных программ, которые обрабатывают базу данных. Более подробно мы узнаем об этом далее в этой главе и в главе 10.
Следующие три примера иллюстрируют доменно-ключевую нормальную форму.
Первый пример доменно-ключевой нормальной формы
Рассмотрим отношение СТУДЕНТ на рис 5.12, имеющее атрибуты НомерСтудента, Курс, Общежитие и Плата. Здесь Плата — это сумма, которую студент платит за проживание в общежитии.
СТУДЕНТ (НомерСтудента, Курс, Общежитие, Плата)
Ключ: НомерСтудента
Ограничения: Общежитие -> Плата
НомерСтудента не должен начинаться с цифры 1
Рис. 5.12. Первый пример ДКНФ
НомерСтудента функционально определяет остальные три атрибута, поэтому НомерСтудента является ключом. Допустим, мы также знаем, что, согласно требованиям пользователей, Общежитие > Плата и НомерСтудента не должен начинаться с 1. Если нам удастся представить эти требования в качестве логических следствий определения доменов и ключей, то мы сможем быть уверены, в соответствии с теоремой Фагина, что аномалий модификации не возникнет. В данном примере это будет легко сделать.
Чтобы реализовать ограничение, указывающее, что номера студентов не должны начинаться с 1, мы просто включим это требование в определение домена атрибута НомерСтудента (рис 5.13). Соблюдение ограничения домена гарантирует, что данное требование будет выполнено.
Далее нам требуется сделать функциональную зависимость Общежитие > Плата логическим следствием ключей. Если бы атрибут Общежитие был ключевым, зависимость Общежитие > Плата была бы логическим следствием ключа. Поэтому
186
Глава 5. Реляционная модель и нормализация
встает вопрос о том, как сделать Общежитие ключом. Атрибут Общежитие не может быть ключом в отношении СТУДЕНТ, так как в одном и том же общежитии живет более одного студента, зато он может быть ключом своего собственного отношения. Таким образом, мы можем ввести отношение ОБЩЕЖИТИЕ-ПЛАТА с атрибутами Общежитие и Плата. Общежитие является ключом этого отношения. Введя это новое отношение, мы можем удалить атрибут Плата из отношения СТУДЕНТ. Окончательные определения доменов и отношений для этого примера представлены на рис. 5.13.
Определения доменов НомерСтудента CDDD, где С десятичная цифра, не равная 1; D десятичная цифра Курс	{'СТ, 'С2', 'СЗ', 'С4', 'АС'} Общежитие	CHAR (4) Плата	DEC (4) Определения отношений и ключей СТУДЕНТ (НомерСтудента, Курс, Общежитие) Ключ: НомерСтудента ОБЩЕЖИТИЕ-ПЛАТА (Общежитие, Плата) Ключ: Общежитие
Рис. 5.13. Определения доменов и ключей для первого примера ДКНФ
Этот же результат мы получили, преобразовав отношение из 2НФ в ЗНФ для удаления транзитивных зависимостей. В этом случае, однако, процесс был проще, а результат является более надежным. Процесс был проще потому, что нам не требовалось знать, что мы устраняем транзитивную зависимость. Все, что нам было нужно — это найти действенные способы превращения всех ограничений в логические следствия определений доменов и ключей. Результат является более надежным потому, что при преобразовании отношения в третью нормальную форму мы знали только то, что количество аномалий в нем стало меньше по сравнению со второй нормальной формой. Приведя отношение к ДКНФ, мы точно знаем, что получившиеся отношения не будут иметь никаких аномалий модификации.
Второй пример доменно-ключевой нормальной формы
Следующий, более сложный пример затрагивает отношение, приведенное на рис. 5.14. Отношение ПРЕПОДАВАТЕЛЬ содержит данные о преподавателях, предметах, которые они ведут, и студентах, которыми они руководят. Атрибуты Номер-Сотрудника и ИмяСотрудника (имя члена профессорско-преподавательского состава) однозначно определяют преподавателя. НомерСтудента однозначно определяет студента, однако ИмяСтудента не обязательно определяет НомерСтудента. Преподаватель может вести несколько предметов и быть руководителем у нескольких
Доменно-ключевая нормальная форма (ДКНФ)
187
студентов, но каждым студентом руководит только один преподаватель. Номер-Сотрудника начинается с единицы, а НомерСтудента не может с нее начинаться.
ПРЕПОДАВАТЕЛЬ (НомерСотрудника, ИмяСотрудника, Предмет, НомерСтудента, ИмяСтудента) Ключ: (НомерСотрудника, Предмет, НомерСтудента) Ограничения: НомерСотрудника -> ИмяСотрудника ИмяСотрудника НомерСотрудника НомерСотрудника -> Предмет | ИмяСтудента ИмяСотрудника -> -> Предмет | ИмяСтудента НомерСтудента -> НомерСотрудника НомерСтудента ИмяСотрудника НомерСтудента ИмяСтудента НомерСотрудника должен начинаться с 1; НомерСтудента не должен начинаться с 1
Рис. 5.14. Второй пример ДКНФ
Эти высказывания могут быть более точно сформулированы с помощью функциональных и многозначных зависимостей, представленных на рис. 5.14. НомерСотрудника и ИмяСотрудника функционально определяют друг друга (в сущности, они эквивалентны). НомерСотрудника и ИмяСотрудника многозначно определяют Предмет и НомерСтудента. НомерСтудента функционально определяет Номер-Сотрудника и ИмяСотрудника. НомерСтудента определяет ИмяСтудента.
В более сложных примерах, таких как этот, полезно рассмотреть ДКНФ в более интуитивном свете. Вспомните, что суть нормализации заключается в том, что каждое отношение должно иметь одну тему. Если рассмотреть отношение ПРЕПОДАВАТЕЛЬ с этой точки зрения, в нем присутствует три темы. Первая тема — это соответствие между атрибутами НомерСотрудника и ИмяСотрудника, вторая тема — предметы, которые ведет преподаватель, а третья — идентификационный номер, имя и руководитель данного студента.
На рис. 5.15 представлены три отношения, отражающие эти темы. Отношение ППС (профессорско-преподавательский состав) выражает эквивалентность атрибутов НомерСотрудника и ИмяСотрудника. НомерСотрудника является ключом, а Имя-Сотрудника является альтернативным ключом, что означает, что оба атрибута уникальны для этого отношения. Поскольку оба они являются ключевыми, функциональные зависимости НомерСотрудника > ИмяСотрудника и ИмяСотрудника > НомерСотрудника представляют собой логические следствия ключей.
Отношение ПОДГОТОВКА отражает соответствие между преподавателями и предметами; в нем указаны предметы, которые может вести каждый из преподавателей. Ключом является комбинация (ИмяСотрудника, Предмет). Оба атрибута являются необходимыми для ключа, потому что один преподаватель может вести несколько предметов, а один и тот же предмет может вестись несколькими преподавателями. Наконец, в отношении СТУДЕНТ для каждого номера студента указано имя этого студента и его руководителя. Заметьте, что каждое из этих отношений имеет единственную тему. Эти отношения выражают все ограничения, фигурирующие на рис. 5.14, в виде логических следствий определений доменов
188
Глава 5. Реляционная модель и нормализация
и ключей. Поэтому данные отношения находятся в доменно-ключевой нормальной форме.
Обратите внимание, что отделение темы ПОДГОТОВКА от темы СТУДЕНТ устранило многозначные зависимости. Когда мы рассматривали четвертую нормальную форму, мы обнаружили, что для того, чтобы устранить многозначные зависимости, необходимо разнести многозначные атрибуты в различные отношения. Используемый нами здесь подход состоит в разбиении отношения с несколькими темами на несколько отношений, каждое из которых содержит одну тему. Тем самым мы устанили многозначную зависимость. Фактически, оба подхода привели нас к одинаковому решению.
Определения доменов
НомерСотрудника CDDD, где С=1; D —десятичная цифра
ИмяСотрудника CHAR (30)
НомерСтудента CDDD, где С — десятичная цифра, не равная 1; D — десятичная цифра
ИмяСтудента CHAR (30)
Определения отношений и ключей
ППС (НомерСотрудника, ИмяСотрудника) Ключ (первичный):НомерСотрудника
Ключ (кандидат)-.ИмяСотрудника
ПОДГОТОВКА (ИмяСотрудника, Предмет)
Ключ: (ИмяСотрудника, Предмет)
СТУДЕНТ (НомерСтудента, Курс, Общежитие) Ключ: НомерСтудента
Рис. 5.15. Определение доменов и ключей для второго примера ДКНФ
Третий пример доменно-ключевой нормальной формы
В следующем примере рассматривается ситуация, которая не охватывается ни одной из нормальных форм, но часто возникает на практике. Это ситуация, когда отношение имеет ограничение на значения данных в строке, не являющееся ни функциональной, ни многозначной зависимостью.
Рассмотрим ограничения, имеющиеся в отношении СТУДЕНТ-РУКОВОДИТЕЛЬ на рис. 5.16. Это отношение содержит информацию о студенте и его руководителе. Атрибут НомерСтудента определяет атрибуты ИмяСтудента, НомерСотрудника, Имя-Сотрудника и СотрудникАспирантуры, поэтому он является ключом. Атрибуты НомерСотрудника и ИмяСотрудника однозначно определяют члена профессорско-преподавательского состава и взаимно эквивалентны, как и в предыдущем примере. И НомерСотрудника, и ИмяСотрудника определяют атрибут СотрудникАспирантуры. Наконец, новым типом ограничения является то, что руководителями аспирантов могут быть только сотрудники аспирантуры.
Доменно-ключевая нормальная форма (ДКНФ)
189
1 СТУДЕНТ-РУКОВОДИТЕЛЬ (НомерСтудента, ИмяСтудента, НомерСотрудника, СотрудникАспирентуры)
Ключ: НомерСтуденте
Ограничения: НомерСотрудника -> ИмяСотрудника ИмяСотрудника -> НомерСотрудника НомерСотрудника и ИмяСотрудника -> СотрудникАспирантуры Только сотрудники аспирантуры могут быть руководителями аспирантов НомерСотрудника начинается с 1
НомерСтудента не должен начинаться с 1
НомерСтудента для аспиранта начинается с 9 СотрудникАспирантуры = Г1 для сотрудников аспирантуры, '	[0 для остальных сотрудников}
'	Рис. 5.16. Третий пример ДКНФ
Ограничения доменов заключаются в том, что НомерСтудента не должен начинаться с 1, для аспирантов НомерСтудента должен начинаться с 9, НомерСотрудника должен начинаться с 1, а атрибут СотрудникАспирантуры должен быть равен 1 для сотрудников аспирантуры и 0 для всех остальных сотрудников. При таком определении доменов требование, чтобы аспирантами руководили только сотрудники аспирантуры, может быть представлено как ограничение на значения строки. В частности, если атрибут НомерСтудента начинается с 9, то атрибут СотрудникАспирантуры должен быть равен 1.
Чтобы привести это отношение к ДКНФ, мы поступим так же, как в предыдущем примере. Каковы основные темы отношения СТУДЕНТ-РУКОВОДИТЕЛЬ? Одна из тем — это профессорско-преподавательский состав; к ней относятся атрибуты НомерСотрудника, ИмяСотрудника и СотрудникАспирантуры. Вынесем эти атрибуты в отношение ППС. Поскольку атрибуты НомерСотрудника и ИмяСотрудника определяют атрибут СотрудникАспирантуры, любой из этих атрибутов может быть ключом, и это отношение находится в ДКНФ (рис. 5.17).
Теперь рассмотрим данные, относящиеся к студентам и их руководителям. На первый взгляд может показаться, что здесь имеется только одна тема, а именно руководство, однако из требования о том, чтобы аспирантами руководили только сотрудники аспирантуры, следует иное. На самом деле, здесь есть две гемы: руководство аспирантами и руководство студентами. В связи с этим на рис. 5.17 мы имеем два отношения: РУКОВОДИТЕЛЬ-АСПИРАНТ, содержащее информацию об аспирантах, и РУКОВОДИТЕЛЬ-СТУДЕНТ, содержащее информацию о студентах. Посмотрим, каковы будут определения доменов: НомерАспиранта начинается с 9; ИмяСотрудникаАспирантуры — это ИмяСотрудника из строки отношения ППС с атрибутом СотрудникАспирантуры, равным 1; наконец, НомерСтудента не должен начинаться с 1 или 9. Все ограничения, фигурирующие на рис. 5.16, следуют из определения ключей и доменов на рис. 5.17. Поэтому данные отношения находятся в ДКНФ и не имеют аномалий модификации.
В качестве подведения итога обсуждения нормальных форм в таблице на рис. 5.18 перечислены все нормальные формы и даны их определяющие характеристики.
190
Глава 5. Реляционная модель и нормализация
НомерСотрудника ИмяСотрудника Сотрудник Аспирантуры НомерСтудента
НомерАспиранта
ИмяСтудента
ения доменов
CDDD, где С=1; D десятичная цифра
CHAR (30) [0,1]
CDDD, где С — десятичная цифра, С * 1; С * 9
D десятичная цифра
CDDD, где С — десятичная цифра, С = 9;
D — десятичная цифра CHAR (30)
Дополнительное определение доменов
ИмяСотрудникаАсп {ИмяСотрудника из таблицы ППС, для которого СотрудникАспирантуры = 1}
Определения отношений и ключей
ППС (НомерСотрудника, ИмяСотрудника)
Ключ: НомерСотрудника или ИмяСотрудника
РУКОВОДИТЕЛЬ-АСПИРАНТ (НомерАспиранта, ИмяСтудента, ИмяСотрудникаАсп) Ключ: НомерАспиранта
РУКОВОДИТЕЛЬ-СТУДЕНТ (НомерСтудента, ИмяСтудента, ИмяСотрудника) Ключ: НомерСтудента
Рис. 5.17. Определение доменов и ключей для третьего примера
Форма	Определяющая характеристика
1НФ 2НФ	Любое отношение Каждый из неключевых атрибутов зависит от всего ключа целиком
ЗНФ НФБ 4НФ 5НФ ДКНФ	Нет транзитивных зависимостей Каждый детерминант является ключом-кандидатом Отсутствуют многозначные зависимости Не описывается здесь Все ограничения на отношение являются логическими следствиями определений доменов и ключей
Рис. 5.18. Нормальные формы
Синтез отношений
В предыдущем разделе мы подходили к проектированию реляционных схем с аналитических позиций. Вопрос, задававшийся нами, был таков: пусть у нас имеется некоторое отношение, в хорошей ли форме оно находится? Имеет ли оно аномалии модификации? В данном разделе мы подойдем к проектированию реляционных структур, исходя из синтетической перспективы. Вопрос в этом случае звучит так: если у нас имеется набор атрибутов с определенными функциональными зависимостями, какие отношения следует из них формировать?
Синтез отношений
191
Прежде всего, отметим, что два атрибута (скажем, А и В) могут иметь связь трех видов:
1.	Они могут определять друг друга: А>ВиВ>А. В этом случае А и В имеют атрибутивную связь «один к одному».
2.	Один из них может определять другой: А > В или В > А. В этом случае А и В имеют атрибутивную связь «многие к одному».
3.	Они могут быть функционально не связаны: А не > В и В не > А. В этом случае А и В имеют атрибутивную связь «многие ко многим».
Атрибутивная связь «один к одному»
Если А определяет В, а В определяет А, значения атрибутов имеют связь «один к одному» (one-to-one relationship). Это должно быть так, поскольку если А определяет В, то между А и В должна быть связь «многие к одному». Между тем, справедливо и другое утверждение: если В определяет А, то между В и А должна быть связь «один к одному». Чтобы оба утверждения были справедливы одновременно, связь между А и В должна в действительности иметь вид «один к одному» (что является частным случаем связи «многие к одному»), а связь между В и А в реальности также имеет вид «один к одному». Поэтому в данном случае наличествует связь «один к одному».
Этот случай иллюстрируется атрибутами НомерСотрудника и ИмяСотрудника в предыдущем разделе, посвященном доменно-ключевой нормальной форме. Каждый из этих атрибутов однозначно определяет сотрудника факультета. Следовательно, каждому значению атрибута НомерСотрудника соответствует ровно одно значение атрибута ИмяСотрудника, и наоборот.
Относительно примера с атрибутами НомерСотрудника и ИмяСотрудника можно высказать три эквивалентных утверждения:
4-	Если два атрибута функционально определяют друг друга, между их значениями имеется связь «один к одному».
4	Если два атрибута однозначно определяют одну и ту же вещь (сущность или объект), между их значениями имеется связь «один к одному».
4	Если два атрибута имеют связь «один к одному», они функционально определяют друг друга.
При создании базы данных с атрибутами, имеющими связь «один к одному», эти два атрибута должны появляться вместе минимум в одном отношении. Другие атрибуты, которые функционально определяются данными атрибутами (атрибут, который функционально определяется одним из них, функционально определяется и другим), могут также находиться в этом отношении.
Рассмотрим отношение ППС (НомерСотрудника, ИмяСотрудника, СотрудникАспирантуры) из третьего примера в предыдущем разделе. НомерСотрудника и ИмяСотрудника функционально определяют друг друга. Атрибут СотрудникАспирантуры также может появиться в отношении, поскольку он определяется атрибутами
192
Глава 5. Реляционная модель и нормализация
НомерСотрудника и ИмяСотрудника. Атрибуты, которые не определяются функционально данными атрибутами, не могут появляться с ними в одном отношении. Рассмотрим отношения ППС и ПОДГОТОВКА из примера № 2, в котором и Номер-Сотрудника, и ИмяСотрудника присутствуют в отношении ППС, но Предмет (из отношения ПОДГОТОВКА) там появиться не может. Атрибут Предмет может иметь различные значения для сотрудника факультета, поэтому Предмет не зависит от атрибутов НомерСотрудника или ИмяСотрудника. Если бы мы добавили атрибут Предмет в отношение ППС, ключом этого отношения обязательно должно было бы быть сочетание (НомерСотрудника, Предмет) либо (ИмяСотрудника, Предмет). В этом случае, однако, отношение ППС не было бы в ДКНФ, потому что зависимости между атрибутами НомерСотрудника и ИмяСотрудника не были бы логическими следствиями ни одного из возможных ключей.
Эти выражения собраны в первом столбце табл. 5.1, а правила определения записей приведены во врезке. Если А и 3 имеют связь 1:1, они могут находиться в одном отношении R. А определяет В, а В определяет А. Ключом отношения может быть либо А, либо В. Новый атрибут С может быть добавлен в отношение R, если один из атрибутов А и В функционально определяет С.
Таблица 5.1. Три типа связей атрибутов
Тип связи между атрибутами
Один к одному Многие к одному Многие ко многим
Определение	R(A,B)	S(C,D)	T(E,F)
отношения*			
Зависимости	А-> В	С -> D	Е -> F
	В -> А	D-> С	F -> Е
Ключ	Либо А, либо В	С	(E.F)
Правило добавления	Либо А, либо В -> С	С^Е	(E,F) -> G
атрибутов
* Буквы, используемые в определениях этих отношений, соответствуют буквам во врезке, расположенной далее.
Атрибуты, имеющие связь «один к одному», должны присутствовать вместе по меньшей мере в одном отношении, чтобы они могли быть эквивалентными (например, НомерСотрудника, равный 198, относится к профессору Харту). В общем случае, однако, нежелательно, чтобы эти атрибуты появлялись вместе более чем в одном отношении, поскольку это приведет к ненужному дублированию данных. Часто один из этих атрибутов или оба они появляются в других отношениях. В примере №2 атрибут ИмяСотрудника появляется и в отношении ПОДГОТОВКА, и в отношении СТУДЕНТ. В принципе можно было бы поместить Имя-Сотрудника в отношение ПОДГОТОВКА, а НомерСотрудника — в отношение СТУДЕНТ, но это, вообще говоря, порочная практика: когда атрибуты спарены подобным образом, из них следует выбрать один, который будет представлять эту пару во всех других отношениях. Во втором примере для этой цели выбран атрибут ИмяСотрудника.
Синтез отношений
193
ПРАВИЛА ПОСТРОЕНИЯ ОТНОШЕНИЙ ----------------------------------------------------
Связь “ОДИН к одному»
+ Атрибуты, имеющие связь «один к одному», должны фигурировать вместе по крайней мере в одном отношении. Пусть отношение носит имя R, а его атрибуты — А и В.
+ Либо А, либо В должен быть ключом отношения R.
♦	Если некоторый атрибут функционально определяется атрибутом А или В, он может быть добавлен в отношение R.
♦	Атрибут, не определяемый функционально атрибутами А или В, не может быть добавлен в отношение R.
♦	Атрибуты А и В должны находиться вместе в отношении R и более ни в каком другом отношении.
+	Для представления пары (А, В) в отношениях, отличных от R, должен последовательно использоваться один из атрибутов, А или В.
Связь «многие к одному»
+	Атрибуты, имеющие связь «многие к одному», могут находиться вместе в одном отношении. Пускай в отношении S атрибут С определяет атрибут D.
♦ Атрибут С должен быть ключом отношения S.
+ Если некоторый атрибут определяется атрибутом С, он может быть добавлен в отношение S.
+ Атрибут, не определяемый функционально атрибутом С, не может быть добавлен в отношение S.
Связь «многие ко многим»
♦ Атрибуты, имеющие связь «многие ко многим», могут сосуществовать в одном отношении. Пускай в отношении Т имеются два таких атрибута, Е и F.
+ Ключом отношения Т должна быть комбинация (Е, F).
4-	Если некоторый атрибут определяется сочетанием атрибутов (Е, F), он может быть добавлен в отношение Т.
4-	Атрибут, не определяемый функционально сочетанием атрибутов (Е, F), не может быть добавлен в отношение Т.
4-	Если добавление нового атрибута G расширяет ключ отношения до (Е, F, G), это значит, что тема отношения изменилась. Либо атрибут G логически не принадлежит отношению Т, либо следует выбрать другое имя для отношения в соответствии с поменявшейся темой.
Атрибутивная связь «многие к одному»
Если атрибут А определяет В, но В не определяет А, то между их значениями имеется связь «многие к одному» (many-to-one relationship). В отношении РУКОВОДИТЕЛЬ из примера № 2 НомерСтудента определяет НомерСотрудника. Отдельно взятый преподаватель может быть руководителем у многих студентов, однако каждым студентом руководит только один преподаватель. Поэтому здесь имеется связь «многие к одному».
Чтобы отношение находилось в ДКНФ, все ограничения должны быть следствиями ключей, и поэтому каждый детерминант должен быть ключом. Если атрибуты А, В и С находятся в одном отношении, и А определяет В, то атрибут А должен быть ключом (имея в виду, что он определяет также и С). Если же атрибут С определяется сочетанием (А, В), тогда сочетание (А, В) должно быть ключом. В последнем случае никакой другой функциональной зависимости (например, А > В) не допускается.
194
Глава 5. Реляционная модель и нормализация
Применить эти утверждения к проектированию баз данных вы можете следующим образом: если в создаваемом отношении А определяет В, то добавлять в это отношение можно только те атрибуты, которые определяются атрибутом А. Допустим, например, что вы поместили в отношение под названием СТУДЕНТ атрибуты НомерСтудента и Общежитие. В это отношение вы можете добавлять любые другие атрибуты, которые определяются атрибутом НомерСтудента, например ИмяСтудента. Но если атрибут Плата определяется атрибутом Общежитие, его нельзя добавить в данное отношение. Атрибут Плата может быть добавлен только в том случае, если НомерСтудента > Плата.
Эти утверждения приведены в среднем столбце табл. 5.1. Если С и D имеют связь N: 1, они могут находиться вместе в отношении S. С будет определять D, но D не будет определять С. Ключом отношения S будет атрибут С. Другой атрибут, Е, может быть добавлен в отношение S, только если С определяет Е.
Атрибутивная связь «многие ко многим»
Если А не определяет В, а В не определяет А, то между значениями этих атрибутов имеется связь «многие ко многим» (many-to-many relationship). В примере № 2 атрибуты ИмяСотрудника и Предмет имеют связь «многие ко многим». Один преподаватель ведет много предметов, а один и тот же предмет ведется многими преподавателями. В связи «многие ко многим» оба атрибута должны быть ключами отношения. Например, ключом отношения ПОДГОТОВКА из примера № 2 является комбинация (ИмяСотрудника, Предмет).
При построении отношений, у которых ключами являются несколько атрибутов, можно добавлять новые атрибуты, которые функционально зависят от всего ключа. Атрибут КоличествоЧасов функционально зависит от каждого из атрибутов в сочетании (ИмяСотрудника, Предмет) и поэтому может быть добавлен в отношение. Атрибут Должность в данное отношение добавить нельзя, потому что он зависит только от атрибута ИмяСотрудника, но не от атрибута Предмет. Если требуется хранить атрибут Должность в базе данных, его следует добавить в отношение, содержащее информацию о профессорско-преподавательском составе, а не о подготовке.
Эти высказывания приведены в правом столбце табл. 5.1. Если атрибуты Е и F имеют связь M:N, то Е не определяет F, a F не определяет Е. Оба эти атрибута можно поместить в отношение Т, и в этом случае ключом отношения Т будет комбинация (Е, F). Новый атрибут G может быть добавлен в отношение Т, если он определяется обоими атрибутами из сочетания (Е, F). Атрибут G нельзя добавить в отношение Т, если он определяется только одним из атрибутов в комбинации (Е, F).
Рассмотрим аналогичный пример. Предположим, мы хотим добавить в отношение ПОДГОТОВКА атрибут НомерАудитории. Определяется ли НомерАудитории ключом отношения ПОДГОТОВКА комбинацией (ИмяСотрудника, Предмет)? Скорее всего нет, поскольку преподаватель может вести один и тот же предмет в различных аудиториях.
Синтез отношений
195
Сочетание (ИмяСотрудника, Предмет) и атрибут НомерАудитории имеют связь M:N. Раз это так, можно применить правила, приведенные в табл. 5.1, но здесь роль Е будет играть сочетание (ИмяСотрудника, Предмет), а роль F — атрибут НомерАудитории. Теперь мы можем построить новое отношение Т с атрибутами Имя-Сотрудника, Предмет и НомерАудитории. Ключом этого отношения будет комбинация (ИмяСотрудника, Предмет, НомерАудитории). В этой ситуации получается, что мы создали новое отношение с новой темой. Рассмотрим отношение Т, содержащее сведения об именах преподавателей, предметах и номерах аудиторий. Темой этого отношения больше не является ПОДГОТОВКА; скорее эту тему можно было бы сформулировать так: КТО-ЧТО-И-ГДЕ-ПРЕПОДАЕТ.
Изменение темы может быть как уместным, так и неуместным. Если НомерАудитории является значимым атрибутом, тема действительно должна быть изменена. В этом случае отношение ПОДГОТОВКА не подходит, и более уместной является тема КТО-ЧТО-И-ГДЕ-ПРЕПОДАЕТ.
С другой стороны, в зависимости от требований пользователей, отношение ПОДГОТОВКА может быть пригодным в том виде, в каком оно есть. В таком случае, если атрибут НомерАудитории все же должен храниться в базе данных, его следует поместить в другое отношение — например, СЕКЦИЯ-НОМЕР, ПРЕДМЕТ-СЕКЦИЯ или что-нибудь наподобие этого.
Многозначные зависимости: часть вторая
Изложенные выше соображения, касающиеся атрибутивной связи «многие ко многим», могут сделать концепцию многозначных зависимостей более простой для понимания. Проблема с отношением СТУДЕНТ (НомерСтудента, Специальность, Секция) на рис. 5.9 состоит в том, что в нем имеется две различных связи вида «многие ко многим»: одна между атрибутами НомерСтудента и Специальность, а другая — между атрибутами НомерСтудента и Секция. Ясно, что специализации студента не имеют никакого отношения к секциям, в которых он занимается. Однако если обе связи присутствуют в одном отношении, возникает впечатление, что между этими атрибутами существует какая-то взаимосвязь.
Атрибуты Специальность и Секция независимы, и никакой проблемы не возникло бы, если бы студент мог специализироваться только в одной области и заниматься только в одной секции. Тогда НомерСтудента функционально определял бы атрибуты Специальность и Секция, и отношение находилось бы в ДКНФ. В этом случае связь каждого из этих атрибутов с атрибутом НомерСтудента имела бы вид «многие к одному».
Другой способ представить себе возникающее затруднение состоит в исследовании ключа (НомерСтудента, Специальность, Секция). Поскольку в отношении СТУДЕНТ имеются связи вида «многие ко многим», ключ должен содержать в себе каждый из атрибутов. Теперь спросим себя: а какую тему представляет данный ключ? Мы можем сказать, что это комбинация специальности студента и посещаемых им секций. Но такая комбинация не одна, их множество. Одна строка этого отношения описывает только часть комбинации, и чтобы получить
196
Глава 5. Реляционная модель и нормализация
всю картину, нам нужны все строки, содержащие информацию о конкретном студенте. Вообще говоря, строка отношения должна содержать все данные, описывающие отдельный экземпляр темы данного отношения. Например, строка Покупатель должна содержать все нужные нам данные о конкретном покупателе.
Рассмотрим отношение ПОДГОТОВКА из примера № 2 в разделе, посвященном доменно-ключевой нормальной форме. Ключом этого отношения является комбинация (ИмяСотрудника, Предмет). Тема состоит в том, что конкретный преподаватель имеет подготовку, достаточную для ведения определенного предмета. Нам нужна только одна строка этого отношения, чтобы получить всю требуемую информацию о комбинации данного профессора и данного предмета (в отношение могут входить такие атрибуты, как КоличествоЧасов, СредняяОценкаКурса и т. д.). Глядя на другие строки, мы не получим никакой дополнительной информации на эту тему.
Как вы знаете, решение проблемы многозначных зависимостей заключается в том, чтобы разбить исходное отношение на два новых, каждое из которых будет иметь только одну тему. В отношении СТУДЕНТ-СПЕЦИАЛЬНОСТЬ представлены комбинации студентов и специальностей. Все, что мы знаем о каждой из таких комбинаций, содержится в одной строке, и мы не получим какой-либо дополнительной информации о данной комбинации, исследуя другие строки.
Оптимизация
В этой главе мы исследовали концепцию нормализации и продемонстрировали, как создавать таблицы в доменно-ключевой нормальной форме. Использовавшийся нами метод пригоден для большинства случаев, однако иногда результат нормализации не стоит затраченных усилий. В последнем разделе главы мы рассмотрим две ситуации, в которых это может случиться.
Денормализация
Как уже говорилось, нормализованные отношения свободны от аномалий модификации, и по этой причине они являются более предпочтительными, чем ненормализованные отношения. Но если судить с других позиций, иногда нормализация не стоит того, чтобы ее проводить.
Рассмотрим отношение КЛИЕНТ (НомерКлиента, ИмяКлиента, Город, Штат, Индекс), где ключом является НомерКлиента. Это отношение не находится в ДКНФ, поскольку в нем имеется функциональная зависимость Индекс > (Город, Штат), которая не следует из ключа — атрибута НомерКлиента. Следовательно, мы имеем ограничение, не являющееся следствием определения ключей.
Данное отношение может быть преобразовано в два отношения следующего вида: КЛИЕНТ (НомерКлиента, ИмяКлиента, Индекс), где ключом является НомерКлиента, и ИНДЕКСЫ (Индекс, Город, Штат), где ключом является Индекс. Эти два отно
Оптимизация
197
шения находятся в доменно-ключевой нормальной форме, но они, скорее всего, не представляют собой более удачного решения по сравнению с исходной таблицей. Возможно, что ненормализованная таблица лучше, поскольку ее будет легче обрабатывать, а неудобства, связанные с дублированием данных о городе и штате, не столь существенны.
В качестве второго примера рассмотрим отношение КОЛЛЕДЖ (НазваниеКол-леджа, Декан, ЗаместительДекана). Эта таблица не находится в доменно-ключевой нормальной форме, так как ограничение НазваниеКолледжа =» Декан не является логическим следствием ключа таблицы.
Отношение КОЛЛЕДЖ можно нормализовать, разбив его на два отношения: ДЕКАН (НазваниеКолледжа, Декан) и ЗАМДЕКАНА (НазваниеКолледжа, ЗаместительДекана). Однако теперь, когда приложению базы данных нужно будет получить данные о колледже, ему придется прочитать минимум две, а возможно, и все четыре строки данных. В качестве альтернативы можно поместить всех трех заместителей декана в таблицу КОЛЛЕДЖ, выделив для каждого индивидуальный атрибут. Получившаяся таблица имела бы следующий вид: КОЛЛЕДЖ1 (НазваниеКолледжа, Декан, ЗаместительДекана1, ЗаместительДекана?, ЗаместительДеканаЗ).
Отношение КОЛЛЕДЖ1 находится в ДКНФ, поскольку все его атрибуты функционально зависят от ключа НазваниеКолледжа. Однако здесь что-то потеряно. Для того чтобы увидеть, что именно мы потеряли, предположим, что мы хотим узнать названия колледжей, в которых есть заместитель декана по имени Мэри Абернати. Для этого нам придется искать данное имя в каждом из трех столбцов ЗаместительДекана. Наш запрос будет выглядеть примерно следующим образом: SELECT НазваниеКолледжа FROM КОЛЛЕДЖ1
WHERE ЗаместительДекана! = ‘Мэри Абернати' OR
ЗаместительДекана? = 'Мэри Абернати' OR
ЗаместительДеканаЗ = 'Мэри Абернати'
Используя нормализованный вариант с таблицей ЗАМДЕКАНА, нам пришлось бы написать только:
SELECT НазваниеКолледжа
FROM ЗАМДЕКАНА
WHERE ЗаместительДекана = 'Мэри Абернати'
В этом примере даны три возможных решения, у каждого из которых есть свои преимущества и недостатки. Выбор среди этих решений — это искусство: не существует твердого и быстрого правила, указывающего, какой из вариантов является наилучшим. Выбор зависит от характеристик приложений, использующих э ту базу данных.
В общем, иногда отношения намеренно оставляют в ненормализованном виде либо нормализуют, а затем денормализуют. Зачастую это длается для повышения производительности. Всегда, когда необходимо комбинировать данные из двух различных таблиц, СУБД должна выполнять дополнительную работу. В большинстве случаев для этого требуется как минимум две операции чтения вместо одной.
198
Глава 5. Реляционная модель и нормализация
Преднамеренная избыточность
Одним из преимуществ нормализованных отношений является то, что в них минимизируется дублирование данных (только значения ключей появляются более чем в одном отношении). Но в целях повышения производительности иногда уместным является умышленное дублирование данных. Рассмотрим, например, приложение, обрабатывающее заказы, которое обращается к таблице ТОВАР, имеющей следующие столбцы:
НомерТовара
НаименованиеТовара
ЦветТовара
ОписаниеТовара
ФотографияТовара
КоличествоВНаличии
ЗаказанноеКоличество
СтандартнаяЦена
СтандартнаяСтоимость
ИмяПокупателя
Предположим, что атрибут НомерТовара является ключом и что таблица находится в ДКНФ. Предположим также, что атрибут ОписаниеТовара — это потенциально длинное текстовое поле, а ФотографияТовара — это столбец двоичных данных длиной минимум 256 Кбайт.
Приложению, обрабатывающему заказы, необходимо будет обратиться к этой таблице, чтобы получить значения атрибутов НазваниеТовара, ЦветТовара, СтандартнаяЦена и КоличествоВНаличии. Допустим, что приложению не требуется ОписаниеТовара или ФотографияТовара. В зависимости от характеристик используемой СУБД, возможно, что присутствие этих двух больших столбцов значительно замедлит обработку. В этой ситуации проектировщики базы данных могут решить продублировать некоторые данные во второй таблице, которая будет содержать только ту информацию, которая требуется для обработки заказа. К примеру, они могут создать таблицу под названием ЗАКАЗ_ТОВАРА (НомерТовара, Наименование-Товара, ЦветТовара, СтандартнаяЦена, КоличествоВНаличии), которая будет использоваться только приложением, обрабатывающим заказы.
В этом случае проектировщики создают потенциальный источник серьезных проблем с целостностью данных. Им придется разработать процедуры как программного, так и ручного контроля, чтобы гарантировать, что таких проблем не возникнет. Поэтому к подобному решению они прибегнут только в том случае, если, по их мнению, повышение производительности окупит расходы, связанные с дополнительным контролем, и риск возникновения проблем с целостностью данных.
Еще одна причина для введения преднамеренной избыточности — это создание таблиц, предназначенных исключительно для создания отчетов и поддержки принятия решений. Дальнейшее обсуждение этого вопроса последует в главе 17.
Резюм,е
199
Резюме
Реляционная модель важна по двум причинам: во-первых, с ее помощью можно описывать структуры баз данных независимым от СУБД образом, а во-вторых, эта модель лежит в основе значительной части современных СУБД. Критерием правильности и желательности отношений может служить нормализация.
Отношение — это двумерная таблица, в ячейках которой записаны одиночные значения. Все значения в одном столбце принадлежат к одному и тому же типу; каждый столбец имеет уникальное имя; порядок следования столбцов несуществен. Столбцы называются также атрибутами. В отношении не может быть двух одинаковых строк, а порядок следования строк несуществен. Строки называются также кортежами. Термины таблица, файл и отношение являются синонимами; то же самое можно сказать о терминах столбец, поле и атрибут', термины строка, запись и кортеж также синонимичны.
Функциональная зависимость — это связь между атрибутами. Y функционально зависит от X, если значение X определяет значение Y. Детерминантом называется группа из одного или нескольких атрибутов, находящаяся с левой стороны функциональной зависимости. Например, если X определяет Y, то X является детерминантом. Ключ — это группа из одного или нескольких атрибутов, которая однозначно определяет кортеж. Каждое отношение имеет минимум один ключ; поскольку каждая строка уникальна, в самом крайнем случае ключом является совокупность всех атрибутов отношения. Хотя ключ всегда уникален, детерминант функциональной зависимости может таковым и не быть. Являются ли атрибуты ключами и являются ли они функционально зависимыми — это определяется не абстрактным набором правил, а тем смыслом, который вкладывают пользователи в эти атрибуты.
В некоторых отношениях в результате обновления данных возникают нежелательные последствия, называемые аномалиями модификации. Аномалия удаления — это ситуация, когда удаление одной строки из отношения вызывает потерю информации о двух или более фактах. Аномалией вставки называется ситуация, когда реляционная структура вынуждает добавлять информацию одновременно о двух фактах. Аномалии могут быть устранены путем разбиения исходного отношения на два.
Существует много типов аномалий модификации. Отношения можно классифицировать по типам аномалий, которые ими ликвидируются. Типы, на которые подразделяются отношения в рамках этой классификации, называются нормальными формами.
По определению каждое отношение находится в первой нормальной форме. Отношение находится во второй нормальной форме, если каждый из его неключевых атрибутов зависит от всего ключа. Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и не имеет транзитивных зависимостей. Отношение находится в нормальной форме Бойса-Кодда, если каждый его детерминант является ключом-кандидатом. Отношение находится в четвертой нормальной форме, если оно находится в нормальной форме Бойса-Кодда и не имеет многозначных зависимостей. Определение пятой
200
Глава 5. Реляционная модель и нормализация
нормальной формы не имеет интуитивной интерпретации, и поэтому мы его не приводили.
Отношение находится в доменно-ключевой нормальной форме, если каждое ограничение, накладываемое на отношение, является логическим следствием определения доменов и ключей. Под ограничением здесь понимается любое условие, определяющее возможные статические значения атрибутов, истинность которого может быть проверена. Домены, как они определены нами, имеют физическую и семантическую составляющие. В контексте ДКНФ, однако, под доменом подразумевается только физическое описание.
Неформальная интерпретация ДКНФ заключается в том, что каждое отношение должно иметь только одну тему. Например, в отношении может содержаться информация о профессорах или о студентах, но не о тех и других одновременно.
Нормализация — это процесс анализа отношений. Отношения можно также строить синтетическим путем, рассматривая связи между атрибутами. Если два атрибута функционально определяют друг друга, между ними имеется связь вида «один к одному». Если один из двух атрибутов функционально определяет второй, между этими атрибутами имеется связь «многие к одному». Если ни один из двух атрибутов не определяет другой, между этими атрибутами имеется связь «многие ко многим». Эти факты, приведенные в табл. 5.1, можно использовать при создании отношений.
В некоторых случаях нормализация нежелательна. Всякий раз, когда исходная таблица разбивается на две или более новых, возникают ограничения ссылочной целостности. Если расходы на дополнительную обработку двух таблиц и обеспечение ссылочной целостности превышают выгоду от устранения аномалий модификации, нормализация не рекомендуется. Вдобавок в некоторых случаях создание повторяющихся столбцов предпочтительнее обычных способов нормализации, а в других случаях для повышения производительности вводится преднамеренная избыточность.
Вопросы I группы
1.	Какие ограничения должны быть наложены на таблицу, чтобы она могла считаться отношением?
2.	Определите следующие термины: отношение, кортеж, атрибут, файл, запись, таблица, строка, столбец.
3.	Дайте определение термина функциональная зависимость. Приведите пример двух атрибутов, имеющих функциональную зависимость, и двух атрибутов, не имеющих функциональной зависимости.
4.	Если атрибут НомерСтудента функционально определяет атрибут Секция, означает ли это, что в отношении может быть только одно значение атрибута НомерСтудента? Обоснуйте свой ответ.
5.	Дайте определение термина детерминант.
6.	Приведите пример отношения с функциональной зависимостью, в которой детерминант состоит из двух или более атрибутов.
Вопросы I группы
201
7.	Дайте определение термина ключ.
8.	Если атрибут НомерСтудента является ключом отношения, является ли он детерминантом? Может ли конкретное значение этого атрибута появиться в отношении более одного раза?
9.	Что такое аномалия удаления? Приведите пример, отличный от того, который дан в тексте.
10.	Что такое аномалия вставки? Приведите пример, отличный от того, который дан в тексте.
11.	Объясните, как соотносятся между собой первая, вторая, третья нормальные формы, нормальная форма Бойса-Кодда, четвертая, пятая и доменноключевая нормальные формы.
12.	Дайте определение термина вторая нормальная форма. Приведите пример отношения, которое находится в первой нормальной форме, но не находится во второй нормальной форме. Преобразуйте это отношение в отношения, находящиеся во второй нормальной форме.
. 13. Дайте определение термина третья нормальная форма. Приведите при-___мер отношения, которое находится во второй нормальной форме, но не находится в третьей нормальной форме. Преобразуйте это отношение в отношения, находящиеся в третьей нормальной форме.
14.	Дайте определение термина нормальная форма Бойса-Кодда. Приведите пример отношения, которое находится в ЗНФ, но не находится в НФБК. Преобразуйте это отношение в отношения, находящиеся в НФБК.
15.	Дайте определение термина многозначная зависимость. Приведите пример.
16.	Почему многозначные зависимости не являются проблемой в отношениях, имеющих только два атрибута?
17.	Дайте определение термина четвертая нормальная форма. Приведите пример отношения, которое находится в НФБК, но не находится в 4НФ. Преобразуйте это отношение в отношения, находящиеся в 4НФ.
18.	Дайте определение термина доменно-ключевая нормальная форма. Почему эта форма важна?
19.	Преобразуйте следующее отношение к ДКНФ. Сделайте и сформулируйте соотвествующие предположения о функциональных зависимостях и доменах.
ОБОРУДОВАНИЕ (Производитель, Модель, ДатаПриобретения, ИмяПокупателя, Те-лефонПокупателя, МестоположениеЗавода, Город, Штат, Индекс)
20.	Преобразуйте следующее отношение в ДКНФ. Сделайте и сформулируйте соотвествующие предположения о функциональных зависимостях и доменах.
СЧЕТ (Номер, ИмяПокупателя, НомерПокупателя, АдресПокупателя, НомерТова-сн:'. ра, ЦенаТовара, КоличествоТовара, НомерПродавца, ИмяПродавца, Промежуточ-
ныйИтог, Налог, ВсегоКОплате)
202
Глава 5. Реляционная модель и нормализация
21.	Снова ответьте на вопрос 20, но теперь добавьте атрибут НалоговыйСтатус-Покупателя (0, если покупатель не освобожден от налога, и 1, если освобожден). Добавьте также ограничение, что налог не должен включаться в счет, если НалоговыйСтатусПокупателя равен 1.
22.	Приведите пример (отличный от того, который дан в тексте) ситуации, в которой, как вы считаете, нормализацию производить не стоило бы. Изобразите отношения и обоснуйте свое решение.
23.	Укажите две ситуации, в которых проектировщики базы данных могут преднамеренно прибегнуть к дублированию данных. Каков риск, связанный с подобными решениями?
Вопросы II группы
24. Рассмотрим следующее отношение (табл. 5.2):
Таблица 5.2. Отношение ПРОЕКТ
НомерПроекта	ИмяСотрудника	ЗарплатаСотрудника
100А	Джонс	64 000
100А	Смит	51 000
100В	Смит	51 000
200А	Джонс	64 000
200В	Джонс	64 000
200С	Паркс	28 000
200С	Смит	51 000
200D	Паркс	28 000
ПРОЕКТ (НазваниеПроекта, ИмяСотрудника, ЗарплатаСотрудника)
Здесь НазваниеПроекта — это название рабочего проекта, ИмяСотрудника — имя сотрудника, работающего в рамках данного проекта, а ЗарплатаСотрудника — заработная плата данного сотрудника.
Если предположить, что представленные здесь данные выявляют все имеющиеся функциональные зависимости и ограничения, какое из следующих утверждений будет верным?
НазваниеПроекта > ИмяСотрудника
НазваниеПроекта > ЗарплатаСотрудника
(НазваниеПроекта, ИмяСотрудника) > ЗарплатаСотрудника
ИмяСотрудника > ЗарплатаСотрудника
ЗарплатаСотрудника > НазваниеПроекта
ЗарплатаСотрудника > (НазваниеПроекта, ИмяСотрудника)
Ответьте на следующие вопросы:
1)	Что является ключом отношения ПРОЕКТ?
2)	Все ли неключевые атрибуты (если таковые есть) зависят от всего ключа целиком?
Вопросы II группы
203
3)	В какой нормальной форме находится отношение ПРОЕКТ?
4)	Опишите две аномалии модификации, характерные для отношения ПРОЕКТ.
5)	Является ли атрибут НазваниеПроекта детерминантом?
6)	Является ли атрибут ИмяСотрудника детерминантом?
7)	Является ли детерминантом сочетание (НазваниеПроекта, ИмяСотрудника)?
8)	Является ли детерминантом ЗарплатаСотрудника?
9)	Содержит ли это отношение транзитивную зависимость? Если да, то какую?
10)	Переделайте это отношение так, чтобы устранить аномалии модификации.
25.	Рассмотрим следующее отношение (табл. 5.3):
Таблица 5.3. Отношение ПРОЕКТ-ЧАСЫ				
ИмяСотрудника	НомерПроекта	НомерЗадачи	Телефон	ВсегоЧасов
Дон	100А	В-1	12345	12
Дон	100А	Р-1	12345	12
Дон	200В	В-1	12345	12
Дон	200 В	р-1	12345	12
Пэм	100А	С-1	67890	26
Пэм	200А	С-1	67890	26
Пэм	200 D	С-1	67890	26
ПРОЕКТ-ЧАСЫ (ИмяСотрудника, НазваниеПроекта, НазваниеЗадачи, Телефон, •*’" ВсегоЧасов)
Здесь НазваниеЗадачи — это название стандартной рабочей задачи, Телефон — номер телефона сотрудника, а ВсегоЧасов — количество часов, отработанных сотрудником в рамках данного проекта.
Если предположить, что представленные здесь данные выявляют все имеющиеся функциональные зависимости и ограничения, какое из следующих утверждений будет верным?
он	ИмяСотрудника > НазваниеПроекта
•or	ИмяСотрудника » НазваниеПроекта
ИмяСотрудника > НазваниеЗадачи
ИмяСотрудника » НазваниеЗадачи
ИмяСотрудника > Телефон
ИмяСотрудника > ВсегоЧасов
(ИмяСотрудника, НазваниеПроекта) > ВсегоЧасов
(ИмяСотрудника, Телефон) > НазваниеЗадачи
НазваниеПроекта > НазваниеЗадачи
НазваниеЗадачи > НазваниеПроекта
Ответьте на следующие вопросы:
1)	Перечислите все детерминанты.
2)	Содержит ли данное отношение транзитивную зависимость? Если да, то какую?
204
Глава 5. Реляционная модель и нормализация
3)	Содержит ли данное отношение многозначную зависимость? Если да, то какие атрибуты не связаны между собой?
4)	Опишите аномалию удаления, которая имеется в этом отношении.
5)	Сколько тем содержит данное отношение?
6)	Переделайте отношение так, чтобы устранить аномалии модификации. Сколько отношений у вас получилось? Сколько тем содержит каждое из новых отношений?
7)	Рассмотрим приведенные ниже определения отношений, доменов и ключей.
Определения доменов:
ИмяСотрудникаСНАР(20)
НомерТелефонаОЕС(5)
НаименованиеОборудованияСНАР(Ю)
МестоположениеСНАР(7)
CTOMMOCTbCURRENCY
flaiaYYMMDD
ВремяННММ, где 00 <= НН <= 23
00 <= ММ <= 59
Отношения, ключи и ограничения:
СОТРУДНИК (ИмяСотрудника, НомерТелефона)
Ключ:ИмяСотрудника
Ограничения:ИмяСотрудника > НомерТелефона
ОБОРУДОВАНИЕ (НаименованиеОборудования, Местоположение, Стоимость) Ключ:На и меновая иеОборудова ния Ограничения:НаименованиеОборудования > Местоположение НаименованиеОборудования > Стоимость
СЕАНС (Дата, Время, НаименованиеОборудования, ИмяСотрудника) Ключ(Дата, Время, НаименованиеОборудования)
Ограничения:(Дата, Время, НаименованиеОборудования) > ИмяСотрудника
26.	Модифицируйте определения так, чтобы добавить следующее ограничение: сотрудник не может записаться более чем на один сеанс работы с оборудованием.
27.	Определим в качестве ночного времени часы между 21.00 и 05.00. Добавьте атрибут ТипСотрудника, значение которого равно 1, если сотрудник работает в ночное время. Измените определения таким образом, чтобы ввести условие, что только сотрудники, работающие ночью, могут записываться на ночные сеансы.
Вопросы к проекту FiredUp
Фирма FiredUp наняла команду проектировщиков, разработавших для базы данных фирмы приведенные ниже отношения (вообще-то эту команду следовало бы уволить!). База данных должна содержать информацию о проданных горелках,
Вопросы к проекту FiredUp
205
выполненном ремонте и клиентах. Чтобы ознакомиться с потребностями фирмы, обратитесь к проектам в конце глав 1-3. Для каждого из представленных ниже отношений укажите ключи-кандидаты, функциональные зависимости и многозначные зависимости (если таковые присутствуют). Если ответ не очевиден, приведите обоснование этого. В какой нормальной форме находится каждое из отношений, если иметь в виду указанные вами ключи и другие элементы? Преобразуйте каждое из отношений в два или более новых отношения, находящихся в доменно-ключевой нормальной форме. Укажите первичный ключ каждой таблицы, ключи-кандидаты и внешние ключи, а также сформулируйте ограничения ссылочной целостности, если они имеются.
Отвечая на эти вопросы, исходите из следующих предположений:
♦ Тип и версия горелки определяют емкость бака.
4- Горелка может ремонтироваться много раз, но не более одного раза в день.
♦	На каждый произведенный ремонт выписывается отдельный счет.
♦	Горелка может быть зарегистрирована на различных пользователей, но не одновременно.
4- Горелка состоит из многих деталей, и каждая деталь может использоваться во многих горелках. Таким образом, фирма FiredUp ведет записи о различных типах деталей (например, клапан форсунки), но не об отдельных деталях (клапан форсунки номер 41734, изготовленный 12 декабря 2001 г.).
Ниже следует список отношений.
ПР0ДУКТ1 (СерийныйНомер, Тип, НомерВерсии, ЕмкостьБака, ДатаИзготовления, Ини-циалыИнспектора)
ПР0ДУКТ2 (СерийныйНомер,Тип, ЕмкостьБака, ДатаРемонта, НомерСчетаЗаРемонт, СтоимостьРемонта)
РЕМ0НТ1 (НомерСчетаЗаРемонт, ДатаРемонта, СтоимостьРемонта, ИмяВыполнявшего-Ремонт, ТелефонВыполнявшегоРемонт)
РЕМ0НТ2 (НомерСчетаЗаРемонт, ДатаРемонта, СтоимостьРемонта, ИмяВыполнявшего-Ремонт, ТелефонВыполнявшегоРемонт, СерийныйНомер, Тип, ЕмкостьБака)
РЕМОНТЗ (ДатаРемонта, СтоимостьРемонта, СерийныйНомер, ДатаИзготовления) ГОРЕЛ КА1 (СерийныйНомер, НомерСчетаЗаРемонт, НомерДетали)
ГОРЕЛКА2 (СерийныйНомер, НомерСчетаЗаРемонт, РегистрационныйНомерВладельца)
Предположим, что нужно записывать владельца горелки, даже если она никогда не ремонтировалась.
Исходя из сделанных предположений, приведенных выше отношений и содержащихся в них атрибутов, а также из ваших знаний о малом бизнесе, постройте для фирмы FiredUp набор отношений в доменно-ключевой нормальной форме. Укажите первичные ключи и внешние ключи, а также сформулируйте ограничения целостности по внешнему ключу.
Глава 6
Проектирование баз данных в рамках модели «сущность—связь»
В главе 3 мы обсуждали модель «сущность—связь», а в главе 5 — реляционную модель и нормализацию. В настоящей главе мы свяжем эти два предмета и покажем, как требования пользователей, выраженные в терминах модели «сущность-связь», преобразуются в реляционные конструкции. Эти конструкции не зависят от конкретной СУБД.
Глава 6 состоит из трех разделов. В первом разделе мы изложим методики преобразования моделей «сущность—связь» в реляционные конструкции. Как вы увидите, важную роль в этом процессе играет нормализация. Второй раздел посвящен применению этих методик для преобразования четырех структур, часто возникающих в приложениях баз данных. В заключительном разделе главы обсуждаются суррогатные ключи и пустые значения.
Преобразование моделей
«сущность—связь» в реляционные конструкции
Согласно модели «сущность—связь», вещи, учет которых хотят вести пользователи, представляются сущностями, а взаимоотношения между этими сущностями представляются явно определенными связями. В данном разделе описывается, как эти сущности и связи преобразуются в элементы реляционной модели.
Представление сущностей с помощью реляционной модели
Представление сущностей средствами реляционной модели имеет прямолинейный характер. Начнем с того, что введем для каждой сущности свое отношение. Именем отношения будет имя сущности, а атрибутами отношения — атрибуты
Преобразование моделей «сущность—связь;
207
сущности. Далее рассмотрим каждое из отношений в свете критериев нормализации, описанных в главе 5. При этом может (но не обязана) возникнуть необходимость в модификации первоначальной структуры.
Сущность КЛИЕНТ содержит:
НомерКлиента
ИмяКлиента
Адрес
Город
Штат
Индекс
ИмяДоверенногоЛица НомерТелефона
а
КЛИЕНТ (НомерКлиента. ИмяКлиента, Адрес, Город, Штат, Индекс, ИмяДоверенногоЛица, НомерТелефона)
б
Рис. 6.1. Представление сущности с помощью отношения: а — сущность КЛИЕНТ; б — отношение, представляющее сущность КЛИЕНТ
На рис. 6.1, а изображена сущность КЛИЕНТ, взятая из рис. 3.1. Она имеет следующие атрибуты: НомерКлиента, ИмяКлиента, Адрес, Город, Штат, Индекс и Телефон. Определим для этой сущности отношение, а атрибуты сущности сделаем его столбцами. Если из модели данных нам известно, какой атрибут идентифицирует сущность, то данный атрибут станет ключом отношения. В противном случае, чтобы определить, какой атрибут или набор атрибутов может идентифицировать сущность, мы должны спросить пользователей или как-то иначе проанализировать требования. Здесь мы предполагаем, что ключом является НомерКлиента. На этом рисунке, как и на следующих за ним, ключи отношения подчеркнуты.
Роль нормализации
На этапе формулировки требований единственное условие состояло в том, чтобы сущность была важна для пользователя. Не предпринималось никаких попыток определить, удовлетворяет ли сущность критериям нормализации, описанным в главе 5. Теперь отношение, введенное для сущности, следует проанализировать в свете критериев нормализации.
Рассмотрим, например, отношение КЛИЕНТ на рис. 6.1, б. Находится ли оно в доменно-ключевой нормальной форме (ДКНФ)? Чтобы это выяснить, нам необходимо знать, какие ограничения существуют относительно него. Без исчерпывающего описания требований мы не будем знать все ограничения (например, все ограничения доменов). Но некоторые требования мы можем определить, исходя только из имен атрибутов и наших знаний о природе бизнеса.
Во-первых, НомерКлиента определяет все остальные атрибуты, поскольку уникальные значения атрибутов ИмяКлиента, Адрес, Город, Штат, Индекс, ИмяДоверенногоЛица и Телефон могут быть определены по заданному значению атрибута
208
Глава 6. Проектирование баз данных в рамках модели «сущность—связь»
НомерКлиента. Есть, однако, и другие ограничения, проистекающие из других функциональных зависимостей. Индекс определяет Город и Штат, а ИмяДоверенногоЛица определяет НомерТелефона. Чтобы создать набор отношений в ДКНФ, мы должны представить эти дополнительные функциональные зависимости как логические следствия доменов и ключей, и это мы можем сделать, введя три отношения, показанные на рис. 6.2. Заметьте, что ключом отношения КЛИЕНТ является НомерКлиента, ключом отношения ТАБЛИЦА_ИНДЕКСОВ является Индекс, а ключом отношения КОНТАКТ является ИмяДоверенногоЛица. Также обратите внимание на ограничения ссылочной целостности.
Отношения, изображенные на рис. 6.2, находятся в ДКНФ и будут лишены аномалий модификации. То есть, чтобы добавить новые индексы и новых доверенных лиц, нам не придется добавлять нового клиента. Кроме того, при удалении последнего клиента с данным индексом мы не потеряем информацию о том, какие город и штат соответствуют этому значению индекса. Однако, как мы указали в конце главы 5, большинство профессионалов сочли бы этот дизайн выхолощенным: вынесение атрибутов Индекс, Город и Штат в отдельную таблицу затрудняет работу с конструкцией в целом. Следовательно, более удачным решением было бы оставить атрибуты Индекс, Город и Штат в отношении КЛИЕНТ.
КЛИЕНТ (НомерКлиента. Адрес, Индекс, ИмяДоверенногоЛица)
ТАБЛИЦА_ИНДЕКСОВ (Индекс, Город, Штат)
КОНТАКТ (ИмяДоверенногоЛица. НомерТелефона)
Ограничения ссылочной целостности:
Значение атрибута Индекс в отношении КЛИЕНТ должно существовать среди значений атрибута Индекс в отношении ТАБЛИЦА_ИНДЕКСОВ
Значение атрибута ИмяДоверенногоЛица в отношении КЛИЕНТ должно существовать среди значений атрибута ИмяДоверенногоЛица в отношении КОНТАКТ
Рис. 6.2. Представление сущности КЛИЕНТ с помощью отношений в доменно-ключевой нормальной форме
Что можно сказать по поводу отношения КОНТАКТ? Если связь между доверенным лицом и компанией имеет вид 1:1, то вынесение контактной информации в отдельную таблицу мало что дает. В этом случае отношение на рис. 6.1, б приемлемо. Если же указанная связь не однозначна, то отношение КОНТАКТ следует представить как отдельную сущность, надлежащим образом связанную с сущностью КЛИЕНТ (эта связь может иметь вид N:1 или 1 :N), и соответственно модифицировать ER-модель.
В других примерах ДКНФ является наибол