Text
                    ТЕОРИ* РАКТИКА
ПОСТРОЕНИЯ
□
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 Гла