ТЕОРИ* РАКТИКА
ПОСТРОЕНИЯ
□
8-Е ИЗДАНИЕ
Д КРЕНКЕ

DATABASE
PROCESSING
Eighth Edition
David M. Kroenke
Prentice Hall PTR
Upper Saddle River, New Jersey 07458
www.phptr.com
PH
PTR

KARCCMKR COmPUTER 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
Часть И. Моделирование данных
Глава 3. Модель «сущность—связь» 82
Глава 4. Семантическая объектная модель 118
Часть Ш. Проектирование баз данных
Глава 5. Реляционная модель и нормализация 166
Глава 6. Проектирование баз данных в рамках модели «сущность—связь» . . 206
Глава 7. Проектирование баз данных в рамках семантической
объектной модели 245
Часть IV. Построение реляционных баз данных
Глава 8. Основы построения реляционных баз данных 274
Глава 9. Язык SQL 304
Глава 10. Проектирование приложений баз данных 330
Часть V. Обработка многопользовательских баз данных
Глава 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
Часть УН, Работа с объектно-ориентированными базами данных
Глава 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
Вопросы к проекту FiredUp 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
Вопросы группы И 162
Проекты 162
Вопросы к проекту FiredUp 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
Вопросы к проекту FiredUp 204
Глава 6. Проектирование баз данных в рамках
модели «сущность—связь» 206
Преобразование моделей «сущность—связь» в реляционные конструкции . . . 206
Представление сущностей с помощью реляционной модели 206
Представление связей типа «ИМЕЕТ» 211
Представление тернарных связей и связей высших порядков 221
Представление связей типа «ЕСТЬ» (подтипов) 225
Пример проекта 226
Деревья, сети и списки материалов 228
Деревья 229
Простые сети 231

10 Содержание
Сложные сети 231
Списки материалов 232
Суррогатные ключи 234
Пустые значения 238
Резюме 239
Вопросы I группы 240
Вопросы И группы 243
Проекты 243
Вопросы к проекту FiredUp 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
Вопросы к проекту FiredUp 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
Вопросы I! группы 374
Проекты 375
Вопросы к проекту FiredUp 375
Часть V. Обработка многопользовательских баз данных
Глава 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
Установка SQL Server 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
Вопросы к проекту FiredUp 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
Терминология и стандарты ХМL 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
OLEDB 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
Вопросы к проекту FjredUp 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
Вопросы к проекту FiredUp 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
Вопросы! группы 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.
Говоря коротко, технология баз данных оказывается сегодня важной как
никогда, и основные технологии, которые необходимо осваивать в этой связи,
стали яснее, чем когда бы то ни было за последние пять лет.
Особенности настоящего издания
В соответствии со сделанными выше замечаниями, вторая половина книги была
полностью переписана. Почти весь материал в главах с 11 по 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 рассматривается
реляционная модель и нормализация. Далее в главе б с помощью идей, развитых
в главах 3 и 5, модели «сущность—связь» трансформируются в конкретные
варианты организации реляционной базы данных. В главе 7 описывается процесс
преобразования моделей семантических объектов в конкретные структуры
реляционных баз данных, для чего используются идеи, изложенные в главах 4 и 5.
Следующая часть книги посвящена основам реализации баз данных. Глава 8
является обзорной, в главе 9 описывается процедурный язык SQL, а в главе 10
рассматриваются структура и функции приложений реляционных баз данных.
Часть V посвящена управлению многопользовательской базой данных. В главе 11
рассматривается администрирование баз данных и обсуждаются важнейшие
вопросы функционирования многопользовательских баз данных, включая
управление конкуренцией, безопасность, резервное копирование и восстановление.
Идеи, изложенные в главе 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), а также исключительно ценным и вдумчивым
отзывам, поступившим от следующих людей:
+ Джек Беккер (Jack Becker), Университет Северного Техаса
+ Уильям Д. Берг (William D. Burg), Университет Алабамы в Бирмингеме
+ Бхушан Капур (Bhushan Kapoor), Калифорнийский государственный
университет — Фуллертон
+ Дональд Р. Москейто (Donald R. Moscato), Иона Колледж
+ Нэнси Л. Руссо (Nancy L. Russo), Университет Северного Иллинойса
+ Бехруз Сагафи (Behrooz Saghafi), Чикагский государственный университет
+ Джозеф Л. Сессум (Joseph L. Sessum), Государственный университет Кен-
несо
+ Ашраф Ширани (Ashraf Shirani), Государственный университет Сан-Хосе
♦ Людвиг Слуски (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) за ее любовь, поддержку и воодушевление.
Теория баз данных — захватывающая область, которая развивалась pi
эволюционировала в течение более чем тридцати лет. Я верю в то, что это ее развитие
продолжится еще как минимум столько же времени, и желаю вам успехов в
исследовании многочисленных возможностей, открывающихся перед вами!
Дэвид Крёнке (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. Введение в базы данных
Рие Edit View Insert Tods Window fctelp
D & •..,.: ЧХ ■ -; Ф • ' -'■ ' •
Ǥ
3-
1 SOURCEJOI
*M&
Name
PhoneNumbei
1 Valley Designs
2 Aspen Construction
3 Mary Engers Design
(Auto Number)
(303) 549-8879
РОЭ) 776-8899
(303) 767-7783
l<fij Create table in Design view
Efj Create table by using wcard
|Ц] Create table by entering data
Щ CUSTOMER
'job-
Ш SOURCE
Record: .Н1.«.|Г
l » 1>Ф«1оГ з
CUSTOMERJOjCustorner Name
Street
2 Wu, Jason
3 Maples. Marilyn
4 Jackson, Chris
■ - i (AutoNumber)
|P««<1: Hi'* П l" ► JHJt+tdF 3
123 E Elm Denver
2518 S Link Lane Denver
4700 Lafayette Eoulder
City [State] -Zip I PhoneNuwber | SOURCE JO
CO 80210-7786 (303) 555-0089
CO 80243- "(303) 777-6898
CO 81237-3484 _ (54Э) 388-1243
/
I*
Re
JOBJD |
t
2
3
4
5
(AutoNumber)
cord: .niVi!
JobDate | Description
3/3/2000 Pamt extenor in 794 White
7/7/2000 Paint dining room and kitchen
3/15/2001 Prep and paint upstairs bath
4/3/2O01 Pamt exterior doors in 633 Red
7/14/2001 Prep and paint interior wood trim
3 JL±±U±±J <f 5
| AmountBiHed j
$2.750 00
$1.778 00
$550 00
$885 00
$1.299 00
$0 00
AmountPaid
$2.750 00
$1,778 00
$550 00
$885 00
$1.299 00
$0 00
CUSTOMERJD!
2}
2}
2j
. . 4!
3j
d!
^ХТ^Лл-.^1
:i^ii*<^%i8&< ЛЛадйСкЛ >■■■ •■>
^JGliU
Рис. 1.1. Таблицы данных для малярной фирмы Мэри Ричарде
-lolxi
Customer ]^Vu, Jason
Phone
Street
Ciiv
State
JOB
|l303) 555-0089
J123E Elm
jDenver
{ССГ; Zip
Г80210-7786
I Record; И 1 < f Г
► |n|n»Iof 3
Referral Source
j^p'e'n Constr.K'i.jn j[]
Phone 1|303'|'"'Г6-38Ээ
JobDate
►
*
j 3/3^2000
| 7/7/2ШЩ:
|3/15/2001::
I
Record, .h !„*„J f
Description
I Pamt exterior in 7Э4 White
1 Paint dtnmg room and kitchen
jPiep and paint upstairs bath
1
1 „»,.1..M.I>*1 of 3
ArnountBrBed
j ilTSCTf
j $1 778 '"["*
| $55и~~Г
I ~r
AmountPaiJ
42.750
$1.778
i550
to
*i
zl
Рис. 1.2. Пример формы для ввода данных для малярной фирмы Мэри Ричарде

Четыре примера применения баз данных 27
tomer Job History I
шты.
' ;:~- в :х:'
Ш§ШШЩ}Ш Ш^лоо% ' Зо« jetup » ^ЩЩт
1 Customer Job History
t CustomerName Wu. Jason
1 PhoneNumber (SOS) 555-008
JobDate Description
3/Э/2000 Paint e*enor in 794 Whte
7/7/2000 Paint cinng room and kitchen
ЗЛ 5/2001 Prep and paint ipstairs b<*h
Total
CustomerName Afaples, Marilyn
PhoneNumber (303) 777-689
JobDate Description
7f\ 4/2001 Prep and pent interior vwod trim
T.tal
CustomerName Jackson, Chris
PhoneNumber (549) SS8-124
| JobDate Description
4/3/2001 Paint e*enor doors n 633 Red
T.tal
Grand ТоШ
„*^>^^
Thursday, March 01,2001
Щ.
AmountBiUed AmountPcad
$2,750 $2,750
*1,77B $1,778
$550 $550
$5,07S $5,07*
AmountBiUed AmountPtad
$1,299 $1.299
$1,299 $1,299
AmountBiUed AmountPcad
$865 $885
«885 Ш5
| 7£rf£|| /^gi|
**««****^
2]
,s^^^s^^:^
^i J
jjpascPant Shop Pro f &M**' Wcrw* • Dat=»
9 Customer Job Hist...
ним "У-Ш
Рис. 1.3. Пример отчета для малярной фирмы Мэри Ричарде
Прикладная программа и СУБД обрабатывают заполненную форму и
переписывают данные из нее в таблицы, подобные изображенным на рис. 1.1.
Аналогичным образом прикладная программа и СУБД извлекают данные из этих
таблиц для создания отчетов, таких как представленные на рис. 1.3.
Еще раз вернувшись к рис. 1.1, обратите внимание, что строки таблицы
содержат перекрестные ссылки и поэтому оказываются связанными друг с
другом. Для каждой работы (JOB) указан номер клиента (CUST0MERJD), заказавшего
эту работу, и для каждого клиента (CUSTOMER) указан номер поставщика клиента
(S0URCE_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
-tnlxfc
ТгеМЩШЩ Music — Customer Form
Customer Nams
Homophone
WorkPhrjne
Street
C*y ...
Stale
INVOICES
I Mary & Fred Jackson
j|703) 4437788 ;.;
\{Г03) 443-44821
1200 Seventeenth Ave
HieKandtia
~Zi* |0223-4"5567 '
ChMien
+
Л
|7 erherine
jj ay main a
1 _
Recofd- и j. < j |
1 J.
JnvoiceNurnba ItwoiceOate
► j—~~ 100037' l'i'u/16/гОО*"
$37
1 » JHJ»»t or 2
i »1"М* г
IJdM P F.ffWffW.JMili^^
-inf*?!
Treble Clef Music — Rental Agreement Form |
hr
J Re
l
nvoiceN'jmfrei j 100097 ....
nvoceDate {' 0/1 £Л?0СЛ j ^
WoiKRione j^Q?] 443-4432
HomePhcne j'"'"/*) 40 ""88
Rental Items
j SwiaWurnbei. Ca>eQO«y D$»eOut DdteRetumed МопЙЛуРее
►
| R*
cord
-
Г 478930^ jB «at cia^ei ' ' 1 UJ/lb/t-JU1 j" " j " %\7C&
556788 ^j jiiandaid vrohn ! ЮЧб'ЛЮ' | ' ; J S2725"
! Uf 1 1 " " !
|§^^§Pjrf3
гасяишЕ=сэиг Tol3l M4-,
Ml 111 ! _iJ_Hii*Jof 2
I iijiijil ишшшшщшшшшт
Treble Clef Music —
ГЙ
[Re
•i#
••Cat
aINurobiM j 478390
tgory |B tla> ;i3rmet
DICES
;..; tnyoiceN umber h\oie<-;Date
HF
te
1 Re
cord
j 100087 рОЛб;?001"|
;р:;Х:^Ш--:-''- "' • ::
Instrument Data Form
MortNyFee j 11 ?
F.er.»ed> j lo
Total
144 75
.-IQJXIJ
-
j 1 j
cord- и! *.l! i v.l»'i>*l of i
l<| >:}| l.:= ► |H.>»l0f 3
Г
Рис. 1.5. Формы, используемые бюро Treble Clef: a — информация о покупателе;
б — договор аренды; а — сведения об инструменте

30 Глава 1. Введение в базы данных
Чтобы уяснить проблемы, которые необходимо преодолеть в
многопользовательской базе данных, представьте себе, что произойдет, если два клиента
одновременно попытаются взять напрокат один и тот же кларнет си бемоль. СУБД
и прикладная программа должны каким-то образом обнаружить эту ситуацию
и сообщить служащим, что им следует выбрать другой инструмент.
Бюро лицензирования и регистрации
Рассмотрим теперь еще более обширное приложение технологии баз данных —
государственное бюро регистрации автомобилей и выдачи водительских прав.
В него входят 52 центра, где принимаются экзамены по вождению и
осуществляется выдача и продление прав, а также 37 офисов, занимающихся регистрацией
транспортных средств.
Персонал этих офисов использует в своей работе базу данных. Прежде чем
конкретному лицу будут выданы или продлены права, в базе данных
просматриваются сведения об этом лице на предмет наличия нарушений правил дорожного
движения, ДТП или задержаний. На основе этих данных принимается решение,
могут ли права быть продлены, и если да, то будут ли в них какие-либо
ограничения. Аналогичным образом, персонал в отделе регистрации автомобилей
обращается к базе данных, чтобы определить, был ли автомобиль зарегистрирован
ранее, а если был, то на чье имя, и нет ли каких-либо из ряда вон выходящих
причин, по которым в регистрации следует отказать.
У этой базы данных сотни пользователей, включая не только персонал,
занимающийся регистрацией и выдачей прав, но и служащих финансового
управления, а также сотрудников правоохранительных органов. Неудивительно, что база
является большой и сложной и имеет более 40 таблиц, причем некоторые из них
содержат сотни тысяч строк данных.
Большие организационные базы данных, подобные только что рассмотренной
нами, были первыми приложениями технологии баз данных. Подобные системы
находятся в эксплуатации уже в течение 20 или 30 лет и за этот период
неоднократно модифицировались в соответствии с менявшимися требованиями времени.
Существуют организационные базы данных, предназначенные для ведения счетов
в банках и других финансовых институтах, учета готовой продукции и
комплектующих иа складах больших предприятий, обработки медицинской
документации в госпиталях и страховых компаниях, а также для правительственных нужд.
Сегодня многие организации модифицируют прикладные программы своих
баз данных, чтобы дать клиентам возможность обращаться к этим данным и
даже вносить в них изменения через Интернет. Если вы работаете на большую
организацию, то вас вполне могут подключить к подобному проекту.
Туристический информационный центр
Калверт-Айленд — это прекрасный, но малоизвестный остров на западном
побережье Канады. Для продвижения острова на мировой туристический рынок
Совет по коммерции Калверт-Айленда разработал сайт, преследующий три цели:

Четыре примера применения баз данных 31
♦ рекламу природных условий Калверт-Айленда, а также мест отдыха и
развлечений;
♦ запись имен и адресов посетителей сайта для последующей рассылки пм
рекламной информации;
♦ прием запросов на бронирование мест в гостиницах, аренду коттеджей
и туристическое обслуживание, а также направление этих запросов
соответствующим фирмам.
Для поддержки этого сайта используются две базы данных. Первая из них —
рекламная — содержит данные, фотографии, видеоклипы и звуковые фрагменты,
дающие представление о природе Калверт-Айленда, возможностях острова в
сфере отдыха и развлечений и происходящих событиях. У этой базы данных есть
два типа пользователей. Обычные пользователи имеют доступ к ней только для
чтения. Пользуясь стандартными браузерами, эти пользователи могут
исследовать сайт в поисках интересующих их сведений об острове. В этом им помогает
прикладная программа, извлекающая данные и мультимедийные элементы из
рекламной базы данных (рис. 1.6).
: -5 ШШШ^^ШШтШШ^ШШШШШШ^Ш^ШШШ^Ш^ШШШШ^^Ш:
'•• ffai =. £*::;:' $W'V'.£© •';: favqifc**:';' |^dp; *f
ь^ШЬивЯ
^й*&'::;.•*:.•. '$.?<r#&iy^ :.;'$tap ^ RefreshJr-Heme'-' i ' Search ;• Fe«^*«''';Misl'o^':.'; Channel .•>: Mscter
j-Addew |£] ЬНр.//1(жаЬ*(УсаЫУ1-а1т«.а$р 3 . i LWw!
Calvert Island Reservation Centre Application I View/Edit ^J
Facility:: Activity Center
Things to Once you've arrived at Calvert Island» you can choose among many vaned
do: activities.
d
0Й::|ЩП::*< 'й'- l*%ltttiJr*^Z<X*:
Ш
Рис. 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
Ричарде
Коллективная Бюро проката музыкальных < 25
инструментов Treble
Clef Music
Организационная Бюро лицензирования Сотни-тысячи
и регистрации автомобилей
Сетевая Туристический Сотни-тысячи
(Интернет) информационный центр
Калверт-Айленда
Отношения между прикладными
программами и СУБД
Все предыдущие примеры и, разумеется, все приложения технологии баз данных
имеют общую структуру, показанную на рис. 1.7, — пользователь
взаимодействует с прикладной программой, которая, в свою очередь, взаимодействует с СУБД,
обращающейся к данным в базе.
< 1 о Мбайт
< 100 Мбайт
> 1 Тбайт
Любой

34 Глава 1. Введение в базы данных
Когда-то граница между прикладной программой и СУБД была четко
определена. Приложения писались на языках третьего поколения, таких как COBOL,
и обращались к СУБД за услугами по обработке данных. Фактически, так дело
обстоит до сих пор, чаще всего в базах данных, располагающихся на больших ЭВМ.
I
<—Н
Приложение,
обрабатывающее
данные клиентов
Пользователь
I
Приложение,
обрабатывающее
информацию
о прокате
Пользователь
№
<—►
Другие
приложения
Пользователи
Рис. 1.7. Отношения между пользователями, приложениями
базы данных, СУБД и базой данных
Сегодня, однако, возможности и функции многих коммерческих СУБД
расширились настолько, что СУБД могут самостоятельно выполнять значительную
часть функций, ранее находившихся в ведении прикладных программ.
Например, в большинстве коммерческих СУБД есть генераторы отчетов и форм,
которые можно встраивать в приложения. Этот факт важен для нас по двум
причинам. Во-первых, хотя основной объем этого текста посвящен проектированию
и разработке баз данных, мы часто будем уделять внимание проектированию и
разработке приложений. В конце концов, ни одному пользователю не нужна база
данных как таковая. Пользователям скорее нужны формы, отчеты и запросы по
их данным.
Во-вторых, время от времени вы будете замечать, что материал этого курса
в чем-то пересекается с материалом курса системного программирования,
поскольку разработка эффективных приложений баз данных требует многих
навыков из тех, что вы приобрели или приобретете в ходе изучения курса системного
программирования. И наоборот, в большинство современных курсов системного
программирования входит такая тема, как проектирование баз данных. Различие
между двумя курсами заключается в расстановке акцентов: здесь мы делаем
упор на проектирование, построение и обработку базы данных, а в курсе
системного программирования — на разработку информационных систем, большинство
из которых использует технологию баз данных.

Системы обработки файлов 35
Системы обработки файлов
Лучший способ уяснить общую природу и свойства современных баз данных —
рассмотреть характеристики систем, существовавших до появления технологии
баз данных. При эксплуатации такого рода систем возникал ряд проблем,
которые технология баз данных помогла решить.
В первых деловых информационных системах группы записей хранились в
отдельных файлах; такие системы назывались системами обработки файлов (file-
processing systems). На рис. 1.8 приведены в качестве примера две системы
обработки файлов, которые можно было бы использовать в бюро проката Treble
Clef Music. Одна система обрабатывает данные клиентов, а другая —
информацию о прокате.
Хотя системы обработки файлов являются огромным усовершенствованием по
сравнению с ведением записей вручную, у них есть значительные ограничения:
♦ данные разделены и изолированы;
♦ значительная часть данных дублируется;
♦ прикладные программы зависят от форматов файлов;
♦ зачастую файлы несовместимы друг с другом;
♦ представление данных в виде, удобном для пользователя, оказывается
затруднительным.
Приложение,
обрабатывающее
данные клиентов
Файл
клентов
Пользователь
файла клиентов
Пользователь
файла клиентов
Приложение,
обрабатывающее
информацию
о прокате
Файл
проката
Рис. 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, б: файлы данных пользователя, метаданные,
индексы и метаданные приложений.
Биты
Байты, 1
или символы Г*
Поля
Записи
Файлы
Биты
Байты,
или символы
Поля
Записи
Файлы "
+
Метаданные
+
Индексы
+
Метаданные
приложения^
Рис. 1.9. Иерархия элементов данных: a — в системах обработки файлов
иб-в системах баз данных
База данных является моделью модели
База данных представляет собой модель. Возникает соблазн сказать, что база
данных — это модель реальности или некоторой части реальности, относящейся
к бизнесу. Однако это неверно. База данных не моделирует реальность или какую-
либо ее часть, но является моделью пользовательской модели (user model).
Например, база данных Мэри Ричарде представляет собой модель того, как Мэри
видит свой бизнес. С ее точки зрения, ее бизнес состоит из клиентов, работ и
поставщиков клиентов. Поэтому в ее базе данных представлены факты, касающиеся
этих объектов. Имена и адреса клиентов, описание и временные рамки
производимых работ, имена поставщиков клиентов — все это данные, являющиеся
важными для ведения бизнеса в представлении Мэри.
Базы данных различаются по уровню детализации. Некоторые их них просты
и примитивны. Список клиентов и сумм, которые они должны заплатить, — вот

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

42 Глава 1. Введение в базы данных
в системах обработки файлов с феноменальной скоростью, но работать с этими
данными становилось все сложнее, и все более затруднительной оказывалась
разработка новых систем. Более того, менеджеры хотели иметь возможность
соотносить данные из одной файловой системы с данными из другой системы.
Ограничения файловой обработки препятствовали простой интеграции
данных. Технология баз данных, однако, выполнила обещание решить эти
проблемы, и крупные компании начали разрабатывать организационные базы данных.
В этих базах данных централизованно хранились и обрабатывались данные о
заказах, товарах и счетах предприятия. Эти приложения представляли собой
главным образом системы обработки транзакций организационного масштаба.
На первых порах, когда технология была еще несовершенной, приложения
баз данных были сложны в разработке и выдавали много ошибок. Даже успешно
работающие приложения были медленными и ненадежными: аппаратное
обеспечение того времени было не в состоянии быстро справиться с объемом
выполняемых транзакций, разработчики еще не изобрели более эффективные способы
хранения и извлечения данных, а программисты еще не освоили работу с базами
данных, и иногда их программы работали некорректно.
Обнаружен был и еще один недостаток баз данных — их уязвимость. Если
произойдет сбой в системе обработки файлов, из строя выйдет только одно
конкретное приложение. Если же сбой случится в базе данных, то выйдут из строя
все ее приложения.
Постепенно ситуация улучшилась. Разработчики аппаратного и программного
обеспечения научились создавать системы, достаточно мощные, чтобы
поддерживать большое количество параллельно работающих пользователей, и достаточно
быстродействующие, чтобы справляться с требуемым объемом транзакций.
Были разработаны новые способы контроля, защиты и резервного копирования баз
данных. Усовершенствовались стандартные процедуры обработки данных, а
программисты научились писать более эффективный и легкий для поддержания код.
К середине 1970-х базы данных были в состоянии эффективно и надежно
обрабатывать организационные приложения. Многие из этих приложений
используются до сих пор, более чем через 25 лет после их создания!
Реляционная модель
В 1970 г. Э. Ф. Кодд (Е. F. Codcl) опубликовал свою эпохальную статью1, в
которой он применил концепции раздела математики, называемого реляционной
алгеброй, к проблеме хранения больших объемов данных. Статья Кодда положила
начало движению в сфере проектирования баз данных, которое привело
несколько лет спустя к созданию реляционной модели базы данных (relational database
model). Эта модель представляет собой определенный способ структурирования
и обработки базы данных, и мы будем подробно обсуждать ее в главе 5, а также
в главах 9-14.
Е. Е. Codd, «A Relational Model of Data for Large Shared Databanks», Communications of the ACM,
06.1970, с 377-387.

История баз данных 43
Преимущество реляционной модели заключается в способе хранения данных,
который минимизирует их дублирование и исключает определенные типы
ошибок обработки, возникающие при других способах хранения данных. Данные
хранятся в виде таблиц со столбцами и строками, как показано на рис. 1.1.
Согласно реляционной модели, не все виды таблиц одинаково приемлемы.
С помощью процесса, называемого нормализацией (normalization),
нежелательная таблица может быть преобразована в две или более приемлемых. Более
подробно о процессе нормализации вы узнаете из главы 5.
Другое преимущество реляционной модели состоит в том, что в столбцах
содержатся данные, связывающие одну строку с другой. Например, на рис. 1.1
столбец CUSTOMER_JD в таблице 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. Определите термин база данных.
11. Что такое метаданные? Что такое индексы? Что такое метаданные
приложений?
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). Как вы думаете, сколько баз данных используется для поддержки
этого сайта — одна или несколько? Какими возможностями и функциями
данный сайт, по вашему мнению, в наибольшей степени обязан
технологии баз данных, если иметь в виду определение базы данных и
преимущества обработки баз данных?
Вопросы к проекту FiredUp
FiredUp, Inc. — небольшая компания, владельцами которой являются Керт и Джу-
ли Роубэрдс. Эта компания, находящаяся в Брисбэйне, Австралия, производит
и продает легкие походные горелки под названием FireNow. Керт, работавший
раньше аэрокосмическим инженером, изобрел и запатентовал сопло, которое не
дает огню в горелке погаснуть даже при очень сильном ветре — до 90 миль в час.
Джули, промышленный дизайнер по образованию, разработала элегантную
складную конструкцию, которая имеет небольшой вес и габариты, проста в установке
и весьма устойчива. Семья Роубэрдс производит горелки в своем гараже и
продает клиентам напрямую, принимая заказы через Интернет, по факсу и по почте.

Вопросы к проекту FiredUp 51
Владельцы FiredUp хотели бы отслеживать проданные горелки на тот случай,
если им понадобится войти в контакт с покупателями относительно дефектов
в изделиях и по другим вопросам, связанным с качеством изделий. Они также
думают, что смогут использовать список покупателей для рекламы других
изделий, если когда-нибудь разработают что-либо еще.
1. Как вы думаете, подойдет ли база данных FiredUp для хранения данных
о проданных горелках и их покупателях? Опишите условия, при которых,
по вашему мнению, база данных будет подходящим средством, а при
каких — неподходящим. Сформулируйте, при каких условиях им подойдет
персональная база данных. При каких условиях им может понадобиться
коллективная база данных? Интернет-база данных?
2. Решите ту же задачу применительно к регистрации кофейных автоматов,
продаваемых компанией Starbucks. Пусть, например, Starbucks хочет иметь
возможность хранить сведения о клиентах, которые приобрели в
магазинах этой компании автоматы для продажи кофе «эспрессо». Как
изменятся ответы па вопросы первого пункта?

Глава 2
Введение в разработку
баз данных
В этой главе в общих чертах рассматривается процесс разработки базы данных
и ее приложений. Мы начнем с описания элементов базы данных и обсуждения
характерных особенностей и функций СУБД. Далее мы проиллюстрируем процесс
создания базы данных и приложения для работы с ней. В заключение мы обсудим
популярные стратегии разработки баз данных. Цель этой главы состоит в том,
чтобы заложить основу для детального описания этой технологии, которое
последует в дальнейших главах.
База данных
На рис. 2.1 показаны основные компоненты системы базы данных. Базу данных
обрабатывает СУБД, которая используется разработчиками и пользователями,
обращающимися к СУБД напрямую или косвенно, через прикладные
программы. Данный раздел посвящен базе данных, а СУБД и прикладные программы
обсуждаются в следующих разделах.
Как вам уже известно из главы 1, база данных состоит из четырех основных
элементов: данных пользователя, метаданных, индексов и метаданных приложений.
Данные пользователя
Сегодня большинство баз данных представляют данные пользователя в виде
отношений (relations). Формальное определение термина отношение мы дадим
в главе 5. На данный же момент будем рассматривать отношение как таблицу
данных. Столбцы таблицы содержат поля, или атрибуты, а строки содержат
записи о конкретных объектах делового мира.
Не все отношения являются одинаково желательными; некоторые отношения
структурированы лучше, чем другие. В главе 5 описан процесс, называемый
нормализацией (normalization), с помощью которого получаются хорошо
структурированные отношения. Чтобы получить представление о разнице между плохо
и хорошо структурированными отношениями, рассмотрим отношение R1 (ИмяСту-

База данных 53
дента, ТелефонСтудента, ИмяРуководителя, ТелефонРуководителя),
содержащее имена и телефоны студентов и их руководителей:
ИмяСтудента
ТлфСтудента
ИмяРуковод
Тлфруковод
Бейкер, Рекс
Чарлз, Мэри
Джонсон, Бет
Скотт, Гленн
Зилог, Фрита
232-8897
232-0099
232-4487
232-4444
232-5588
Парке
Парке
Джонс
Парке
Джонс
236-0098
236-0098
236-0110
236-0098
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
Имя столбца
НомерСтудента
Имя
фамилия
Специальность
ИмяРуководителя
Телефон
Кафедра
НомерДисциплины
Название
КоличествоЧасов
НомерСтудента
НомерДисциплины
Курс
Имя таблицы
Студент
Студент
Студент
Студент
Руководитель
Руководитель
Руководитель
Дисциплина
Дисциплина
Дисциплина
УчебныйПлан
УчебныйПлан
УчебныйПлан
Тип данных
Integer
Text
Text
Text
Text
Text
Text
Integer
Text
Decimal
Integer
Integer
Text
Длина
4
20
30
10
25
12
15
4
10
4
4
4
2
Хранение метаданных в таблицах не только эффективно для СУБД, но и
удобно для разработчиков, поскольку для запроса метаданных они могут
использовать те же самые средства, что и для запроса пользовательских данных. В главе 9
мы обсудим язык под названием SQL, который используется для запроса и
обновления таблиц метаданных и пользовательских данных.
В качестве возможного примера использования SQL представьте, что вы
разработали базу данных с 15 таблицами и 200 столбцами. Вы помните, что
некоторые столбцы имеют тип данных currency, но не можете вспомнить, какие именно.
С помощью SQL можно обратиться к таблице SysColumns и по ней определить,
какие столбцы имеют указанный тип данных.
Индексы
Третий тип данных, которые хранятся в базе данных, призван улучшить ее
производительность и доступность. Эти данные, называемые иногда избыточпъши
данными (overhead data), состоят главным образом из индексов (indexes), хотя
в ряде случаев используются и другие структуры данных, такие как связанные
списки (индексы и связанные списки обсуждаются в приложении А).
В табл. 2.2 приведены данные о студентах и два индекса к ней. Чтобы
уяснить, какая может быть польза от индексов, представьте себе, что данные в
таблице СТУДЕНТ расположены в порядке возрастания значения поля НомерСтудента,
а пользователь хотел бы создать из этих данных отчет, отсортированный по по*
лю Фамилия. Для этого можно было бы извлечь все данные из таблицы и
отсортировать, но, если размеры таблицы не слишком малы, этот процесс может
занять много времени. В качестве альтернативы можно создать индекс Фамилия,
приведенный в табл. 2.2. Записи в этом индексе отсортированы по полю Фамилия,
Длины приведены в байтах или, что то же самое, в символах (для текстовых данных).

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), которое выполняет
функцию посредника между подсистемой средств проектирования и обработки
и данными. Ядро СУБД получает запросы от двух других компонентов,
выраженные в терминах таблиц, строк и столбцов, и преобразует эти запросы в команды
операционной системы, выполняющие запись и чтение данных с физического
носителя.
Кроме того, ядро СУБД участвует в управлении транзакциями, блокировке,
резервном копировании и восстановлении. Как будет показано в главе 11,
действия с базой данных должны выполняться как единое целое. Например, при
обработке заказа изменения в таблицах КЛИЕНТ, ЗАКАЗ и СКЛАД должны
производиться согласованно: либо выполняются все, либо не выполняется ни одно. Ядро
СУБД помогает координировать действия, с тем чтобы либо выполнялись все
действия в группе, либо не выполнялись ни одного.
Microsoft предоставляет два различных ядра для Access 2002: Jet Engine и SQL
Server. Ядро Jet Engine используется для небольших персональных и
коллективных баз данных. Ядро SQL Server, представляющее собой независимый продукт
Microsoft, предназначено для крупных баз данных уровня отдела и небольших
В английском языке подсистема обработки обозначается термином ?rin-time subsystem. He следует
путать его с похожим термином 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, Dateln, DateOut),
содержащую данные об инвентаре. Здесь перед скобками даны имена таблиц, а в
скобках указываются имена столбцов.
Ни CaptainName (имя капитана), ни Description (описание) не обязаны быть
уникальными, поскольку вполне может быть два капитана по имени Мэри Смит,
и уж наверняка имеется много инвентаря под названием «футбольные мячи».
Чтобы обеспечить однозначную идентификацию каждой строки (важность этого
будет объяснена в последующих главах), мы добавим в каждую из этих таблиц
столбец с уникальным номером, как показано ниже:
CAPTAIN(CAPTAIN_ID, CaptainName, Phone, Street, City, State, ZIP)
ITEM(ITEMJD, Quantity, Description, Dateln, DateOut)
Связи
Две представленные здесь таблицы имеют следующие связи: одна строка
таблицы CAPTAIN связана с несколькими строками таблицы ITEM, но одна строка
таблицы ITEM связана с одной и только одной строкой таблицы CAPTAIN. Такая связь
обозначается 1:N и произносится «один kN» или «один ко многим». Обозначение
Как будет показано в главах 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, Dateln, DateOut, CAPTAIN JD)
При такой структуре легко определить, какому капитану был выдан данный
инвентарь. Например, чтобы узнать, кому был выдан инвентарь за номером 1234,
в соответствующей строке таблицы ITEM мы найдем значение CAPTAIN JD. По
этому номеру мы сможем определить имя и номер телефона данного капитана.
Домены
Домен1 (domain) — это множество значений, которые может принимать
столбец. Рассмотрим домены для столбцов таблицы ITEM. Предположим, что ITEMJD
и Quantity (количество) — целые числа, Description — текст с максимальной
длиной 25 символов, Dateln и DateOut (даты выдачи и возврата) имеют тип «дата»,
a CAPTAINJD также является целым числом. Кроме задания физического
формата, нам также необходимо решить, будут ли какие-либо из доменов уникальными
для данной таблицы. В нашем примере мы хотим, чтобы столбец ITEMJD был
уникальным, поэтому необходимо указать это в определении домена. Поскольку
капитану может быть выдано более одной единицы инвентаря, столбец CAPTAIN^
ID не является уникальным для таблицы ITEM.
Необходимо также задать домены для столбцов таблицы CAPTAIN. CAPTAIN JD
является целым числом, а все остальные столбцы — это текстовые поля
различной длины. CAPTAIN JD должен быть уникальным для таблицы CAPTAIN.
Деловой регламент
Последний элемент схемы базы данных — это деловой регламент (business rules),
представляющий собой ограничения на возможные действия пользователя,
которые необходимо отразить в базе данных и ее приложениях. Примером делового
регламента для колледжа Highline может служить следующий набор правил:
1. Чтобы капитан мог получить на руки какой-либо инвентарь, у него
должен быть местный телефон.
2. Ни за одним капитаном не должно числиться более семи футбольных
мячей.
3. По окончании каждого семестра капитаны обязаны возвратить весь
инвентарь в течение пяти дней.
4. Капитан не может получить на руки новый инвентарь, если у него имеется
задолженность по ранее взятому инвентарю.
Это определение значительно упрощено, с тем чтобы сконцентрироваться на компонентах системы
базы данных. Более полное обсуждение доменов происходит в главе 4.

Создание базы данных 61
Деловой регламент является важной частью схемы, поскольку он задает
такие ограничения на возможные значения данных, которые должны выполняться
в любом случае, независимо от того, каким образом изменения достигают ядра
СУБД. Не важно, что является источником запроса на изменение данных —
пользователь формы, запрос на обновление/чтение или прикладная программа:
СУБД должна позаботиться о том, чтобы эти изменения не нарушили никаких
правил.
К сожалению, реализация делового регламента осуществляется в различных
СУБД по-разному. В Access 2002 некоторые правила могут задаваться в схеме и
выполняться автоматически. В таких продуктах, как SQL Server и Oracle, деловой
регламент реализуется с помощью так называемых хранимых процедур (stored
procedures). В некоторых случаях СУБД оказывается неспособной реализовать
выполнение требуемых правил, и их приходится закладывать в прикладные
программы. Мы обсудим эту тему более подробно в главе 10.
Создание таблиц
Следующим шагом после разработки схемы базы данных является создание
таблиц. Для этого используются специализированные средства, предоставляемые
СУБД. На рис. 2.4 показан вид окна, используемого Microsoft Access при создании
таблицы ITEM. Имя каждого столбца создаваемой таблицы указывается в столбце
Field Name (Имя поля), а тип данных задастся в столбце Data Type (Тип данных).
В столбце Description (Описание), не обязательном к заполнению, даются описания
столбцов таблицы и комментарии. Дополнительные данные по каждому
столбцу — количество символов, формат, заголовок и прочее — указываются в полях
ввода группы Field Properties (Свойства поля), расположенной в нижней части окна.
На рис. 2.2 фокус ввода находится на столбце ITEMJD. Обратите внимание,
что свойство Indexed (Индексируется) в нижней части окна установлено в значение
Yes (No Duplicates), что означает, что для столбца ITEMJD должен быть создан
индекс из уникальных значений. Таблица CAPTAIN создается аналогичным образом.
Определение связей
Связь между таблицами CAPTAIN и ITEM имеет вид 1:N, что изображается на схеме
путем помещения ключа таблицы CAPTAIN в таблицу ITEM. Столбец, играющий ту
же роль, что и столбец CAPTAINJD в таблице ITEM, называется иногда внешним
ключом (foreign key), поскольку он является ключом таблицы, внешней по
отношению к той таблице, в которой он находится. При создании форм, запросов и
отчетов СУБД может оказать большую помощь разработчику, если она знает, что
столбец CAPTAIN_ID в таблице ITEM является внешним ключом таблицы CAPTAIN.
В различных СУБД статус внешнего ключа объявляется по-разному. В Microsoft
Access для этого рисуется связь между ключом и внешним ключом, как показано
на рис. 2.3. Столбец CAPTAINJD основной таблицы (CAPTAIN) соответствует
столбцу CAPTAIN JD в связанной с ней таблице (ITEM).

62 Глава 2. Введение в разработку баз данных
•»inixj
ITEMJD|
Quantity
Description
DateOut
Datejn
captain" id
AutoNumber
Number
Text
Date/Time
Date/Time
Number
Surrogate key
Quantity checked out
Descntion of item
: Date checked out
Date checked in
■ Foreign key for i ;N relationship to CAPTAIN
ШЩШЙЩШ^: ;
General J Lookup |
FieMSte*1
ЫеЦ-Шв*
Format:.!■■■■
Captibnl -;
inde^cf:;:;
^У1111Ш11111111111':
t:rg Integer
Ircrement
res i^fic Z'Lplicates'
\Afieldnaiflfr.canbeup to
| ertcN^&ersfong,
i ^uding; spaces. Press
Г Fl fcf-h^p .on ftefc}
Рис. 2.2. Создание таблицы в Microsoft Access 2002
1,11-1
з
ТаЫе/Queryt
J CAPTAIN
I CAPTAIN JD
1
1
Related Table/Query:
jJlTEM
jj CAPTAIN JD
d
й
Лснп Type,,
'Г* EnforceR.ef eventsintegrity-
Relationship Tyoe:J:y!$pe-To-Man>
Рис. 2.З. Объявление связи в 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. Введение в разработку баз данных
|jji^LUj.',"iHiiiyyiii.. шшшшшшштштшшштт
f5
■. J CeptainN^^^vi^l^^Pftcfhe-^^jP^-*-" ■ :\>'$1&ШШ&*Р'->.ь
+
Miyamoto, Mary '398 232 1770 McGilvra Hall #544
Abernathy, Mary Jayne 223 768 3378 777 East Fiftieth
~¥
Qga;ntity ■•; |;:;:У||::-.:-.Description-: | ■ ^DateOirt^ |
14 Soccer Shirts 3/22/2001
5.Soccer Balls 3/22/2001
o;
+ Jackson, Stephen ; 331.442.1454 300 East Centerview Apt 21
cor
d: _
«1 #1 i $*A+W*]tf.3-x^£}>
Iflfjf |1|1^Ш|11|Ь| *|!
j,-. City -<ШШ1Жгр li
Campus
Chicago
Datefn
6/3/2001
6/3/2001
Evanston
ML ";323398
ML ^22343 ■;
6
НЭ Captain СЬесклЛ;Рй!1^;:П::--й:^Щ=ЙЩ||^ЩШ|
►
Re
Ca
Ph
ptainName JAbernathy, Mary Jayne
one J223 768 337
ITEM
Quantify Description
►
cprc
j" 14 j Soccer Shirts
j 5 )Soccer Balis ~ "
If r-jiz
cord: И I <..] j "_: Г ► Mn-j of 2
1; Hj < 11 2 ► ]HJ»*j of 3 .
ЙЩйй?:8!:Ш:й^'::й?:^.' '■ y''
Street
City
State
|"7Ea>rFiNeihJ
r:,:ago
fr 2p rs:
DateGui Dataln Л
"]3/22>200l"j 6/3/2001
*]3/22/2C0T'] Б/3/2007 -J
"1 1 J
.„Jq.jxlj
зэе i
!
.,
в
ы^тшшвш^ш^ш^^^^^^^^^^^т^. ^m*i\
CaptainNaw.
Phone:
Street:
C*y:
State:
Zip'.
Captain Registration Page 1
|3ackson, Steohen 1!
|зЗМ42.1 1
1300 East Centerview Apt 22 j j
j Evanston
nr— !
122343 '
ч captain2 of 3 ;|j|i ■ ■ v'►;£>!;>■ ■ ►* ^|Ш|$-||;'^^:;':Щ^ j!
Рис. 2.4. Представление данных из таблиц CAPTAIN и ITEM: a — табличный формат;
б — форма для ввода данных; в — форма для ввода данных в браузере
Ни в одной из представленных форм не отображаются столбцы CAPTAIN_ID
и ITEM__ID. Эти идентификаторы скрыты от пользователя. Но СУБД
автоматически присваивает им новые значения, когда пользователь создает новые строки
в таблицах CAPTAIN или ITEM. Так, когда пользователь открывает пустую фор-

Компоненты приложения 65
му, СУБД автоматически создает новую строку в таблице CAPTAIN и присваивает
значение столбцу CAPTAINJD этой строки. Каждый раз, когда пользователь
создает для капитана новую строку в таблице ITEM, СУБД присваивает значение
столбцу ITEM_ID этой строки, а в столбец CAPTAINJD новой строки помещает
текущее значение CAPTAIN_ID. Обратимся вновь к рис. 2.2. Для столбца ITEMJD был
заявлен тип данных AutoNumber (Автонумерация). Это предписывает Access
автоматически присваивать ITEM_ID новые значения всякий раз, когда
создаются новые строки в таблице ITEM. При создании таблицы CAPTAIN (не показана на
рисунке) аналогичный вариант был выбран и для CAPTAIN_ID. Заметьте, однако,
что для столбца CAPTAIN_ID в таблице ITEM автоматическая нумерация не
задается. Это обусловлено тем, что новое значение CAPTAINJD присваивается при
добавлении строки в таблицу CAPTAIN; это значение затем копируется в поле
CAPTAINJD таблицы ITEM, когда строка этой таблицы привязывается к
определенному капитану.
File gdJt_. View':.. Insert Format Tools Window Hdp .:.■■■...'
CaptamNarre - ' Tahoma -8 В 1 U Щ: Ж ^1 &* ~ A * .$ -■ :'"""U c=> ▼ J
Make cliject visible? NUM A
Рис. 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 знает, что две эти таблицы
связаны через CAPTAINLID, как показывает линия на рис. 2.6 между двумя
прямоугольниками, символизирующими таблицы.
Б Microsoft Access -IQuery t vSelfctt Омегу}
£jfp File Edit V«w insert Query Ipols )$Щ**к-\$№'
fii- ! <fa z ai - 5F> ©:W-::<5L
CAPTAINJD
CaptainName
Phone
Street
City
State
,Zip
4
\
ПЕМ_Ю
Quantity
Description
lOateOut
Dateln
CAPTAIN JD
1
J
Field I CaptainName
TatAe'
So*1:'
Criteria:
Quantity
ITEM
Description
a
<#9/t/2O0t*|
lLL
Й
id
Рис. 2.6. Создание запроса в Microsoft Access 2002

Компоненты приложения 67
Далее указывается, какие столбцы данных следует возвращать в запросе.
В Access это делается путем перетаскивания имен столбцов из прямоугольников,
символизирующих таблицы, в ячейки в нижней части формы. На рис. 2.8 в запрос
помещены столбцы CaptainName, Phone, Quantity, Description, DateOut и Dateln. После
этого в строке Criteria (Критерии) указываются критерии запроса. Критерии
сейчас заключаются в том, что данные должны датироваться числами,
предшествующими (<) 1 сентября 2001 г. (9/1/2001 в американских обозначениях). Знак
«#» в форме — это символ, который окружает даты в Access. Кроме того,
значение Dateln должно быть равно нулю (Is Null); это означает, что для Dateln
значение не задано. Результат этого запроса приведен на рис. 2.7. Обратите внимание,
что весь показанный здесь инвентарь был выдан до 1 сентября 2001 г., что и
требовалось в определении запроса.
В Access и большинстве других СУБД запросы можно хранить как часть
приложения, так что впоследствии при необходимости они могут быть
выполнены повторно. Кроме того, запросы могут быть параметризованными, то есть
построенными так, чтобы значения параметров для них можно было
задавать прямо перед выполнением. Например, можно параметризовать запрос,
изображенный на рис. 2.6, так, чтобы пользователь вводил значение DateOut
непосредственно перед выполнением запроса. В результате будет показан весь
инвентарь, выданный на руки до указанной даты, но до сих пор не
возвращенный.
Третий тин запроса, более легкий для пользователей, называется запросом
из формы (query by form). В этом случае пользователь вводит критерии запроса
в форму для ввода данных и нажимает кнопку поиска. СУБД находит все данные,
соответствующие заданным критериям. В нашем случае в форме на рис. 2.4
пользователь ввел бы <#9/1/2001# в поле DateOut и Is Null в поле Dateln. после
чего нажал бы кнопку QueryByForm (Запрос по форме). СУБД нашла бы записи для
всех капитанов, отвечающие указанным критериям запроса. Запрос по форме
является более новым и современным способом запроса данных, чем запрос по
образцу, и, скорее всего, заменит его во многих приложениях.
Рис. 2.7. Результат запроса, приведенного на рис. 2.6

68 Глава 2. Введение в разработку баз данных
Отчеты
Отчет (report) — это форматированное отображение информации из базы
данных. Отчет на рис. 2.8 содержит по одному разделу на каждого капитана
команды, и в каждом таком разделе приведен список инвентаря, выданного на руки
данному капитану. Например, инвентарь, выданный капитану по имени Мэри
Миямото (Mary Miyamoto), показан в первом разделе отчета.
Captain Equipment Report
vf ■*■?>•;+; <?y+x,:i*:-5?fS!'JS >$&&&'<^'.*\,?:&$&'!Х Ik?.
j CaptainName Miyamoto, Mary
\ Phone 398.2311770
DateOut Quantity Description Dateln
4/1/2001 1 Coaches Manual
4/1/2001 7 Soccer Balls 6/10/2001
4/10/2001 25 Blue Soccer Shirts 6/10/2001
j CaptainName Abernalhy, MaryJayne
\ Phone 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 J D содержит персональные данные капитана и метки для раздела
содержимого. В разделе содержимого отображается инвентарь, выданный
капитану.

Компоненты приложения 69
Ы Microsoft Access - [Captain Equipment R«mm* : Reporfl
:S.Fte .gtft ..-View Insert Fgrmat Tods Wjndow Мф
; Report - • ' .
# П:
д eg1 ..> Э с - 3 -
Sf
u\
■f Repe»t Heady
Captain Equipment Report
4 Pagie Header
«CAPTAIN Г0 Header
Phone \:?honi? ' J-
D4teOuil.Quartfity Description
«РеЫ
Dti&IX
СчгЧ-'-Л JS.QUWIMt [riC-^I.Qn
«Page Foot a
*F Repot r Fax*
"Azp '; jkfftqp/A )(и/ ' 4 #»5«У i
!ГГ
*td
Design View
Рис. 2.9. Разработка отчета в Microsoft Access 2002
Недостаток этого отчета в том, что два поля с датами оказываются
разделенными. Отчет выглядел бы лучше, если бы мы поместили поле DateOut между
полями Description и Dateln. Это делается путем элементарного перетаскивания
меток и текстовых полей, и именно таковы типичные изменения, которые
делаются с помощью подобных инструментов.
Вообще говоря, отчеты могут иметь много разделов. В более сложном
примере, таком как распределение студентов по курсам, отчет мог бы быть
сгруппирован по таблицам КОЛЛЕДЖ, КАФЕДРА, ДИСЦИПЛИНА и СТУДЕНТ. В этом случае он
имел бы три полосы заголовков и строку содержимого.
Меню
Меню (menus) предназначены для того, чтобы сделать компоненты приложения
более доступными для конечного пользователя, а также для контроля действий
пользователя. На рис. 2.8 показан пример меню для колледжа Highline. В полосе,
находящейся в верхней части формы, изображены пункты меню верхнего уровня:
File (Файл), Forms (Формы), Queries (Запросы), Reports (Отчеты) и Help (Помощь).
Подчеркнутые буквы представляют «горячие» клавиши (hotkeys). Если
удерживать клавишу <Alt>, нажимая при этом клавишу с подчеркнутой буквой,
откроется соответствующее подменю.
На рис. 2.10 пользователь нажал клавиши <Alt> + <5>. Выбранное подменю
состоит из следующих пунктов: Select All Records (Выбрать все записи), Select by Name
(Выбрать по имени) и Select by Phone (Выбрать по номеру телефона). В свою
очередь, каждый из этих пунктов можно выбрать с помощью «горячих» клавиш,
нажимая <ALt> и нужную клавишу. Меню делают приложение более доступным

70 Глава 2. Введение в разработку баз данных
для пользователя, показывая существующие варианты выбора и помогая выбрать
желаемое действие. Меню могут также использоваться для управления доступом
пользователей к формам, отчетам и программам. Некоторые приложения
пользуются этим, динамически изменяя меню после того, как пользователь
зарегистрируется (sign on).
Прикладные программы
Последний компонент приложения базы данных — это прикладные программы
(application programs). Как мы уже упоминали ранее, такие программы могут
быть написаны на входном языке СУБД или на стандартном языке, работа
которого с СУБД обеспечивается через специальный программный интерфейс. Здесь
мы будем пользоваться Microsoft Visual Basic в сочетании с Access 2002.
* Htshime хтшштшшш щшштт
шш
■ №:
РШШ::';|:|0|^^ Нф£!
шшшшшшт
Рис. 2.10. Пример меню
ЁШШШШШШШМШШШШ
>^тт
ii
\
<F-Defce* -У:
Ш Text Вон: Description
■jDescnption
^[CaptamName
ЩХ1
•{phone
Before Update . . ,' r'.: '*
J
Afte/ Update ,
\\\Ш:' '\ЩшШЩЩР1 ..OnCtoty . .
♦ F о* m Header
:-Ш11Щ^1Ц^^;':.Ъ«С!«А№-
# Detail '■..'.-
±L
|lT£M_IDJQuanWy jbescnption
351
On Undo« ! ;'i . . . .
On Change. <
On Enter.
On Exit> . . ; . . ,
On Got Focus ... ,
On lost Focus .....
On dick,
Or, 0Ы Click
*J
1
[Event,Procedure]| rlr, J -—I
zi
-p.
Рис. 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.
£fe £dt View Insert Debug Run Tools Add-!ns Window £ф/
■ Jafxj
0^4
► и тЫ Ы&ЪЯ'(-Щй$Ы-р:,
•Зй $& acwzmain (ACWZMAIM)
Б-|£ IH2DB1(CH2DB1)
В -'Ч Microsoft Access Class Obje._i-
Ш fwthJTEMSubfam
iL
J Description Textbox
^'Alphabetic fciigitaiHJs v
^d
[ColumnWtdth
kortrobource
CootroiTipText
ControlType
pecimaJPtaces
beFauKValue
pisplaywhen
enabled
[EnterKev6ehavior
|дшаши
:2310
iDescfiptnn
;109
io
0
jTrue
'False
| Desertion
-1
J
■Ш
шшммшишм
-»j;. Ichange
«s
||«UisJj<fi
~3
^civate Sub Description Change О
If Forma'[Captain Checkout Form]'City.Value <> "Campus" Then
If InStr(Description.Text, "Coaches Manual") > 0 Then
Beep
MsgBox ("Off campus coaches cannot checkout coaches manual")
Description.Text - ""
End If
1
Рис. 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
Mary В. Wu
продавца
Регион
Западный
Западный
НазваниеКомпании
Cabo Controls
Ajax Electric
American Maxell
ДатаЗаказа
9/12/2001
9/17/2001
9/24/2001
Общая сумма:
Сумма
$2,349,83
$2,349,88
$23,445,00
$17,339,44
$40,784,44
$43,134,32
Отчет о комиссионных продавца
03 октября 2001
Имя МестныйНомер ДатаВыпискиЧека ТипКомиссионных СуммаКомиссионных
I Kevin Dougherty 232-9988
MaryB.Wu 232*9987
9/30/2001
9/30/2001
9/30/2001
xz
с
A
Общая сумма:
$487,38
$487,38
$237,44
$1,785,39
$2,022,83
$2,510,21
Рис. 2.13. Примеры двух связанных отчетов: а — отчет о продажах
и б — отчет о комиссионных

Процесс разработки базы данных 75
Заказы, перечисленные в отчете на рис. 2.13, 6, каким-то образом связаны с
заказами, перечисленными на рис. 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 г., но

Вопросы к проекту FiredUp 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 P. P. Chen, «The Entity-Relationship Model — Towards a Unified View of Data», ACM Transactions on
Database Systems, январь 1976, с. 9-36.
2 Thomas A. Bruce, Designing Quality Databases with IDEF1X Information Modeh (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-10th Avenue
Boston
MA
01234
Frita Bellingsley
210-8896
Рис. З.1. КЛИЕНТ: пример сущности
Атрибуты
У сущностей есть атрибуты (attributes), или, как их иногда называют, свойства
(properties), которые описывают характеристики сущности. Примерами
атрибутов могут служить Имя Сотрудника, ДатаНайма и КодКвалификации. В тексте этой
книги атрибуты обозначаются как прописными, так и строчными буквами. В
модели «сущность—связь» предполагается, что все экземпляры данного класса
сущностей имеют одинаковые атрибуты.
Исходное определение модели «сущность—связь» включает в себя
композитные атрибуты (composite attributes) и многозначные атрибуты (multi-valued
attributes). В качестве примера композитного атрибута можно привести атрибут
Адрес, состоящий из группы атрибутов {Улица, Город, Штат, Индекс}. Примером
многозначного атрибута может служить атрибут ИмяДоверенногоЛица сущности
КЛИЕНТ, который может содержать имена нескольких доверенных лиц данного
клиента. Атрибут может быть одновременно и композитным, и многозначным —

84 Глава 3. Модель «сущность—связь»
например композитный атрибут Телефон, состоящий из группы атрибутов {Код-
Региона, МестныйНомер}, может быть многозначным, что позволит иметь в базе
данных несколько телефонных номеров одного и того же лица. В большинстве
реализаций модели «сущность—связь» однозначные композитные атрибуты
игнорируются, и требуется, чтобы многозначные атрибуты (будь они составные
или нет) преобразовывались в сущности, как будет показано ниже.
Идентификаторы
Экземпляры сущностей имеют идентификаторы (identifiers) — атрибуты, с
помощью которых эти экземпляры именуются, или идентифицируются. Например,
экземпляры сущностей класса СОТРУДНИК могут идентифицироваться по
атрибутам НомерСоциальнойСтраховки, ТабельныйНомерСотрудника или ИмяСотрудника.
Такие атрибуты, как Зарплата или ДатаНайма, вряд ли могут служить
идентификаторами экземпляров сущностей класса СОТРУДНИК, поскольку обычно эти атрибуты
не используются для однозначного указания на конкретного сотрудника.
Подобно этому, сущности класса КЛИЕНТ могут идентифицироваться по атрибутам
НомерКлиента или ИмяКлиента, а сущности класса ЗАКАЗ могут
идентифицироваться по атрибуту НомерЗаказа.
Идентификатор экземпляра сущности состоит из одного или более атрибутов
сущности. Идентификатор может быть уникальным (unique) либо неуникальным
(nonunique). Если идентификатор является уникальным, его значение будет
указывать на один и только один экземпляр сущности. Если идентификатор
является неуникальным, его значение будет указывать на некоторое множество
экземпляров. ТабельныйНомерСотрудника является, скорее всего, уникальным
идентификатором, а ИмяСотрудника — неуникальным (например, может быть
несколько сотрудников по имени Джон Смит).
Идентификаторы, состоящие из нескольких атрибутов, называются
композитными идентификаторами (composite identifiers). Примерами могут служить
совокупности вида {КодРегиона, МестныйНомер}, {НазваниеПроекта, НазваниеЗадачи}
и {Имя, Фамилия, ДобавочныйНомерТелефона}.
Связи
Взаимоотношения сущностей выражаются связями (relationships). Модель
«сущность—связь» включает в себя классы связей и экземпляры связей1. Классы
связей (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, а связь СЛУЖЕБНЫЙ_АВТОМОБИЛЬ
связывает одиночную сущность класса СОТРУДНИК с одиночной сущностью класса
АВТОМОБИЛЬ. В соответствии с этой диаграммой, ни за одним сотрудником не
закреплено более одного автомобиля, и ни один автомобиль не закреплен более чем
за одним сотрудником.
СОТРУДНИК
м>
АВТОМОБИЛЬ
СЛУЖЕБНЫИ-АВТОМОБИЛЬ
а
ОБЩЕЖИТИЕ
СТУДЕНТ
ОБЩЕЖИТИЕ-ЖИЛЕЦ
б
СТУДЕНТ
КЛУБ
СТУДЕНТ-КЛУБ
СТУДЕНТ
ОБЩЕЖИТИЕ 1Щ№ЩУ^ СТУДЕНТ
IT-
КЛУБ
Рис. 3.3. Три типа бинарных связей: а — бинарная связь 1:1; б ~ бинарная связь 1:14;
в — бинарная связь N:M; г — представление связи с помощью разветвлений
На рис. 3.3, б изображен второй тип связи, 1:N («один к N» или «один ко
многим»). В этой связи, которая называется ОБЩЕЖИТИЕ-ЖИЛЕЦ, единичный
экземпляр сущности класса ОБЩЕЖИТИЕ связан со многими экземплярами сущно-

86 Глава 3. Модель «сущность—связь»
сти класса СТУДЕНТ. В соответствии с этим рисунком, в общежитии проживает
много студентов, но каждый студент живет только в одном общежитии.
Позиция, в которой стоят 1 и N, имеет значение. Единица стоит на той
стороне связи, где располагается ОБЩЕЖИТИЕ, а 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. Имя сущности указывается внутри прямоугольника, а имя связи
указывается рядом с ромбом.
ОБЩЕЖИТИЕ
C1:N
СТУДЕНТ
ОБЩЕЖИТИЕ-СТУДЕНТ
Рис. 3.4. Связь с указанной минимальной кардинальностью
Описываемые здесь графические символы, которые берут начало в этой модели, не являются
лучшим способом отображения модели в системе с графическим интерфейсом пользователя, подобной
Macintosh или Microsoft Windows. Фактически модель «сущность—связь» была разработана задолго
до того, как какая-либо система графического интерфейса приобрела популярность. Символы
языка UML, которые будут представлены позже в этой главе, легче использовать в графической среде.

Элементы модели «сущность—связ^» 87
Хотя в некоторых ER-диаграммах имя связи указывается внутри ромба,
получающаяся при этом диаграмма может выглядеть ужасно, поскольку ромбы
приходится делать большого размера и вне масштаба, чтобы в них поместилось
имя связи. Чтобы избежать этого, имена связей иногда пишут над ромбом. Когда
имя помещается внутрь или поверх ромба, кардинальность связи изображается
с помощью разветвлений на линиях, соединяющих сущность (или сущности)
с множественной стороной связи. На рис. 3.3, г показаны связи ОБЩЕЖИТИЕ-
ЖИЛЕЦ и СТУДЕНТ-КЛУБ с такими разветвлениями.
Как мы уже говорили, максимальная кардинальность показывает максимальное
число сущностей, которые могут участвовать в связи. Каково же минимальное
число таких сущностей, приведенные диаграммы не сообщают. Например, рис. 3.3, б
показывает, что студент может проживать максимум в одном общежитии, однако
из него не ясно, обязан ли студент проживать в каком-либо общежитии.
Для указания минимальной кардинальности (minimum cardinality) существует
несколько способов. Один из них, продемонстрированный на рис. 3.4, заключается
в следующем: чтобы показать, что сущность обязана участвовать в связи, на линию
связи помещают перпендикулярную черту, а чтобы показать, что сущность может
(но не обязана) участвовать в связи, на линию связи помещают овал.
Соответственно, рис. 3.4 показывает, что сущность ОБЩЕЖИТИЕ должна быть связана как
минимум с одной сущностью СТУДЕНТ, однако сущность СТУДЕНТ не обязана иметь
связь с сущностью ОБЩЕЖИТИЕ. Полный набор накладываемых на связь
ограничений состоит в том, что ОБЩЕЖИТИЕ имеет минимальное кардинальное число,
равное единице, и максимальное кардинальное число, равное «многим» сущностям
СТУДЕНТ. СТУДЕНТ имеет минимальное кардинальное число, равное нулю, и
максимальное кардинальное число, равное одному экземпляру сущности ОБЩЕЖИТИЕ.
Может существовать связь между сущностями одного и того же класса.
Например, для сущностей класса СТУДЕНТ может быть определена связь С0СЕД_
П0_К0МНАТЕ. Такая связь показана на рис. 3.5, я, а на рис. 3.5, б изображены
экземпляры сущностей, охваченных этой связью. Связи между сущностями
одного и того же класса называются иногда рекурсивными связями (recursive
relationships).
Изображение атрибутов в диаграммах
«сущность—связь»
В некоторых версиях ER-диаграмм атрибуты обозначаются эллипсами,
соединенными с сущностью или связью, которой они принадлежат. На рис. 3.6, а показаны
сущности ОБЩЕЖИТИЕ и СТУДЕНТ и связь ОБЩЕЖИТИЕ-ЖИЛЕЦ с принадлежащими
им атрибутами. Как видно из рисунка, сущность ОБЩЕЖИТИЕ имеет атрибуты
НазваниеОбщежития, Местоположение и КоличествоКомнат, а сущность СТУДЕНТ
имеет атрибуты НомерСтудента, ИмяСтудента и Курс. Связь ОБЩЕЖИТИЕ-ЖИЛЕЦ имеет
атрибут Плата, который показывает внесенную студентом плату за проживание
в конкретном общежитии.
Если сущность имеет много атрибутов, такое их перечисление в ER-диаграмме
может сделать ее чересчур громоздкой и трудной для восприятия. В подобных случаях

88 Глава 3. Модель «сущность—связь»
список атрибутов сущностей дается отдельно, как показано на рис. 3.6, б. Многие
CASE-средства показывают такие атрибуты в раскрывающихся окнах.
СТУДЕНТ
^
1:N)
СОСЕД-ПО-КОМНАТЕ
Рис. 3.5. Рекурсивная связь
НомерСтудента '
[ Местоположение\)
(ЯазваниеОбщежития)
ОБЩЕЖИТИЕ-
ЖИЛЕЦ
ОБЩЕЖИТИЕ
КоличествоКомнат
СТУДЕНТ
ОБЩЕЖИТИЕ-
ЖИЛЕЦ
ОБЩЕЖИТИЕ
СТУДЕНТ
ОБЩЕЖИТИЕ содержит СТУДЕНТ содержит
НазваниеОбщежития
Местоположение
КоличествоКомнат
НомерСтудента
ИмяСтудента
Курс
ОБЩЕЖИТИЕ-ЖИЛЕЦ содержит
Плата
Рис. 3.6. Изображение свойств на диаграммах «сущность—связь»
а — указание на диаграмме; б — отдельное перечисление

Элементы модели «сущность—связь» 89
Слабые сущности
В модели «сущность—связь» определен особый тип сущности, называемый
слабой сущностью (weak entity). К слабым сущностям относятся такие сущности,
которые могут существовать в базе данных только в том случае, если в ней
присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой,
называется сильной сущностью (strong entity).
Чтобы разобраться в том, что такое слабые сущности, рассмотрим базу данных
отдела кадров с классами сущностей СОТРУДНИК и ПОДЧИНЕННЫЙ. Предположим,
что, в соответствии с деловым регламентом, экземпляр сущности СОТРУДНИК может
существовать, не будучи связанным ни с одной сущностью класса ПОДЧИНЕННЫЙ,
но сущность ПОДЧИНЕННЫЙ не может существовать вне связи с какой-либо
сущностью класса СОТРУДНИК. Тогда сущность ПОДЧИНЕННЫЙ является слабой.
Это означает, что данные о сущности ПОДЧИНЕННЫЙ могут появиться в базе
данных только в том случае, если эта сущность имеет связь с какой-либо сущностью
класса СОТРУДНИК.
СОТРУДНИК
1:N>ej ПОДЧИНЕННЫЙ!
ДОМ
КВАРТИРА
Идентификатор: Идентификатор:
НазваниеДома {НазваниеДома
НомерКвартиры}
6
Рис. 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 и зависит от существования сущности
ПРОЕКТ, она является еще и идентификационно-зависимой от последней,
поскольку ее ключ содержит ключ сущности ПРОЕКТ. Таким образом, сущность
НАЗНАЧЕНИЕ является слабой.
АГЕНТ
РЕЦЕПТ
ПРОЕКТ
Идентификатор:
НазваниеПроекта
Рис. 3.8. Примеры обязательных сущностей
В этой книге мы определяем слабые сущности как логически зависящие от
существования другой сущности. Следовательно, не все сущности, имеющие
минимальную кардинальность 1 в связи с другой сущностью, являются слабыми.
Только логически зависимые сущности квалифицируются нами как слабые. Это
определение также подразумевает, что слабыми являются все
идентификационно-зависимые сущности. Кроме того, любая слабая сущность имеет
минимальное кардинальное число 1 в связи с сущностью, от которой зависит, но
произвольно взятая сущность с минимальным кардинальным числом, равным 1, не
обязательно должна быть слабой1.
Представление многозначных атрибутов при помощи
слабых сущностей
Многозначные атрибуты представляются в модели «сущность—связь» путем
создания новой слабой сущности и построения связи вида «один ко многим».
В качестве примера на рис. 3.9, а изображено представление многозначного
атрибута ДоверенноеЛицо сущности КЛИЕНТ. Создается новая сущность под с именем
Д0ВЕРЕНН0Е_ЛИЦ0 с единственным атрибутом ДоверенноеЛицо. Связь между
сущностями Д0ВЕРЕНН0Е_ЛИЦ0 и КЛИЕНТ имеет вид «один ко многим». Созданная
таким образом сущность должна быть слабой, поскольку она логически зависит
от сущности, имеющей многозначный атрибут.
Здесь не упоминаются случаи, когда минимальная кардинальность оказывается больше единицы.
Логика аналогична, но сущность теперь зависит от набора сущностей.
ЗАКАЗ
ПАЦИЕНТ
а
б
( НАЗНАЧЕНИЕ }fl-<ft:1
Идентификатор:
{НазваниеПроекта,
Название задачи}

92 Глава 3. Модель «сущность—связь»
На рис. 3.9, б изображено представление многозначного составного атрибута
Адрес. Новая слабая сущность АДРЕС содержит всю совокупность атрибутов, а
именно атрибуты Улица, Город, Штат и ПочтовыйИндекс.
имя_доверенного_лица)
ИМЯ_ДОВЕРЕННОГО_ЛИЦА содержит:
ИмяДоверенногоЛица
АДРЕС J
АДРЕС содержит:
Улица
Город
Штат
Индекс
Рис. 3.9. Представление многозначных атрибутов с помощью слабых сущностей
Подтипы сущностей
Некоторые сущности имеют необязательные наборы атрибутов; эти сущности
часто представляются с помощью подтипов (subtypes)1. Рассмотрим, например,
сущность КЛИЕНТ с атрибутами НомерКлиента, ИмяКлиента и СуммаКОплате.
Предположим, что клиент может быть физическим лицом, товариществом или корпорацией
и что необходимо указывать некоторую дополнительную информацию,
зависящую от типа клиента. Пусть эта информация имеет следующее содержание:
ФИЗИЧЕСКОЕ_ЛИЦО: Адрес, НомерСоциальнойСтраховки
ТОВАРИЩЕСТВО: ИмяУправляющегоПартнера, Адрес, ИдентификационныйНалоговый-
Номер
КОРПОРАЦИЯ: КонтактноеЛицо, Телефон, ИдентификационныйНалоговыйНомер
Одна из возможностей — отнести все эти атрибуты к сущности КЛИЕНТ, как
показано на рис. 3.10, а. В этом случае, однако, некоторые атрибуты будут
неприменимы. Например, такой атрибут, как имя управляющего партнера, не имеет
смысла для индивидуального или корпоративного клиента, и таким образом, он
не может иметь какого-либо значения.
В модели, более близкой к реальной ситуации, вместо этого будет определено три
подтипа сущностей, как показано на рис. 3.10, 6. Здесь сущности ФИЗИЧЕСКОЕ_
ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ изображены как подтипы сущности КЛИЕНТ.
Последняя, в свою очередь, является надтипом (supertype) для сущностей
ФИЗИЧЕСКОЕ.ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ.
Подтипы были добавлены в модель «сущность—связь» после публикации оригинальной статьи Че-
на, и они являются частью того, что называется расширенной моделью ^сущность—связь*.
КЛИЕНТ
КЛИЕНТ содержит:
НомерКлиента
ИмяКлиента
прочие атрибуты...
КЛИЕНТ
КЛИЕНТ содержит:
НомерКлиента
ИмяКлиента
прочие атрибуты...
1:N
:1:N

Элементы модели «сущность—связь»
93
Символ е рядом с линиями связи указывает, что сущности ФИЗИЧЕСКОЕ_ЛИЦО,
ТОВАРИЩЕСТВО и КОРПОРАЦИЯ являются подтипами сущности КЛИЕНТ. Каждый
подтип должен принадлежать надтипу КЛИЕНТ. Кривая линия с цифрой 1 рядом
показывает, что сущность КЛИЕНТ должна принадлежать к одному и только
одному подтипу. Это означает, что подтипы являются взаимоисключающими и что
требуется только один из них.
КЛИЕНТ содержит:
НомерКлиента
ИмяКлиента
СуммаКОплате
Адрес
НомерСоциальнойСтраховки
ИмяУправляющегоПартнера
ИдентификационныйНалоговыйНомер
ДоверенноеЛицо
PhoneK Телефон
КЛИЕНТ содержит:
НомерКлиента
ИмяКлиента
СуммаКОплате
ФИЗИЧЕСКОЕ_ЛИЦО содержит:
Адрес
НомерСоциальнойСтраховки
ТОВАРИЩЕСТВО содержит:
ИмяУправляющегоПартнера
Адрес
ИдентификационныйНалоговыйНомер
КОРПОРАЦИЯ содержит:
ДоверенноеЛицо
Телефон
ИдентификационныйНалоговыйНомер
КЛИЕНТ,
ИСПОЛЬЗУЮЩИЙ
Windows NT
КЛИЕНТ,
ИСПОЛЬЗУЮЩИЙ]
UNIX
КЛИЕНТ,
ИСПОЛЬЗУЮЩИЙ
БОЛЬШУЮ ЭВМ
Рис. 3.10. Подтипы сущностей: а — КЛИЕНТ без подтипов; б — КЛИЕНТ с подтипами;
в — невзаимоисключающие подтипы с необязательным надтипом
Сущности со связью типа «ЕСТЬ» должны иметь один и тот же
идентификатор, поскольку они представляют различные аспекты одного и того же. В данном

94 Глава 3. Модель «сущность—связь»
случае таким идентификатором является НомерКлиента. Сравните эту ситуацию
со связью типа «ИМЕЕТ», показанной на рис. 3.3, где сущности представляют
различные вещи.
Иерархии генерализации имеют специальную характеристику, называемую
наследованием (inheritance), которая означает, что подтипы классов сущностей
наследуют атрибуты от надтипа. Сущность ТОВАРИЩЕСТВО, к примеру, наследует
атрибуты ИмяКлиента и СуммаКОплате от сущности КЛИЕНТ.
Причины, по которым подтипы используются в моделировании данных,
отличаются от причин, по которым они используются в объектно-ориентированном
программировании. Фактически, в модели данных они применяются с
единственной целью: избежать ситуаций, при которых некоторые атрибуты должны иметь
нулевые значения. Например, на рис. 3.10, я, если атрибуту НомерСоциальнойСтра-
ховки присвоено значение, то остальные четыре атрибута должны быть равны
нулю. Эта ситуация наиболее ярко проявляется в медицинских приложениях:
представьте себе, например, что пациенту мужского пола задается вопрос о
количестве беременностей. Нулевые значения более детально обсуждаются в главе 6.
Пример ER-диаграммы
На рис. 3.11 показан пример ER-диаграммы, содержащей все элементы модели
«сущность—связь», о которых шла речь до сих пор. Она изображает сущности
и связи для инженерной консалтинговой компании, которая занимается
анализом строительства и состояния домов и других зданий и сооружений.
СОТРУДНИК
ЗАКРЕПЛЕННЫЙ_ГРУЗОВИК
ГРУЗОВИК
ИНЖЕНЕР
ИСПОЛНИТЕЛЬ_РАБОТЫ \n
ИНЖЕНЕР-КВАЛИФИКАЦИЯ
1:N)
РАБОТА
ИНЖЕНЕР-
СЕРТИФИКАЦИЯ
м/ КЛИЕНТ-РАБОТА /мХ
м/ / N > ВИД-СЕРТИФИКАТА
СЕРТИФИКАТ
КЕМ_ПРИВЕДЕН
Рис. 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
Производитель
Модель
ГодВы пуска
Ограничения и методы
перечисляются здесь
а
ОБЩЕЖИТИЕ
Название
МестныйАдрес
КоличествоМест
Телефон
Ограничения и методы
перечисляются здесь
ОБЩЕЖИТИЕ-ЖИЛЕЦ
1..1 0..*
СТУДЕНТ
НомерСтудента
ИмяСтудента
Телефон
Группа
Комната
Ограничения и методы
перечисляются здесь
б
СТУДЕНТ
НомерСтудента
ИмяСтудента
| Телефон
Группа
Комната
Ограничения и методы
перечисляются здесь
СТУДЕНТ-КЛУБ
0..* 0..*
КЛУБ
НомерКлуба
КодИсточникаФинансирования
Описание
Президент
Телефон Президента
Ограничения и методы
перечисляются здесь
в
Рис. 3.12. Представления различных типов связей в UML: a — связь 1:1;
б — связь 1 :N; a — связь N:M

98 Глава 3. Модель «сущность—связь»
Связи показаны линиями, соединяющими две сущности. Кардинальность
представлена в формате х..у, где х — это необходимый минимум, а у —
допустимый максимум. Так, 0..1 означает, что наличие данной сущности необязательно,
а максимально допустимое количество — одна. Звездочка представляет
неограниченное количество. Например, запись 1..* означает, что требуется одна сущность,
а допускается неограниченное количество. Найдите на-рис. 3.12, а> б примеры
связей с максимальной кардинальностью 1:1, 1:N и N:M.
Представление слабых сущностей
На рис. 3.13 изображено UML-представление слабых сущностей. На линии связи
рядом с родителем слабой сущности (то есть рядом с сущностью, от которой
зависит слабая сущность) помещается закрашенный ромб. На рис. 3.13, а сущность
РЕЦЕПТ является слабой сущностью, а сущность ПАЦИЕНТ — ее родителем. Все
слабые сущности имеют родителя, поэтому их кардинальность в связи с родителем
всегда 1..1. Исходя из этого, кардинальность на родительской стороне
обозначается просто как 1.
ПАЦИЕНТ
Имя
Телефон
Страховая Компа н ия
НомерСтраховки
Идентификатор: Имя
Методы
ПАЦЕНТ-РЕЦЕПТ
<не идентифицирующая>
ж1 0..*
w
РЕЦЕПТ
Дата
Но мер Рецепта
Врач
Лекарство
Дозировка
Идентификатор: НомерРецепта
Методы
а
ПРОЕКТ
НазваниеПроекта
Дата Начала
ДатаЗавершения
КодИсточникаФинансирования
Идентификатор: НазваниеПроекта
Методы
ПРОЕКТ-НАЗНАЧЕНИЕ
<идентифици рующая>
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» (устойчивый). Это означает, что существование данных должно
продолжаться даже после того, как будет разрушен объект, их обрабатывавший.
Проще говоря, это значит, что класс сущности должен храниться в базе данных.
СОТРУДНИК
ЗАКРЕПЛЕННЫИ_ГРУЗОВИК ТипСотрудника
I
ГРУЗОВИК
i КЛИЕНТ-
РАБОТА
Плата
0..*
КЛИЕН
КЛИЕНТ
0..1 1..1
ИСПОЛНИТЕЛЬ^
0..* 1.1
РАБОТА-КР
T-KP
ИНЖЕНЕР
АБОТЫ
0..*
РАБОТА
п л
и.л
0..*
КЕМ_ПРИВЕДЕН
♦1 °'Ч
ИНЖЕНЕР- I
КВАЛИФИКАЦИЯ
ИНЖЕНЕР-
СЕРТИФИКАЦИЯ
ВИД_СЕРТИФИКАТА
0..*
| СЕРТИФИКАТ |
Рис. 3.15. UML-версия диаграммы «сущность—связь» с рис. 3.11
Далее, UML допускает назначение атрибутов классам сущностей. Атрибуты
класса (class attributes) отличаются от атрибутов сущностей тем, что они
принадлежат всему классу сущностей данного типа. Так, на рис. 3.16 атрибут Число-
Пациентов сущности ПАЦИЕНТ является атрибутом всей совокупности сущностей
этого типа, имеющихся в базе данных. ИсточникПоступления — это атрибут,
документирующий источник поступления всех пациентов, присутствующих в базе
данных.
Как вы позже узнаете, в рамках реляционной модели такие атрибуты
классов просто негде хранить. Вместо того чтобы хранить атрибуты вроде
ЧислоПациентов в базе данных, они иногда вычисляются на этапе выполнения программы.
В других случаях для хранения этих атрибутов выделяется специальный класс
сущностей. Для класса сущностей ПАЦИЕНТ, изображенного на рис. 3.16,
можно создать новую сущность под названием ИСТ0ЧНИК_П0СТУШ1ЕНИЯ_ПАЦИЕНТА,
имеющую атрибуты ЧислоПациентов и ИсточникПоступления. В таком случае все
сущности класса ПАЦИЕНТ будут связаны с сущностью ИСТ0ЧНИК_П0СТУПЛЕНИЯ_
ПАЦИЕНТА.

Диаграммы «сущность—связь» в стиле UML 101
«Перманентный»
ПАЦИЕНТ
#ЧислоПациентов
#ИсточникПоступления
#НомерПациента
#Имя
#Телефон
#СтраховаяКомпания
| #НомерСтраховки
+Первичный ключ: НомерПациента
+ПолучитьИмя(): Имя
+ВвестиИмя(): Имя
+ПолучитьРецепт(перечислитель)
+RemovePrescripton()
ПАЦИЕНТ-РЕЦЕПТ
<не идентифицирующая>
▼
«Перманентный»
РЕЦЕПТ
... атрибутов класса
...список атрибутов
. .. список методов
Рис. 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, в моделировании данных есть столько же от
искусства, сколько от науки. Решение, описанное только что, является лишь одним
из возможных. Второе решение состоит в том, чтобы исключить сущности ЗАНЯТИЕ
и ИНСТРУКТОР из списка, приведенного в предыдущем абзаце, и удалить все
подтипы. Третье возможное решение — это исключить сущность ЗАНЯТИЕ
(поскольку занятие нигде не упоминается само по себе как словосочетание), но оставить
сущность ИНСТРУКТОР и ее подтипы. В данном случае мы выберем третий
вариант, так как он представляется наиболее подходящим с точки зрения
имеющейся у нас информации. Таким образом, список сущностей будет выглядеть
следующим образом: ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ, ГРУППОВОЕ_ЗАНЯТИЕ, ИНСТРУКТОР,
ПОСТОЯННЫЙ_ИНСТРУКТОР, ПРИХОДЯЩИЙ_ИНСТРУКТОР, ВЕЧЕРЛАНЦЕВ и КЛИЕНТ.
Чтобы сделать правильный выбор среди этих альтернатив, необходимо
проанализировать требования и выяснить, каким образом данные требования
отразятся на структуре системы. Иногда полезно рассмотреть атрибуты сущностей.
Если, например, сущность ЗАНЯТИЕ не имеет никаких атрибутов, кроме
идентификатора, то вводить такую сущность нет необходимости.
Связи
Начнем стого, что сущность ИНСТРУКТОР имеет два подтипа: П0СТ0ЯННЫЙ_ИНС-
ТРУКТОР и ПРИХОДЯЩИЙ_ИНСТРУКТОР. Любой инструктор должен быть либо
постоянным, либо приходящим, значит, подтипы являются взаимоисключающими.

104 Глава 3. Модель «сущность—связь
Далее рассмотрим связи между сущностями ИНСТРУКТОР и ИНДИВИДУАЛЬН0Е_
ЗАНЯТИЕ или ГРУППОВОЕ_ЗАНЯТИЕ. Инструктор может проводить много
индивидуальных занятий и, как правило, индивидуальное занятие проводится одним
инструктором. Но в ходе дальнейшего разговора с менеджерами
танцевального клуба выясняется, что для продвинутых танцоров, особенно тех, кто
готовится к соревнованиям, к индивидуальным занятиям иногда привлекается два
инструктора. Поэтому связь между сущностями ИНСТРУКТОР и ИНДИВИДУАЛЬНОЕ^.
ЗАНЯТИЕ должна иметь тип «один ко многим». По поводу групповых занятий мы,
однако, будем полагать, что каждое из них ведет только один инструктор. Связи,
описанные нами только что, изображены на рис. 3.17.
Клиенты могут посещать как индивидуальные, так и групповые занятия.
Иногда индивидуальное занятие проводится с одним человеком, а иногда — с парой.
Есть два способа моделирования этой ситуации. Можно определить сущность
ПАРА как имеющую связь 1:2 с сущностью КЛИЕНТ, а можно допустить, что обе
сущности, КЛИЕНТ и ПАРА, могут иметь связь с сущностью ИНДИВИДУАЛЬНОЕ^.
ЗАНЯТИЕ. Мы предполагаем, что пары не посещают групповые занятия, а если и
посещают, то этот факт не настолько важен, чтобы записывать его в базу данных.
Эта альтернатива показана на рис. 3.18, а.
Существование сущности ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ зависит от сущностей
КЛИЕНТ и ПАРА. То есть занятие не может существовать, если оно не проводится
с каким-либо клиентом или парой. Число 1 рядом с горизонтальной линией,
проведенной на рисунке под сущностями КЛИЕНТ и ПАРА, показывает, что в
индивидуальном занятии должны участвовать как минимум один клиент или одна
пара, что разумно, поскольку индивидуальное занятие зависит от них.
ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ
ГРУППОВОЕ ЗАНЯТИЕ
Ч)\ у^
ИНСТРУКТОР
ПОСТОЯННЫЙ_ИНСТРУКТОР ПРИХОДЯЩИЙ_ИНСТРУКТОР
Рис. 3.17. Исходная ER-диаграмма для танцевального клуба Джефферсона
Альтернатива заключается в том, чтобы не вводить пары, а указать тип связи
между сущностями КЛИЕНТ и ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ как «многие ко многим».
Если быть более точным, эта связь должна иметь тип «один или два ко многим»,
как показано на рис. 3.18, б. Хотя эта модель является не такой подробной, как
модель на рис. 3.18, <я, ее может быть вполне достаточно для нужд танцевального
клуба Джефферсона.
Осталось рассмотреть возможные связи сущности ВЕЧЕР_ТАНЦЕВ с другими
сущностями. Вечера танцев посещают как инструкторы, так и клиенты, и разработ-

Примеры 105
чики должны решить, важно ли показывать эти связи в структуре базы данных.
Действительно ли для танцевального клуба важно знать, какие клиенты посетили
какие танцевальные вечера? Так ли уж хотят менеджеры клуба вести запись
посетителей в компьютерную информационную систему при входе в танцзал? И
захочется ли посетителям, чтобы эти данные записывались? Скорее всего, эти связи
не принадлежат к числу тех, которые требуется или следует хранить в базе данных.
КЛИЕНТ И <2:1
И ПАРА
Гиндивидуальное_занятие"
(N:My
ГРУППОВОЕ ЗАНЯТИЕ
И КЛИЕНТ г^
[индивидуальное_занятие]
групповое занятие
Рис. 3.18. Способы представления клиента: а — с сущностью ПАРА; б— без сущности ПАРА
Иначе обстоит дело со связью между сущностями ВЕЧЕР__ТАНЦЕВ и ИНСТРУКТОР.
Хозяин клуба любит, когда на танцевальных вечерах присутствуют несколько
клубных инструкторов. В связи с этим требованием правление клуба
составило расписание посещения вечеров инструкторами. Составление и запись этого
расписания требуют, чтобы в базе данных присутствовала связь ВЕЧЕР_ТАНЦЕВ-
ИНСТРУКТОР, которая имеет тип «многие ко многим».
Окончательный вид ER-диаграммы для танцевального
клуба Джефферсона
На рис. 3.19 показан окончательный вид ER-диаграммы для модели, описанной
в этом разделе. Мы не стали приводить на ней имена связей: хотя это сделало бы
диаграмму более правильной по форме, при имеющихся у нас данных указание
имен связей мало что прибавило бы.
Существование сущности ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ зависит от сущности
КЛИЕНТ, а ГРУППОВОЕ_ЗАНЯТИЕ — нет, потому что расписание групповых занятий

106 Глава 3. Модель «сущность—связь»
составляется задолго до того, как на них записывается какой-либо клиент, и эти
занятия будут проводиться даже в том случае, если ни один клиент не придет.
Для индивидуальных занятий, однако, дело обстоит не так — они назначаются
только по запросу клиента. Обратите также внимание, что в этой модели не
представлены пары.
КЛИЕНТ
[ индивидуал ьное.занятие]
ГРУППОВОЕ ЗАНЯТИЕ
ИНСТРУКТОР
N:M>
ВЕЧЕР_ТАНЦЕВ
ПОСТОЯННЫЙ_ИНСТРУКТОР ПРИХОДЯЩИЙ_ИНСТРУКТОР
Рис. 3.19. Окончательный вид ER-диаграммы для танцевального клуба Джефферсона
Разработав модель, подобную этой, следует проверить, насколько она точна
и полна по отношению к требованиям пользователей. Обычно это делается с
помощью самих пользователей.
Проверка созданной ER-модели данных
Ошибки проще и дешевле исправлять на ранних стадиях процесса разработки
базы данных, чем на поздних. Например, изменение максимального
кардинального числа связи с 1:N на N:M на стадии моделирования данных сводится просто
к внесению соответствующего исправления в ER-диаграмму. Но когда база
данных уже разработана и наполнена данными и написаны прикладные программы
для ее обработки, такое изменение потребует значительной переделки, возможно,
даже недель труда. Поэтому важно определить, какая модель данных требуется,
прежде чем начинать ее воплощать.
Один из способов сделать это — рассмотреть ER-модель в контексте того,
на какого рода запросы может ответить база данных со структурой,
описываемой данной моделью. Взгляните, к примеру, на диаграмму, изображенную на
рис. 3.19. На какие вопросы может дать ответ база данных, реализованная на
основе данного проекта?
+ Какие и кем были проведены индивидуальные занятия?
+ Какие клиенты посещали индивидуальные занятия у Джека?
+ Кто является постоянным инструктором клуба?
+ Какие инструкторы должны прийти на танцевальный вечер в пятницу?

Примеры 107
При проверке модели данных вы можете формулировать такие вопросы и
задавать их пользователям, которых затем можно попросить составить свой
список вопросов. Они могут задавать вопросы, касающиеся структуры базы
данных, чтобы проверить ее соответствие поставленным требованиям. Например,
представьте, что пользователи спрашивают, какие клиенты посетили вечер танцев
в прошлую пятницу. Разработчики модели данных, изображенной на рис. 3.19,
должны прийти к заключению, что их структура неверна, поскольку на
поставленный вопрос с помощью данной ER-модели ответить невозможно. Если
требуется ответ на этот вопрос, необходимо ввести связь между сущностями КЛИЕНТ
и ВЕЧЕР.ТАНЦЕВ.
Очевидно, что посредством такого неформального и нечетко
структурированного процесса невозможно доказать, что структура является правильной. Тем не
менее, это прагматичный метод, пригодный для определения потенциальной
правильности структуры. И даже такой метод все же лучше, чем отсутствие
проверки вообще!
Пример 2: бюро проката парусных яхт Сан-Хуана
Бюро проката яхт Сан-Хуана — это посредническая фирма, занимающаяся
прокатом парусных яхт. Яхты не являются собственностью фирмы — она сдает их
от имени владельцев, которые хотят получать доход от своих яхт, когда не
пользуются ими. За свои услуги фирма Сан-Хуана берет плату. Фирма
специализируется на яхтах, которые могут использоваться для многодневных или
недельных походов: самая маленькая из яхт имеет длину 28 футов, а самая
большая — 51 фут.
Каждая яхта полностью экипирована на момент сдачи в аренду. Большая
часть оборудования предоставляется владельцами, но некоторое
оборудование добавляется фирмой. Оборудование, предоставляемое владельцами, включает
в себя предметы, закрепленные на яхте, то есть радиостанции, компасы,
глубиномеры и прочий инструмент, плиты и холодильники. Есть и другое оборудование,
предоставляемое владельцами, но не являющееся частью яхты. Это могут быть
паруса, лини, якоря, спасательные шлюпки, спасательные жилеты, а также то,
что находится в каютах: блюда, столовое серебро, кухонные принадлежности,
постельные принадлежности и т. д. Фирма Сан-Хуана предоставляет также
расходуемый инвентарь и припасы — карты, навигационные книги, таблицы приливов
и течений, мыло, полотенца для посуды, туалетную бумагу и тому подобные
предметы.
Важной составляющей обязанностей фирмы Сан-Хуана является учет
оборудования, имеющегося на яхтах. Многое оборудование является дорогим, а
некоторое, в частности то, которое не закреплено на яхте, может легко потеряться
или быть украдено. В течение срока проката яхты ответственными за
оборудование являются клиенты.
Фирма Сан-Хуана ведет подробный учет клиентов и истории проката яхт.
Это требуется не только для маркетинговых целей, но и для того, чтобы иметь

108 Глава 3. Модель «сущность—связь»
записи о путешествиях клиентов. Некоторые маршруты и погодные условия
более опасны, чем другие, поэтому фирма желает знать об опыте своих клиентов.
По большей части фирма занимается прокатом только яхт, то есть капитан
или команда не предоставляется. В некоторых случаях, однако, клиенты
заказывают услуги капитана или каких-либо других членов команды, и тогда фирма
нанимает соответствующий персонал на договорной основе.
Яхты часто требуют обслуживания. Контракты, заключенные фирмой Сан-
Хуана с владельцами лодок, требуют от фирмы ведения тщательной записи всех
операций по обслуживанию и связанных с этим расходов, включая обычные
операции, такие как мойка или замена масла, а также внеплановые ремонты. Иногда
ремонт может потребоваться во время рейса. Например, у яхты может отказать
двигатель, когда она будет находиться далеко от доков Сан-Хуана. В этом случае
клиенты вызывают по радио диспетчера фирмы, который определяет наиболее
подходящее место для проведения ремонта и направляет персонал оттуда на
аварийную яхту. Чтобы принимать все эти решения, диспетчерам требуется
информация об имеющихся ремонтных доках, а также сведения о качестве и стоимости
предыдущих ремонтов.
Прежде чем продолжить чтение, постарайтесь составить диаграмму
«сущность—связь» для этого случая самостоятельно. Проанализируйте
приведенный выше текст и найдите в нем существительные, которые, на ваш взгляд,
являются важными для проекта. После этого определите возможные связи
между сущностями. Наконец, перечислите возможные атрибуты каждой сущности
и связи.
Сущности
Модель данных, требуемая для бюро аренды Сан-Хуана, более сложна, чем
модель для танцевального клуба Джефферсона. Потенциальные сущности
показаны на рис. 3.20, а.
Рассмотрим сначала сущности, относящиеся к оборудованию. Есть много
различных типов оборудования, и это наводит нас на мысль о введении
подтипов. Однако спросим себя: почему фирму Сан-Хуана должно интересовать
оборудование? Фирме вовсе не нужно знать характеристики каждого предмета —
например, длину цепи каждого якоря. В задачи фирмы скорее входит учет
элементов оборудования и их типов, чтобы можно было определить, что из
оборудования потеряно или повреждено. Таким образом, для данного случая мы отнесем
все типы оборудования к одной сущности — ОБОРУДОВАНИЕ.
Принадлежность оборудования указывается путем введения связи между
сущностями ОБОРУДОВАНИЕ и ВЛАДЕЛЕЦ. Если фирма Сан-Хуана может быть
экземпляром сущности ВЛАДЕЛЕЦ, то все оборудование, являющееся собственностью
фирмы, может быть отнесено к этой сущности. Аналогичным образохМ, исходя из
описанной ситуации, представляется безосновательным разделение
оборудования на закрепленное и не закрепленное на яхте. Точный список может быть
составлен и без такого разделения. Окончательный список сущностей приведен на
рис. 3.20, б.

Примеры 109
АРЕНДА
ЯХТА
КЛИЕНТ
ВЛАДЕЛЕЦ
ОБОРУДОВАНИЕ
ОБОРУДОВАНИЕ.ВЛАДЕЛЬЦА
ЗАКРЕПЛЕННОЕ_ОБОРУДОВАНИЕ_ВЛАДЕЛЬЦА
НЕЗАКРЕПЛЕННОЕ_ОБОРУДОВАНИЕ_ВЛАД ЕЛЬЦА
СОБСТВЕННОЕ_ОБОРУДОВАНИЕ_ФИРМЫ
МАРШРУТ_И_ПОГОДА
РЕЙС
ВРЕМЕННАЯ_КОМАНДА
ПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ
ВНЕПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ
РЕМОНТ
РЕМОНТНЫЙДОК
а
Возможные сущности для бюро аренды Сан-Хуана
АРЕНДА, или РЕЙС (синонимы)
ЯХТА
КЛИЕНТ
ВЛАДЕЛЕЦ
ОБОРУДОВАНИЕ
МАРШРУТ_И_ПОГОДА
ВРЕМЕННАЯ_КОМАНДА
ПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ
РЕМОНТ, или ВНЕПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ (синонимы)
РЕМОНТНЫЙЛОК
б
Окончательный список сущностей
Рис. 3.20. Сущности для бюро аренды яхт Сан-Хуана
Обратите внимание, что АРЕНДА и РЕЙС являются синонимами: они относятся
к одной и той же транзакции. Мы приводим здесь оба имени, чтобы можно было
соотнести их с описанием ситуации.
Возможно, что сущности ПЛАН0В0Е__ТЕХ06СЛУЖИВАНИЕ и ВНЕПЛАНОВОЕЛХ-
ОБСЛУЖИВАНИЕ следует объединить. Один из способов определить, необходимо
это или нет, — проанализировать атрибуты обеих сущностей. Если они
одинаковы, то два класса сущностей могут быть объединены. Заметьте также, что
сущности РЕМОНТ и ВНЕПЛАН0В0Е_ТЕХ06СЛУЖИВАНИЕ определены как синонимы.
Связи
На рис. 3.21 изображена диаграмма «сущность—связь» для бюро аренды Сан-
Хуана. По большей части представленные на этой диаграмме связи являются
очевидными, но связь между сущностями ОБОРУДОВАНИЕ и АРЕНДА может быть
предметом спора. Можно было бы сказать, что определенная часть оборудования
должна быть отнесена к яхте (сущность ЯХТА), а не к аренде, или что часть
оборудования (а именно оборудование, которое закреплено на яхте) следует отнести
к яхте, а оставшуюся часть — к аренде. Эти изменения представляют собой
возможные альтернативы для структуры, показанной на рис. 3.21.

110 Глава 3. Модель «сущность—связь»
ВЛАДЕЛЕЦ ПЛАНОВ0Е_ТЕХ0БСЛУЖИВАНИЕ
Рис. 3.21. ER-диаграмма для бюро аренды яхт Сан-Хуана
Кроме того, обратите внимание, что сущность ПЛАНОВОЕ_ТЕХОБСЛУЖИВАНИЕ
связана с сущностью ЯХТА, в то время как сущность РЕМОНТ, или ВНЕПЛАНОВОЕ.
ТЕХОБСЛУЖИВАНИЕ, связана с сущностью АРЕНДА. Это подразумевает, что когда
яхта не находится в аренде, никакого ремонта для нее не требуется. Может быть,
это не соответствует действительности.
Наконец, сущности АРЕНДА и ПОГОДА_И_МАРШРУТ имеют связь 1:1, и они также
имеют одинаковые идентифицирующие атрибуты. В связи с этим можно, а может
быть, даже нужно объединить их в один класс сущностей.
Базы данных как модели моделей
Как вы можете видеть, есть множество различных способов моделирования
конкретной ситуации в деловом мире, и это множество становится все обширнее по
мере того, как моделируемая ситуация усложняется. Зачастую количество
возможных моделей оказывается огромным, и выбрать среди них одну может быть
нелегко.
Иногда при выявлении альтернатив команда, занимающаяся проектом,
углубляется в дискуссии по поводу того, какая модель данных наилучшим образом
представляет реальный мир. Эти дискуссии исходят из ложных посылок. Базы
данных не моделируют реальный мир, хотя распространено ошибочное мнение,
согласно которому именно в этом и состоит их назначение. Базы данных
являются моделями пользовательских моделей мира (или, точнее, делового мира).
Вопрос, задаваемый при выявлении альтернативных моделей данных, состоит не
в том, насколько точно данная модель отражает реальный мир, а в том,
насколько точно она отражает имеющуюся в воображении пользователя модель среды,

Резюме 111
которая его окружает. Цель заключается в том, чтобы разработать структуру,
которая будет соответствовать представлениям пользователей.
Иммануил Кант и другие философы могли бы возразить, что людям не дано
построить модель того, что существует на самом деле, и заявили бы, что суть
вещей навсегда останется тайной для человечества1. Распространяя эту
аргументацию на компьютерные системы, Виноград (Winograd) и Флоре (Flores)
высказали идею, что в обществах индивидуумы конструируют системы символов,
которые позволяют им успешно действовать в мире. Последовательность
символов не является моделью бесконечности реального мира, а скорее представляет
собой просто социальную систему, позволяющую пользователям успешно
координировать свои действия; ничего более по этому поводу сказать нельзя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.

Вопросы группы I 113
4. Объясните, что такое композитный атрибут, и приведите пример.
5. Какой из атрибутов, приведенных вами в ответе на вопрос 3,
идентифицирует сущность?
6. Дайте определение связи и приведите пример.
7. Объясните, в чем разница между классом связей и экземпляром связи.
8. Дайте определение степени связи. Приведите пример связи со степенью
больше 2, отличный от того, который дан в тексте.
9. Перечислите три типа бинарных связей и приведите примеры. Нарисуйте
ER-диаграмму для каждого типа.
10. Дайте определения терминов максимальное кардинальное число и
минимальное кардинальное число, максимальная кардинальность и минимальная
кардинальность.
11. Назовите и нарисуйте символы, используемые в диаграммах «сущность-
связь» для изображения: (а) сущности; (б) связи; (в) слабой сущности и ее
связи; (г) рекурсивной связи; (д) сущности подтипа.
12. Приведите пример ER-диаграммы для сущностей ОТДЕЛ и СОТРУДНИК,
имеющих связь 1:N. Сделайте допущение, что в отделе может и не быть
сотрудников, но каждый сотрудник должен работать в каком-либо отделе.
13. Приведите пример рекурсивной связи и изобразите его на ER-диаграмме.
14. Приведите примеры атрибутов для сущностей ОТДЕЛ и СОТРУДНИК (из
ответа на вопрос 12) и изобразите их на ER-диграмме. Используйте для
этого символы UML-стиля.
15. Дайте определение термина слабая сущность и приведите пример,
отличный от того, который дан в тексте.
16. Поясните, в чем состоит неоднозначность в определении термина слабая
сущность. Как этот термин интерпретируется в книге? Приведите
примеры, отличные от тех, которые даны в тексте.
17. Дайте определение термина идентификационно-зависимая сущность и
приведите пример, отличный от того, который дан в тексте.
18. Продемонстрируйте использование слабой сущности для представления
многозначного атрибута Квалификация сущности СОТРУДНИК. Укажите
минимальное и максимальное кардинальное число на обеих сторонах связи.
Используйте традиционные символы.
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).
Пользуясь средствами сайта, определите, какой ноутбук вы могли бы
приобрести для пользователя с бюджетом $10000. Занимаясь выяснением
этого вопроса, подумайте о том, какой структурой может обладать база данных
по компьютерным системам и подсистемам, используемая для поддержки
данного сайта.
Разработайте ER-диаграмму для базы данных по компьютерным системам
и подсистемам для этого сайта. Изобразите на ней все сущности и связи,
причем у сущности должно быть минимум два атрибута. Укажите
минимальное и максимальное кардинальное число для обеих сторон каждой
связи. Возможными сущностями являются БА30ВАЯ_К0НФИГУРАЦИЯ, 0БЪЕМ_
ПАМЯТИ, ВИДЕОКАРТА и ПРИНТЕР. (Разумеется, в реальности возможных
сущностей гораздо больше.) Введите какие-нибудь многозначные атрибуты, как
показано в тексте. Используйте подтипы, где это имеет смысл. Чтобы проект
не оказался чрезмерно велик, ограничьтесь тем, что требуется для человека,
который точно решил купить компьютер, но еще не выбрал, какой именно.
2. Зайдите на сайт виртуального книжного магазина, например Amazon (www.
amazon.com). Пользуясь средствами сайта, найдите три лучших книги по
XML для человека, который только начал изучать этот предмет.
Занимаясь выяснением данного вопроса, подумайте о том, какой может быть
структура базы данных по книгам, авторам, предметам и родственным темам.

116 Глава 3. Модель «сущность—связь»
Разработайте ER-диаграмму для базы данных этого сайта. Изобразите на ней
все сущности и связи, причем каждая сущность должна иметь не меньше двух-
трех атрибутов. Укажите минимальное и максимальное кардинальное число
для обеих сторон каждой связи. Возможными сущностями являются ЗАГОЛОВОК,
АВТОР, ИЗДАТЕЛЬ, ЭКЗЕМПЛЯР и ТЕМА. (Разумеется, в реальности возможных
сущностей гораздо больше.) Введите какие-нибудь многозначные атрибуты, как
показано в тексте. Используйте подтипы, где это имеет смысл. Чтобы проект не
слишком разрастался, предположим, что учет нужен только для книг. Далее
ограничьтесь потребностями человека, который точно решил купить книгу, но
еще не выбрал, какую. Не рассматривайте заказ клиента, выполнение заказа,
заказ на поставку и другие подобные деловые операции.
Вопросы к проекту FiredUp
Рассмотрим ситуацию, обсуждаемую в конце глав 1 и 2. Предположим, что фирма
FiredUp разработала линию из трех горелок: FiredNow, FiredAlways и FiredAt-
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. Вы узнаете, чем цели, свойства
и конструкции семантической объектной модели отличаются от
объектно-ориентированных баз данных.
Е. F. Codd, «Extending the Relational Model to Capture More Meaning», ACM Transactions on Database
Systems, декабрь 1976, с. 397-424; Michael Hammer and Dennis McLeod, «Database Description
with SDM: A Semantic Database Model», ACM Transactions on Database Systems, сентябрь 1981,
с. 351-386.

Семантические объекту 119
Модель «сущность—связь»
ч
\
\
{)
W
w\
Сущности
и связи
-*
Представление
пользовательских данных
w
W
Семантические
объекты
-+
Структура
базы данных
Структура
базы данных
Пользовательские отчеты,\
формы, запросы N
Семантическая объектная модель
Рис. 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), как их
иногда называют, состоит в том, что когда пользователь думает об определенной
кафедре, он имеет в виду не только название кафедры, локальный адрес, номер
телефона и номер факса этой кафедры, но также колледж, в котором она
находится, профессоров, преподающих на ней, и студентов, занимающихся на ней.
Поскольку КОЛЛЕДЖ, ПРЕПОДАВАТЕЛЬ и СТУДЕНТ также являются объектами,
полная модель данных содержит диаграммы и для них. Объект КОЛЛЕДЖ несет в себе
атрибуты колледжа, объект ПРЕПОДАВАТЕЛЬ — атрибуты членов профессорско-
преподавательского состава, а объект СТУДЕНТ содержит атрибуты студентов.
КАФЕДРА
/о НазваниеКафедр
МестныйАдрес™
Корпус
НомерОфиса _
НомерТелефона
НомерФакса
ы
|-Д-Щсвд9Щ|?;*|
[.ПРЕПОДАЕ^ЛЬ;]
| V сШейЩй]
КАФЕДРА
ю НазваниеКафедры
МестныйАдрес ~
Корпус i.-i
НомерОфиса i.i_
J 0.1
НомерТелефона 1 N
I
НомерФакса 0N
|к Щ|||1[:: "1
|РРЕГ||||||||ЛЬ ]
Ц с^И1|ИмИ11:::
1.1
1 N '
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
Й|йлЬедж БизнёЩ
Рис. 4.3. Экземпляр объекта КАФЕДРА с рис. 4.2
Далее, имеется один экземпляр атрибута КОЛЛЕДЖ, со значением Колледж
Бизнеса, и множество экземпляров объектных атрибутов ПРЕПОДАВАТЕЛЬ и СТУДЕНТ.
Каждый из этих объектных атрибутов является полноценным объектом и имеет
все атрибуты, определенные для объекта данного типа. Чтобы не усложнять
диаграмму, мы указали на ней только имена экземпляров объектных атрибутов.
Объектная диаграмма — это картина восприятия пользователем объекта в
рабочей среде. Таким образом, в воображении пользователя объект КАФЕДРА
содержит все эти данные. Кафедра логически содержит данные о колледже, к
которому она принадлежит, а также о профессорах и студентах, относящихся к этой
кафедре.
Парные атрибуты
В семантической объектной модели нет однонаправленных связей между
объектами. Если один объект содержит в себе другой объект, то этот другой будет,
в свою очередь, содержать в себе первый. Например, если объект КАФЕДРА
содержит в себе объектный атрибут КОЛЛЕДЖ, то и объект КОЛЛЕДЖ будет содержать
соответствующий объектный атрибут КАФЕДРА. Эти объектные атрибуты
называются иногда парными атрибутами (paired attributes), так как они всегда
появляются по два.
Почему объектные атрибуты должны быть парными? Ответ заключается в том
способе, каким человеческие существа представляют себе связи между объектами.
1Ы
НазваниеКафедры
МестныйАдрес
НомерТелефона
НомерФакса
КОЛЛЕДЖ
ПРЕПОДАВАТЕЛЬ
СТУДЕНТ

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 символов, представляющих наименования кафедр
университета Higliline». Фраза «набор строк длиной до 7 символов» представляет собой
физическое описание домена, а «...представляющих имена кафедр университета
Highline» — семантическое описание. Семантическое описание отличает строки
из семи символов, представляющие названия кафедр, от строк такой же длины,
которые представляют, скажем, названия учебных дисциплин, корпусов или
какие-то еще атрибуты.
В некоторых случаях физическое описание домена простого атрибута
представляет собой нумерованный список — набор отдельных значений атрибутов.
Доменом атрибута ЦветДетали может быть, например, нумерованный список
{«Синий», «Желтый», «Красный»}.
Домен группового атрибута также имеет физическое и семантическое
описание. Физическое описание — это список всех атрибутов в группе в порядке их
следования. Семантическое описание — это описание функции, или назначения,
данной группы. Так, физическим описанием домена МестныйАдрес (см. рис. 4.2)
является список {Корпус, НомерОфиса}; семантическим описанием является фраза
«местоположение офиса в университете Highline».
Домен объектного атрибута — это набор экземпляров объектов данного типа.
На рис. 4.2, например, доменом объектного атрибута ПРЕПОДАВАТЕЛЬ является
совокупность всех экземпляров объектов класса ПРЕПОДАВАТЕЛЬ, представленных
в базе данных. Доменом объекта КОЛЛЕДЖ является совокупность всех объектов
класса КОЛЛЕДЖ, представленных в базе данных. В определенном смысле, домен
атрибута — это динамически нумерованный список, который содержит все
экземпляры объектов данного типа.
Представления семантических объектов
Пользователи имеют доступ к значениям объектных атрибутов через
приложения базы данных, которые предоставляют формы для ввода данных, отчеты и
запросы. В большинстве случаев такие формы, отчеты и запросы не требуют
доступа ко всем атрибутам объекта. Например, на рис. 4.4. показаны представления

126 Глава 4. Семантическая объектная модель
объекта КАФЕДРА для двух различных приложений. Некоторые атрибуты объекта
КАФЕДРА (например, НазваниеКафедры) являются видимыми в обоих
представлениях. Другие атрибуты видимы только в одном из представлений. Например,
атрибут СТУДЕНТ является видимым только в представлении СписокСтудентов, а
атрибут ПРЕПОДАВАТЕЛЬ виден только в представлении Персонал.
Часть объекта, видимая для конкретного приложения, называется
представлением семантического объекта (semantic object view), или просто
представлением (view). Представление состоит из имени объекта и списка всех атрибутов,
видимых в этом представлении.
Представления используются двояким образом. Когда вы разрабатываете
базу данных, вы можете использовать их для разработки модели данных.
Взгляните снова на рис. 4.1. Как можно видеть, при разработке модели данных
разработчики базы данных и приложений двигаются в обратном направлении. То есть
они начинают с форм, отчетов и запросов, которые пользователи объявляют
необходимыми, и двигаются назад, к структуре базы данных. Для этого комарща
выбирает требуемую форму, отчет или запрос и определяет, какое представление
должно существовать, чтобы можно было создать такую форму, отчет или
запрос. Затем команда переходит к следующей форме, отчету или запросу и делает
то же самое. Далее получившиеся два представлершя объединяются. Описанный
процесс повторяется до тех пор, пока структура базы данных не будет полностью
сформирована.
Второй аспект использования представлений возникает, когда структура
базы данных уже создана. В этом случае представления создаются для поддержки
новых форм, отчетов и запросов на основе существующей структуры базы
данных. Примеры этого второго подхода приведены в части IV, где обсуждаются
SQL Server и Oracle.
КАФЕДРА
ю НазваниеКафедры у
МестныйАдрес
Корпус^.,
НомерОфиса1.1_
НомерТелефона 1 N
НомерФакса 0 N
|| коЩедж
ШРЕПОдаВАТЕЛЬ
ЬШ. ._.■ " J--J L
Шетдант. ,ш
^.^■■...,:—•••••■'•;■■■ i •;:;:i:;:;:f;:^i
Представление СписокСтудентов
— НазваниеКафедры
•СТУДЕНТ:;
к Представление Персонал
\ НазваниеКафедры
ЛЩПОДАШЕПЬ
Рис. 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
232-1414
236-0011
236-9988
236-1184
Всего студентов
318
211
247
184
212
Рис. 4.5. Пример отчета о колледже
КОЛЛЕДЖ
ю НазваниеКолледжа
ИмяДекана
НомерТелефона
МестныйАдрес
Корпус 1.1
НомерОфиса 11
0.1
:зй4«вЖ:
КАФЕДРА
ю НазваниеКафедры
Заведующий
НомерТелефона
ВсегоСтудентов
, кдашадж
Рис. 4.6. Первая версия объектов КОЛЛЕДЖ и КАФЕДРА
Кардинальность атрибута КАФЕДРА объекта КОЛЛЕДЖ равна 1.N — это
означает, что колледж должен иметь как минимум одну кафедру и кафедр может быть
много. Это минимальное кардинальное число не может быть выведено из отчета
на рис. 4.5. Чтобы его получить, пользователям был задан вопрос о том, может
ли существовать колледж без кафедр, и их ответ был отрицательным.
Также обратите внимание, что структура объекта КАФЕДРА выведена на
основе данных, представленных на рис. 4.5. Поскольку объектные атрибуты всегда
являются парными, объект КОЛЛЕДЖ показан внутри объекта КАФЕДРА, хотя,
строго говоря, этот факт нельзя получить из анализа рис. 4.5. Как и в ситуации
с атрибутом КАФЕДРА объекта КОЛЛЕДЖ, пользователей попросили определить
кардинальность атрибута КОЛЛЕДЖ. Она равна 1.1, что означает, что кафедра
может быть связана с одним и только одним колледжем.
По ходу изложения мы интерпретировали отчет на рис. 4.5 таким образом,
что группы повторяющихся данных относятся к объекту КАФЕДРА как к
независимому объекту. Фактически наличие таких групп часто является сигналом
о том, что существует некий другой объект. Однако это не всегда так.
Повторяющаяся группа может быть также групповым атрибутом, у которого оказалось
несколько значений.

Создание семантических объектных моделей данныу 129
Вас, возможно, интересует, как различить эти два типа повторяющихся
данных — те, которые представляют объект, и те, которые представляют группу.
Какого-либо твердого и четкого правила на этот счет не существует, поскольку
ответ зависит от того, как пользователи представляют себе свой мир.
Следовательно, наилучшим выходом будет спросить самих пользователей о семантике
их данных. Спросите, являются ли эти повторяющиеся группы данных частью
колледжа, или они относятся к чему-то еще — чему-то самостоятельному. В первом
случае они составляют групповой атрибут, во втором — семантический объект.
Посмотрите также другие отчеты (или формы, или запросы). Имеются ли у
пользователей отчеты по кафедрам? Если да, то предположение о том, что кафедра
может быть представлена семантическим объектом, подтвердится. На самом деле
персонал университета Highline работает с двумя видами отчетов по кафедрам.
Этот факт еще более укрепляет нас в мысли о том, что следует ввести объект под
названием КАФЕДРА.
Далее, группы атрибутов, представляющие независимый объект, обычно
содержат явный идентифицирующий атрибут или несколько атрибутов.
Автомобили имеют номер или номер лицензии, продукты имеют учетный номер или
штрих-код (SKU). Заказы также имеют учетные номера. Однако группа
атрибутов {ДатаИзмерения, ДавлениеВШине} не имеет явного идентификатора. Когда вы
спросите пользователя об идентификаторе этой группы, он в ответ спросит вас
что-нибудь вроде: «Давление в шине чего?». Это будет давление в шине
легкового автомобиля или грузовика или трейлера, или какого-либо еще
транспортного средства. Следовательно, такая группа представляет собой групповой
атрибут некоторого другого объекта — объекта, который является ответом на вопрос
«чего?».
Объект КАФЕДРА
Отчет, представленный на рис. 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.
КАФЕДРА
/о НазваниеКафедры
Заведующий
НомерТелефона
ВсегоСтудентов
МестныйАдрес
Корпус 1.1
НомерОфиса л л
'~J о.
1|щ;щл^||1;
||||пЩДЩЩ1]||
ПРЕПОДАВАТЕЛЬ
ю ИмяПреподавателя
МестныйАдрес
Корпуси
НомерОфиса 1 л
0.1
НомерТелвфона
Рис. 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. Семантическая объектная модель
КАФЕДРА
/о НазваниеКафедры
Заведующий
НомерТелефона
ВсегоСтудентов
МестныйАдрес
Корпус 1.1
НомерОфиса 11
-* 0.1
колледж т
ПРЕПОДАВАТЕЛ
|ОТУДЕНТ
1.N
СТУДЕНТ
ю Имя Студента
/о НомерСтудента
НомерТелефона
кн
Рис. 4.10. Уточненный объект КАФЕДРА и новый объект СТУДЕНТ
Мистеру Фреду Парксу
123, Эльм-Стрит
Лос-Анджелес, Калифорния 98002
Уважаемый мистер Парке,
рад сообщить, что вы приняты на кафедру бухгалтерского учета
университета Highline, начиная с осеннего семестра 2000 года.
Кафедра бухгалтерского учета находится по адресу: корпус
бизнеса, комната 210.
Вашим руководителем назначена профессор Элизабет Джонсон,
ее номер телефона 232-8740, офис расположен в корпусе бизнеса,
комната 227. Просьба назначить встречу с руководителем сразу
по прибытию в университетский городок.
Поздравляю, и добро пожаловать в университет Highline!
Искренне ваш,
Ян П. Сматерс,
Президент
Рис. 4.11. Письмо-приглашение
Кроме того, из письма видно, что именам в адресах и приветствиях должно
предшествовать обращение «Мистер» или «Мисс». Чтобы обеспечить такую
возможность, к объекту СТУДЕНТ следует добавить еще один атрибут, и на основании
данного атрибута выбирать титул. Другая возможность — хранить в базе данных
сам титул. Преимущество этого подхода в том, что он позволяет хранить и другие
титулы, помимо «Мистер» и «Мисс», — например, «Доктор».
В текущей версии модели данных иных титулов, кроме «Мистер» и «Мисс»,
не требуется. Однако вполне вероятна ситуация, при которой дополнительные

Создание семантических объектных моделей данных 133
обращения могут понадобиться; следовательно, второй вариант более надежен, и
поэтому к объекту СТУДЕНТ на рис. 4.12 добавлен атрибут Обращение.
ПРЕПОДАВАТЕЛЬ -
ю Имя Преподавателя
Имя 0i1
Фамилия лл
МестныйАдрес
Корпус 1.1
НомерОфиса и
НомерТелефона
шщ^т
;;г|||ЩЗД"||§
1.1
1.N
СТУДЕНТ
ю Имя Студента
Имя01
Фамилия 1Л
ю НомерСтудента
НомерТелефона
ДомашнийАдрес ~\
Улица01
Город и
Штат и
Индекс лл
Обращение
Дата Поступления
ЩЩЩ?ШЩ
щшсшШ^Ш!!
Рис. 4.12. Уточненные объекты ПРЕПОДАВАТЕЛЬ и СТУДЕНТ
Опять-таки, эти изменения иллюстрируют итеративную природу
моделирования данных. Имеющиеся решения часто приходится пересматривать и
корректировать вновь и вновь. Это не означает, что процесс проектирования идет
с ошибками; фактически, такие итерации являются обычными и ожидаемыми.
Спецификация объектов
На рис. 4.13 показан окончательный вариант объектных диаграмм для базы
данных университета Highline. Внесено несколько дополнительных изменений:
атрибуты ИмяДекана и Председатель смоделированы в формате {Имя, Фамилия},
чтобы все имена имели одинаковый формат. Далее, чтобы увеличить точность
модели, атрибут ПРЕПОДАВАТЕЛЬ объекта СТУДЕНТ был переименован — теперь он
называется РУКОВОДИТЕЛЬ. Экземпляр объекта ПРЕПОДАВАТЕЛЬ, связанный через
:>тот атрибут с экземпляром объекта СТУДЕНТ, это не просто кто-то из
преподавателей данного студента, а совершенно конкретный преподаватель, который является
руководителем данного студента, и термин руководитель является более точным,
чем термин преподаватель.
Домен этого атрибута не меняется. Атрибут РУКОВОДИТЕЛЬ имеет домен
ПРЕПОДАВАТЕЛЬ, такой же домен и у атрибута ПРЕПОДАВАТЕЛЬ. Он по-прежнему
указывает на экземпляры семантического объекта ПРЕПОДАВАТЕЛЬ. Смена имени — это
лишь уточнение роли, которую домен ПРЕПОДАВАТЕЛЬ играет в семантических
объектах СТУДЕНТ. Аналогичное изменение было сделано и в объекте ПРЕПОДАВАТЕЛЬ:
атрибут СТУДЕНТ был переименован и называется теперь РУКОВОДИМЫЙ_СТУДЕНТ,
но этот атрибут по-прежнему связан с объектами из домена СТУДЕНТ.

134 Глава 4. Семантическая объектная модель
КОЛЛЕДЖ
/о НазваниеКолледжа
ИмяДекана
Имя о.1
Фамилия лл -
НомерТелефона
МестныйАдрес
Корпус 1.1
НомерОфисаи
1.1
0.1
?.$■•$%■
КАФЕДРА
/о Назван иеКафедры
Заведующий
Имя о.1
Фамилия лл
НомерТелефона
ВсегоСтудентов -
МестныйАдрес
Корпус 11
НомерОфиса л 1
Ш1Щ^ЖЯ
шшшшшш
1.1
ПРЕПОДАВАТЕЛЬ -
ю ИмяПреподавагеля
Имя 01
Фамилия 1t1
МестныйАдрес
Корпус 1.1
HoMepOqf)nca 1.1
НомерТелефона
Ш^Ш$й;Ш
1.1
. $1Ш1В11Ш1
СТУДЕНТ
id ИмяСтудента
Имя01
Фамилия^
ю НомерСтудента
НомерТелефона
Домашний Адрес
Улица ол
Город, 1
Штат111
Индекс1л
Обращение
ДатаПоступления
;;г кафедра V
1.1
^консультант-;
Рис. 4.13. Полный набор семантических объектных диаграмм
В табл. 4.1 и 4.2 представлена спецификация модели данных. Семантические
объекты и атрибуты определены в спецификации семантических объектов, а
домены определены в спецификации доменов. Первая таблица является
альтернативным представлением информации в семантических объектных диаграммах,
и ее интерпретация очевидна.
Вторая таблица, таблица доменов, содержит такую информацию о доменах,
которая не может быть получена из семантических объектных диаграмм. Как
было указано ранее, домен имеет как семантическое, так и физическое описание.
Семантическое описание каждого объекта дается в столбце Описание, а
физическое описание дается в столбце Спецификация. Содержание столбца Описание
говорит само за себя.

Создание семантических объектных моделей данных 135
Таблица 4.1. Спецификации семантических объектов для базы данных
университета Highline
Имя объекта Имя свойства Мин. Макс. Статус Имя домена
кард. кард, идент.
КОЛЛЕДЖ
КАФЕДРА
ПРЕПОДАВАТЕЛЬ
СТУДЕНТ
Назван иеКолледжа
ИмяДекана
Имя
Фамилия
Телефон
МестныйАдрес
Корпус
НомерОфиса
КАФЕДРА
НазваниеКафедры
Заведующий
Имя
Фамилия
Телефон
ВсегоСтудентов
МестныйАдрес
Корпус
НомерОфиса
КОЛЛЕДЖ
ПРЕПОДАВАТЕЛЬ
СТУДЕНТ
ИмяПреподавателя
Имя
Фамилия
МестныйАдрес
Корпус
НомерОфиса
Телефон
КАФЕДРА
РУКОВОДИМЫЙ
СТУДЕНТ
ИмяСтудента
Имя
Фамилия
НомерСтудента
Телефон
ДомашнийАдрес
Обращение
ДатаПоступления
КАФЕДРА
РУКОВОДИТЕЛЬ
1
1
0
1
0
0
1
1
1
1
1
0
1
0
0
0
1
1
1
1
1
1
0
1
0
1
1
0
1
1
1
0
1
1
0
1
0
0
1
1
N
N
N
N
Ю
Ю
ID
ID
Ю
НазваниеКолледжа
ИмяЧеловека
Имя
Фамилия
Телефон
МестныйАдрес
Корпус
НомерОфиса
КАФЕДРА
Назван иеКафедры
ИмяЧеловека
Имя
Фамилия
Телефон
ЧислоСтудентов
МестныйАдрес
Корпус
НомерОфиса
КОЛЛЕДЖ
ПРЕПОДАВАТЕЛЬ
СТУДЕНТ
ИмяЧеловека
Имя
Фамилия
МестныйАдрес
Корпус
НомерОфиса
Телефон
КАФЕДРА
СТУДЕНТ
ИмяЧеловека
Имя
Фамилия
НомерСтудента
Телефон
Адрес
Обращение
Квартал ьнаяДата
КАФЕДРА
РУКОВОДИТЕЛЬ

136 Глава 4. Семантическая объектная модель
Таблица 4.2. Спецификация доменов для базы данных университета Highline
Имя домена
Адрес
Корпус
Местный Ад рее
Город
КОЛЛЕДЖ
НазваниеКолледжа
КАФЕДРА
НазваниеКафедры
Имя
Фамилия
Тип
Групповой
Простой
Групповой
Простой
Семантический
объект
Простой
Семантический
объект
Простой
Простой
Простой
Семантическое
описание
Адрес в США
Название корпуса
в университете
Адрес в университете
Название города
Один из колледжей
университета Highline
Официальное название
колледжа университета
Highline
Учебная кафедра
университета
Официальное название
учебной кафедры
университета
Часть группы
ИмяЧеловека,
представляющая имя
Часть группы
Физическое
описание
Улица
Город
Штат
Индекс
Text 20
Корпус
НомерОфиса
Text 25
См. спецификацию
семантических объектов
Text 25
См. спецификацию
семантических объектов
Text 25
Text 20
Text 30
ЧислоСтудентов
НомерОфиса
ИмяЧеловека
Телефон
ПРЕПОДАВАТЕЛЬ
Квартал ьнаяДата
Формула
Простой
Групповой
Простой
Семантический
объект
Простой
ИмяЧеловека,
представляющая
фамилию
Число студентов
на данной кафедре
Номер офиса
в университете
Имя и фамилия
администратора,
преподавателя или
студента
Номер телефона с кодом
региона
Имя постоянного члена
профессорско-
преподавательского
состава Highline
Учебная четверть и год
Integer; значение
в интервале {0-999},
формат 999
Text 4
Имя
Фамилия
Text 4
См. спецификацию
семантических
объектов
Text 3; значения {q01},
где q = один из
символов {«О», «3», «В»,
«Л»}, а 01 — десятичное
число от 00 до 99

Типы объектов 137
Имя домена
Штат
Улица
СТУДЕНТ
НомерСтудента
Обращение
Индекс
Тип
Простой
Простой
Семантический
объект
Простой
Простой
Простой
Семантическое
описание
Двухбук венная
аббревиатура штата
Название улицы
Лицо, принятое
в университет Highline
Идентификатор,
присвоенный
студенту, принятому
в университет Highline
Обращение человека
(для использования
в обращениях)
Девятизначный индекс
Физическое
описание
Text 2
Text 30
См. спецификацию
семантических объектов
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
ОБОРУДОВАНИЕ
ю ИнвентарныйНомер
Описание
ДатаПриобретения
Стой мость
Рис. 4.14. Пример простого объекта: а — отчеты, основанные на простом объекте;
б - простой объект ОБОРУДОВАНИЕ
Композитные объекты
Композитный объект (composite object) — это семантический объект,
содержащий один или несколько многозначных, простых или групповых атрибутов, но не
имеющий объектных атрибутов. Счет за услуги гостиницы, изображенный на
рис. 4.15, а, демонстрирует потребность в композитном объекте. Этот счет
содержит данные, относящиеся к счету в целом: НомерСчета, ДатаПрибытия, ИмяКлиента
и СуммаКОплате. Кроме того, в нем имеется повторяющаяся группа атрибутов,
которая описывает предоставленные клиенту услуги. Каждая группа включает в
себя атрибуты ДатаОказанияУслуги, ОписаниеУслуги и Стоимость.
На рис. 4.15, б показана диаграмма объекта СЧЕТ_ИЗ_0ТЕЛЯ. Атрибут Строка-
Расходов — это групповой атрибут, имеющий максимальное кардинальное число
N, что означает, что группа {ДатаОказанияУслуги, ОписаниеУслуги и Стоимость}
может появляться многократно в одном и том же экземпляре семантического
объекта СЧЕТ_ИЗ_0ТЕЛЯ.
Строка расходов не моделируется как самостоятельный семантический
объект, а вводится как атрибут объекта СЧЕТ_ИЗ_0ТЕЛЯ. Такая организация
оправдана тем, что гостиница не рассматривает каждую строку расходов в счете клиента
как нечто отдельное, и строки расходов не имеют собственных идентификаторов.
Служащие не вводят данные в строку расходов иначе как в контексте счета. Сна-

Типы объектов 139
чала служащий вводит данные для счета № 1234, а затем, в контексте данного
счета, вводит суммы. Бывает и так, что служащий берет уже существующий счет
и вносит в него дополнительные расходы.
Номер счета:
Имя клиента.
10/12/2001
10/12/2001
10/12/2001
10/12/2001
10/13/2001
I 10/13/2001
10/13/2001
ОТЕЛЬ GRANDVIEW
Си Блафс, Калифорния
1234 Дата
Мэри Джонс
Номер
Еда
Телефон
Налог
Номер
Еда
Телефон
Сумма к оплате
прибытия: 10/12/2001
$99.00
$ 37.55
$ 2.50
$ 15.00
$99.00
$ 47.90
$15.00
$315.95
а ^ б
Рис. 4.15. Пример композитного объекта: а — отчет, основанный на композитном объекте;
б — композитный объект СЧЕТ_ИЗ_ОТЕЛЯ
Минимальное кардинальное число атрибута СтрокаРасходов равно 0, что
означает, что объект СЧЕТ_ИЗ_0ТЕЛЯ может существовать без единой строки расходов.
Это позволяет открывать счет в тот момент, когда клиент вселяется в гостиницу,
и до того, как появятся какие-либо расходы. Если бы минимальное
кардинальное число равнялось 1, то нельзя было бы открыть счет, прежде чем будет
начислена хотя бы одна сумма. Решение об этом должно приниматься в свете
имеющегося делового регламента. Политика отеля может заключаться в том, чтобы не
открывать счет, пока не будут начислены какие-либо расходы. В таком случае
минимальное кардинальное число атрибута СтрокаРасходов должно равняться 1.
Композитный объект может иметь более одного многозначного атрибута.
На рис. 4.16, а показан счет за услуги гостиницы, в котором имя клиента и
стоимость услуг представлены многозначными атрибутами. Каждая из этих групп
независима от другой. Например, второе имя в группе ИмяКлиента не связано
логически со второй строкой расходов.
На рис. 4.16, б представлена объектная диаграмма для счета, показанного
на рис. 4.16, а. Атрибут ИмяКлиента показан как многозначный. Он не помещен
и скобку СтрокаРасходов, поскольку повторения имен не имеют ничего общего
с повторениями услуг. Они независимы, как мы только что отметили.
И простые, и групповые атрибуты могут быть многозначными. На рис. 4.16, а,
например, ИмяКлиента является простым многозначным атрибутом. Одного этого
достаточно, чтобы объект можно было назвать композитным.
Многозначные атрибуты могут также быть вложенными. Представьте себе,
к примеру, что требуется вести учет отдельных видов расходов в рамках одной
строки. В форме на рис. 4.17, а расходы подразделяются на виды. Например, еда
СЧЕТ_ИЗ_ОТЕЛЯ
/о НомерСчета
ДатаПрибытия
ю ИмяКлиента
СтрокаРасходов 1
ДатаОказанияУслуги 11
Описание Услуги 1 л
Стоимость 11
~*0.N
СуммаКОплате 1 л

140 Глава 4. Семантическая объектная модель
делится на завтрак, обед и ужин. Объектная диаграмма с такими вложенными
атрибутами, представленная на рис. 4.17, б, показывает, что оплата любых услуг
может быть разделена на составляющие.
1 Номер счета
1имя клиента
10/12/2001
10/12/2001
! 10/12/2001
10/12/2001
10/13/2001
10/13/2001
| 10/13/2001
ОТЕЛЬ GRANDVIEW
Си Блафс, Калифорния
1234
Мэри Джонс
Фред Джонс
Сэлли Джонс
Номер
Еда
Телефон
Налог
Номер
Еда
Телефон
Дата
Сумма к оплате
прибытия: 10/12/2001
$ 99.00
$ 37.55
$ 2.50
$15.00
$99.00
$47.90
$15.00
$315.95
СЧЕТ_ИЗ_ОТЕЛЯ
ю НомерСчета
ДатаПрибытия
ю ИмяКлиента
Строка Расходов
ДатаОказанияУслуги 11
ОписаниеУслуги 1<1
Стоимость 1.,
СуммаКОплате 1.,
0.N
Рис. 4.16. Композитный объект с двумя группами: а — объект СЧЕТ_ИЗ_ОТЕЛЯ
многозначным именем клиента; б — объект СЧЕТ_ИЗ_ОТЕЛЯ с двумя
многозначными группами
Номер счета:
Имя клиента:
10/12/2001
10/12/2001
10/12/2001
I 10/12/2001
10/13/2001
10/13/2001
10/13/2001
ОТЕЛЬ GRANDVIEW
Си Блафс, Калифорния
1234 Дата прибытия: 10/12/2001
Мэри Джонс
Номер
Еда о ~
Завтрак
Обед
Телефон
Налог
Номер
Еда
Завтрак
Закуски
Обед
Телефон
Сумма к оплате
-^^ а
$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
СЧЕТ_ИЗ_ОТЕЛЯ
ю НомерСчета
ДатаПрибытия
ю ИмяКлиента
Строка Расходов
ДатаОказанияУслуги 1
ОписаниеУслуги
ПодвидУслуги Г1
СтоимостьПодвида
1.1.
СтоимостьУслуги 11
СуммаКОплате Г1<
Рис. 4.17. Композитный объект с вложенными группами: а — объект СЧЕТ_ИЗ_ОТЕЛЯ
с разновидностями услуг; б — объект СЧЕТ_ИЗ_ОТЕЛЯ с вложенными
многозначными группами

Типы объектов 141
Для закрепления повторим, что композитный объект — это объект, имеющий
один или несколько простых или групповых атрибутов. Объектных атрибутов
он не содержит.
Составные объекты
Составной объект (compound object) имеет минимум один объектный атрибут.
На рис. 4.18, а показаны две различные формы для ввода данных. Одна из них
используется автомобильным парком компании для учета имеющихся
транспортных средств. Во вторую форму вводятся данные о сотрудниках. Согласно этим
формам, конкретное транспортное средство закрепляется не более чем за одним
сотрудником, и за конкретным сотрудником может быть закреплено не более
одного автомобиля.
Мы не можем определить из этих форм, должен ли каждый автомобиль
закрепляться за каким-либо сотрудником и должен ли каждый сотрудник иметь
автомобиль. Чтобы получить эту информацию, нам пришлось бы спросить об
этом пользователей, работающих в автопарке или в отделе кадров. Предположим,
мы выяснили, что сотрудник не обязан иметь транспортное средство, но каждое
транспортное средство должно быть закреплено за каким-либо сотрудником.
На рис. 4.18, б представлены диаграммы для объектов СОТРУДНИК и ТРАНС-
П0РТН0Е_СРЕДСТВ0. Объект СОТРУДНИК содержит в качестве одного из атрибутов
объект ТРАНСПОРТНОЕ_СРЕДСТВО, а ТРАНСПОРТНОЕ_СРЕДСТВО, в свою очередь,
содержит в качестве одного из атрибутов объект СОТРУДНИК. Поскольку и СОТРУДНИК,
и ТРАНСП0РТНОЕ_СРЕДСТВО имеют объектные атрибуты, оба они являются
составными объектами. Более того, так как ни один из атрибутов не является
многозначным, связь между объектами СОТРУДНИК и ТРАНСПОРТНОЕ_СРЕДСТВО имеет
вид «один к одному» — 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. Семантическая объектная модель
ДАННЫЕ ТРАНСПОРТНОГО СРЕДСТВА ,
Номер лицензии
Производитель
Серийный номер
Тип | Год выпуска | Цвет
Закреплен за сотрудником
РАБОЧИЕ ДАННЫЕ СОТРУДНИКА !
Имя сотрудника
Почтовый ящик
Код оплаты
Код
квалификации
Дата приема
на работу
Номер сотрудника
Отдел | Телефон ,
Закреплен автомобиль
СОТРУДНИК
ю ИмяСотрудника
Ш НомерСотрудника
ПочтовыйЯщик
Отдел
Телефон
КодОплаты
КодКвалификации
Дата Найма
ТРАНСПОРТНО^СРЕДСТВО
ГРАНСПОРТНОЕ_СРЕДСТВО
ю Имя Препода вате ля
Ш НомерЛицензии
СерийныйНомер ,
Производитель
Тип ,
Год выпуска
Цвет
... СОТРУДНИК
1.1
Рис. 4.18. Составные объекты со связью вида 1:1 между свойствами: а — примеры форм
для ввода данных об автомобиле и сотруднике; б — составные объекты СОТРУДНИК
и ТРАНСПОРТНОЕ.СРЕДСТВО
Как мы уже отметили ранее, объектные атрибуты всегда появляются парами.
Даже если формы, отчеты и запросы демонстрируют только одну сторону связи,
у связи всегда имеется две стороны. Связь можно сравнить с мостом,
соединяющим два острова: мост соприкасается с обоими островами, и двигаться по нему
можно в обоих направлениях, даже если по обычаю или закону этот мост
является однонаправленным.
Если не удается найти ни одной формы или отчета, документирующего одну
из сторон связи, команда разработчиков должна спросить пользователей о
кардинальных числах этой связи. В этом случае команде требуется выяснить,
сколько общежитий может быть у студента и должен ли студент быть прикреплен
к общежитию. Здесь мы допустим, что ответы на этот вопрос были следующими:
студент может быть прикреплен максимум к одному общежитию, но может и не
быть прикрепленным ни к одному. Так, на рис. 4.19, б объект DORMITORY
содержит многозначный объектный атрибут STUDENT, а объект STUDENT имеет
однозначный объектный атрибут DORMITORY. Таким образом, связь между объектами
DORMITORY и STUDENT имеет вид «один ко многим», или 1:N.

Ти п ы о бъе ktqb 143
DORMITORY OCCUPANCY REPORT i
Dormitory
Jngersol!
Student name
Adams, Elizabeth
Baker, Rex
Baker, Brydie
I Charles, Stewart
Scott Sally
Taylor, Lynne
Resident Assistant
Sarah and Allen French
Student Number
710
104
744
319
447
810
Phone |
3-5567
Class
SO
FR
JN
SO
SO
FR
Щ Student Data fotm
iiil
DORMITORY
Ш DormName
Ю ResidentName
Phone
| ' STUDENT"><';':
I.N
STUDENT
id StudentName
id. StudentNumber
Major
Adviser
Class
HighScool
PriorCollege
Cam pus Address
CampusPhone
V DORMITORY
0.1
Рис. 4.19. Составные объекты со связью вида 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.
S3 воок Stock Data
I
зоок
id Title
;?AuffloRf-;/i:
id ISBN
Publisher
Copyringht Date
IN
AUTHOR
id AuthorName
AuthorDates
||J; BOOK
1 N I
Рис. 4.20. Составные объекты со связью вида N:M между свойствами: а — примеры
форм для ввода данных книжного магазина; б — объекты BOOK и AUTHOR
На рис. 4.21 изображены все четыре типа составных объектов. Вообще
говоря, объект А может содержать максимум один или много объектов Б.
Аналогично, объект Б может содержать один или много объектов Б. Мы будем
использовать эту таблицу при обсуждении структуры базы данных в главе 7.
Гибридные объекты
Гибридные объекты (hybrid objects) — это комбинации композитных и составных
объектов. В частности, гибридный объект — это семантический объект, имеющий
минимум один многозначный групповой атрибут, в состав которого входит
объектный атрибут.
На рис. 4.22, а изображена вторая версия отчета о занятости общежития,
представленного на рис. 4.20, я. Различие заключается в том, что третий столбец

Типы объектов 145
данных студента содержит атрибут Rent (плата за проживание) вместо атрибута
Class (группа). Эта разница является существенной, поскольку плата за
проживание в общежитии является атрибутом не студента, а общежития, и относится
к комбинации объектов STUDENT и DORMITORY.
Объект 1 может содержать
Один
Много
Один
1:1
М:1
Много
1:N
M:N
Объект 2
может
содержать
Рис. 4.21. Четыре типа составных объектов
DORMITORY OCCUPANCY REPORT
Dormitory
Ingersoll
Student name
Adams, Elizabeth
Baker, Rex
Baker, Brydie
Charles, Stewart
Scott, Sally
Taylor, Lynne
Resident Assistant
Sarah and Allen French
Student Number
710
104
744
319
447
810
Phone
3-5567
Rent
$175.00 i
$225.00
$175.00
$ 135.00 I
$ 225.00
$175.00
DORMITORY
Ш DormName
ResidentName
Phone
StudentRent
ШШЯШШШЯ I
Rent
0.1
I
STUDENT
id StudentName
Ш StudentNumber
Щ)ОВМГТОЯУ :ff
0.1
DORMITORv.
id DormName
ResidentName
Phone
$ТЦ||||1Т
Rent
0.1
STUDENT
id StudentName
id StudentNumber
Г
DORMITORY.:
Рис. 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, 6 показан семантический объект SALES-ORDER (заказ). Он
содержит необъектные атрибуты SatesOrderNumber (номер заказа), Date (дата), Subtotal
(промежуточный итог), Tax (налог) и Total (итог). Кроме того, он содержит
объектные атрибуты CUSTOMER и SALESPERSON, а также многозначную группу,
представляющую каждую позицию заказа. Группа содержит необъектные атрибуты Quantity
(количество) и Extended Price (цена с надбавкой) и объектный атрибут ITEM.
Объектные диаграммы на рис. 4.23, б неоднозначны в одном аспекте, который
может быть важен или не важен, в зависимости от приложения. Согласно
объектной диаграмме, товар может быть связан более чем с одним заказом. Но поскольку
многозначная группа Lineltem инкапсулирована (вложена) в объект SALES-ORDER,
из этой диаграммы не ясно, может ли конкретный вид товара появляться один
раз или многократно в одном и том же объекте SALES-ORDER.
В общем, есть четыре интерпретации максимального кардинального числа
для спаренных атрибутов гибридного объекта SALES-ORDER:
1. Конкретный товар может появляться только в одном заказе и только в
одной строке данного заказа.
2. Конкретный товар может появляться только в одном заказе, но во многих
его строках.
3. Конкретный товар может появляться во многих заказах, но в каждом
заказе — только в одной строке.
4. Конкретный товар может появляться во многих заказах, а в рамках
заказа — во многих строках.
Когда важно различать эти случаи, нужно использовать следующую запись:
в случаях 1 и 2 максимальное кардинальное число гибридного объектного
атрибута следует установить равным 1. Так, для данного примера максимальное
кардинальное число атрибута SALES-ORDER объекта ITEM установлено равным 1. Если
конкретный товар может появляться только в одной строке заказа (случай 1), он
должен быть помечен как имеющий уникальный идентификатор в данной
группе. Если нет (случай 2), то помечать его не требуется. Эти два случая
изображены на рис. 4.24, а и б.

Типы объектов 147
S3 CatbonRwer Furniture Sales G tder Form
f^j^^^l^ffv-ili^Si^
Date 25-Sep-C4
ШШШ' Carbon R 'ver с
d
^ ::гз4
;|Щге '^щШшк
'•:'■■ ■?$■'' '•'..':.?%■'&:>''.*''
';'■' S atoei^i.Hfe£:;
W
"Dods":-
--d
Salesperson Code
1 g-i 1
: :j Quanli^H foero ЙышЬ« j:-.
'• Pfttfrription
j UnifPflte:
78 .Executive Desk
79 Conference Table
80 Side Chair
SALES-ORDER
ID SalesOrderNumber
Date
.::.£ШТО№И;
ШШМ$РШ80Н$
Lineltem
Quantity-^
ШШй
ExtendePrice л
1.1
Subtotal
Tax 1И
Total л л
1.1
IN
ITEM
ID ItemNumber
Item Description
UnitPrice1 1
|SALE^gDEgi
O.N
CUSTOMER
id CustomerName
Address
City
State
Zip
Phone
BjSALES-ORD^e
SALESPERSON i
jp SalesPersonName
SalesPersonCode
>;::$НМ$Щ*Ш'<-
O.N
Рис. 4.23. Гибридный объект SALES-ORDER и связанные с ним объекты:
а — форма заказа; б — объекты, моделирующие форму заказа
В случаях 3 и 4 максимальное кардинальное число гибридного объектного
атрибута устанавливается равным N. Так, для данного примера максимальное

148 Глава 4. Семантическая объектная модель
кардинальное число атрибута SALES-ORDER в объекте ITEM устанавливается
равным N. Далее, если конкретный товар может появляться только в одной строке
заказа (случай 3), он должен быть помечен как имеющий уникальный
идентификатор в данной группе. Если нет (случай 4), то помечать его не требуется. Эти
два случая изображены на рис. 4.25, а и б.
SALES-ORDER
ю SalesOrderNumber
Date
CUSTOMER
SALESPERSON! 1
Lineltem
Quantity т.-,
:§TEM
ExtendePrice л
Subtotal
TaXi.i
Total л л
1.1
ITEM
Ш ItemNumber
Item Description
UnitPrice11
0.1
SALES-ORDER
id SalesOrderNumber
Date
CUSTOMER
II
1.1
SALESjPEBSONi
Lineltem
Quantity r1
"■:ШШ
ExtendePrice
Subtotal
Tax!.!
Total 4 4
1.1 -'
1 N
1.1
ITEM
ID ItemNumber
Item Description
UnitPrice1 л
^тшщщ^
0.1
Рис. 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
ю SalesOrderNumber
Date
§ОЩ^ЩШ:
р&А1£8Й|^&М-
1.1
1.1
Linellem
Quantity^
~:;пШ?\'
ExtendePrice
Subtotal
1.1
1.1
1.N
Taxt1
Total л
i.i
ITEM
jq ItemNumber
ItemDescription
UnitPrice1>1
№ES-QFffii
J0.N
SALES-ORDER
jq SalesOrderNumber
Date
Ш-^ЩшщЩ
||gfttESFER$QN;
Linellem
Quantity^ t
ITE&&
ExtendePrice
Subtotal
Tax ^
Total A A
1.1
1.1
1.1
ITEM
jq ItemNumber
ItemDescription
UnitPricei^
'O.N
Рис. 4.25. Примеры 3 и 4 максимальной кардинальности: а — один товар в одной строке
многих заказов; б — один товар во многих строках многих заказов

150 Глава 4. Семантическая объектная модель
FLY CHEAP INTERNATIONAL
Flight Planning Data Report
FLIGHT NUMBER
ORIGINATING CITY
FUEL ON TAKEOFF
WEIGHT ON TAKEOFF
FC-17 DATE 7/30/2001
Seattle DESTINATION Hong Kong
AIRPLANE
Tail Number
Type
Capacity
PILOT
Name
FI-ID
Flight Hours
N1234FI
747-SP
148
Micheel Nilson
32887
18,348
Рис. 4.26. Пример ассоциативного объекта: отчеты и формы
Чтобы лучше понять это, рассмотрим рис. 4.28, а, на котором изображен
отчет о назначении архитекторов на проект. Хотя само назначение не имеет явного
идентификатора, в действительности идентификатором является комбинация

Типы объектов 151
{НазваниеПроекта, ИмяАрхитектора}. Эти атрибуты, однако, принадлежат объектам
ПРОЕКТ и АРХИТЕКТОР соответственно, а не объекту НАЗНАЧЕНИЕ.
Идентификатором назначения является, таким образом, комбинация идентификаторов вещей,
которые назначаются друг другу.
FLIGHT
id FlightiD j
FlightNumber !
Date J
OriginatingCity
Destination
FueOnTakeOff
WeightOnTakeOff
I AIRPLANE -'Щ
-3^4
Рис. 4.27. Объекты FLIGHT, PILOT и AIRPLANE
На рис. 4.28, б показаны объектные диаграммы для этого случая. И ПРОЕКТ,
и АРХИТЕКТОР являются объектными атрибутами объекта НАЗНАЧЕНИЕ, а группа
{ПРОЕКТ, АРХИТЕКТОР} является идентификатором объекта НАЗНАЧЕНИЕ. Это
означает, что комбинация экземпляра объекта ПРОЕКТ и экземпляра объекта АРХИТЕКТОР
идентифицирует конкретное назначение.
Обратите внимание, что идентификатор НомерНазначения на рис. 4.28, б не
является уникальным; тем самым указывается, что архитектор может быть
назначен на один и тот же проект несколько раз. Если это не так, идентификатор
должен быть объявлен уникальным. Далее, если сотрудник может быть назначен
на один и тот же проект более одного раза и если по какой-то причине важно
иметь уникальный идентификатор для назначения, к группе следует добавить
атрибут даты или какой-нибудь еще атрибут, указывающий время (неделя,
квартал и т. д.).
Объекты вида родитель/подтип
Чтобы понять, что представляют собой объекты вида родитель/подтип (parent/
subtype objects), рассмотрим объект СОТРУДНИК на рис. 4.29, а. Некоторые
атрибуты объекта СОТРУДНИК относятся ко всем сотрудникам, а некоторые — только
к тем сотрудникам, которые являются менеджерами. Объект на рис. 4.29, а не
слишком точно отражает действительность, поскольку атрибуты, свойственные
менеджерам, не подходят для сотрудников, не являющихся менеджерами.
Более удачная модель показана на рис. 4.29, б. Здесь объект СОТРУДНИК
содержит объект подтипа МЕНЕДЖЕР. Все атрибуты, относящиеся к менеджерам, перене-
AIRPLANE
ip_ TallNumber
Manufacturer
Type
TotalAirframeHours
TatalEngineHours
EngHoursPastOH
CurrentCapacity
RangeAsConfig
TUQHT
J0.N
.
PILOT 1
ю FCI-ID
Name
SpocialSecurity Number 1
Street
City
State i
Zip
Phone
EmergPhone
DateOfLastCheckOut
Hours
DateOfLastPhysical
Ш^МшШШш
O.N

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
НАЗНАЧЕНИЕ
ю НомерНазначения
ПРОЕКТ
'1.1!
АРХИТЕКТОР
111
НачалоНазначения
КонецНазначения
МаксимумЧасов
МаксСтоимостьТруда
МаксСтоимостьМатериалов
ПРОЕКТ
ю НазваниеПроекта
МенеджерПроекта
НачалоПроекта
ОкончаниеПроекта
ШЗЩШЩЙ!
АРХИТЕКТОР
ю ИмяАрхитектора
Телефон
НомерОфиса
НАЗНАЧЕНИИ
1.N
Рис. 4.28. Ассоциативный объект НАЗНАЧЕНИЕ: а — пример отчета о назначении;
б — объект НАЗНАЧЕНИЕ с семантическим объектным идентификатором
Первым атрибутом подтипа является родительский объект, обозначенный
индексом Р. Указание родительского атрибута является обязательным всегда.
Идентификаторы у подтипа те же, что и у родителя. На рис. 4.29 атрибуты Номер-
Сотрудника и ИмяСотрудника являются идентификаторами как объекта СОТРУДНИК,
так и объекта МЕНЕДЖЕР.
Атрибуты подтипа показываются с помощью индексов 0.ST или 1.ST. Первая
цифра (0 или 1) — это минимальное кардинальное число подтипа. Если оно
равно 0, подтип является необязательным, а если 1, то подтип является
обязательным. (Обязательный подтип не имеет смысла для этого примера, но необ-

Типы объектов 153
ходимость в нем появится в последующих, более сложных случаях.) Буквы ST
(subtype — подтип) указывают на то, что атрибут является подтипом, или
атрибутом типа «ЕСТЬ».
Объекты вида родитель/подтип обладают важной характеристикой,
называемой наследованием. Подтип приобретает, или наследует, все атрибуты своего
родителя, и поэтому объект МЕНЕДЖЕР наследует все атрибуты объекта СОТРУДНИК.
Вдобавок родитель приобретает все атрибуты своих подтипов, и сотрудник,
являющийся менеджером, приобретает все атрибуты менеджера.
Семантический объект может содержать более одного атрибута подтипа. На
рис, 4,30 показан второй вариант объекта СОТРУДНИК, который имеет два атрибута
подтипа — МЕНЕДЖЕР и ПРОГРАММИСТ. Поскольку оба этих атрибута являются
необязательными, объект СОТРУДНИК может иметь, один или оба эти подтипа или не
иметь ни одного. Это означает, что некоторые сотрудники не являются ни
менеджерами, ни программистами, некоторые являются менеджерами, но не являются
программистами, некоторые являются программистами, но не являются
менеджерами, а некоторые одновременно являются программистами и менеджерами.
СОТРУДНИК
id НомерСотрудника 11
id ИмяСотрудника tЛ
ДатаНайма
Зарплата
ДолжностьМенеджера
УровеньМенеджмента
НачисленнаяПремия
ВыплаченнаяПремия
Данные сотрудника
Данные менеджера
СОТРУДНИК
ю НомерСотрудника
ю ИмяСотрудника
ДатаНайма
Зарплата
МЕНЕДЖЕР
o.sr
МЕНЕДЖЕР
£',' СОТРУДНИК
Stai «23 р
ДолжностьМенеджера
УровеньМенеджмента
НачисленнаяПремия
ВыплаченнаяПремия
Рис. 4.29. Необходимость введения подтипа МЕНЕДЖЕР: а — объект СОТРУДНИК
без подтипа; б - объект СОТРУДНИК с подтипом МЕНЕДЖЕР
Иногда подтипы исключают друг друга. То есть транспортное средство может
быть легковым автомобилем или грузовиком, но не тем и другим одновременно.
Клиент может быть индивидуальным клиентом, товариществом или
корпорацией, но только одним из этих трех типов. Когда подтипы исключают друг друга,
они помещаются в группу подтипов, и группе присваивается индекс в формате
X.Y.Z. X — это минимальное кардинальное число, равное 0 или 1, в зависимости

154 Глава 4. Семантическая объектная модель
от того, является ли группа подтипов обязательной. Y и Z указывают количество
атрибутов в группе, которым разрешается иметь значение. Y — минимальное
количество, Z — максимальное.
На рис. 4.31, а три типа клиентов изображены как группа подтипов. Индекс
группы, 0.1.1, означает, что подтип не требуется, но если он существует, в группе
должен существовать минимум один и максимум один*подтип (иначе говоря,
ровно один). Заметьте, что каждый из подтипов имеет индекс 0.ST, то есть все
они являются необязательными, как и должно быть. Если бы все они были
обязательными, максимальное количество атрибутов было бы 3, а не 1. Эта запись
достаточно надежна, чтобы предусмотреть ситуации, когда обязательными
являются три из пяти или семь из десяти подтипов.
СОТРУДНИК
Ш НомерСотрудника
ю ИмяСотрудника
ДатаНайма
Зарплата
1^'МЕИей^Це1
ШОГЙШШТ
0ST
0.ST
МЕНЕДЖЕР
11 7Ь6ТрэднМ?:;|
Должность Менеджера
УровеньМенеджмента
НачисленнаяПремия
ВыплаченнаяПремия
ПРОГРАММИСТ
1ШШШШШЙШШ
Язык o.n
ОперационнаяСистема 0 N
Рис» 4.30. Объект СОТРУДНИК с двумя подтипами
Можно смоделировать и более сложные ограничения, если ввести вложенные
подтипы. Группа подтипов на рис. 4.31, б моделирует ситуацию, когда
корпорация может быть либо налогооблагаемой, либо не налогооблагаемой. Если
корпорация не является налогооблагаемой, это должна быть либо правительственная
организация, либо школа. В этом примере показано только несколько
необъектных атрибутов. В реальности, если бы требовалась такая сложная структура,
в ней, скорее всего, было бы больше атрибутов.
Объекты вида архетип/версия
Последний тип объектов — это объекты вида архетип/версия (archetype/version
objects). Объект-архетип (archetype object) — это семантический объект,
порождающий другие семантические объекты, которые представляют версии (version
objects), выпуски или издания архетипа. Например, на рис. 4.32 объект-архетип
УЧЕБНИК порождает объекты-версии ИЗДАНИЕ. Согласно этой модели, атрибуты
Название, Автор и Издательство принадлежат объекту УЧЕБНИК, а атрибуты Поряд-
ковыйНомерИздания, ДатаВыхода и КоличествоСтраниц — объекту ИЗДАНИЕ.

Типы объектов 155
КЛИЕНТ
ю НомерКлиента
ИмяКлиента
Телефон
$тЩ£Щ&КтЩ.
•ТОВДШЩЕСТВд;.;
0.ST :
o.st ;
ШЬ* ■'.■":..';.v.i..:.6... •■■■ :•:.• ::; ;*ш
O.ST
0/1.1
ФИЗИЧЕСК0Е_ЛИЦО
>"^-клиЁйт:
НомерСоциальнойСтраховки
СовокупнаяСтоимость
ТОВАРИЩЕСТВО
;gg|№^EHfv
НалоговыйНомер
УправляющийПартнер
КОРПОРАЦИЯ
Р
НалоговыйНомер
Баланс
ИмяДоверенногоЛица
ТелефонДо вере иного Лица
ФИЗИЧЕСКОЕ_ЛИЦО
•:КЯШШ
НалоговыйНомер
Баланс
ИмяДоверенногоЛица
Тел ефон Доверен но гоЛ и ца
:тлШ)0&пмштт^юр(2
0.ST
нЕвдо(адш
OS Г
0.1.1
ПРАВИТЕЛЬСТВЕННОЕ АГЕНТСТВО
Н^НЯИИ^^К^сШ
ФедеральныйНомер
НАЛОГООБЛАГАЕМАЯ КОРП
|||||||||1||||
НалоговаяСтавка
НЕНАЛОГООБЛАГАЕМАЯ_КОРП
шшшшшшш?
НомерОсвобожд
р
эния
;пЩитШьственноЩ
^^^^^^^^^^^' ";Ш111|1111
0.ST
0.ST
0.1
ШКОЛА
ИЕнЭДрэШ^
ШкольныйОкруг
Рис. 4.31. Взаимоисключающие (а) и вложенные (б) подтипы
Идентификационная группа объекта ИЗДАНИЕ состоит из двух частей: УЧЕБНИК
и ПорядковыйНомерИздания. Это типичный образец идентификатора
объекта-версии. Одна часть идентификатора содержит объект-архетип, а вторая часть — это
простой атрибут, идентифицирующий версию архетипа. На рис. 4.33 изображен
еще один пример объектов вида архетип/версия.

156 Глава 4. Семантическая объек