Текст
                    ТЕОРИЯ И ПРАКТИКА
ПОСТРОЕНИЯ
БАЗ ДАННЫХ
9-Е ИЗДАНИЕ
Д. КРЁНКЕ
рн
PTR
гхпитгр

DATABASE PROCESSING NINTH EDITION David M. Kroenke Prentice Hall PTR Upper Saddle River, New Jersey 07458 www.phptr.com
HARCCHHR COmPUTER SCIENCE * Д.КРЁНКЕ ТЕОРИЯ И ПРАКТИКА ПОСТРОЕНИЯ БАЗ ДАННЫХ 9-Е ИЗДАНИЕ Е^ППТЕР* Москва • Санкт-Петербург • Нижний Новгород. Воронеж Новосибирск • Ростов-на-Дону • Екатеринбург • Самара Киев Харьков Минск 2005 _______ Ульяновские государегаоиные технические умиаерснто
ББК 32 973.233 УДК 6813.06 К79 Крёнке Д. К79 Теория и практика построения баз данных 9-е изд. — СПб. Питер 2005 — 859 с.: ил. — (Серия «Классика computer science»). ISBN 5-94723-583-8 В книге Д. Крёнке, выдержавшей уже 9 переизданий, вы найдете традиционно подробный, методически выверенный теоретический и практический материал, посвященный вопросам разработки и использования баз данных. В новом издании более глубоко обсуждаются моделирование данных и проектирование баз данных; расширены разделы no SQL и XML; добавлен раздел, знакомящий е ADO NET. Книгу отличает большое количество примеров, моделирующих типичные ситуации из практики делового мира. ББК 32.973.233 УДК 681 3 06 Права на издание получены по соглашению с Prentice Hall. Inc. Upper Sadie River New Jersey 07458. Все права защищены Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения алаг/ггьмее авторских прав. г-'Ы|^- .-.жж_.яяся в данной книге, получена из источников, рассматриваемых издательством как надежные Тем не тчнее. имев в виду возможные -ычгомж или технические ошибки, издательство не может гарантировать абсолютную ток есть и полноту приводимых сведений и не несет ответственности за возможные ошибки, связанные с использованием книги. IS8H 0131015141 (англ ) ООН 6-94723-583-8 ©2003 by Pearson Education, Inc. ©Перевод на русский язык. ЗАО Издательский дом «Питер», 2005 © Издание на русском языке, оформление, ЗАО Издательский дом «Питер». 2005
Краткое содержание Предисловие.................................................... Благодарности.................................................. Глава 1 Введение в базы данных.......................... 24 Часть I. Модель данных «сущность—связь» Глава 2. Модель «сущность—связь»: методы и средства моделирования ............................................ 60 Глава 3. Создание моделей данных «сущность—связь»: описание процесса и примеры........................116 Часть II. Проектирование баз данных Глава 4. Реляционная модель и нормализация.................172 Глава 5. Проектирование баз данных.........................215 Часть III. Структурированный язык запросов (SQL) Глава 6. Введение в язык SQL...............................266 Глава 7. Использование SQL в приложениях...................307 Глава 8. Перепроектирование баз данных.....................354 Часть IV. Обработка многопользовательских баз данных Глава 9. Многопользовательские базы данных.................394 Глава 10. Работа с базами данных в Oracle 9i...............435 Глава 11. Работа с базами данных в SQL Server 2000 ....... 494 Часть V. Стандарты доступа к базам данных Глава 12. ODBC, OLE DB, ADO и ASP..........................544 Глава 13. XML и ADO.NET....................................591 Глава 14. JDBC, Java Server Pages и MySQL..................651 Глава 15. Совместное использование данных предприятия......690 Часть VI. Работа с объектно-ориентированными базами данных Глава 16. Объектно-ориентированные базы данных.............738 Приложение А. Структуры данных.............................775 Приложение Б. Семантическая объектная модель...............802 Алфавитный указатель.......................................845
Содержание Предисловие....................................................... 17 Особенности настоящего издания......................................17 Более глубокое обсуждение моделирования дан! ix и проектирования баз данных.....................................17 Расширение изучения SQL..........................................18 XMLhADO.NET......................................................19 Соблюдение баланса в охвате Oracle 9i и SQL Server 2000 ........ 19 Структура книги.....................................................29 Благодарности..................................................... 22 От издательства.....................................................29 Глава 1. Введение в базы данных.....................................24 Почему используются базы данных?....................................24 Проблемы списков....................................................25 Проблемы совместно используемых данных..............................27 Базы данных как группы связанных таблиц.............................28 Связи............................................................29 Объединение таблиц...............................................31 Что такое система обработки базы данных?............................31 Функции прикладных программ......................................32 Функции СУБД.....................................................33 Определение и компоненты базы данных.............................34 Три примера систем баз данных....................................37 Как построить систему баз данных....................................44 Фаза формулирования требований..................................45 Фаза проектирования.............................................46 Фаза реализации.................................................48 Разработка приложения ..........................................48 Краткая история баз данных..........................................48 Ранние модели баз данных........................................49 Реляционная модель..............................................50 СУБД для персональных компьютеров...............................51 Объектно-ориентированные СУБД (ООСУБД)..........................51 Недавняя история................................................52 Резюме............................................................... Вопросы группы I..................................................53
Вопросы группы II...................,................. . . . . Вопросы к проекту FiredUp.................................... Вопросы к проекту Twigs Tree................................. se 56 57 Часть I. Модель данных «сущность—связь» Глава 2. Модель «сущность—связь»: методы и средства моделирования ...................................................... 60 Тройственная схематическая модель ANSI/SPARC.........................60 Внешняя, концептуальная и внутренняя схемы.........................61 Построение концептуальной схемы................................... 62 Сага о Брюсе и Зельде..............................................62 Модель «сущность—связь» и ее варианты.........................., , , . 65 Версии модели «сущность—связь»................................ . , 65 Выбор версии модели................................................66 Расширенная модель «сущность—связь»..................................67 Сущности....................................................., . . 67 Атрибуты.................................................... - 68 Идентификаторы.....................................................69 Связи............................................................ 69 Подтипы сущностей................................................ .76 Пример ER-диаграммы................................................78 Стандарт IDEF1X......................................................80 Сущности в IDEF1X..................................................80 Связи в IDEF1X................................................. . . 83 Домены..............................................................91 Стандарт IDEF1X и средства моделирования данных...........,.........94 Диаграммы «сущность—связь» в стиле UML................................94 Сущности и связи в UML..............................................94 Конструкции ООП, введенные языком UML...............................98 Роль UML в базах данных на сегодняшний день.........................99 Резюме................................................................100 Вопросы группы I.....................................................103 Вопросы группы II....................................................106 Вопросы к проекту FiredUp............................................113 Вопросы к проекту Twigs Tree.........................................114 Глава 3. Создание моделей данных «сущность—связь»: описание процесса и примеры.......................................116 Процесс моделирования данных.......................................116 Определение системных требований...............................117 Определение сущностей........................................ 120 Определение связей.............................................122 Определение идентификаторов....................................124 Определение атрибутов и доменов............................ . . 125 Проверка модели.......................>........................127 Методы проверки модели данных..................................129
В Содержание Построение моделей данных на базе анализа форм и отчетов...... 131 Одиночные сущности..........................................131 Идентифицирующие связи принадлежности.......................132 Неидентифицирующие связи принадлежности.....................134 Неспецифические (N:M) связи.................... ............137 Подтипы и категории.........................................141 Модель ЗАКАЗ................................................141 Рлрзбитка модели данных: пример................................144 Отчет о колледже............................................144 Отчет о кафедре и преподавателях............................145 Отчет о студентах кафедры...................................148 Домены......................................................152 Резюме.........................................................154 Вопросы группы I...............................................156 Вопросы группы II..............................................158 Задачи по моделированию........................................166 Вопросы к проекту FiredUp...................................... 169 Вопросы к проекту Twigs Tree...................................170 Часть II. Проектирование баз данных Глава 4. Реляционная модель и нормализация.........................172 Отношения..........................................................172 Пример отношения и две таблицы, не являющиеся отношениями.......173 Замечание по терминологии.......................................176 Типы ключей........................................................176 Композитные ключи...............................................177 Первичные ключи и ключи-кандидаты...............................177 Функциональные зависимости......................................178 Нормализация.......................................................180 Аномалии модификации...........................................180 Суть нормализации..............................................182 Классы отношений...............................................183 Нормальные формы от первой до пятой................................184 Вторая нормальная форма (2НФ)..................................184 Третья нормальная форма (ЗНФ)..................................185 Нормальная форма Бойса-Кодца (НФБК)............................186 Четвертая нормальная форма (4НФ)...............................188 Пятая нормальная форма (5НФ)...................................191 Доменно-ключевая нормальная форма (ДКНФ)................... , . 191 Определение....................................................192 Первый пример доменно-ключевой нормальной формы................193 Второй пример доменно-ключевой нормальной формы . . 194 Третий пример доменно ключевой нормальной формы............... . 196 Синтез отношений .............................................. 198 Атрибутивная связь «один к одному».............................198 Атрибутивная связь «многие к одному»...........................201
Атрибутивная связь «многие ко mhoi им» . , . ................. 201 Многозначные зависимости: часть вторая...................... • 203 Ненормализованные струю уры.................................... 204 Нормализованная схема неестественна.............. .... 204 Нормализация неудобна....................................... . 204 Нормализация может привести к низкой производительности........205 Резюме.............................................. ........... 206 Вопросы группы I............................................... 208 Вопросы группы II.............................................. 210 Вопросы к проекту FiredIIр.......................................212 Вопросы к проекту Twigs Tree.....................................214 Глава 5. Проектирование баз данных...............................215 Процесс проектирования базы данных...............................215 Преобразование сущностей и атрибутов в таблицы и столбцы.......216 Выбор первичного ключа.........................................217 Суррогатные ключи..............................................219 Представление связей.............................................221 Принципы представления связей..................................221 Представление идентификационно-зависимых связей................225 Представление связей принадлежности вида 1:1 и 1:N.............229 Представление связей вида N:M..................................236 Представление подтипов и категориальных связей.................241 Представление слабых, но не идентификационно-зависимых сущностей . . . 244 Примеры связей.................................................245 Особые ситуации..................................................249 Представление рекурсивных связей...............................249 Представление тернарных связей и связей высших порядков........251 Пустые значения................................................256 Резюме...........................................................257 Вопросы группы I.................................................260 Вопросы группы II................................................263 Вопросы к проекту FiredUp........................................264 Вопросы к проекту Twigs Тгее.....................................264 Насть III. Структурированный язык запросов (SQL) Глава 6. Введение в язык SQL.......................................266 База данных управления проектами на предприятии....................267 Средства определения данных языка SQL..............................269 Оператор CREATE TABLE.....................;.....................269 Определение первичных и альтернативных ключей с помощью оператора ALTER.................................................271 Предпочтение — использованию оператора CREATE...................274 Передача SQL-кода на исполнение СУБД............................275 Операторы DROP..................................................276 Средства запроса данных языка SQL..................................276 Чтение заданных столбцов из одиночной таблицы...................276 Чтение заданных строк из одиночной таблицы. ....................278
10 Содержание Чтение заданных строк и столбцов из одиночной таблицы............279 Диапазоны, специальные символы и пустые значения в предложениях WHERE............................................280 Сортировка результатов...........................................282 Встроенные функции SQL...........................................283 Встроенные функции и группировка.................................285 Чтение данных из нескольких таблиц с применением вложенных запросов 286 Чтение данных из нескольких таблиц с помощью операции соединения . . . 288 Сравнение вложенного запроса и соединения........................292 Внешние соединения...............................................293 Средства модификации данных языка SQL...............................295 Вставка данных................................... ..............295 Изменение данных.................................................296 Удаление данных.................................................. 297 Резюме..............................................................298 Обзорные вопросы................................................. . 300 Упражнения..........................................................303 Вопросы к проекту FiredUp...........................................304 Вопросы к проекту Twigs Tree........................................305 Глава 7. Использование SQL в приложениях ......... 307 Галерея View Ridge..................................................307 Требования к приложению..........................................308 Модель данных ...................................................308 Создание таблиц..................................................313 Данные для примера...............................................316 SQL-представления...................................................316 Использование представлений для скрытия столбцов и строк.........320 Использование представлений для отображения вычисляемых столбцов ... 321 Использование представлений для скрытия сложного синтаксиса......322 Другие варианты использования представлений......................325 Обновление представлений.........................................326 SQL-представления не являются внешними представлениями...........327 Встраивание SQL-операторов в прикладные программы...................328 Триггеры............................................................329 Использование триггеров для проверки допустимости вводимых данных . . . 330 Использование триггеров для присвоения значений по умолчанию.....331 Обновление представлений.........................................333 Процедуры обеспечения ссылочной целостности......................334 Хранимые процедуры..................................................338 Преимущества хранимых процедур...................................338 Хранимая процедура Add_WORK......................................339 Использование SQL в коде приложения.................................341 Резюме............................... .......................... Вопросы группы I................................................... д47 Вопросы группы II............................................... 249 Вопросы к проекту FiredUp............ Вопросы к проекту Twigs Tree.... . . i..............................qso
Глава 8. Перепроектирование баз данных..................... , , . 354 Зачем перепроектировать базы данных?............................. 354 другие SQL-операторы........................................... - 355 Коррелированные подзапросы..................................... 356 Условия EXISTS и NOT EXISTS.....................................359 Анализ существующей базы данных................................... 361 Реконструкция ................................................. 362 Графы зависимостей.............................................. 363 Резервное копирование и тестовые базы данных................... 366 Изменение имен таблиц и свойств столбцов..........................368 Изменение имен таблиц...........................................368 Добавление и удаление столбцов..................................369 Изменение типа данных столбца или ограничений...................371 Добавление и удаление ограничений...............................371 Изменение кардинальности и свойств связей.........................372 Изменение минимальной кардинальности............................372 Изменение максимальной кардинальности...........................373 Добавление и удаление связей......................................377 Добавление таблиц и связей с целью нормализации.................378 Автоматическое конструирование....................................384 Резюме............................................................384 Вопросы группы I................................................. 387 Вопросы группы II.................................................390 Вопросы к проекту FiredUp.........................................391 Вопросы к проекту Twigs Тгее......................................392 Часть IV. Обработка многопользовательских баз данных Глава 9. Многопользовательские базы данных...........................394 Администрирование баз данных.........................................395 Управление структурой базы данных..................................396 Управление параллельной обработкой...................................398 Необходимость в атомарных транзакциях..............................398 Блокировка ресурсов................................................403 Оптимистическая и пессимистическая блокировки......................406 Объявление характеристик блокировки................................408 Согласованность транзакций........................................409 Уровень изоляции транзакции.......................................410 Тип курсора.......................................................411 Безопасность базы данных............................................413 Права и обязанности по обработке..................................414 Обеспечение безопасности средствами СУБД..........................415 Принципы обеспечения безопасности СУБД............................416 Обеспечение безопасности средствами приложения....................418 Атака со вставкой SQL-кода........................................420 Восстановление баз данных...........................................420 Восстановление путем повторной обработки..........................421 Восстановление через откат-накат.................................... Управление СУБД.......................................................
12 Содержание Поддержание репозитория данных . ..................,............426 Резюме............................................... , . . . . 427 Вопросы группы I.................................................429 Вопросы группы II............................................... 432 Проект...................................................... . 432 Вопросы к проекту FiredUp............................... . . 433 Вопросы к проекту Twigs Tree................................ . 434 Глава 10. Работа с базами данных в Oracle 9i.....................435 Установка Oracle................................................ 436 Создание базы данных Oracle.................................. 436 Работа с SQL* Plus.............................................437 Создание таблиц.............................................. 442 Создание индексов........................................ 449 Изменение структуры таблицы....................................450 Создание представлений.........................................451 Работа с Oracle Enterprise Manager Console.......................452 Логика приложения............................................ 455 Хранимые процедуры . , .......................... 457 Словарь данных.................................................. 472 Управление параллельной обработкой........................ ... . 474 Уровень изоляции «завершенное чтение»..........................475 Уровень изоляции «сериализуемость».............................476 Уровень изоляции «только чтение»............................... 477 Дополнительные замечания о блокировках.........................477 Безопасность.....................................................477 Системные привилегии учетной записи.................. . . . . 478 Идентификация пользователей с помощью учетных записей..........481 Резервное копирование и восстановление в Oracle..................483 Средства восстановления Oracle.................................483 Типы сбоев.....................................................484 Вопросы, не затронутые в данной главе............................486 Резюме.......................................................... 486 Вопросы группы I.................................................488 Проект...........................................................490 Вопросы к проекту FiredUp........................................491 Вопросы к проекту Twigs Тгее.....................................493 Глава 11. Работа с базами данных в SQL Server 2000.............. 494 Установка SQL Server 2000 ........................................ 494 Создание базы данных SQL Server 2000 ............................. 495 Создание таблиц................................................497 Создание базы данных галереи View Ridge........................499 Индексы........................................................507 Логика приложения................................................508 Хранимые процедуры......................................... ... 509 Триггеры.......................................,...............515 Управление параллельной обработкой...............................524 Пс ведение курсора................................. . ...... 525 Блокировочные подсказки........................................526
Содержание 13 Безопасность .................................... ....... Настройки безопасности SQL Server.......................... • 527 Настройки безопасности учетной записи............................ 528 Настройки безопасности ролей..................................... 530 Резервное копирование и восстановление............................. 531 Типы резервных копий.............................................532 Модели восстановления SQL Server................................. 533 Восстановление базы данных.......................................534 План обслуживания базы данных....................................534 Вопросы, не затронутые в этой главе.................................535 Резюме..............................................................536 Вопросы группы I....................................................537 Проекты.............................................................539 Вопросы к проекту FiredUp...........................................540 Вопросы к проекту Twigs Tree........................................541 Часть V. Стандарты доступа к базам данных Глава 12. ODBC, OLE DB, ADO и ASP.................................. 544 Информационное окружение веб-сервера................................544 Стандарт ODBC.......................................................548 Архитектура ODBC.................................................548 Уровни соответствия..............................................550 Задание имени источника данных ODBC..............................552 OLEDB...............................................................554 Цели создания OLE DB.............................................556 Основные конструкции OLE DB......................................557 ADO.................................................................559 Вызов ADO из ASP-страниц.........................................559 Объектная модель ADO.............................................560 Примеры использования ADO...........................................565 Пример 1 — чтение конкретной таблицы.............................565 Пример 2 — чтение таблицы обобщенным способом....................568 Пример 3 — чтение любой таблицы..................................571 Пример 4 — обновление таблицы....................................576 Пример 5 — вызов хранимой процедуры..............................581 Резюме......................................,......................586 Вопросы группы I............................................... 587 Вопросы группы II..................................................589 Вопросы к проекту FiredUp..........................................590 Вопросы к проекту Twigs Tree.......................................590 Глава 13. XML и ADO.NET............................................591 Важность XML.......................................................591 XML как язык разметки..............................................593 XML-документ и DTD................................................ Материализация ХМ L-доку ментов с помощью XSLT..................595
14 Содержание XML Schema.........................................................600 Проверка допустимости по схеме................................ 601 Элементы и атрибуты........................................... 602 Плоские и структурированные схемы..................................603 Глобальные элементы.............................................606 Создание XML-документов на основе информации из базы данных........608 SELECT...FOR ХМL................................................609 SELECT...FOR XML для нескольких таблиц . .......................611 XML-схема, описывающая все покупки клиентов........................614 Схема с двумя многозначными маршрутами..........................616 Значение XML....................................................619 ADO.NET............................................................622 Набор данных ADO.NET............................................623 Обработка сведений о клиентах в базе данных View Ridge с помощью ADO.NET . 625 Назначение приложения...........................................626 Установка соединения и заполнение набора данных.................626 Добавление новых структур в набор данных........................629 Обработка набора данных.........................................632 Обновление информации в наборе данных и исходной базе данных .... 636 Обзор стандартов XML............................................642 Резюме.............................................................644 Вопросы группы I...................................................647 Вопросы группы II..................................................649 Вопросы к проекту FiredUp..........................................650 Вопросы к проекту Twigs Тгее.......................................650 Глава 14. JDBC, Java Server Pages и MySQL..........................651 JDBC...............................................................651 Типы драйверов..................................................652 Использование JDBC..............................................653 Примеры использования JDBC......................................656 Java Server Pages................................................ 663 JSP-страницы и сервлеты ........................................663 Apache Tomcat...................................................664 Настройка Tomcat для обработки JSP..............................664 Примеры JSP-страниц.............................................666 MySQL..............................................................678 Ограничения MySQL...............................................678 Работа c MySQL..................................................679 Настройка разрешений на доступ для JDBC.........................681 Управление параллельной обработкой данных.......................682 Резервное копирование и восстановление..........................683 Заключительное слово о MySQL....................................684 Резюме.............................................................684 Вопрос группы!.....................................................686 Вопросы группы II .................................................688 Проект ............................................................688 Вопрос к проекту FiredUp...........................................689 Вопросы к проекту Twigs Tree.......................................689
Глава 15. Совместное использование данных предприятие . • 999 Архитектуры корпоративных систем обработки данных .... Системы удаленной обработки. ....................... • > ’ ' Клиент-серверные системы........................ • • ‘ Системы совместного использования файлов ........ Системы обработки распределенных баз данных.......... • • < - • Загрузка данных......................................... Компания Universal Equipment..........................- - • • • 700 Процесс загрузки............................................. ... 702 Потенциальные проблемы при обработке загруженных баз данных . . . . 703 Оперативная аналитическая обработка данных (OLAP).... .... » 705 Информационные хранилища......................................... 714 Компоненты информационного хранилища........................... 714 Требования к информационному хранилищу............................ 716 Проблемы разработки и эксплуатации информационных хранилищ........717 Информационные лавки......................................... 722 Администрирование данных............................................723 Потребность в администрировании данных............................724 Проблемы администрирования данных............................... - 725 Задачи отдела администрирования данных............................726 Резюме............................................................ - 730 Вопросы группы I....................................................733 Вопросы группы II...................................................736 Часть VI, Работа с объектно-ориентированными базами данных Глава 16. Объектно-ориентированные базы данных.................738 Введение в объектно-ориентированное программирование.......^ . . . 739 Терминология ООП..............................................739 Пример ООП......................................................741 Постоянное хранение объектов....................................745 Постоянное хранение объектов в традиционной файловой системе. .... 746 Постоянное хранение объектов с использованием реляционной СУБД . . . 747 Постоянное хранение объектов с использованием ООСУБД.........749 Постоянное хранение объектов в Oracle .................................750 Типы объектов и коллекции....................................751 Объекты Oracle......................................... ..... 755 Стандарты ООСУБД............................................ ... 759 SQL3.........................................................760 ODMG-93................................................. 786 Резюме.................................................. .......770 Вопросы группы I................................................ 772 Вопросы группы II.................................... 774 Приложение А. Структуры данных................................... Плоские файлы............................................... , 775 Обработка плоских файлов в различном порядке ............ . Замечание по поводу адресации записей.............. . . . 777
1в Содержание Упорядочение с помощью связных списков.............................777 Упорядочение с помощью индексов.................................. 780 Бинарные деревья...................................................781 Резюме по структурам данных........................................783 Представление бинарных связей.........................................784 Обзор видов связей между записями..................................784 Представление деревьев.............................................786 Представление простых сетей...................................... 789 Представление сложных сетей........................................791 Представление вторичных ключей................................. ... 794 Представление вторичных ключей с помощью связных списков 795 Представление вторичных ключей с помощью индексов...............796 Резюме................................................................799 Вопросы группы I......................................................800 Вопросы группы II.....................................................801 Приложение Б. Семантическая объектная модель.......................802 Семантические объекты.................................................803 Определение семантических объектов.................................803 Атрибуты.......................................................... 804 Объектные идентификаторы......................................... 808 Домены атрибутов...................................................809 Представления семантических объектов............................. 809 Типы объектов.........................................................811 Простые объекты....................................................811 Композитные объекты................................................812 Составные объекты..................................................815 Представление составных объектов со связью 1:1.....................819 Представление связей «один ко многим» и «многие к одному»..........820 редставление связей «многие ко многим»............................822 Гибридные объекты..................................................823 Представление гибридных связей ....................................827 Ассоциативные объекты..............................................829 Объекты вида родитель-подтип................................... 832 Объекты вида архетип-версия............................... . . . 836 Сравнение семантической объектной модели и модели «сущность—связь». . 837 Вопросы группы I.................................................... 840 Вопросы к проекту FiredUp.............................................843 Алфавитный указатель...............................................845
Предисловие Базы данных — повсюду. Они обеспечивают основную функциональность прило- жений типа клиент—сервер, организационных приложений, а также приложений электронной коммерции типа бизнес—клиент и бизнес—бизнес. Кроме того, они используются на миллионах рабочих мест. Из-за такой популярности обработка баз данных стала самой важной темой при обучении информационным системам. Знание построения базы данных, разработки, администрирования и технологии доступа необходимо для успеха любого специалиста по информационным системам. К сожалению, рост популярности баз данных не означает роста компетентио- ч4 сти в них. Многих студентов (и даже профессионалов) вводит в заблуждение простота создания маленьких баз данных с помощью продуктов типа Microsoft Л\ Access. Им кажется, что они владеют технологией баз данных достаточно для создания баз данных с более замысловатой структурой, требующих сложной об- работки. Результат часто плачевен: такие базы данных сложно использовать, они не удовлетворяют системным требованиям. Кроме того, их трудно переделать. Ситуация похожа на ту, что имеет место при обучении программированию на компьютере. Выучив синтаксис языка, студенты думают, что они могут строить сложные приложения, не овладев предварительно навыками проектирования про- грамм. Важность умения проектировать программы становится очевидна только тогда, когда программы делаются больше и сложнее. Особенности настоящего издания Растущая важность технологии баз данных наряду с тревожной тенденцией уве- личения количества плохо спроектированных баз данных заставили меня серьез- но задуматься над организацией материала книги. В результате он был сильно пересмотрен. Более глубокое обсуждение моделирования данных и проектирования баз данных Для начала я решил, что книга нуждается в более глубоком рассмотрении и моде- лирования данных, и проектирования баз данных. После принятия такого реше- ния я осознал, что параллельный анализ двух методов моделирования данных — Ульяновский государственный технический университет Научней библиотека
18 Предисловие ие лучший способ изучения нового. Студентам нужно глубокое понимание одно- го метода и побольше практики по его применению. Исходя из этого, я убрал ак- цент с семантической объектной модели, переместив ее в приложение, и углубил рассмотрение модели сущность—связь. В этом издании вы найдете две главы, по- священные построению модели сущность—связь. Кроме того, чтобы облегчить студентам изучение моделирования данных, эти главы завершаются вопросами и заданиями (проектами) по моделированию данных. Для приобретения нужной ci оровки будет важно ответить на эти вопросы и выполнить задания. Одной из трудностей проникновения в глубь модели сущность—связь является то, что не существует ее общепринятой версии. Как обсуждается в главе 2, сущест- вуют классическая модель сущность—связь, версия обработки информации, версия национального стандарта IDEF1X, а также версия, включенная в язык UML. Чтобы подробнее представить модель сущность—связь, я должен был решить, какую из этих версий использовать. Процесс этого решения также описывается в главе 2, и суть его в следующем: я считаю, что UML-версия в конечном счете будет наиболее важной, но в настоящее время больше используется IDEFlX-вер- сия, поскольку она применяется в таких популярных средствах моделирования данных, как Visio и ERWin. Таким образом, в главах 2, 3 и 5 по большей части используется версия IDEF1X. UML-версия, однако, тоже представлена — в конце главы 2. Как и главы, посвященные моделированию данных, главы о проектировании баз данных стали глубже. В это издание вошли две главы по проектированию баз данных. Глава 5 описывает преобразование моделей данных в проекты баз дан- ных, а в главе 9 рассказывается о перепроектировании баз данных. Изложение в главе 5 теперь больше не сводится к тому, «куда поместить внешний ключ». В частности, подробно описывается целостность ссылочных данных. Кроме того, рассматриваются и более серьезные темы, такие как проектирование для рекур- сивных связей и проектирование для двоичных ограничений на тернарные связи. Главу 5 завершают более 80 вопросов и заданий, а также задачи для проектов FiredUp и Twigs. По окончании университета немногим студентам придется начинать проекти- рование базы данных с чистого листа. Скорее, большинство будет работать над проектами перепроектирования баз данных. Поэтому я добавил новую главу, по- священную этой важной теме. Эта новая глава появилась после главы об SQL, поскольку этот язык требуется для понимания и выполнения перепроектирова- ния базы данных Перепроектирование также требует корреллированных подза- просов и запросов EXISTS/NOT EXISTS, и глава снабжена реалистичными при- мерами их использования. Расширение изучения SQL Кроме углубления рассмотрения моделирования данных и проектирования баз данных, в настоящем издании я также расширил рамки применения SQL. В главе 4 излагаются основы SQL для определения данных и манипулирования данными
ОСОО- НП 1И HilLTUWUHW»' Вопрос определения данных для очень пажен, поскольку срщитва Цшфичесютф проектирования нельзя использован. программным образом, а повторно их ВКЛЮ- чатьпеинтереспо. Глава б излагает основы DML для стандарта SQL 92 и вклм.чм® два формата соединения, а также обсуждение внутреннего и внешнею соединения. В главе 7 представлен пример базы данных для галереи View Ridge; <ia бала данных широко используется и в последующих главах. После этою глава 7 как бы надстраивает SQL, описанный в главе б, и рассказывает об исполь ювании SQL в приложениях баз данных. Кроме того, в главу 7 включено обсуждение использования SQL в триггерах и хранимых процедурах. В главе 8 показано использование SQL для перепроектирования баз данных Как уже отмечалось, эта глава дает студентам реалистичное понимание необхо- димости в более сложных SQL-операторах. XML и ADO.NET Третье большое изменение этого издания было сделано в главе 13. В ней пол- ностью переписано все, что связано с языком XML, а также добавлено обсужде- ние ADO.NET. Что бы вы ни думали о Microsoft, а множества данных ADO.NET являются существенной новацией и весьма важны для веб-сервисов XML. С по- мощью ADO.NET программист может создать в памяти полную реляционную базу данных, которая будет отделена от любой внешней базы данных, управляемой Oracle, DB2, SQL Server или другой СУБД. Такая база данных может управлять- ся приложениями, написанными на любом из языков .NET, таких как С#, С++ или VB.NET. В главе 13 VB.NET используется для создания приложения ASP.NET, кото- рое создает множество данных и таблицу, XML, а также представление этого множества в виде XML-схемы. Чтобы облегчить присутствие Microsoft, прило- жение показывает использование ADO.NET совместно с Oracle. Соблюдение баланса в охвате Oracle 9i и SQL Server 2000 Oracle и SQL Server обсуждаются у меня в равной степени. В главе 7 показаны псевдотриггеры и псевдохранимыс процедуры, которые присущи и Oracle, и SQL Server. В главе 9 представлены многопользовательские СУБД с обсуждением возможностей Oracle и SQL Server. В главе 10 (посвященной Oracle) и в главе 11 (посвященной SQL Server) выдержана одна глубина изложения. В обеих главах показываются одни и те же хранимые процедуры и триггеры. В главе 12 пред- ставлены ASP-приложения, которые ведут базы данных как Oracle, так и SQL Server. Поскольку SQL Server не обеспечивает такой объектпо-орпептнровагиюй Функциональности, как Oracle, в главе 16 преобладает Oracle. Начинать изучение можно как с Oracle, так п с SQL Server. Книга построен* гак, что вы можете использовать любой из этих продуктов с один гковым успехом
20 Предисловие Структура книги главе 1 обработка баз данных изложена простейшим образом. Необходимость обработки баз данных иллюстрируется описанием проблем управления ненорма- лизованными (неупорядоченными) данными в таблице. После этого рассматри- ваются компоненты системы базы данных и дается краткое описание процесса разработки базы данных. Завершает первую главу краткая история баз данных. В главах 2 и 3 обсуждается моделирование данных с помощью модели сущ- ность- связь (E-R model). В главе 2 описываются разновидности этой модели, в том числе традиционная модель сущность—связь, IDEF1X и UML, а затем показываются приемы использования этих моделей. В главе 3 продолжается разговор о построении модели данных — объясняется процесс этого построения, приводятся примеры наглядных форм и отчетов, а также демонстрируется раз- работка модели данных для маленького университета. Главы 4 и 5 посвящены проектированию баз данных. В главе 4 рассматривают- ся реляционная модель и нормализация. Глава 5, в свою очередь, показывает, как преобразовать модель сущность—связь в реляционную модель. Как уже было от- мечено, эта глава стала глубже, чем простое описание того, куда поместить внеш- ние ключи. Помимо этого, подробно обсуждаются правила ссылочной целостности. Следующие три главы представляют язык SQL. В главе 6 даются основы SQL и иллюстрируется использование этого языка для определения данных и мани- пулирования данными. В главе 7 показано использование SQL в приложениях и обсуждаются представления, встроенный SQL, триггеры и хранимые процеду- ры. В главе 8 рассказывается о перепроектировании баз данных. Эта глава начи- нается с обсуждения коррелированных подзапросов и уелловий EXISTS/NOT EXISTS. После этого описывается процесс перепроектирования баз данных и при- водятся категории перепроектирования. Главы части IV имеют общую структуру. В главе 9 представлено администри- рование данных и администрирование баз данных, а также обсуждаются особен- ности управления большими многопользовательскими базами данных. Глава 10 продолжает главу 9 и представляет возможности и функции Oracle 9i, в том чис- ле использование хранимых процедур и триггеров. В главе 11 обсуждается то же, только для SQL Server 2000. Главы 12 13 и 14 посвящены обработке баз данных приложений. В главе 12 обсуждаются ODBC, OLE DB и ADO и показывается использование VBScript для вызова ADO из ASP-страниц. База данных и хранимые процедуры, разрабаты- ваемые в главах 10 и И, используются для иллюстрации обработки Oracle и SQL Server из ASP. В главе 13 представлены XML и XML Schema, и объясняется их важность для обработки баз данных. Вторая половина главы 13 иллюстрирует операторы SELECT...FOR XML, а также поясняет и демонстрирует использование ADO.NET для создания и обработки баз данных. Также показана способность множеств данных обеспечивать просмотр одних и тех же данных в виде таблиц, XML и XML Schema. В главе 14 показана обработка баз данных с помощью программного обеспе- чения с OI крытым кодом. Описывается роль JDBC и использование Java и Java
Структура книги 21 Server Pages, а также разрабатывается база данных для галереи View Ridge с по- мощью MySQL — тот же пример, который используется для Oracle и SQL Server в главах 10 и 11. Студенты должны уловить смысл этого, даже если они не про- граммируют на Java. Те же, кто знает Java, найдут эту главу легкой для себя. Завершают книгу главы 15 и 16. В главе 15 описывается разработка базы дан- ных предприятия и обсуждается OLAP. В главе 16 представлены понятия объект- но-ориентированных баз данных и приемы для работы с ними. Также обсуждает- ся использование возможностей Oracle для объектно-реляционных баз данных. В книгу входят два приложения. Приложение А описывает основные струк- туры данных. Приложение В представляет семантическую объектную модель и показывает, как такие модели можно преобразовать в реляционные проекты баз данных. В этом приложении весь концептуальный материал по таким моде- лям взят из восьмого издания, но из него удалены все примеры.
Благодарности В первую очередь я хочу поблагодарить рецензентов восьмого издания, которые обеспечили полезное и проницательное руководство процессом пересмотра мате- риала к ги: ♦ Карен Доулинг (Karen Dowling), Государственный университет Аризоны ♦ Ричард Хес (Richard Heath), Государственный университет Сант-Клода ♦ Вики Джонатан (Vicki Jonatan), Колледж Портлаида ♦ Брайан Маки (Brian Mackie), Университет Северного Иллинойса ♦ Мэтт Макгован (Matt McGowan), Университет Бредли ♦ Клер Мак-Инерли (Claire Mclnerley), Университет Рутжерса ♦ Чанг Мяо (Chang Miao), Северо-Западный Университет ♦ Marty Murray (Марти Муррей), Колледж Портлаида ♦ Дэ д Пальцер (Davi alzer), Технический Колледж Кловер-парка ♦ Дэвид Петри (David Petrie), Университет Редландса ♦ Линда Прис (Linda Preece), Университет Южного Иллинойса ♦ Кевин Робертс (Kevin Roberts), Университет Деври 4- Ашариф Шираки (Asharif Shirani), Государственный университет Сан-Хосе ♦ Эйлин Сиккема (Eileen Sikkema), Университет Вашингтона ♦ Боб Спир (Bob Spear), Университет Мэриленда 4 Шерон Туттл (Sharon Tuttle), Государственный Гумбольдт-университет 4- Диана Вальц (Diane Waltz), Университет Техаса в Сан-Антонио 4- Питер Волькотт (Peter Wolcott), Университет Небраски Кроме того, я благодарю Дональда Нильсена (Donald Nilsen) из корпорации Microsoft за всесторонние дискуссии со мной касательно цели и функциональности ADO.NET. Еще хотелось бы поблагодарить Гаррн А. Спаркса (Harry A. Sparks) из компании Sparks Consulting (который по совместительству является профес- сором Вебстеровского университета в Сан-Луисе) за советы по улучшению из- ложения вопросов безопасности в главе 9. Также я благодарен Марсии Вильямс (Marcia Williams) из колледжа Бельвю и всем, кто посещал мои лекции па обра- зовательной конференции в Белыяо, штат Вашингтон, летом 2002 года. Я верю, что нынешнее издание книги «Теория и практика построения баз Данных* лучшее В большой степени это произошло благодаря тому впима-
От издательства 23 нию, которое уделил книге Боб Хоран (Bob Horan), мой редактор в издательстве Prentice Hall. Я сердечно благодарю Боба за его энтузиазм и за мудрое руково- дство. Кроме того, я благодарен Килу Хеннону (Kyle Hannon), который, несмот- ря на крайнюю занятость, всегда успевает внести великое множество редактор- ских поправок. Спасибо также Ванессе Натри (Vanessa Nuttry) из Prentice Hall. Ванесса руководила выпуском трех моих книг, и я сердечно благодарен ей за ее преданность и профессионализм во всех этих проектах. Наконец, я благодарен Линде, моей жене, за ее любовь, терпение и понимание. Дэвид Кренке Сиэттл, штат Вашингтон От издательства Ваши замечания, предложения, вопросы отправляйте по адресу электронной по- чты comp@piter.com (издательство «Питер», компьютерная редакция). Мы будем рады узнать ваше мнение! Все исходные тексты, приведенные в книге, вы можете найти по адресу http://www.piter.com/download. На веб-сайте издательства http://www.piter.com вы найдете подробную инфор- мацию о наших книгах.
Глава 1 Введение в базы данных Базы данных всегда были важнейшей темой при изучении информационных сис- тем. Однако в последние годы всплеск популярности Интернета и бурное разви- тие новых технологий для Интернета сделали знание технологии баз данных для многих одним из актуальнейших путей карьеры. Технологии баз данных унели Интернет-приложения далеко от простых брошюрных публикаций, которые характеризовали ранние приложения. В то же время Интернет-технология обес- печивает пользователям стандартизированные и доступные средства публикации содержимого баз данных. Правда, ни одна из этих новых разработок не отменяет необходимости в классических приложениях баз данных, которые появились еще до развития Интернета для нужд бизнеса. Это только расширяет важность знания баз данных. Многие студенты считают этот предмет приятным и интересным, даже не- смотря на его сложность. Проектирование и разработка базы данных требуют и искусства, и умения. Понимание пользовательских требований и перевод их в эффективный проект базы данных можно назвать творческим процессом. Пре- образование этих проектов в физические базы данных с помощью функционально полных и высокопроизводительных приложений — инженерный процесс. Оба процесса полны сложностей и приятных интеллектуальных головоломок. Поскольку сейчас существует большая необходимость в развитии технологии баз данных, навыки, которые вы разовьете, и знания, которые вы получите в про- цессе изучения этого курса, будут востребованы. Цель книги — предоставить твердое обоснование фундаментальных положений технологии баз данных, что- бы вы могли начать успешную карьеру в этой области, если вам этого захочется. В этой главе мы обсудим, что, как и почему в базах данных. Мы поймем, по- чему используются базы данных, расскажем, какие существуют компоненты сис- темы базы данных и как разрабатывать такие системы. Глава завершится экскур- сом в историю баз данных. Почему используются базы данных? Цель базы данных — помочь людям и организациям вести учет определенных ве- щей. На первый взгляд, эта цель кажется скромной, и вы, возможно, удивитесь, зачем нам нужна такая сложная технология и целый курс, посвященный этому
Проблемы слисиов 25 предмету. Большинство из нас может вспомнить ситуации, в которых нам тр«<, ется отслеживать некоторые веши. Я, например, составляю список дел, которые нужно сделать на этой неделе, список покупок в магазине, список расходов для налоговой декларации и так далее. Почему не делатью же самое для информаци- онных систем? На самых ранних стадиях развития информационных технологий исполь- зовались списки — набитые на перфокарте и написанные на магнитной ленте. Со временем, однако, стало ясно, что только немногие проблемы можно решить с помощью таких списков. В следующем разделе мы обсудим такие проблемы а затем опишем, как построить базы данных для их решения, Проблемы списков Рассмотрим список в табл. 1.1, который используется фирмой Lakeview Equipment Rentals. Эта фирма занимается прокатом оборудования, такого как краны и экс- каваторы, строительным подрядчикам. В табл. 1.1 показан лишь небольшой кусок деятельности этой фирмы, но даже этот маленький пример иллюстрирует целый ряд важных проблем со списками. Таблица имеет 10 столбцов: Job (про- ект), Contractor (подрядчик), Phone (телефон), Equipment type (тип оборудования), Equipment number (номер оборудования), Daily rate (плата за день), Start date (дата начала), End date (дата окончания), Days (количество дней), Charge (стоимость). В первую очередь обратим внимание на следующее. Что случится, если у под- рядчика изменится номер телефона? Предположим, например, что у фирмы КН Services телефон станет 213-444-9988. Чтобы содержать список в порядке, нам нужно сделать изменения в четырех строках. Если мы не изменим все эти строки, мы получим противоречащие друг другу данные и не сможем установить, какой же из этих номеров верен. Далее предположим, что список отражает прокатную деятельность фирмы за весь квартал или год. В таком списке могут быть сотни или тысячи строк. Чтобы записать измененный телефонный номер, нам понадо- бится произвести поиск по списку и сделать исправления в каждой строке, кото- рая содержит фирму КН Services. Этот процесс очень долог и чреват ошибками. Еще одна проблема возникает, когда мы удаляем из такого списка данные. Скажем, фирма RB Partnership решила не брать в прокат экскаватор (backhoe), так что мы должны удалить последнюю строку. В процессе такого уда пения не только теряются данные о прокате, но также теряются номер телефона фирмы RB Partnership и тот факт, что эта фирма работает над проектом под названием Village Square и что она согласилась взять в прокат экскаватор за 750 долларе в день. А ведь мы, скорее всего, просто хотели удалить данные о дате проката. Такого же типа и следующая ситуация. Что делать, когда у нас есть только некоторые (но не все) данные? Допустим, мы знаем, что университет Swaging имеет телефон 206-555-8989 и что он работает над реконструкцией моста на Ц тральной улице. Мы хотим записать эти данные, но куда их поместить в списке’ Ведь эта компания еще ничего не брала у пас в прокат.
Тарима 1 Л. Список Lakeview Equipment Job Contractor Phone Equipment type Equipment number Daily rate Start date End date Daye Charge Sea view BM0 KH Serctces 213-222-1181 Backhoe 10400 $750 17.06.2002 19.06.2002 3 $2250 Highland Center Comstock, Inc 232-492-3383 Backhoe 10400 $750 24.06.2002 24.06.2002 1 $750 Vtaw OvTCB • iu w Bldg KH Sercices 213-222-1181 Middle crane 335 $350 17.06.2002 3.07.2002 17 $5950 Long Ptaza KH Sercices 213-222-1181 Backhoe 10020 $650 1.07.2002 3.07.2002 3 $1950 Sea View ВИд KH Se cices 213-222-1181 Scaffolding $135 15.06.2003 Highland Center Comstock, Inc 232-492-3383 Middle crane 335 $400 1.07.2002 8.07.2002 8 $3200 Village Square RB Partnership 508-555-3233 Backhoe 10020 $750 8.07.2002 11.07.2002 4 $3000
Проблемы совместно используемым данных 27 Другая проблема состоит в несовместимости данных. Мы можем сдедат! hjm> стую опечатку в имени подрядчика и случайно написать KJ Service# вместо КН Services. Пользователи этого списка нс поймут, то ли у нас появился новый кли- ент, то ли это ошибка. Такие ошибки не могут во шикнуть, если мы выберем под- рядчика из списка имеющихся. Есть и более тонкие несоответствия. Проверим, например, четвертую и пятую строки. Обе они — о прокате экскаватора с номером 10020. В четвертой строке ежедневная плата 650 долларов, а в последней — 750 долларов. Является ли это не- совпадение следствием опечатки, или арендная плата меняется в зависимости от дня? Пли, может быть, для разных клиентов существуют разные цены? В этом слу- чае КН Services платит за экскаватор 650 долларов в день, a RB Partnei>hip — 750 Если это правда, то мы должны убедиться, что каждый раз, когда мы вводим сочетание фирмы КН Services с экскаватором под номером 10020, мы должны вводить плату 650 долларов в день. Другая проблема касается отсутствующих данных. Например, в записи о про- кате строительных лесов нет конечной даты. Ошибка ли это, или это означает что-нибудь другое? Это может значить, что прокат еще не закончен или что ком- пания КН Services хочет держать леса неопределенно долго. Проблемы совместно используемых данных Другие проблемы использования списка всплывают, когда мы рассматриваем данные, которые совместно используются многими людьми в компании Lakeview Equipment Rentals. Компания хочет дать каждому доступ к именам подрядчиков и к телефонным номерам из общего источника данных. Таким образом, если кто-нибудь изменит телефонный номер, то это изменение нужно сделать в общем источнике данных компании, В противном случае сотрудникам придется изме- нить эти данные на каждом компьютере компании. Однако если данные о подрядчике используются совместно, возникают дру- гие проблемы. Бухгалтерия ходет вести учет счетов подрядчиков и платежей. Сотрудники отдела проката хотят отслеживать координаты подрядчиков, встре- чи и заказы. Отдел по работе с клиентами хочет знать, какие проблемы возника- ли с определенными подрядчиками и как они решались. Все эти отделы не обяза- тельцо хотят использовать данные совместно с другими отделами. Бухгалтерия, например, не хочет, чтобы кто-то другой имел доступ к данным о счетах и плате- жах. Отдел по работе с клиентами не хочет, чтобы кто-то в компании знал, какие проблемы есть у клиентов. Таким образом, отделы готовы совместно использо- вать только некоторые данные, но не все. Существуют и другие проблемы использования списков, но идея уже понят- на: нужен более сильный способ хранения данных.
28 Глава 1. Введение в базы данных " ' 'v- «I —-- --------- Базы данных как группы связанных таблиц Одна серьезная проблема со списками, подобными изображенному в табл. 1.1, со- стоит в том, что они содержат данные на различные темы. Помните пашу учи- тельницу родного языка? Она наверняка говорила вам, что абзац должен быть посвящен только одной теме. Если у вас есть абзац, содержащий две темы или бо- лее, следует его разбить на несколько, каждый из которых говорит только об одной теме. Это суть процесса под названием нормализация, который мы глубоко иссле- дуем в главе 4. Проверим список в табл. 1.1. Сколько тем он содержит? Одна — строитель- ные проекты, другая — подрядчики, третья — оборудование и четвертая — про- кат. На рис. 1.1 показаны результаты разбиения списка на отдельные компонен- ты. Каждый из этих компонентов представляет собой таблицу данных, поэтому мы будем называть их таблицами. Таких таблиц получилось четыре — по коли- честву тем: CONTRACTOR (подрядчики), JOB (проекты), EQUIPMENT (оборудование) и RENTAL (прокат). ft «I •kh Straw 213/44 1131 CwrHxk.tac <32 432 3395 RE Partrfrtihip 503 555 3235 Рис. 1.1. Данные Lakeview Equipment в таблице -ji । > i>.« Когда список разбивается на четыре таблицы, многие проблемы, которые мы обсуждали, исчезают. Если компания КН Services меняет свой телефон на 213- 444-9988, мы делаем это изменение только однажды — в таблице CONTRACTOR. Если мы хотим удалить запись о прокате, мы всего лишь удаляем строку из таб- лицы RENTAL, не теряя при этом никаких данных о проектах, подрядчиках или оборудовании Если мы хотим добавить данные о новом клиенте, то просто до- бавляем эти данные в таблицу CONTRACTOR. Что касается противоречивости данных, то мы можем разработать наше при- ложение баз данных так, что когда кому-нибудь понадобится сделать новую за- пись о прокате, он просто выберет запись в таблице CONTRACTOR. Таким образом, ошибку сделать нельзя. Это также дает нам возможность контролировать появ- лея»«« новых клиентов Можно сделать так, что только определенные люди, на- прпыер. бухгалтеры, смогут добавлять новые строки в таблицу CONTRACTOR.
А как насчет протиноречиных данных о стоимости прокат в 1и0л II / М •«< кажется, тут и начинается веселье, Иа рис, 1.1 стоимость проката в мнь rate) помещена и таблицу EQUIPMENT. Это значит, что оборудовали» вл* но да- ваться в прокат за одну и ту же плату всем клиентам. Так отроекти|мзвана вся таблица. Является ли это правильным? Это зависит от бизнсс-правиЛ компании Lakeview. Есин, однако, плата зависит от каждого конкретного случая HpotaiiA, то столбец Daily rate нужно поместить в таблицу RENTAL Гели » жд подрядчик платит за прокат по собственным расценкам, нужно построить новую таблицу Главное здесь не в решении этой частной проблемы. Главное что проекти- рование таблицы должно отражать порядки организации, которая ее использует В этой книге мы потратим довольно много времени и усилий на подробный раз- бор каждой такой ситуации. Разбиение на таблицы также позволяет нам добавлять больше данных по каж- дой теме, чем появляется в списке в табл. 1.1. На рис. 1.2, например, показаны дополнительные данные для подрядчиков. При необходимости мы можем разра- ботать приложения нашей базы данных так, что только определенный персонал сможет знакомится с этими дополнительными данными. j Phone... j : [ sueetg • ♦ КН &ues 213.444.И81 • .Comstock, lac 232.492.3303 • RE Paint-ship 538 555.3233 U1 Piny 1200 Cc?nstcck' 1234 Sm Slw'*- Ne*/ Yom Ci’y NY Nw Yotx City NY .Highlands CA 1 .ШЬ1232 42345-1399 Siert Data : i ‘ - d Date 6/17/2002 6/19/2002-3 : 6/24/2002; 6/24/2002.1 . 6/17/2902 " ‘7/3^002; 17 “** • 7/1/2902:...... 7/3/2002:3 : 6/16Шй:................... lb.... 7/1 £2902; ' 7/6/29029 ’’ "Z zpi/yaa/;* ... ..1 1 j УГКПГб: И| t " A 1 Рис. 1.2. Таблица CONTRACTOR и дополнительные данные Связи Сейчас вас может испугать следующий вопрос. Данные на рис. 1.1 и 1.2 хороши, но где же связи между ними? Как можно узнать, какой подрядчик взял напрокат какое оборудование, для какого проекта и на какой срок? По данным на этих рисунках невозможно сказать, что к чему относится. Мы пришли к одному из фундаментальных вопросов теории баз данных. Этот вопрос мы будем обсуждать в главах 5 и 8 в теме о проектировании баз данных Сейчас рассмотрим рис. 1.3, на котором изображен один из способов построить связи между таблицами. Каждой строке в каждой таблице дается уникальный идентификатор 10 Этот идентификатор для пользователей фирмы Lakeview не имеет ншпогпг-q смысла;
30 Г два Г Введение в базы данных его цель — просто пронумеровать все строки таблицы. Значения идентификато- ра мы будем использовать для представления связи со строками таблицы RENTAL Рис.1.3. Таблицы Lakeview и связи между ними Рассмотрим четвертую строку таблицы RENTAL на рис. 1.3. Значение 3 в столб- це, обозначенном JoblD (идентификатор проекта) означает, что этот прокат отно- сится к проекту, который имеет в таблице JOB идентификатор, равный 3. Это строка, содержащая проект Long Plaza, который соотносится с данными в табл. 1.1. Подобным же образом располагаются в таблице прокат для подрядчика, имею- щий идентификатор 1 (КН Services), и для оборудования с ID, равным 3 (экска- ватор номер 10020). Список в табл. 1.1. содержит столбец, обозначенный Charge (стоимость), но такого столбца нет на рис. 1.3. Причина в том, что мы можем вычислить этот столбец, если он нам понадобится. Так и будет в базе данных. Стоимость будет вычисляться каждый раз, а не храниться. Хорошо это спроектировано или нет, опять же зависит от порядков в Lakeview. Следствие такого проектирования со- стоит в том, что если значение платы за день в таблице RENTAL меняется, то все долги при следующем вычислении будут основаны уже на новой цене. Таким образом, мы можем получить значение стоимости, отличное от того, что пользо- ватель платил в свое время. Подобные ситуации мы еще будем обсуждать в по- следующих главах. Подведем итог. Чтобы справиться с проблемами, которые возникают со спис- ками, подобными показанному в табл. 1.1, мы разбили список на четыре табли- пы, каждая из которых посвящена определенной теме. После этого мы связали таблицы с помощью уникального идентификатора. Как вы потом узнаете, этот уникальный идентификатор называется ключом. Ключ, который представляет связь, вроде JoblD в таблице RENTAL, называется внешним ключом. Эти термины мы будем использовать много раз в наших последующих обсуждениях.
Что такое система обработки базы данных? 31 Объединение таблиц «Но где же наш список?» — спросите вы. На рис. 1.3. все изображено красиво и пра впльно, но пользователи в фирме Lakeview, по крайней мерс некоторые из них, захотят увидеть список типа того, с которого мы начинали. Где он? В главах 6-8 будет изучаться язык, который является настоящим подъязыком данных. Называется он SQL (Structured Query Language, язык структурирован- ных запросов) и используется для манипуляций с таблицами типа изображен- ных на рис. 1.3. SQL — это промышленный стандарт, который поддерживается всеми основными системами управления базами данных (СУБД). Приведенный ниже оператор SQL используется в Access для объединения таблиц и отображе- ния их в том виде, как в табл. 1.1. SELECT JOB.Name. CONTRACTOR.Contractor. CONTRACTOR.Phone. EQUIPMENT.[Equipment Type], EQUIPMENT.[Equipment Number], EQUIPMENT.[Dally Rate], RENTAL.[Start Date], RENTAL.[End Date], RENTAL.Days.[Dallу Rate]*[Days] AS Charge FROM JOB. EQUIPMENT. CONTRACTOR, RENTAL WHERE CONTRACTOR.ID = RENTAL.ContractorID ANDEQUIPMENT.ID = RENTAL.ContractorID ANDJOB.ID = RENTAL.JoblD: Результат выполнения этого оператора показан на рис. 1.4. Там содержится список, с которого мы начинали, но с исправленными ошибками. . . j. . -jab _____________ _________________ S«sV:₽wBEg .KHSer-ccc 2*3444 1/61 Вас? Нэе H-gblas-d Canter ; CfimsUKk. ;.nc 232.4923363. ..Back Hee.......... Sss Yew Bfc'g 'KHSwtes 2'3.444.1 *81 Oar* .. XHSer»:ces *134^4 1 ;£1 'Back Чае KHSetv-cee 213.444 1181 Scaffc:riing , tr.r. 22? 432.3#3 Medii*v Crow H У Partr.crihp 403.516 3233 Вась Нее -'Efeow •;; IEfriymeCTy t л идШ L.i Qaljy Jfotr E»:LO*ts -foY* j 'Chary - ---- .... - - .........— • s/tz/axr блзчгооз 2 $з;2босс . €J24pX2: &О4ЖЙ2 1 $750 GC 10400 KU к 355 1CC29 $750.00 $750.90 $135.90 Lcr-g pj«a Highland Cen:e; VJIagc- Lquore •5350.00 . . 6;17Z3X< »£59 30 7/J/20& |Щ£ Рис. 1.4. Исходный список, построенный на основе таблиц 22002 17 Приведенный выше SQL-оператор можно использовать, чтобы определить об- щую структуру. Но понять все в подробностях он не поможет. Когда вы закончите чтение этой книгид вы легко сможете писать такие и более сложные операторы. Что такое система обработки базы данных? На рис. 1.5 показаны четыре основных элемента базы данных. Слева показано, как пользователи выполняют свои задачи с помощью базы данных. Они вводят новые данные, модифицируют существующие и удаляют ненужные. Кроме того. °ни разными способами читают данные: посредством форм, запросов и путем ге- нерации отчетов. Следующий компонент, приложение баз данных, представляет собой множество из одной или более компьютерных программ, которые служат
32 Глава 1. Давление в базы посредниками между пользователем и СУБД (программой, обрабатывающей ба- зу данных). Приложение создает формы, запросы и отчеты, посылает данные пользователю и получает их от него, а также преобразует действия пользователя в запросы для управления данными с помощью СУБД. Цель СУБД состоит в получении запросов от приложений и в преобразова- нии этих запросов в файлы ввода или вывода базы данных. В большинстве слу- чаев СУБД посылает SQL-операторы и переводит их в инструкции операцион- ной системы компьютера для чтения и записи данных в файлы базы данных. Теперь рассмотрим функции программы приложения и СУБД более подробно. ПольЛ •аатьль Рис. 1.5. Компоненты системы базы данных Функции прикладных программ На рис. 1.6 перечислены функции прикладных программ баз данных и СУБД. В первую очередь приложение создает и обрабатывает формы. Веб-приложение, например, генерирует HTML и другие конструкции веб-форм, которые заставля- ют форму отображаться на компьютере пользователя. Когда пользователь запол- няет форму и посылает данные обратно, приложение определяет, какие таблицы данных нуждаются в модификации, и посылает запросы к СУБД, чтобы вызвать необходимую модификацию. Если во время этого процесса возникают ошибки, приложение получает сообщение об ошибке и генерирует подходящее сообщение для пользователя или осуществляет какое-нибудь другое действие. Вторая функция прикладной программы, показанная на рис. 1.6, — создание и передача запросов. Сначала приложение генерирует запрос к СУБД. Такие за- просы почти всегда пишутся на языке SQL. После обработки запроса его резуль- таты форматируются и передаются пользователю. Третья функция похожа на вторую. Приложение запрашивает данные у СУБД (опять с помощью SQL) и форматирует результаты запроса в виде отчета. Кроме создания форм, запросов и отчетов, приложение также производит другие действия по изменению базы данных в соответствии с логикой, специ- фичной для этого приложения. Например, в некотором приложении пользова- тель запросил 10 единиц определенного товара. Теперь предположим, что когда прикладная программа произвела запрос базы данных (через СУБД), она нашла только 8 единиц в наличии Что следует сделать? Это зависит от логики данного конкретного приложения. Возможно, следует не брать ничего со склада и уведо- мить пользователя о возникшей ситуации, или же взять 8 единиц, а 2 оформить как Отложенный заказ. Могут быть и другие варианты. В любом случае, реализа- ция соответствующей логики — задача прикладной. программы. ле Во ви. ри дем да! aej все В n ко\ Про ЬВ Cyi < *ИД1 (
Что такое система обработки базы данных? 33 Приложение базы данных • Создание и обработка форм SQL Создание базы данных Система управления базой данных (СУБД) •Данные пользователя • Метаданные • Индексы и реляционные структуры •Хранимые процедуры •Триггеры •Метаданные приложения • Создание и передача запросов • Создание и обработка отчетов • Выполнение логики приложения •Управление приложением Создание таблиц Создание поддерживающих структур Чтение данных из базы Изменение данных базы Поддержка структур базы данных Установка правил • Управление параллельной обработкой • Обеспечение безопасности • Сохранение и извлечение резервных копий Рис. 1.6. Функции и содержимое компонентов обработки базы данных Последняя функция прикладной программы, указанная на рис. 1.6, — управ- ление приложением. Существует два способа осуществлять это управление. Во-первых, приложение должно быть написано так, чтобы пользователю были видны только определенные опции. Приложение может сгенерировать меню с ва- риантами для пользователя. При этом оно должно убедиться, что пользователю Доступны только нужные варианты. Во-вторых, приложение должно управлять данными с помощью СУБД. Оно может, например, указать СУБД сделать опре- деленный набор изменений в данных. СУБД может быть приказано произвести все эти изменения или не делать ни одного из них. Функции СУБД В противоположность прикладным программам которые часто пишутся самими компаниями, их использующими, почти все СУБД являются коммерческими продуктами. К коммерческим СУБД относятся Oracle от корпорации Oracle. °В2 от корпорации IBM, а также Access и SQL Server от корпорации Microsoft. Существуют десятки СУБД, но эти четыре захватили львиную долю рынка. Функции СУБД перечислены на рис. 1.6. СУБД используется для создания «мой базы данных, таблиц и других поддерживаемых структур - например, "следующие две функции СУБД - чтение и изменение данных в базе дан- ных Для этого СУБД получает запросы SQL (или какие-нибудь другие запросы)
34 Глава 1. Введение в базы данных и преобразует их в действия по отношению к базе данных. Другая функция СУБД — поддержка всех структур базы данных. Например, время от времени может понадобиться изменить формат таблицы пли другую поддерживаемую структуру. Для таких изменений программисты используют СУБД. При работе с большинством СУБД можно устанавливать правила, касающиеся значений данных. Например, рассмотрим рис. 1.3: что случится, если пользова- тель ошибочно введет значение 4 в столбец ContractorlD (идентификатор подряд- чика) в таблице RENTAL? Такого подрядчика нет, и это значение вызовет множе- ство ошибок. Чтобы предотвратить такую ситуацию, можно объявить СУБД, что любое значение ContractorlD в таблице RENTAL должно уже быть значением иден- тификатора в таблице CONTRACTOR. Если такого значения нет, вставка и запрос о модификации разрешаться не будут. Такие правила, которые называются огра- ничениями ссылочной целостности, устанавливаются СУБД. Последние три функции СУБД, указанные на рис. 1.6, относятся к управле- нию базой данных. СУБД контролирует работу, следя, чтобы изменения одного пользователя не пересекались с изменениями другого. Эта важная (и сложная) функция будет обсуждаться в главе 9. Кроме того, СУБД содержит систему безопасности, которая используется для проверки того, что голько авторизо- ванные пользователи выполняют определенные действия с базой данных. Поль- зователям могут не позволить знакомиться некоторыми данными, а также ограни- чить их действия только определенными изменениями в определенных данных. Наконец, база данных, как централизованное хранилище данных, является ценным имуществом организации. Рассмотрим, например, ценность базы данных книг в компании типа Amazon.com. Ввиду крайней важности этой базы данных нужно принимать меры по предотвращению потерь данных из-за случайных оши- бок, проблем аппаратного обеспечения пли природных катастроф СУБД обеспе- чивает возможность резервного копирования данных нз базы данных и восста- новления их в случае необходимости. Определение и компоненты базы данных На рис. 1.6 компонент системы базы данных, находящийся справа, — сама база данных. Перед тем как продолжать, мы должны определить термин.база данных и описать ее компоненты. В общем случае, можно сказать, что база данных — это самодокументирован- ное собрание интегрированных записей. Для всех реляционных баз данных (а это сегодня почти все базы данных, и только этот тип рассматривается в данной кни- ге) это определение можно модифицировать так: база данных — это самодоку- мгнтированное с обрание связанных таблиц. Ключевые слова в этом определении — самодокументированность и связан- ные таблицы. Вы уже примерно представляете, что мы подразумеваем под свя- занными таблицами. Примерами являются таблицы JOB, CONTRACTOR, EQUIPMENT и RENTAL Ваше понимание этого углубится в главах 5 и 8.
Что такое система обработки базы данных? 35 Под саиодокументировттостью мы подразумеваем, что описание структуры базы данных содержится в самой базе данных. Благодаря этому мы всегда можем vзнать содержимое базы данных, просто посмотрев на нее. Нам не нужно смот- реть куда-то еще. Эта ситуация похожа на ситуацию с библиотекой в вашем студгородке Можно сказать, что находится в библиотеке, просмотрев карточки каталога. Данные о структуре базы данных называются метаданными. Примерами ме- таданных служат имена таблиц, имена столбцов и таблицы, которым они при- надлежат, а также свойства таблиц и столбцов, и так далее. На рис. 1.7 показаны метаданные для базы данных Lakeview, которую мы рас- сматривали ранее. Таблица под названием SYSTABLES содержит данные о каждой из таблиц базы данных, а вторая таблица (SYSCOLUMNS) содержит данные о каждом из столбцов и о связях столбцов с таблицами. Этот рисунок — только пример метаданных. Таблицы, подобные этим, существуют внутри баз данных, обраба- тываемых продуктами типа Oracle, SQL Server или DB2, но они более сложные. Заметим, однако, что сами метаданные содержатся в таблицах. Это значит, что осведомленный персонал может использовать SQL для запросов к метаданным, так же, как и к пользовательским данным. ТзЬЫО jiapteName Л iNumberCbk . NurnbetRov¥s К 1 JOB 2 4 2 CONTRACTOR 8 3 3 EQUIPMENT 4 4 RENTAL 7 7 Column© ICdName " 1 DataType 1 ID mt 4 1 __2 Name char 50 J .ID int 4 2 4 Contractor char 50 2 5 Phone char 20 2 6 Street char 50 2 7 Streets char 50 2 _е City char 50 2 9 State char 2 10 Up char 10 2 11 ID mt 4 3 12 Equipment Type char 35 3 13 Dary Rate currency 4 3 — Н ID int 4 4 _1S ХЬЮ int 4 4 _ и GxrtractorlD nt 4 4 — И Equipment!!? int 4 4 18 Start Data date/bme 4 4 End Date date/tfna 4 4 20 Days int 4 4 ZJ21 Equnment Number nt 8 3 ® Рис. 1.7. Пример метаданных
36 Глава 1. Введение в базы данных Все поставщики СУБД предоставляют набор средств отображения структуры баз данных. Например, иа рис. 1.8 показано использование команды Describe в базе данных Oracle. Как видно, эта команда выдает список имен п свойств столбцов в таблице. Рис. 1.8. Использование команды Dercribe из Oracle Согласно рис. 1.5, база данных содержит пользовательские данные и мета- данные, как было только что описано. Кроме того, база данных имеет индексы и другие структуры, которые существуют для облегчения представления баз дан- ных. Впоследствии мы поговорим об этих структурах подробнее. Сейчас скажем только, что индекс похож на предметный указатель в конце книги и показывает, где искать определенные записи в таблице. Например, можно построить индекс EquipmentlD (идентификатор оборудования) в таблице RENTAL. Этот индекс можно использовать для быстрого нахождения всех строк в таблице RENTAL, имеющих определенное значение идентификатора. Хранимая процедура — это программа, которая хранится в базе данных. Неко- торые хранимые процедуры являются утилитами для базы данных. Например, Lakeview может иметь хранимую процедуру, которая удаляет все данные о про- кате более чем годовалой давности и все платежи, которые были сделаны за про- кат. Такой хранимой процедуре может потребоваться проверка множества таб- лиц в базе данных и реализация сложной логики. Другие хранимые процедуры реализуют логику приложения. Например, можно написать хранимую процеду- ру для генерации списка задолженностей.
Что такое система обработки базы данных? 37 Триггер — это процедура, которая выполняется при вопикновении опреде- ленных ситуаций в данных. База данных Lakeview может, скажем, иметь триггер CustomerCheck, который проверяет, имеет ли клиент хорошую репутацию, перед сохранением каких-либо новых данных о прокате для него. При попытке добавить строку в таблицу RENTAL (прокат) СУБД сначала загрузит и обработает триггер, а потом уже сделает изменение. В этом случае триггер не позволит вставку но- вой строки, если репутация клиента плохая. Подобно хранимым процедурам, триггеры содержатся в базе данных. Хранимые процедуры пишутся или на язы- ке, уникальном для конкретной СУБД, или на языках общего назначения типа Java. О хранимых процедурах и триггерах вы узнаете подробнее из глав 10 и И. Наконец, некоторые базы данных содержат метаданные приложений — про- стые данные, которые описывают элементы приложения, такие как формы и от- четы. Например, Microsoft Access содержит метаданные приложения как часть своих баз данных. Три примера систем баз данных Технология баз данных может использоваться в широком спектре приложений. На одном его конце исследователь может использовать технологию баз дан- ных для отслеживания результатов экспериментов, проводимых в лаборатории. В такой базе данных может быть всего несколько таблиц, и каждая из них может иметь максимум несколько сотен строк. Исследователь может быть единствен- ным пользователем такого приложения. На другом конце спектра — гигантские базы данных, которые поддерживают международные организации. Такие базы данных содержат сотни таблиц по мил- лиону строк данных каждая и используются одновременно тысячами пользова- телей. Эти базы данных работают круглосуточно и без выходных. Сделать даже обычную копию такой базы данных — трудная задача. В этом разделе показаны три разных приложения баз данных: одно — для единичного пользователя, второе — для малого бизнеса и третье — для большого правительственного агентства. Малярная фирма Мэри Ричардс Мэри Ричардс — профессиональный маляр, владеет и управляет небольшой ком- панией, состоящей из нее самой, еще одного профессионального маляра и, когда это необходимо, наемных работников. Мэри занимается этим бизнесом уже 10 лет и приобрела за это время репутацию высококвалифицированного маляра, рабо- тающего за умеренную плату. Большую часть заказов она получает от постоянных клиентов, нанимающих ее для покраски домов, а также от их знакомых. Кроме того, некоторое количество заказов Мэри получает от строительных подрядчиков и профессиональных дизайнеров интерьера. Клиенты помнят Мэри намного лучше, чем она их. Порою она бывает смуще- на, когда клиент звонит ей и говорит что-нибудь такое: «Здравствуйте, Мэри, это
38 Глава 1. Введение в базы данных Джон Мэплз. Вы красили мой дом три года назад». При этом звонящий подразу- мевает, что Мэри вспомнит его и работу, которую она для него сделала; но если учесть, что Мэри красит более 50 домов в год, для нее это будет затруднительно. Ситуация становится еще хуже, когда клиент заявляет: «Моей соседке понрави- лось, как вы покрасили наш дом, и она хочет, чтобы вы и у нее сделали что-ни- будь подобное». Чтобы несколько разгрузить свою память и лучше организовать учет деятель- ности фирмы, Мэри наняла консультанта для разработки базы данных, которую она могла бы хранить на своем персональном компьютере. В базе данных долж- ны храниться записи о клиентах, заказах и поставщиках клиентов, представлен- ные в форме таблиц (рис. 1.9). IFJ Mwrosoft Access : . < leob tfrdw tri «1ИД t Аг -нФ £« ;c jb ' : ‘ - гл- . < • ’'J- Рис. 1.9. Таблицы данных для малярной фирмы Мэри Ричардс Как мы уже говорили, СУБД хранит данные в таблицах и извлекает их отту- да. К сожалению, эти данные, будучи представлены в форме таблиц, не слишком полезны для Мэри. Ей, скорее, хотелось бы знать, как клиенты и заказы связаны друг с другом — например, какие работы были выполнены ею для конкретного клиента или какие клиенты были направлены к ней конкретным человеком. Чтобы предоставить Мэри такую возможность, консультант создал приклад- ttpto программа (application program), которая обрабатывает формы (forms) для
Что такое система обработки базы д анных? ввода данных и формирует отчеты (reports). Рассмотрим пример, предела*- леннып на рис. 1.10. В изображенную здесь форму Мэри вводит личные данные клиента — имя, телефон и адрес. Далее опа вводит сведения о работах, ыпо ценных для клиента, и указывает, кто направил этого клиента к ней Эти данн е могут быть затем отражены в отчете, пример которого показан на рис. 111 Дру- гие функции этой базы данных включают оценку стоимости заказа, учет постав- щиков клиентов и создание наклеек с адресом для рекламных буклетов, которые Мэри время от времени рассылает. Рис. 1,10. Пример формы ввода данных для малярной фирмы Мэри Ричардс Прикладная программа и СУБД обрабатывают заполненную форму и пере- писывают данные из нее в таблицы, подобные изображенным на рис. 1.9. Анало- гичным образом прикладная программа и СУБД извлекают данные из этих таб- лиц для создания отчетов, таких, как на рис. 1.11. Еще раз вернувшись к рис. 1.9, обратите внимание, что строки таблицы со- держат перекрестные ссылки и поэтому оказываются связанными друг с другом. Для каждой работы (ЗОВ) указан номер клиента (CUSTOMER_ID), заказавшего эту работу, и для каждого клиента (CUSTOMER) указан номер поставщика клиента (SOURCE_ID), то есть человека, направившего этого клиента к Мэри. Эти ссылки используются для объединения данных в формы и отчеты (рис. 1.10 и 1.11). Как вы можете догадаться, Мэри вряд ли имеет представление о том, как про- ектировать таблицы, создавать их с помощью СУБД и разрабатывать приклад- ную программу для создания форм и отчетов. Но ваших знаний о технологии баз Данных к моменту окончания этого курса должно хватить для того, чтобы суметь разработать такую базу данных и прикладную программу для работы с ней. Вы должны будете также уметь проектировать таблицы и манипулировать ими для создания довольно сложных форм и отчетов.
40 Глава 1. Введение в базы данных Customer Job History (зоз) sss-ctx *2,730 »,w fiT/MtX} Pert Hong K*sm «0 tktwi tv 78 V.77B ЗЛ5ЙЙ0* Prepbrxip»WU3lU*sbafn *M0 »И0 *4028 $>,073 Total МюлвМняЬвг AwounlBliied AmotmiPaid »’^S8 r;as $1299 Jl.m Total Jackx*\ C/rtf (54$) Щ.124 fltarw^ti^r AmotmifiHixl Atnoxnlfiaid tees JbftPw Ztocrffifow 300000 P*i<u»er>M*TSHW»*« ЩЩЩ30ргкЩ| * •>. lit »>* \v--4*. i«4f> ОвммыгМыпс #4 Awofl С Ьф CMtwnjrtJttm Maples, Man^rt (303) 777-евР JabDatf Dtvccriptian__________________ 40'2005 Point work* tfoercin 633 Rod JbbDaie 7ЯЛОК" Prepandpawirtwinr wxxitnm •I sees Put Itfl j fowpmerlnh Ний-. < \ 4 *» и« Рис. 1.11. Пример отчета для малярной фирмы Мэри Ричардс Ajn>uniSUM A/nsumirtod Бюро проката музыкальных инструментов Treble Clef Music База данных Мэри Ричардс называется однопользовательской (single-user), по- скольку в каждый конкретный момент времени к ней обращается только один пользователь. В некоторых случаях такое ограничение неприемлемо: иногда тре- буется, чтобы одновременно к базе данных могли обращаться несколько человек с различных компьютеров. Такие многопользовательские (multi-user) базы данных являются более сложными, поскольку СУБД и прикладные программы должны заботиться о том, чтобы действия одного пользователя не противоречили дей- ствиям другого. Бюро проката Treble Clef Music использует базу данных для учета сдаваемых в аренду музыкальных инструментов. Для этого требуется многопользователь- ская база данных, поскольку в периоды наплыва клиентов выдачей музыкаль- ных инструментов могут одновременно заниматься несколько служащих. Кроме того, менеджер также должен иметь доступ к базе данных, чтобы определить момент, когда необходимо будет заказать большее количество определенных ин- струментов. При эгом менеджер не должен мешать процессу выдачи инструментов. Б reble Сlef Music имеет локальную сеть, соединяющую несколько персо- нальных компьютеров с сервером, па котором находится база данных (рис. 1.12).
Что такое система обработки бмы д» >***"> 41 У каждого из служащих есть доступ к прикладной программе, позволяющей ра- ботать с тремя видами форм (рис. 1.13). Форма CUSTOMER содержит информацию о клиенте, форма RENTAL AGREEMENT представляет договор аренды и используется для учета выдачи и возврата инструментов, а форма INSTRUMENT содержит сведе- ния об инструменте и историю его аренды. Компьютеры служащих Компьютер управляющего Рис. 1.12. Локальная сеть бюро проката Treble Clef Music Чтобы уяснить проблемы, которые необходимо преодолеть в многопользова- тельской базе данных, представьте себе, что произойдет, если два клиента одно- временно попытаются взять напрокат один и тот же кларнет си-бемоль. СУБД и прикладная программа должны каким-то образом обнаружить эту ситуацию и сообщить служащим, что им следует выбрать другой инструмент. Бюро регистрации автомобилей и выдачи прав Рассмотрим теперь еще более обширное приложение технологии баз данных — государственное бюро регистрации автомобилей и выдачи водительских прав. В него входят 52 центра, где принимаются экзамены по вождению и осуществля- ется выдача и продление прав, а также 37 офисов, занимающихся регистрацией транспортных средств. Персонал этих офисов использует в своей работе базу данных. Прежде чем конкретному лицу будут выданы или продлены права, в базе данных просматри- ваются сведения об этом лице на предмет наличия нарушений правил дорожного Движения, ДТП или арестов. На основе этих данных принимается решение, могут ли права быть продлены, и если да, то будут ли в них какие-либо ограничения. Аналогичным образом, персонал в отделе регистрации автомобилей обращает- ся к базе данных, чтобы определить, был ли автомобиль зарегистрирован ранее, а если был, то на чье имя, и нет ли каких-либо из ряда вон выходящих причин, по которым в регистрации следует отказать.
42 Глава 1. Введение в базы данных а б в Рис. 1.13. Формы, используемые бюро проката Treble Clef Music: а — форма Customer, б форма Rental Agreement, а — форма Instrument Data
Что такое система обработки базы данных? 43 у этой базы данных сотни пользователей, включая не только персонал, за- нимающийся регистрацией и выдачей прав, но и служащих финансового управ ленпя, а также сотрудников правоохранительных органов. Не удивительно, что база является большой и сложной и имеет более 40 таблиц, причем некоторые из них содержат сотни тысяч строк данных. Компоненты этой системы пока- заны на рис. 1.14. Заметьте, что приложения написаны на разных языках и, вероятно, в раз- ные периоды времени. Oracle обрабатывает две разные базы данных по пору- чению этих приложений. Поскольку эти приложения очень важны, система должна быть доступна круглосуточно и без выходных. Такой уровень доступ- ности делает простые задачи, например резервное копирование, очень труд- ными. Большие организационные базы данных, подобные только что рассмотренной нами, были первыми приложениями технологии баз данных. Подобные системы находятся в эксплуатации уже в течение 20 или 30 лет и за этот период неод- нократно модифицировались в соответствии с менявшимися требованиями вре- мени. Существуют организационные базы данных, предназначенные для веде- ния счетов в банках и других финансовых институтах, учета готовой продукции и комплектующих па складах больших предприятий, обработки медицинской документации в госпиталях и страховых компаниях, а также для правитель- ственных нужд. Сегодня многие организации модифицируют прикладные программы сво- их баз данных, чтобы дать клиентам возможность обращаться к этим данным н даже вносить в них изменения через Интернет. Если вы работаете в большой организации, то вас вполне могут подключить к подобному проекту. Сравнение четырех типов баз данных Приведенные примеры демонстрируют возможные варианты использования тех- нологии баз данных. Есть согни тысяч баз данных, похожих на ту, что имеется в малярной фирме Мэри Ричардс, — однопользовательские базы данных с отно- сительно небольшим количеством данных, скажем, менее 10 Мбайт. Формы и от- четы для этих баз данных имеют обычно довольно простой вид. У других баз данных, подобных той, что используется в бюро проката Treble Elef Music, несколько пользователей, но общее их количество обычно не превы- шает 20-30 человек. Они содержат умеренное количество данных — например 50 или 100 Мбайт. Формы и отчеты должны быть достаточно сложными, чтобы поддерживать несколько различных деловых функций. Самые большие размеры у баз данных, подобных той, которую мы рассмат- ривали для случая бюро регистрации автомобилей, — у них сотни пользователей 11 триллионы байт данных. Для работы с этими базами данных используется множество различных приложений, у каждого из которых свои собственные Формы и отчеты. Характеристики этих типов данных сведены в табл. 1.2.
44 Глава 1 Введение в базы данных Код C# HTML и VBScript Приложение для регистрации автомобилей Приложение для обновления информации о водителях Приложение для истории водителей Код Java Oracle База данных по водителям Рис. 1.14. Организационная система баз данных База данных по автомобилям Прочтя книгу, вы сможете проектировать и реализовывать базы данных напо- добие тех, что используются в малярной фирме Мэри Ричардс и в бюро проката Treble Clef Music. Возможно, вы будете еще не в состоянии создавать такие боль- шие и сложные базы данных, как та, что используется в бюро регистрации транс- портных средств, но, тем не менее, сможете быть полезным членом команды по разработке и созданию такой базы данных. Вы также сможете создавать неболь- шие или средних размеров базы данных, использующие Интернет-технология. Таблица 1.2. Характеристики разных типов баз данных Тип Пример Число пользователей Размер базы данных Персональная Малярная фирма Мэри Ричардс 1 < 10 Мбайт Для рабочей группы Бюро проката музыкальных инструментов Treble Clef Music <25 <100 Мбайт Организационная Бюро регистрации автомобилей и выдачи прав сотни или тысячи >1 Тбайт, возможно, несколько баз данных Как построить систему баз данных Процесс построения базы данных по большей части совпадает с процессом по- строения любой другой информационной системы. Как показано в табл. 1.3, существуют три основных фазы: формулирование требований, проектирование и реализация. Большая часть этой книги посвящена второй фазе, хотя в некото-
Как построить систему баз данных 4S рых главах мы будем рассматривать также создание запросов и кода прилоа • iшя. Однако сначала мы познакомимся с разработкой базы данных. таблица 1.3. Обзор фаз построения базы данных фаза построения базы данных Базы данных Приложения Фаза формулирования требований Построение модели данных Определение требований Задание элементов данных приложения Определение ограничений и правил Фаза проектирования Таблицы Формы Отношения Отчеты Индексы Запросы Ограничения Код приложения Хранимые процедуры и триггеры Фаза реализации Создание таблиц Создание форм Создание отношений Создание отчетов Создание ограничений Создание запросов Написание хранимых процедур Написание кода приложения и триггеров Тестирование Заполнение базы данных Тестирование Фаза формулирования требований Во время этой фазы разрабатывается модель данных: типы элементов данных, их длина и другие свойства. Кроме того, на данные накладываются ограничения и правила. Модель данных — это логическое представление структуры базы данных. Моделирование данных очень важно, поскольку и база данных, и все ее структу- ры зависят от модели данных. Если модель данных некорректна, результат будет разочаровывающим. Учитывая важность модели данных, я посвятил ей следу- ющие две главы. На рис. 1.15 показан пример диаграммы модели данных для фирмы Lakeview Rentals. На рисунке представлен пример диаграммы сущность—связь — средства выражения моделей данных, которое стало промышленным стандартом. На этом Рисунке JOB, CONTRACTOR, RENTAL и EQUIPMENT являются сущностями. Линии представляют связи между этими сущностями. Остальными подробностями пока можно пренебречь. Нужно только знать, что такие диаграммы существуют для Документирования моделей данных. Как вы увидите позже, во время фазы формулирования требований необхо- димо определить свойства элементов данных, такие как тип данных, максимальная Длина, требуется ли значение и т. д. Кроме того, следует определить значения элементов данных и правила обработки данных. Приведем пример ограничения ДДИных: значение Equipment type (тип оборудования) должно быть из следующего
46 Глава 1. Введение в базы данных множества: ['Backhoe', 'Smallcrane', 'Medium crane, 'Large crane', 'Scaffolding'^ (экска- ватор, малый кран, средний кран, большой кран, строительные леса). Ограниче- ния и правила мы будем обсуждать в следующих двух главах. Рис. 1.15. Диаграмма сущность—связь для базы данных Lakeview Rentals Фаза проектирования Во время фазы проектирования модель данных преобразуется в таблицы и отно- шения. На рис. 1.16 показан пример диаграммы с труктуры данных — диаграммы, используемой для отображения таблиц и их отношений. На этой диа1рамме ли- ния между таблицами EQUIPMENT и RENTAL представляет связь. Вилка по направ- лению к таблице RENTAL означает, что данная строка в таблице EQUIPMENT можег относиться ко многим строкам таблицы RENTAL. Эту и подобные диаграммы мы будем использовать при обсуждении проектирования баз данных в главах 5 и 8. В этих главах вы узнаете значение и других элементов на этом рисунке. JOB Table CONTRACTOR Table Рис. 1.1 в. Пример диаграммы структуры данных для Lakeview Rentals
Как построить систему баз данных 47 Необходимость в индексах определяется во время фазы проектирования биы данных, и иногда также задаются характеристики индексов (я говорю « иногда» поскольку не все СУБД поддерживают эту спецификацию) Механизмы огра ничении, хранимые процедуры и триггеры также проектируются Об этом вы узнаете из глав 10-12. CREATE TABLE EQUIPMENT ID EquipmentType EquipmentNumber DailyRate Int Char (35) Char (25) Number (6,1 Primary Key, Not Null, Not Null, г»; CREATE TABLE RENTAL( ID Int Pnmary Key, Jobl D Int Not Null. ContractorlD Int Not Null, Equipment® Int Not Null, StartDate Char (12) Not Null, EndDate Char (12), Days Smalllnt, Charge Number (8,2)); ALTER TABLE RENTAL ADD CONSTRAINT EquipmentFK FOREIGN KEY (EqwpmentID) REFERENCES RENTAL; a 6 Рис. 1.17. Создание таблиц, a — с помощью текстовых команд, б — с помощью графических средств
48 Глава 1. Введение в базы данных Фаза реализации Как показано в табл. 1.3, в фазе реализации создаются таблицы и связи. Для соз- дания таблиц используются два способа: с помощью SQL и через средство графи- ческого проектирования. На рис. 1 17, а показаны SQL-операторы для созда- ния таблиц EQUIPMENT и RENTAL и для определения связей между ними. Такие SQL-операторы можно вводить в базу данных для определения таблиц и связен. На рис. 1.17, б показан другой прием — использование средства графического проектирования для определения таблицы CONTRACTOR в SQL Server. Большин- ство СУБД позволяют использовать оба способа. Аналогичным образом, в боль- шинстве СУБД можно задавать ограничения на данные как с помощью SQL, так п с помощью графических средств. О том, как писать SQL-операторы для этих целей, вы узнаете в главах 7 и 8. Во время реализации также пишутся и тестируются хранимые процедуры и триггеры. Как это делается в Oracle, вы узнаете в главе 10, а в SQL Server — в главе И. Наконец, база данных заполняется данными, и система тестируется. Некоторые информационные системы на этом уже готовы. Обычно же когда база данных и ее приложение завершены, необходимо еще модифицировать их в соответствии с новыми требованиями, которые разрабатываются во время фазы реализации. Такие модификации также проходят эти же гри фазы (форму- лирования требований, проектирования и реализации), но это происходит в кон- тексте существующих баз данных и приложений. Изменение существующих баз данных может быть очень трудным, и этот процесс, называемый перепроектиро- ванием базы данных, мы будем обсуждать в главе 8 Разработка приложения Разработка приложения осуществляется параллельно с разработкой базы дан- ных. Поскольку эта книга посвящена базам данных, мы не будем слишком по- дробно останавливаться на разработке приложения. В главе 7 будет обсуждаться использование SQL для приложений, а в главах 10 и 11 будет описываться напи- сание хранимых процедур и триггеров. Однако по большей части третий столбец табл. 1.3 мы оставим для ваших занятий по системному программированию. Перед тем как перейти к моделированию данных, мы завершим эту главу кратким экскурсом в историю баз данных. Краткая история баз данных бл 1.4 сведена история развития технологии баз данных. До середины 1960-х годов почти все компьютерные хранилища данных были на магнитных лентах, оскольку лента может обрабатываться только последовательно, данные должны ‘ >< и храниться в виде списков (или последовательных файлов, как они называ- лись) Однако, как вы узнали в начале этой главы, хранение даже простейших иных в таком формате чревато большими проблемами.
Краткая история баз данных 49 Таблица 1.4. Краткая история баз данных Период Технология д^1968 Обработка файлов Примечания Предшествовала обработке баз данных. Данные хранились в виде списков. Характер обработки определялся всеобщим использованием в качестве носителя магнитной ленты 1968-1980 Иерархические и сетевые модели Эра обработки нереляционных баз данных. Выдающейся иерархической моделью данных была DL/I фирмы IBM Первая СУБД называлась IMS. Выдающейся сетевой моделью данных была модель DBTG фирмы CODASYL. Самой популярной сетеаой СУБД была IDMS 1980 - наст. Реляционная время модель данных 1982 Первые СУБД для микрокомпьютеров 1985 Развитие интереса к объектно- ориентированным СУБД (ООСУБД) 1991 Компания Microsoft выпустила Access 1995 Первые приложения баз данных для Интернета 1997 Применение XML к обработке баз данных Реляционная модель данных впервые была опубликована в 1970 году. Реализовываться в коммерческих приложениях начала в 1980 году. IBM выпустила DB2, среди других продуктов выделяется Oracle. Реляционный язык SQL стал промышленным стандартом Фирма Ashton-Tate разработала dBase, Microrim — R:Base, a Borland — Paradox С развитием объектно-ориентированного программирования были предложены ООСУБД. Коммерческий успех их невелик, в первую очередь потому, что преимущества не оправдывают перевод миллиардов байтов данных организаций в новый формат. Продолжают развиваться и сейчас Персональная СУБД, созданная как элемент Windows. Постепенно вытеснила с рынка все другие персональные СУБД Базы данных стали ключевым компонентом Интернет- приложений. Популярность Интернета существенно повысила необходимость в базах данных и требования к ним Использование XML решило проблемы, которые долго стояли перед базами данных. Ведущие производители стали интегрировать XML в свои СУБД Ранние модели баз данных С коммерческим успехом хранилищ на дисках в середине 1960-х стало воз- можным получение непоследовательного, или прямого, доступа к записям. Базы Данных стали разрабатываться по-другому. Изначально стали успешными две конкурирующие архитектуры, или модели. Корпорация IBM разработала и вне- дрила DL/I (Data Language One, язык данных один), который моделировал дан- Ные в базах данных в форме иерархий, или деревьев (см. рис. 1.18, а). Эта модель, которая была разработана совместно с промышленными предприятиями, легко МоглД использоваться для поддержки данных, таких как сметы материалов и списки Деталей, но для общих целей мало подходила. Представление неиерархических Сегевых данных (рис. 1.18, б) было громоздким.
50 Глава 1. Введение в базы данных После этого CODASYL, группа, которая разрабатывала стандарты для языка COBOL, в 1970 году создала модель под названием DBTG (Data Base Task Group группа задач баз данных). Модель DBTG была готова к представлению как ие- рархических, так и сетевых данных. Один раз эта модель предлагалась в качестве национального стандарта, но не была принята в первую очередь из-за своей сложности. Однако это была основа для ряда коммерчески успешных СУБД в се- мидесятых и восьмидесятых годах прошлого века. Наиболее успешным был продукт корпорации Cullinane под названием IDMS. Замечание: каждый узел имеет не более одного родительского узла а Замечание: узлы могут иметь и по несколько родительских узлов б Рис. 1.18. а — пример иерархии: университетская организация, б — пример сети: классы и студенты Реляционная модель Реляционная модель, которая представляет данные в формате, показанном на рис 1.3, впервые была предложена Е. Ф, Коддом в 1970 году. Кода работал в IBM, и после десяти лет исследований, разработки и лоббирования на уровне корпо- рации он с коллегами убедил IBM разработать несколько СУБД, основанных на
Краткая история баз данных 61 реляционной модели Наиболее известным на этих продуктов является DB2 — СУБД, которая активно используется и поныне. Между тем другие корпорации (такие как Oracle, Ingres, Sybase и Informix) тоже разработали СУБД, основанные на реляционной модели SQL Server был разработан в Sybase и в конце восьмидесятых ходов продан Microsoft. Сегодня D 2 Oracle и SQL Server являются наиболее выдающимися коммерческими СУБД СУБД для персональных компьютеров С появлением большого числа микрокомпьютеров стало возможно иметь персо- нальные базы данных. В результате был разработан ряд СУБД для персональных компьютеров. Наиболее успешной из них была dBase — продукт корпорации Ashton-Tate. Еще среди ранних персональных СУБД можно назвать R:base корпо- рации Microrim и Paradox от Borland. Поскольку компьютеры обладали довольно большой вычислительной мощ- ностью, персональные СУБД предоставляли больше графических интерфейсов пользователя. Кроме того, со временем под влиянием этих продуктов изменились и интерфейсы больших организационных СУБД. На рис. 1.17 показан этот момент. Технология того, что показано на рис. 1.17, а, разрабатывалась для символьно- ориентированных интерфейсов, которые были распространены для СУБД, пред- шествовавших персональным компьютерам. На рис. 1.17, б показан пример графи- ческого интерфейса, который появился с возникновением персональных СУБД. Объектно-ориентированные СУБД (ООСУБД) Объектно-ориентированное программирование начало развиваться в середине восьмидесятых годов прошлого века и привело к созданию объектно-ориентиро- ванных СУБД. Целью этих продуктов была способность хранить объекты из объектно-ориентированного программирования (например, из языков C++ или Java) в базе данных, не преобразуя их в реляционный формат. В настоящее время ООСУБД не имеют коммерческого успеха. Их использо- вание требует от организаций преобразовывать свои базы данных из реляцион- ного в ООСУБД формат. Кроме того, большинство крупных организаций имеют более старые приложения, не основанные на объектно-ориентированном про- граммировании. Программы в таких приложениях потребовалось бы как-то сопровождать новыми ООСУБД. Таким образом, высокая стоимость перевода существующих баз данных и информационных систем из реляционных СУБД в ООСУБД задерживает их широкое распространение. Были разработаны объектно-ориентированные СУБД, такие как Oracle 81 и 9i, Что позволило создавать как реляционное, так и объектное представление дан- НЬ1Х одной и той же базы данных. Эти СУБД начинают получать коммерческий Успех, но не такой, как чисто реляционные СУБД. Объектно-ориентированные уБД мы рассмотрим в главе 16.
52 Глава 1 Введение в базы данных Недавняя история » .. л „ -w.nn Access который на несколько дет вытеснил С РЫН' б,.а,тому, что ка все остальные С> Д_ « Microsof( СМ()171а использовать свое влияние на 'n,TCn>"PZ^™?l°'с ХбоХя смс,11Я.»я других продукт»» П^«. Esoft нужно отдать епра»ед,.п.юсгь: Access - суиерпролукт. Он доминирует на рынке потому что это легкая в использовании и сильная СУБД Как все знают, использование Интернета распрост ранилось в середине девя- ностых годов Но немногие знают, что именно это сильно повысило значение и важность технологии баз данных. Как только ранние статические веб-страницы уступили дорогу динамическим, как только стали иметь успех компании типа Amazon com и как только большие организации начали использовать Интернет для публикации своих данных, все большее и большее количество сайтов стало зависеть от баз данных. Эта тенденция продолжается и по сей д Наконец, в последние годы появился и стал широко использоваться язык XML, который представляет собой технологию для поддержки веб-сайтов, но был расширен для проведения важных решений, связанных с базами данных Я ык XML мы будем обсуждать в главе 13. Пока же нам осталось осознать, что инте- грация технологии баз данных с XML является ведущим пунктом области баз данных сегодня и будет важна еще много лет в будущем. Резюме Хотя обработка баз данных всегда была важной темой, популярность Интернета сделала ее еще и одной из самых нужных специальностей. Навыки, которые вы разовьете, и знания, которые вы приобретете, будут чрезвычайно востребованы. Цель базы данных — помочь людям и организациям вести учет различных ве- щей. Хотя для этой цели можно использовать списки, они вызывают множество проблем. Их сложно изменять без возникновения несоответствий, удаления из списков могут иметь непредвиденные последствия, а неполные данные трудно записывал,. Кроме того, вводя данные, легко вызвать их противоречивость, аконец различные части организации хотят поддерживать некоторые данные местно, а некоторые — исключительным образом. Это трудно организовать при использовании списков. кйЖ7тяа1гаГННЫХ состоят из гР>'пп реляционных таблиц. В большинстве случаев таким обпйзт^п содержит данные по определенной теме. Поддержка данных лидах п!елставпГаеТ ВСе проблемы- перечисленные для списков. Связи в таб- путем присвоения1?^ рззнь1ми спосо^ами- в эт°й главе связи представлялись этого идентиЛикатог^Д0И С"Р0Ке уникального идентификатора и использования лицы. Для представления1 “язи„СТроки одной таблицы со строкой другой таб- можно создавать с помощью да?ка5ОЬЛЬЗ°ВаЛ”СЬ ” ВНешНие ключи- Та6лш‘ы дартом для обработки таблиц ’ КОТОрыи является промышленным стан-
__________________________________________Вопросы группы I 53 Система базы данных состоит из четырех основных элементов пользователи приложения базы данных, СУБД и сама база данных. Пользователи применяют базу данных для решения своих задач. Приложения производят формы, запросы и отчеты, выполняют логику приложения и управляют обработкой базы. СУБД создает, обрабатывает и администрирует базу данных. База данных — это самодо- кументпрованное собрание интегрированных записей. Она содержит пользователь- ские данные, метаданные, индексы, хранимые процедуры, триггеры и метадан- ные приложения. Хранимая процедура — это программа, которая обрабатывает участок базы данных и хранится в базе данных. Триггер — это процедура, кото- рая вызывается при наступлении определенного события. На рис. 1.6 показаны функции компонентов базы данных. Технология баз данных может использоваться в широком спектре приложе- ний. Некоторые базы данных используются одним человеком, другие — группой людей, а третьи — большими организациями. В табл. 1.2 показаны некоторые характеристики этих разных типов баз данных. Подобно всем информационным системам, системы баз данных разрабатыва- ются в течение трех фаз: формулирования требований, проектирования и реали- зации. Во время фазы формулирования требований разрабатывается модель данных, или логическое представление структуры базы данных. Модели данных важны, потому что от них зависит проектирование базы данных и приложения. Диаграмма сущность—связь — средство, используемое для представления моде- ли данных. Модель данных преобразуется в таблицы и связи на фазе проектирования. Также проектируются индексы, ограничения, хранимые процедуры и триггеры. Диаграммы структур данных иногда используются для таблиц документов и их связей. Во время фазы реализации создаются таблицы, связи и ограничения, пишутся хранимые процедуры и триггеры, база данных заполняется данными в тестируется. Сегодня таблицы и связанные с ними конструкции создаются с по- мощыо SQL пли графических средств, являющихся частью СУБД. Разработка приложения идет параллельно с разработкой базы данных. Боль- шая часть этой книги посвящена разработке базы данных, но проектирование 11 построение запросов и создание кода приложения также будут рассматриваться в последующих главах. Существенные события в истории обработки баз данных показаны в табл. 5. Вопросы группы I I Почему обработка баз данных сегодня важнее, чем раньше? 2- Сформулируйте цель базы данных. 3, Перечислите проблемы, которые могут возникать при использовании спис- ков для учета чего-либо. 4 Основываясь на вашем ответе на вопрос 3, скажите, когда, по вашему мне- Н1|ю, можно использовать списки для учета чего-либо.
54 Глава! Введение в базы данных При отнете и» «опросы 5-9 иепОЛИуП™ НаучРуховоди.оль Тол1^учу^_Д ^*0HC ,?о_44 44 Штайн инф технологии Мм> КееЙ\ 281-39-44 Джонсон бухучет Грим Розенблюм 281 39-44 Гонзалес бухучет Грин РОЗенблЮМ 201-ЛЭ чч Джонс 221-23-45 РИКИ бухучет Грим 5. Опишите проблемы, которые могут возникнуть, когда научный руководи- тель меняет свой номер телефона. 6. Предположим, студент Штайн бросил учебу, и вторая строка удаляется. Опишите побочные эффекты от этого удаления. 7. Как можно использовать этот список для записи того факта, что Смит - заведующий кафедрой компьютерных наук? 8. Предположим, что в последней строке значение последнего столбца изме- нилось с Грин на Абернати. Какие проблемы возникнут при интерпрета- ции этого списка? 9. Переделайте этот список в набор из трех взаимосвязанных таблиц. Для представления связей используйте прием, показанный на рис 1.3. 10. Объясните, почему ни одна из проблем, описанных в вопросах 5-8, не мо- жет возникнуть в таблицах, которые вы построили при ответе на вопрос 9. И. Используя в качестве примера оператор SQL, показанный в разделе «Объ- единение таблиц», составьте подобный оператор для объединения таблиц, которые вы построили при ответе на вопрос 9. Если в каком-нибудь из имен столбцов есть пробелы, поставьте имена столбцов в квадратные скоб- ки [ ]. Поскольку в вашем результате нет вычислений, вам не понадобится выражение типа [Daily Rate]*[Days] As Charge. 12. Назовите четыре компонента системы базы данных. 13. Перечислите функции приложения базы данных. 14. Для чего предназначена СУБД? Перечислите ее функции. 15. Определите термин база данных. 16. Перечислите содержимое базы данных. 17. Чю 1акое метаданные? Приведите пример. 18. В чем разница между хранимой процедурой и триггером? бочейСг1дщтТЗЛИЧИЯ Между слеДУющими базами данных: личной, для ра- оочеи группы и организационной. мы базывданных ^ормулирован11Я требований при разработке систе- 21. Что такое модель данных? п„чему такие модел„ ,!ажны? 22. Назовите задан»фдзь. проект,,ром,™ „р„ разработкебазы ........
Вопросы группы II 23 Назовите задачи фазы реализации при разработке системы базы данных. 24. Назовите две модели данных, которые предшествовали реляционной модели 25. Опишите недостатки двух моделей, о которых идет речь в предыдущем вопросе. 26. Кто первый предложил реляционную модель? 27. Как персональные СУБД повлияли на организационные СУБД? 28. Назовите три ранних персональных СУБД. 29. Какова цель ООСУБД? 30. Почему ООСУБД не имеют коммерческого успеха? 31. Что такое объектно-реляционная СУБД? 32. Какая технология сейчас на переднем крае в области баз данных? Вопросы группы II 33. Предположим, что Новоорлеанское товарищество деревянных лодок (фик- тивная организация) публикует ежемесячный бюллетень, на который оно тратит 35 долларов в год. Пусть для рассылки этих бюллетеней товарище- ство хранит следующие данные в виде списка: Имя, Улица, НомерДома, Город, Штат, Индекс, НачДата, КонДата, СуммСтоимость. Какие проблемы могут возникнуть при хранении данных в таком списке? 34. Предположим, что подписчик этого бюллетеня на три года изменил свой адрес. Нужно ли изменять адресные данные для всей подписки, или толь- ко для текущей? Почему? 35. Разбейте список из вопроса 33 на две таблицы — ПОДПИСЧИК и ПОДПИСКА. Постройте связи между таблицами, используя в качестве примера рис. 1.3. Как такое расположение может исправить проблемы, которые вы нашли, отвечая на вопрос 33? Как оно влияет на ваш ответ на вопрос 34? 3G. Предположим, что товарищество решило опубликовать два издания: еже- квартальный путеводитель (зима, весна, лето и осень) и ежемесячное новостное издание. Предположим, что стоимость путеводителя — 15 дат- ларов в год, а новостного издания — 35 долларов в год. Пусть для этой подписки общество хранит следующие данные: Имя, Улица, НомерДома, Город, Штат, Индекс, Издание, НачДата, КонДата, Сумм- Стоимость. Какие проблемы могут возникнуть при хранении этих данных в виде списка? 37> Разбейте список из вопроса 36 на две таблицы: ПОДПИСЧИК и ПОДПИСКА. Постройте свя ш между таблицами, используя в качестве примера рис. 1.3. Как такси* расположение может исправить проблемы, которые вы наш ти, отвечая на вопрос 36? Объясните, почему такое двухтабличное располо- жение лучше, чем одна таблица.
56 Глава 1. Введение в базы данных________ 3S Предположим, что стоимость путеводителя 15 долларов В ошхт- лого издания — 35 долларов в юд, no стоимость обоих издании сразу •” 40 долларов в год. Повлияет ли это обсоятельство на проекторов; не таблиц для вопроса 37? Почему? Как товарищество должно действовать в этой ситуации? 39 Практически любой член товарищества, имеющий компью ери е и ’ кп, может создавать и обрабатывать список. Однако разработка базы дан- ных п приложения базы данных уже требует специализиро и умений. Если бы товарищество попросило вас помочь определить, оку- пятся ли затраты на базу данных, как бы вы рассуждали? Какие вопросы вы бы задали? Какой анализ вы бы провели? Вопросы к проекту FiredUp FiredUp, Inc. — небольшая компания, владельцами которой являются Керт и Джу- ли Роубердс. Эта компания, находящаяся в Брисбейне, Австралия, производит и продает легкие походные горелки под названием FiredNow. Керт, работавший раньше аэрокосмическим инженером, изобрел и запатентовал сопло, которое не дает огню в горелке погаснуть даже при очень сильном ветре — до 90 миль в час. Джули, промышленный дизайнер по образованию, разработала элегантную склад- ную конструкцию, которая имеет небольшой вес и габариты, проста в установке и весьма устойчива. Семья Роубердс производит горелки в своем гараже и прода- ет клиентам напрямую, принимая заказы через Интернет, по факсу и по почте. Владельцы FiredUp хотели бы отслеживать проданные горелки на тот случай, если им понадобится войти в контакт с покупателями относительно дефектов в изделиях и по другим вопросам, связанным с качеством изделий. Соответ- ственно, они ввели форму регистрации продукта для каждой из горелок. Форма содержит следующие данные: ИняПокупателя, Улица. НомерДома, Город, Штат, Индекс, Страна, НомерТелефона, ДатаПокупки, СерийныйНомер ♦ Предположим, фирма FiredUp хранит свои данные в списке. Опишите пять потенциальных проблем, которые у нее могут возникнуть при этом. ♦ Предположим, что вместо списка они решили создать персональную базу данных со следующими таблицами: КЛИЕНТ (Имя, Улица, Дом, Квартира, Город Штат, ПочтовыйИндекс, Страна, ЭлектронныйАдрес, Телефон) и ПОКУПКА (Дата- Покупки, СерийныйНомер) 1. Создай ге таблицу с данными, структура которой будет соответствовать таб- лице КЛИЕНТ. В таблице должно быть по меньшей мере четыре строки. (Для отета на вопросы 1-7 достаточно ввести данные в текстовом редакторе.) 2. Какой из столбцов таблицы КЛИЕНТ можно использовать для однозначной идентификации строки в таблице? Такой столбец иногда называется пер- вичным ключом, как вы позже узнаете из этой книги. 3. Создайте iаблицу с данными, структура которой будет соответствовать та шице ПОКУПКА. В таблице должно быть по меньшей мерс четыре строки
Вопросы к проекту Twiqb Tree 57 4. Какой из столбцов таблицы ПОКУПКА можно использовать в качестве пер- вичного ключа для этой таблицы? 5. Имея определенные выше таблицы, невозможно связать конкретного по- купателя с его горелкой. Один из способов сделать это — добавить столбец СерийныйНомер из таблицы ПОКУПКА в таблицу КЛИЕНТ. После этого табли- ца КЛИЕНТ будет выглядеть следующим образом: КЛИЕНТ (Имя, Улица, Дом, Квартира, Город, Штат, ПочтовыйИндекс, Страна, ЭлектронныйАдрес, Телефон). Скопируйте данные из таблицы КЛИЕНТ и добавьте к ним столбец Серий- ныйНомер. Назовите получившуюся таблицу КЛИЕНТ1. 6. Связь двух таблиц можно представить и по-другому: поместить столбец ЭлектронныйАдрес из таблицы КЛИЕНТ в таблицу ПОКУПКА. После этого таб- лица ПОКУПКА будет выглядеть следующим образом: ПОКУПКА (ДатаПокупки, СерийныйНомер, ЭлектронныйАдрес). Скопируйте данные из таблицы ПОКУПКА и добавьте к ним столбец ЭлектронныйАдрес из таблицы КЛИЕНТ. Назовите получившуюся таблицу ПОКУПКА1. 7 Теперь у вас имеются три возможные структуры: КЛИЕНТ1+ПОКУПКА, КЛИЕНТ+ПОКУПКА1 и КЛИЕНТ1+ПОКУПКА1. При каких условиях вы могли бы рекомендовать первую структуру? Вторую структуру? Третью структуру? Вопросы к проекту Twigs Tree Саман га Грин владеет и управляет фирмой Twigs Tree. Она закончила лесоводче- ские курсы и работала в большой фирме по ландшафтному дизайну, которая за- нималась подрезкой деревьев. Чс рез несколько лет она купила грузовик, машину Для корчевания иней и другое оборудование и затем открыла в Сент-Луисе, штат Миссури, собственное дело. Хотя большинство выполняемых ею заказов представляют собой одноразовые операции по спиливанию дерева или корчеванию пня, есть и повторяющиеся — например, подрезка деревьев каждый год или раз в два года Когда дело идет медленно, она звонит старым клиентам, чтобы напомнить им о себе и о необхо- димости произвести очередное подрезание деревьев. Саманта хранит о своих заказах следующие данные: ИмяКлиента, Телефон, Ули- ца, Город, Штат, Индекс, ДатаОбслуживания, Описание, Затраты, Плата, ДатаПлатежа. ♦ Предположим, Саманта хранит свои данные в виде списка. Опишите пять потенциальных проблем, с которыми она может при этом столкнуться. ♦ Допустим, Саманта решила вместо списка создать персональную базу дан ных со следующими таблицами. КЛИЕНТ (Имя, Телефон, Улица, Город, Штат, Индекс) и ЗАКАЗ (ДатаОбслуживания, Описание, Затраты, Плата, ДатаПлатежа). 1 Постройте таблицу, заполнив ее данными, соответствующими структуре таблицы КЛИЕНТ. В таблице должно быть по меныпей мере четыре ст|юки (Для ответа на первые вопросы достаточно ввести данные в текстовом ре- дакторе )
58 Глава 1 Введение в базы данных 2 Какой из столбцов таблицы КЛИЕНТ можно использовать для однозначной идентификации строки в таблице (то есп> в качестве ключа)? 3. Постройте таблицу данных, которая соответствует структуре ЗАКАЗ В ней должно быть по меньшей мере четыре строки. 4. Объясните, почему ни один из столбцов таблицы ЗАКАЗ нельзя использо- вать в качестве ключа. 5. Добавьте в таблицу КЛИЕНТ столбец идентификатора, как к таблицам на рис. 1.3. Дополните соответствующим образом ваши данные. 6. Имея определенные выше таблицы, невозможно связать конкретного кли- ента с его заказом. Один из способов сделать это — добавить столбец иден- тификатора из таблицы ЗАКАЗ в таблицу КЛИЕНТ. Таблица КЛИЕНТ при этом будет содержать следующее: КЛИЕНТ (Имя, Телефон, Улица, Город, Штат, Индекс, ИдентЗаказа). Скопируйте ваши данные из таблицы КЛИЕНТ и добавьте к ним ИдентЗака- за. Назовите новую таблицу КЛИЕНТ1. 7. Еще один способ создать связь между таблицами — поместить столбец Те- лефон из таблицы КЛИЕНТ в таблицу ЗАКАЗ. При этом таблица ЗАКАЗ будет выглядеть так: ЗАКАЗ (ДатаОбслуживания, Описание, Затраты, Плата, ДатаПлате- жа, Телефон). Скопируйте ваши данные из таблицы ЗАКАЗ и добавьте к ним Телефон. На- зовите новую таблицу 3AKA31. 8. Теперь у вас есть три возможных структуры базы данных: КЛИЕНТ1+ЗАКАЗ, КЛИЕНТ+ЗАКА31 и КЛИЕНТ1+ЗАКА31. При каких условиях вы могли бы реко- мендовать первую структуру? Вторую структуру? Третью структуру?
Часть I Модель данных «сущность—связь» В двух главах, составляющих первую часть книги, описываются и иллюстриру- ются на примерах методы, средства и процессы моделирования данных. В главе 2 происходит первое знакомство с моделью данных «сущность—связь» и рассматри- ваются несколько вариантов этой модели, с которыми читатель вероятнее всего может столкнуться в ходе практической деятельности. Здесь же описываются ком- поненты, входящие в состав средств моделирования данных. В главе 3 излагаются в общих чертах и демонстрируются на многочисленных примерах процессы моде- лирования данных с использованием инструментария, представленного в главе 2. Лучший способ научиться моделированию данных — это практика, и мы на- стоятельно рекомендуем вам не обходить вниманием задачи и примеры, приве- денные в конце каждой главы. Еще больше полезных знаний и навыков вы смо- жете приобрести, если обзаведетесь каким-нибудь программным продуктом для моделщювания данных и будете использовать его для создания собственных мо- делей. О том, как это сделать, можно прочесть в главе 2.
Глава 2 Модель «сущность—связь»: методы и средства моделирования В настоящей главе рассматриваются методы и средства моделирования данных. Вначале дается описание тройственной схематической модели AN. I PARC С помощью этой модели разъясняются роль и место моделирования данных в про- цессе проектирования баз данных. Далее описывается модель «сущность-связь» в том виде, как она изначально была предложена. Как вы далее увидите, есть существенные соображения в пользу того, чтобы изучать эту модель именно в такой форме. Затем рассматривается более новая версия модели «сущность—связь» — модель IDEFX1, получившая наибольшее распространение в современной про- мышленности. В завершение главы вы узнаете, как модель «сущность—связь» была встроена в UML — технологию объектно-ориентированного программиро- вания. Усвоив описанные здесь модели и средства, в следующей главе вы сможете приступить к их практическому применению. Тройственная схематическая модель ANSI/SPARC Тройственная схематическая модель базы данных ANSI/SPARC, предложенная Комитетом по планированию и разработке требовании к стандартам (Standards Planning and Requirements Committee, SPARC) Американского национального института стандартов (American National Standards Institute, ANSI), была пер- вые опубликована в 1975 году. Несмотря на то, что эта модель уже довольно шара, с ее помощью исключительно удобно описывать роль и цели моделирова- ния данных. ачнем с определения схемы. Схема (schema) — это представление чего-либо, римерами схем могут служить чертежи здания, блок-схема алгоритма или объектная диаграмма. Три схемы, составляющие рассматриваемую нами модель, определяют три различных представления базы данных.
Тройственная схематическвя модель ANSI/SPARC 61 Внешняя, концептуальная и внутренняя схемы Модель ANSI/SPARC включает в себя три схемы — внешнюю, концептуальнуюи внутреннюю (рис. 2.1). Внешняя схема (external schema), называемая также поль- зовательским представлением (user view), описывает то, как пользователи пред- ставляют себе базу данных. Для всех баз данных, кроме простейших, внешняя схема отображает лишь часть реальной базы данных. Например, если вернуться к примеру с фирмой Lakeview, приведенному в главе 1, то с точки зрения торго- вых агентов внешняя схема базы данных содержала бы данные только из таблиц CONTRACTOR и RENTAL. Пользователи Рис. 2.1. Тройственная схематическая модель Концептуальная схема (conceptual schema) — это полное логическое представ- ление базы данных, включающее описание всех данных и связей между ними. С' юва «лшическос представление» имеют тот смысл, что концептуальная схема не aamiiui от конкретною способа хранения данных. Хранить концептуальную ' хему можно в базе данных, в файловом архиве, в виде набора связанных между собой э юкцюпных таблиц и другими способами. Одной концептуальной схеме обычно соответствует множество различных ’’Певших схем У фирмы Lakeview может быть одна внешняя схема для торговых агентов, ip\iая — для отдела маркетинга, третья — для бухгалтерии, и т. д. Внутренняя схема (internal schema) — это представление, описывающее фи- зическую реализацию концептуальной схемы с использованием конкретного ’’Ротукга и или технологии Описание набора таблиц, ключей, внешних ключей, ”н тексов и других физических структур представляет собой внутреннюю схему. °1и.т н та же концептуальная схема может быть представлена различными впут- Рснними схемами например, одна из них может быть тля Oracle, другая — для Эти две внутренние схемы могут быть очень похожими или совершенно Различными Для нас эти различия несущественны, лишь бы обе они алекват Мо отражали соответствующую концептуальную схеме (Ра имеется, если вести об эффективности обработки, одна внутренняя схема может иметь огром- преимущество ис|>ед другой )
62 гппвя 2. Модель «сущность-связы^мотодыи сре;щгвамоДОлирований Построение концептуальной схемы Почему все это так важно? Наша задача при создании модели данных состоит построить концептуальную схему. Однако пользователи не будут го- ворить с нами на языке этой схемы. Пользователи . оворят о данных с точки эре ния своей работы, то есть своего собственного представления (внешней схемы) дшХ Нашей же целью будет, взяв за отправную точку все эти внешние схемы, построить единую концептуальную схему, которая бы поддерживала каждое из заданных нам на входе пользовательских представлении. Не менее важно при создании концептуальной схемы четко отличать ее от внутренней схемы. Не следует смешивать физическое представление данных с. их логическим представлением. В противном случае мы придем к тому, что ха- рактеристики СУБД будут ограничивать и искажать наше видение концептуаль- ной модели. Из-за этого мы можем упустить из виду какой-то важный аспект в мире пользователей или, что еще хуже, позволить СУБД ограничивать свободу действий пользователей. Такого рода ограничения подобны хвосту, который ви- ляет собакой. Не хотелось бы, чтобы характеристики индексов СУБД определя- ли то, как торговые агенты должны осуществлять продажи! Разумеется, разработав концептуальную схему, мы вскоре можем обнару- жить, что нам придется так или иначе от нее отступить, дабы обеспечить ее эффективную реализацию во внутренней схеме. Но прежде чем мы приступим к модификации схемы, у нас, по крайней мере, будут зафиксированные в доку- ментальной форме требования пользователей, и мы будем идти на компромисс сознательно. Может статься, что потом, в результате более тщательного обдумы- вания или из накопленного опыта, нам все-таки удастся найти способ реализо- вать ту концептуальную схему, которая нужна пользователям. А может быть, это станет возможным благодаря новому продукту или новым возможностям уже существующего продукта. Поэтому, создавая концептуальные модели, старайтесь абстрагироваться от физических структур и элементов внутренней схемы. Вместо этого направьте своп усилия па то, чтобы предоставить пользователям нужные им внешние схе- мы, с помощью которых они могли бы успешно выполнять свою работу. За прошедшие годы было разработано огромное количество разнообразных методов, концепций и символьных систем для документирования концепту- । >ix моделей. Наиболее популярные из них базируются на модели «сущ- ность связь» — их л1ы и рассмотрим в этой и следующих главах. Альтернатпв- тпДНт10Д’ НОСЯ1ЦИИ пазвание семантической объектной модели (semantic object model), описывается в приложении Б. Сага о Брюсе и Зельде модшш^ассмо^ЯДН° проде“онстРиР°вать суть тройственной схематической изучением пек он'С РЮС0М ” Зельдой- Брюс — биолог, занимающийся хлорида бифенипа <РСтУСГ 3агряЗНенпе воды 11 берет пробы на наличие поли- I Да бифенила (РСВ) и других химических веществ. Несколько раз в году он
Тройственная схематическая модель ANSI/SPARC вВ объезжает реки и подсчитывает количество рыбы в них, так как эта статисти. счужит важным показателем благополучия речной среды. Результаты своя* исследований он заносит в специальную форму (рис 2.2), содержащую дайны* о реке и таблицу для записи количества рыбы. Рис. 2.2. Внешняя схема Брюса Зельда, зоолог, занимается изучением рыбы. Основываясь на полученных ею данных, агентства отдельных штатов и федерального уровня определяют квоты на ловлю рыбы, налагают запрет на вылов определенных пород и оценивают со- стояние здоровья различных видов рыбы. Для записи своих результатов Зельда также использует специальную форму (рис. 2.3). Она выбирает интересующий ее вид рыбы и заносит в таблицу данные по каждой реке, где встречает этот вид. Рис. 2.3. Внешняя схема Зельды
64 rn.Pa Z Модель «сущность-связь»: методы и <WWW Брюс и Зельда работают в одном унмверспгете, и однажды! пиверситет рч ет создать единую базу данных, в которой содержалась бы вся информации о р бе и реках Первым шагом в этом деле, как известно, является иш ервыоироьзиие пользователей, и вот некто назначает встречу с фюгом и Зельдои Встреча происходит приблизительно так. Начинает ра.ясвор Зельда. «Брюс, я посмотрела, как ты записываешь свои результаты (см. рис. 2.2) У тебя же все вывернуто наизнанку! Сперва нужно выбрать интересующую нас породу рыбы, а потом занести в таблицу данные о количестве экземпляров данной породы раз- личных реках». Брюс возражает: «Боюсь, Зельда, что формальдегид от твоих рыб ударилтебе в голову. Так никто не делает. Сначала надо выбрать определенную реку, а по- том для данной конкретной реки записать статистику по всем породам рыбы, ко- торые мы в ней обнаружим. Если бы я записывал свои данные так же, как это де- лаешь ты (см. рис. 2.3), это бы заняло у меня часы!» Однако Зельда не сдается: «Напротив, Брюс, это твои мыслительные способ- ности, похоже, пострадали от слишком большой дозы PC В. Если мы будем за- писывать результаты так, как предлагаешь ты...». Далее дебаты продолжаются в том же духе, и каждая из сторон доказывает, что именно ее способ записи явля- ется правильным. Хотите верьте, хотите нет, но на подобные споры были потра- чены тысячи, если не миллионы часов. Проблема, разумеется, состоит в том, что Брюс, и Зельда смотрят на одни и те же данные с совершенно разных позиций. При разговоре Брюса и Зельды присутствует концептуализатор Конрад. Взгля- нув на формы, представленные на рис. 2.2 и 2.3, он говорит себе: «Эти формы - не что иное, как взгляд на одни и те же данные с двух различных точек зрения, то есть две внешние схемы. Нельзя ли объединить их в одной концептуальной схеме?» Конрад приходит к выводу, что это сделать можно, и конструирует концепту- альную схему, показанную на рис. 2.4. Как вы помните, концептуальная схема — это полное логическое представление данных. Она будет содержать множество друшх элементов, помимо тех, что показаны здесь, но пока нам хватит и этого.
Модель «Сущность—связь» и ее варианты 65 Концептуальная схема Конрада (см. рис. 2.4) включает три различных труп- пы данных: РЫБА. РЕКА и НАБЛЮДЕНИЕ. Линии представляют связи между ними Обратите внимание, что с одной рекой потенциально может быть связано много наблюдений. То же самое справедливо и для рыбы. Теперь, если следовать подходу Брюса, мы сперва выбираем нужную нам ре- ку в группе РЕКА, затем в группе НАБЛЮДЕНИЕ находим записи обо всех наблюде- ниях, сделанных на данной реке, и из этих наблюдений получаем данные о коли- честве рыбы различных видов. Если потребуются какие-то дополнительные сведения о рыбе, помимо названия вида (столбцы Рыба и Название вида), мы возь- мем их из группы РЫБА. С точки же зрения Зельды, мы сначала выбираем интере- сующий нас вид рыбы в группе РЫБА, затем в группе НАБЛЮДЕНИЕ находим записи обо всех наблюдениях, где фигурирует данный вид, и из этих записей извлекаем название реки. Дополнительные сведения о реках, помимо их названий (столбцы Река и Название реки), можно взять из группы РЕКА. Концептуальная схема, изображенная на рис. 2.4, хороша для данного приме- ра, однако для построения реальной базы данных необходимо гораздо больше подробностей. Далее в этой главе мы рассмотрим методы и средства, которые ис- пользуются для представления таких концептуальных схем при проектировании реальных баз данных. Но прежде мы доведем до конца нашу историю. Конрад передаст свою кон- цептуальную схему Оливии — специалисту по Oracle. Оливия, исходя из схемы Конрада, создаст внутреннюю схему, или проект базы данных, для СУБД Oracle. Она спроектирует таблицы, определит ключи и внешние ключи, создаст индек- сы, выделит пространство под таблицы па физических носителях и примет ряд Других решений относительно структуры внутренней схемы. Затем она физически реализует созданную схему в виде базы данных и сопутствующих ей структур. Процесс проектирования и реализации описывается нами в главах 4, 5, 8,10 и И. Модель «сущность—связь» и ее варианты Модель «сущность—связь» (entity-relationship model, E-R model) представляет собой совокупность понятий и графических символов для пост роения концепту- альных схем. Модель «сущность—связь» была предложена Питером Ченом и опуб- ликована им в 1976 году. В своей статье Чен описал основные элементы модели. Позже к этой модели были добавлены подтипы (речь о которых пойдет далее). Результатом чего стала расширенная модель «сущность—связь» (extended E-R wodel). На сегодняшний день, как правило, когда говорят о модели «сущность— связь», имеют в виду именно расширенный ее вариант. Версии модели «сущность—связь» Идеи, лежащие в основе расширенной модели «сущность—связь», были взяты на ВооРУЖение широким кругом профессионалов в области моделировав ня данных и проектирования баз данных, и сегодня почти все проекты по моделированию
66 Глава 2 Модель «сущность-связь, методы и средства мц данных используют ту или ннх^^Хшдя назваХ (information гадш.-гШй. IE), была ра.рабоган. Дж^м™, Май™ “о“ п 1990 Опа ми.м1Ю «... рагпроггр»...-... » «шремяжой »|». мышленности. и мы не будем рассматривать се далее . В 993 году Национальный институт стандартен, и технологии (National Institute of Standards and Technology) анонсировал еще одну версию модели «сущность-связь» в качестве национального стандарта Ш иная я ,х Л получила название IDEF1X. что расшифровывается как «Integrated Def.n.twn 1, Extended» - «Единый стандарт, версия 1, расширенная». Этот стандарт включает в себя основные идеи модели «сущность-связь», но использует для их представ- ления другие графические символы. В стандарте IDEF1X предусмотрены сред- ства для разработки как концептуальных, так и внутренних схем, а также методы преобразования первых во вторые. На этом, однако, путаница не кончается. Новая объектно-ориентированная модель разработки под названием UML (Universal Modeling Language - универ- сальный язык моделирования) также взяла за основу модель «сущность—связь», но при этом ввела свои собственные символы и привнесла объектно-ориентиро- ванную специфику. В конечном счете мы имеем исходную модель «сущность—связь», расширен- ную модель «сущность—связь», информационную инженерию, национальный стандарт IDEF1X и UML. Эту ситуацию можно заклеймить как абсурдную (тако- вой она в действительности и является), однако тем самым мы не сможем в ней ничего изменить. Вопрос звучит так: что мы со всем этим будем делать? Выбор версии модели Проще всего было бы вскинуть руки и сказать: «Чем связываться со всеми этими версиями, давайте лучше сосредоточимся на расширенной модели „сущность- связь", а остальные версии рассмотрим потом, если понадобится». Проблема за- ключается в том, что когда модель IDEF1X стала национальным стандартом, компании, занимавшиеся разработкой средств для моделирования данных, были вынуждены обеспечить соответствие своих продуктов этому стандарту, чтобы иметь возможность продавать их правительственным учреждениям. Игнориро- вать такой большой рынок было бы непростительно, поэтому большинство попу- лярных в настоящее время программных продуктов для моделирования данных, иащ^мер, ERWin и Visio, используют IDEF1X. А это значит, что именно с верси- ей 1DEF1X вам, вероятнее всего, придется сталкиваться в вашей практике, и даже чаще, чем с расширенной моделью «сущность—связь», В то же время, растущая популярность объектно-ориентированной системной разра отки и объектно-ориентированного программирования дала толчок рас- пространению ML. Однако изначально UML предназначался в первую очередь для моделирования процессов и программ, и, по мнению многих, он пока не го- тов к использованию в качестве полноценного средства моделирования данных, олжно пройти еще какое-то время, прежде чем UML достигнет той стадии эре-
Расширенная модель «сущность—связь» 67 пости, па которой находятся модель 1DEF1X и информационная инженерия Кроме того, если вы не знакомы с концепциями обьекгно ориентированного программирования, UML может оставить у вас странное впечатление. По правде говоря, какое бы решение мы ни приняли в .ной ситуации, оно все равно будет неудовлетворительным. Тем нс менее, наш подход будет таков ша- ппе классической расширенной модели «сущность- связь» необходимо, потому что содержащиеся в пей идеи и символы лежат в основе всех без исключения версий, а также потому, что данная модель столь широко распространена в про- мышленности. К несчастью, без знания модели 1DEF1X также не обойтись, по- скольку вам наверняка придется работать со средствами моделирования данных, а они по большей части следуют именно этой версии. Ну и, наконец, следует по крайней мере ориентироваться в символах, используемых в UML. Исходя из вышесказанного, структура этой главы будет такова. Сначала будет описана расширенная модель «сущность—связь» в ее классическом варианте. Далее мы представим версию IDEF1X, которая не только использует другие сим- волы, но и по-другому классифицирует связи. В заключительном разделе главы будет вкратце рассмотрено использование модели «сущность—связь» в UML. В оставшейся части книга будет использоваться либо расширенная модель «сущность—связь», либо стандарт IDEF1X. Хотя временами это будет затруд- нять изложение, мы не видим другого способа хорошо подготовить вас к реше- нию задач, с которыми вы можете столкнуться в ходе вашей будущей карьеры. Расширенная модель «сущность—связь» Ключевыми элементами модели «сущность—связь» являются сущности, атрибу- ты, идентификаторы и связи. Рассмотрим каждый из них по очереди. Сущности Сущность (entity) — это некоторый объект, идентифицируемый в рабочей среде пользователя, нечто такое, за чем пользователь хотел бы наблюдать. Примера- ми сущностей могут служить СОТРУДНИК Мэри Доу, КЛИЕНТ 12345, ЗАКАЗ 1000, ПРОДАВЕЦ Джон Смит или ПРОДУКТ А4200. Сущности одного и того же типа группи- руются в классы сущностей (entity classes). Так, класс сущностей СОТРУДНИК явля- ется совокупностью всех сущностей СОТРУДНИК. В тексте книги классы сущно- стей обозначаются заглавными буквами. Важно уяснить разницу между классом сущностей и экземпляром сущности. 'асе сущностей — это совокупность однотипных сущностей, и описывается он структурой или форматом сущностей, его составляющих. Экземпляр сущности ()Cnt,ty “’Stance) представляет конкретную сущность, такую как КЛИЕНТ 12345; он ^исывается значениями атрибутов данной сущности. Обычно класс сущностей Держит множество экземпляров сущности. Например, класс КЛИЕНТ содержит
68 Глава 2 Модель «сущность—-связь» методу и йЭбд< im множество экземпляров — но одному ид каждого клиента, о запись в базе данных. Пример класса сущностей и двух »кземиляров < показан па рис. 2.5. Рис. 2.5. КЛИЕНТ; пример сущности Атрибуты У сущностей есть атрибуты (attributes), или, как их иногда называют, с< (properties), которые описывают характеристики сущности. Примерами атрибу- тов могут служить ИмяСотрудника, ДатаНайма и КодКвалификации. В тексте этой книги для записи имен атрибутов используются как прописные, так и строчные буквы. В модели «сущность—связь» предполагается, что все экземпляры данного класса сущностей имеют одинаковые атрибуты. Исходное определение модели «сущность—связь» включает в себя коэшо- зитные атрибуты (composite attributes) и многозначные атрибуты (multi-valued attributes). В качестве примера композитного атрибута можно привести атрибут Адрес, состоящий из группы атрибутов {Улица, Город, Штат. Индекс}. Примером многозначного атрибута может служить атрибут ДоверенноеЛицо сущности КЛИЕНТ, который может содержать имена нескольких доверенных лиц данного клиента Атрибут может быть одновременно и композитным, и многозначным — нап мер, композитный атрибут Телефон, состоящий из группы атрибутов {КодРе МестныйНомер}, будучи многозначным, позволяет иметь в базе данных нес ко телефонных номеров одного и того же лица. В большинстве версий м «сущность—связь» однозначные композитные атрибуты игнорируются, и '
Расширенная модель «сущность—связь» ется, чтобы многозначные атрибуты (будь они составные ИЛИ чет) иреобразовы вались в сущности, как будет показано ниже. Идентификаторы Экземпляры сущностей имеют идентификаторы (identifiers) — атрибуты, с по мощыо которых эти экземпляры именуются, или идентифицируются. Например, экземпляры сущностей класса СОТРУДНИК могут идентифицироваться по атри- бутам НомерСоциальнойСтраховки, ТабельныйНомерСотрудника или ИмяСотрудника. Такие атрибуты, как Зарплата или ДатаНайма, вряд ли могут служить идентифика- торами экземпляров сущностей класса СОТРУДНИК, поскольку обычно эти атри- буты не способны однозначно указать на конкретного сотрудника. Точно так же сущности класса КЛИЕНТ могут идентифицироваться по атрибутам НомерКлиента или ИмяКлиента, а сущности класса ЗАКАЗ могут идентифицироваться по атрибуту НомерЗаказа. Идентификатор экземпляра сущности состоит из одного или более атрибутов сущности. Идентификатор может быть уникальным (unique) либо неуиикальчым (nonunique). Если идентификатор является уникальным, его значение будет указы- вай. на один и только один экземпляр сущности. Если идентификатор является неуинкальным, его значение будет указывать па некоторое множество экземпляров. ТабельныйНомер является, скорее всего, уникальным идентификатором, а ИмяСо- грудника — неуинкальным (например, может быть несколько сотрудников по имени Джон Смит) Идентификаторы, состоящие из нескольких атрибутов, называются компо- зитными идентификаторами (composite identifiers). Примерами могут служить идентификаторы вида {КодРегиона, МестныйНомер}, {НазваниеПроекта, НазваниеЗа- дачи} и {Имя, Фамилия, ДобавочныйНомерТелефона}. Связи Взаимоотношения сущностей выражаются связями (relationships). Модель «сущ- ность-связь» включает в себя классы связей п экземпляры связей1. Классы свя- зей (relationship classes) выражают взаимоотношения между классами сущностей, а экземпляры связи (relationship instances) — взаимоотношения между экземпля- рамп сущностей. У связей могут быть атрибуты. Класс связей может соединять несколько классов сущностей. Число классов 'УЩностей, участвующих в связи, называется степенью связи (relationship degree). Изображенная на рис. 2.6. а связь ПРОДАВЕЦ—ЗАКАЗ имеет степень 2, поскольку в ней участвуют два класса сущностей — ПРОДАВЕЦ и ЗАКАЗ. Связь РОДИТЕЛЬ на OTFi 2 6’ ' имсет степень 3-так как в ней участвуют три класса сущностей — МАТЬ, Ч и РЕБЕНОК Связи степени 2 весьма распространены, их часто называют еще и,трными связями (binary relationships). 1 Дл1 очи!^”*”™ мы С>дем и,,огда «пускать слово экзелнияр в тех случаях, когда из контекста будет ндно, что подразумевается именно экземпляр сущности, а не класс сущностей
—- гя«чь. методы и средстве мо, 70 глава 2 Модель «сущность-свя ь------------------- . МАТЬ РЕБЕНОК j ОТЕЦ*) -^редлтЕль ПРОДАВЕЦ—ЗАКАЗ ЗАКАЗ б стопный связей а — связь степени 2,6 — связь степени 3 Рис. 2.6. Различные степени связей, а Три типа бинарных связей На рис. 2.7 °™„™“ap“ тХ На рис. 2.7, а связь СЛУЖЕБНЫЙ-АВТОИОБИЛЬ связывает конкретного сотрудника с конкретным автомобилем. Согласно этой диа. ...у» ни за одним сотрудником не закреплено более одного автомобиля, и ни один ав- томобиль не закреплен более чем за одним сотрудником. СЛУЖЕБНЫЙ_АВТОМОБИЛЬ а ОБЩЕЖИТИЕ—ЖИЛЕЦ б СТУДЕНТ—КЛУБ в Рис. 2.7. Три типа бинарных связей: а — 1:1; б — 1:N; в — N:M На рис. 2.7, б изображен второй тип связи, 1:N («один к N» или «один ко мно- гим»), В этой связи, которая называется ОБЩЕЖИТИЕ—ЖИЛЕЦ, единичный экзем- пляр сущности класса ОБЩЕЖИТИЕ связан со множеством экземпляров сущности класса СТУДЕНТ. В соответствии с этим рисунком, в общежитии проживает много студентов, но каждый студент живет только в одном общежитии. Важна позиция, в которой стоят 1 и N. Единица стоит на той стороне связи, где располагается ОБЩЕЖИТИЕ, a N стоит на той стороне связи, где располагается СТУДЕНТ. Если бы мы поменяли местами 1 и N и записали бы эту связь как N't, получилось бы, что в общежитии проживает всего один студент, причем студент может жить в нескольких общежитиях. Это, разумеется, не так. На рис. 2.7, в показан третий тип бинарной связи. N;M (читается «N к М» мл» «многие ко многим»). Эта связь называется СТУДЕНТ-КЛУБ, и она связывает эскл
Расширенная модель «сущность—связь» 71 пляры сущностей класса СТУДЕНТ с экземплярами сущностей класса КЛУБ. Один студент может быть членом нескольких клубов, а в одном клубе может состоять много студентов. Числа внутри ромба, символизирующего связь, обозначают максимальное ко- личество сущностей на каждой стороне связи. Эти ограничения называются мак- симальными кардинальными числами, а совокупность из двух таких ограничений для обеих сторон связи называется максимальной кардинальностью (maximum cardinality) связи. Например, о связи, изображенной на рис. 2.7, б, говорят, что она обладает максимальной кардинальностью 1:N. Кардинальные числа могут иметь и другие значения, а не только 1 и N. Например, связь между сущностями БАСКЕТБОЛЬНАЯ.КОМАНДА и ИГРОК может иметь кардинальность 1:5, что говорит нам о том, что в баскетбольной команде может быть не более пяти игроков. Связи трех типов, представленных на рис. 2.7, называются иногда связями типа «ИМЕЕТ», или связями принадлежности (HAS-A relationships). Например: сотрудник имеет автомобиль, студент имеет общежитие, клуб имеет студентов. Диаграммы «сущность—связь» Схемы, изображенные на рис. 2.7, называются диаграммами «сущность—связь» (entity-relationship diagrams, ER-diagrams). Как в оригинальной, так и в расширен- ной модели «сущность—связь» классы сущностей обозначаются прямоугольни- ками, связи обозначаются ромбами, а максимальное кардинальное число каждой связи указывается внутри ромба1. Имя сущности указывается внутри прямо- угольника, а имя связи указывается рядом с ромбом. В других версиях модели используются другие символы, как вы увидите позже. Как мы уже говорили, максимальная кардинальность показывает максималь- ное число сущностей, которые могут участвовать в связи. Каково же минималь- ное число таких сущностей, приведенные диаграммы не сообщают. Например, рис. 2.7, б показывает, что студент может проживать максимум в одном обще- житии, однако из него не ясно, обязан ли студент проживать в каком-либо об- щежитии. Для указания минимальной кардинальности (minimum cardinality) существует несколько способов. Одни из них, продемонстрированный на рис. 2.8, заключает- ся в следующем: чтобы показать, что сущность обязана участвовать в связи, на чинию связи помещают перпендикулярную черту, а чтобы показать, что сущность может (но не обязана) участвовать в связи, на линию связи помещают овал. Со- 1Ч " тленно, рис. 2.8 показывает, что сущность ОБЩЕЖИТИЕ должна быть связана как минимум с одной сущностью СТУДЕНТ, однако сущность СТУДЕНТ не обязана мет связь с сущностью ОБЩЕЖИТИЕ. Полный набор накладываемых на связь ограничений состоит в том, что ОБЩЕЖИТИЕ имеет минимальное кардинальное щт5Ываемые здесь графические символы, которые берут начало в этой модели, не являются луч- Мас По^°0°| отображения модели в системе с графическим интерфейсом пользователя, подобной ‘ntoeh или Microsoft Windows. Фактически модель «сущность-связь» была разработана задолго *» L'Mi КаК ка|<ая-либо система графического интерфейса приобрела популярность Символы язы- *- которые будут представлены позже в этой главе, легче использовать в графической среде
72 Глява2. Модель сущиосм.-сдзь.: методы и cp««eT»a модепиооции. павное единице, и максимальное кардинальное число. р« «многим. Хост» СТУДЕНТ. СТУДЕНТ имеет минимальное кардинальное число раним ну. Х и максимальное кардинальное число, рапное одному экземпляру сутаж, 3 ОБЩЕЖИТИЕ. [ ОБЩЕЖИТИЕ JO—<l:N>—Н СТУДЕНТ ПРОЖИВАНИЕ Рис. 2.8. Связь с указанной минимальной кардинальностью Может существовать связь между сущностями одного и того же класса. На- пример, для сущностей класса СТУДЕНТ может быть определена связь СОСЕД_ПО_ КОМНАТЕ. Такая связь показана на рис. 2.9, а, а на рис. 2.9, б изображены экземпля- ры сущностей, охваченных этой связью. Связи между сущностями одного и того же класса называются иногда рекурсивными связями (recursive relationships). Рис. 2.9. Рекурсивная связь Изображение атрибутов на диаграммах «сущность-связь» 1псам1°со^иТИЯХ ДИаГРаММ ^У^^ь-связь, атрибуты обозначаются эл- оис 2 10 иными с сущностью или связью, которой они принадлежат На 0Б“,ЕЖ,,™Е " ™ЯЕНТ ” 06ЩЕЖИГиТ-^ЕЦ с имеет атрибуты Название^ УТаМИ‘ Как вндно из Рисунка, сущность ОБЩЕЖИТИЕ СТУДЕНТ имеет атрибуты нХрТтудентГимяГ^6 “ Ko™4ecTBoKoMHaT’ а сущность ЖИЛЕЦ имеет атрибут ПпЯта J У J ’ ИмяСтудента и Курс. Связь ОБЩЕЖИТИЕ- проживание в конкретном общежитииП°КаЗЫВаеТ ВНесенНуЮ «удентом плату за
73 Расширенная модель «сущность—cnw Если сущность имеет много атрибутом, такое их перечисление на диаграмм» может сделать ее чересчур громоздкой и трудной для восприятия В других вер- сиях модели, как вы увидите далее, атрибуты отображаются по-другому Рис. 2.10. Изображение свойств на диаграммах «сущность—связь» Слабые сущности В модели «сущность—связь» определен особый тип сущности, называемый сла- бой сущностью (weak entity). К слабым сущностям относятся такие сущности, которые могут существовать в базе данных только в том случае, если в ней при- сутствует сущность некоторого другого типа. Сущность, не являющаяся слабой, называется сильной сущностью (strong entity). Чтобы разобраться в том, что такое слабые сущности, рассмотрим базу данных отдела кадров с классами сущностей СОТРУДНИК и ПОДЧИНЕННЫЙ. Предположим, существует правило, что экземпляр сущности СОТРУДНИК может существовать не будучи связанным ни с одной сущностью класса ПОДЧИНЕННЫЙ, но сущность ПОДЧИНЕННЫЙ не может существовать вне связи с какой-либо сущностью клас- са СОТРУДНИК. Тогда сущность ПОДЧИНЕННЫЙ является слабой. Это означает, что запись о сущности ПОДЧИНЕННЫЙ может появиться в базе данных только в том случае, если эта сущность имеет связь с какой-либо сущностью класса СОТРУДНИК. Как показано на рис. 2.11, а, слабые сущности обозначаются прямоугольника- ми со скругленными углами. Кроме того, связь, от которой зависит существова- ние сущности, обозначается ромбом со скругленными углами. В некоторых диа- граммах (здесь не показано) прямоугольники для слабых сущностей рисуются Двойной линией, а связи, от которых зависит существование этих сущностей, изображаются двойными ромбами. В модели «сущность—связь» имеется особый тип слабых сущностей, назы- ваемый идентификационно-зависимыми сущностями (ID-dependent entities). Это такие сущности, идентификаторы которых содержат идентификатор другой сущ- ности. Рассмотрим сущности ДОМ и КВАРТИРА. Пусть идентификатором сущно- сти ДОМ является атрибут НазваниеДома, а идентификатором сущности КВАРТИРА является композитный идентификатор {НазваниеДома, НомерКвартиры). Поскольку ‘’верификатор сущности КВАРТИРА содержит в себе идентификатор сущности й М НазваниеДома, то сущность КВАРТИРА является идентификационно-зависи- мой от сущности ДОМ Сравните рис. 2.11, б с рис. 2,11, а. По-другому можно
74 Глава 2. Модель «сущность связь». методы и средства модели представить это таким образом, что как леи ГХеу.№-™,ш,..еея.,,.осу1пое™уСТ очески, так и фи мчески ква|: соответствующее здание СОТРУДНИК Идентификатор: НомерСотрудника 1 N ПОДЧИНЕННЫЙ Идентификатор НомерСоциальнойСтраховки ДОМ 1N КВАРТИРА ] а Идентификатор: НазваниеДома Идентификатор- {НазваниеДома, НомерКвартиры} Рис. 2.11. Слабые сущности: а — идентификационно-независимая, б — идентификационно-зависимая Идентификационно-зависимые сущности встречаются часто. Еще одним приме- ром может служить сущность ВЕРСИЯ в связи с сущностью ПРОДУКТ, где ПРОДУКТ — это некоторый программный продукт, а ВЕРСИЯ номер его версии. Идентифи- катором продукта является атрибут НазваниеПродукта, а идентификатором вер- сии является совокупность {НазваниеПродукта, НомерВерсии}. Третий пример - это связь между сущностями ИЗДАНИЕ и УЧЕБНИК. Идентификатором сущности УЧЕБНИК является атрибут Заглавие, а идентификаторов! издания является сово- купность {Заглавие, ПорядковыйНомерИздания}. К сожалению, в определении термина слабая сущность есть скрытая неодно- значность, и она по-разному интерпретируется в различных версиях модели «сущность—связь» и программных продуктах для моделирования данных. Эта неоднозначность заключается в следующем: в строгом смысле слабая сущность определяется как любая сущность, чье присутствие в базе данных зависит от дру- гой сущности; тогда любая сущность, участвующая в связи минимальной карди- нальности 1 с другой сущностью, является слабой. Таким образом, рассматривая базу данных образовательного учреждения, можно заключить следующее: если у студента должен быть руководитель, то сущность СТУДЕНТ является слабой, поскольку она не может быть записана в базу данных без связи с какой-либо сущностью класса РУКОВОДИТЕЛЬ. Некоторые, однако, считают это толкование чересчур широким. Студент физически не зависит от руководителя (в отличие 01 случая с квартирой и домом), как не зависит от него и логически (что бы по этому поводу ни думали студент и руководитель!), поэтому сущность СТУДЕНТ должна считаться сильной сущностью. нмр^п ГЫ "зЕ)сжа1ь подобных ситуаций, некоторые интерпретируют определе- к па-иЛл011 Су'дности олее ограниченно. Чтобы сущность можно было отнести данномУл^ Х’ °На Д°ЛЖНа Логически зависеть от другой сущности Согласно ?лабьши я даЛеНИЮ;^Х°СТИ П°ДЧИНЕННЫЙ и КВАРТИРА должны считаться слабыми, а сущность СТУДЕНТ - нет. Подчиненный не был бы подчиненным.
Расширенная модель «сущность - еспи бы не находился в подчинении у кого-то, а квартира не может существам» без здания, в котором она могла бы располагаться. Студент же может логически существовать и без руководителя, даже если бизисс-нравила этого не допускают Чтобы проиллюстрировать эту интерпретацию, рассмотрим несколько при- меров. Пусть у нас имеется связь между сущностями ЗАКАЗ и АГЕНТ (рис 2 12, а) Хотя можно было бы потребовать, чтобы для каждого заказа указывался агеН1 его обрабатывающий, в действительности это не всегда необходимо (заказ может быть, к примеру, продажей за наличные, при которой имя агента не записывает- ся). Следовательно, минимальное кардинальное число, равное 1, проистекает из бпзнес-правил, а не из логической необходимости. Таким образом, сущность ЗАКАЗ, хотя и требует наличия сущности АГЕНТ, не зависит от существования последней, поэтому ЗАКАЗ следует рассматривать как сильную сущность. а б [ НАЗНАЧЕНИЕ —Н] ПРОЕКТ | Идентификатор: Идентификатор: {НазваниеПроекта, НазваниеПроакта НаэваниеЗадачи) Рис. 2.12. Примеры обязательных сущностей Теперь рассмотрим связь между сущностями ПАЦИЕНТ и РЕЦЕПТ, изображен- ную на рис. 2.12, 6. Здесь рецепт не может логически существовать без пациента. Следовательно, помимо того, что минимальное кардинальное число сущности РЕЦЕПТ равно 1, эта сущность также зависит от существования сущности ПАЦИЕНТ Отсюда следует, что РЕЦЕПТ — это слабая сущность. Наконец, рассмотрим сущ- ность НАЗНАЧЕНИЕ, изображенную на рис. 2.12, в. Идентификатор этой сущно- сти содержит идентификатор сущности ПРОЕКТ. Здесь, кроме того, что сущность НАЗНАЧЕНИЕ имеет минимальную кардинальность 1 и зависит от существования сущности ПРОЕКТ, она является еще и идентификационно-зависимой от послед- ней, поскольку ее ключ содержит ключ сущности ПРОЕКТ. Таким образом, сущность НАЗНАЧЕНИЕ является слабой. В этой книге мы определяем слабые сущности как логически зависящие от существования другой сущности. Следовательно, не все сущности, имеющие ми- ««мальную кардинальность 1 в связи с другой сущностью, являются слабыми ЗДько логически зависимые сущности квалифицируются нами как слабые. Это но1>еДеЛеПИе также подразумевает, что слабыми являются все идентификацион- зависимые сущности. Кроме того, любая слабая сущность имеет минимальное
76 Глава 2. Модель .сущнос.ь-связь» "Д— i rntnil С CVIlUIOCIblO, от коюрои 34ИИСИ1, ИО П|«и карднналыкх' число в У шпальным чис лом, равным 1, взятая сущностьс минимальным кирдпи.инным ' должна быть слабой. Представление многозначных атрибутов при помощи идентификационно-зависимых сущностей Многозначные атрибуты представляю™ я модели .гущоость-сняг». „уызозд. ™™,o»ii .и.втифика.и.ошю-эаи.,сомой сушина» » ПМЧИОИШ еввзн с М вХодов ко многом.. В качестве промера на рис. 2.13, о "I*" — пение многозначного атрибута ДоверенноеЛицо сущности КЛИЕНТ Создастся и», вая сущность под именем ДОВЕРЕННОЕЛИЦО с единственным атрибутом Довере» ноеЛицо Связь между сущностями ДОВЕРЕННОЕЛИЦО и КЛИЕНТ имеет вид -лил ко многими. Созданная таким образом сущность должна быть идентификацион- но-зависимой, поскольку она должна содержать идентификатор сущности, име- ющей многозначный атрибут. На рис. 2.13, б изображено представление многозначного композитного атри- бута Адрес. Новая слабая сущность АДРЕС содержит всю совокупность атрибутов, а именно атрибуты Улица, Город, Штат и ПочтовыйИндекс. КЛИЕНТ содержит. Номер Клиента прочие атрибуты... КЛИЕНТ ДОВЕРЕННОЕ_ЛИЦО ] ДОВЕРЕННОЕЛИЦО содержит ДоверенноеЛицо а КЛИЕНТ АДРЕС 1:N КЛИЕНТ содержит: НомерКлиента прочие атрибуты . АДРЕС содержит: Улица Город Штат Индекс Рис. 2.13. Представление б многозначных атрибутов с помощью слабых сущностей Подтипы сущностей Некоторые сущности имеют необязательные наборы атрибутов; эти сущности часто представляются с помощью подтипов (subtypes)1. Рассмотрим, например, сущность КЛИЕНТ с атрибутами НомерКлиента, ИмяКлиента и СуммаКОплате. Пред- положим, что клиент может быть физическим лицом, товариществом или корпо- рацией и что необходимо указывать некоторую дополнительную информаинкх зависящую от типа клиента. Пусть эта информация имеет следующее содержаний 1 Подтипы были добавлены в модель «сущность связь» после публикации 6рппша.чыюй статьи 4W*. и они являются частью того, что называется расширенной моделью «сущность-сжик* ’
Расширенная модель «сущность—связь» 77 фИЗИЧЕСКОЕ_ЛИЦО: Адрес, НомерСоциальнойСтраховки ТОВАРИЩЕСТВО: ИмяУправляющегоПартнера, Адрес, ИдентификационныйНалоговыйНомер КОРПОРАЦИЯ: КонтактноеЛицо, Телефон, ИдентификационныйНалоговыйНомер Одна из возможностей — отнести все эти атрибуты к сущности КЛИЕНТ, как показано на рис. 2.14, а. В этом случае, однако, некоторые атрибуты будут непри менимы. Например, такой атрибут, как имя управляющего партнера, не имеет смысла для индивидуального или корпоративно! о клиента, и, таким образом, он нс может иметь какое-либо значение. КЛИЕНТ содержит: НомерКлиента ИмяКлиента СуммаКОплате Адрес НомерСоциальнойСтраховки ИмяУправляющегоПартнера ИдентификационныйНалоговыйНомер ДоверенноеЛицо Телефон КЛИЕНТ содержит: НомерКлиента ИмяКлиента СуммаКОплате ФИЗИЧЕСКОЕ_ЛИЦО содержит: Адрес НомерСоциальнойСтраховки ТОВАРИЩЕСТВО содержит: ИмяУправляющегоПартнера Адрес ИдентификационныйНалоговыйНомер КОРПОРАЦИЯ содержит: ДоверенноеЛицо Телефон ИдентификационныйНалогоаыйНомер б ₽Мс- 2.14. Подтипы сущностей: а — КЛИЕНТ без подтипов; б — КЛИЕНТ с подтипами, в - невзаимоисключающие подтипы с необязательным надтипом
78 Глава 2. Модель «сущность—связь»: методы и средства модели. В модели, более близкой к реальной ситуации, вместо этою будут определены три сущности-подтипа, как показано на рис. 2 14, 6. Здесь сущности ФИЗИЧЕСКОЕ ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ изображены как подтипы сущности КЛИЕНТ Последняя, в свою очередь, является подтипом (supertype) для сущностей ФИЗИЧЕСКОЕ_ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ. Символ е рядом с линиями связи указывает, что сущности ФИЗИЧЕСКОЕ_ЛИЦО. ТОВАРИЩЕСТВО и КОРПОРАЦИЯ являются подтипами сущности КЛИЕНТ. Каждый подтип должен принадлежать надтипу КЛИЕНТ. Кривая линия с цифрой 1 рядом показывает, что сущность КЛИЕНТ должна принадлежать к одному и только одно- му подтипу. Это означает, что подтипы являются взаимоисключающими и что требуется только один из них. Сущности со связью типа «ЕСТЬ» должны иметь один и тот же идентифика- тор, поскольку они представляют различные аспекты одного и того же. В данном случае таким идентификатором является НомерКлиента. Сравните эту ситуацию со связью типа «ИМЕЕТ», показанной на рис. 2.7, где сущности представляют разные вещи и поэтому имеют разные идентификаторы. Иерархии обобщений имеют специальную характеристику, называемую на- следованием (inheritance), которая означает, что подтипы классов сущностей на- следуют атрибуты от надтипа. Сущность ТОВАРИЩЕСТВО, к примеру, наследует атрибуты ИмяКлиента и СуммаКОплате от сущности КЛИЕНТ. Причины, по которым подтипы используются в моделировании данных, от- личаются от причин, по которым они используются в объектно-ориентирован- ном программировании. Фактически в модели данных они применяются с един- ственной целью: избежать ситуаций, при которых некоторые атрибуты должны иметь нулевые значения. Например, если атрибуту НомерСоциальнойСтраховки на рис. 2.14, а присвоено значение, то остальные четыре атрибута должны быть равны нулю. Эта ситуация наиболее ярко проявляется в медицинских приложени- ях: представьте себе, например, что пациенту мужского пола задается вопрос о ко- личестве беременностей. Нулевые значения более детально обсуждаются в главе 5. Пример ER-диаграммы На рис. 2.15 показан пример диаграммы, содержащей все элементы модели «сущ- ность-связь», о которых шла речь до сих пор. Она изображает сущности и связи для инженерной консалтинговой компании, которая занимается анализом строи- тельства и состояния жилых домов, а также других зданий и сооружений. На диаграмме есть класс сущностей, представляющий сотрудников компа- нии. Поскольку некоторые сотрудники являются инженерами, сущность ИНЖЕНЕР связана с сущностью СОТРУДНИК как подтип. Каждый инженер должен быть со- трудником. Сущность ИНЖЕНЕР имеет связь 1:1с сущностью ГРУЗОВИК: каждый грузовик должен быть закреплен за каким-то инженером, но не у всех инжене- ров есть грузовики.
Расширенная модель «сущность—связь- 79 КЕМ_ПРИВЕДЕН Рис. 2.15. Пример диаграммы «сущность—связь» Инженеры выполняют работы (сущность РАБОТА) для клиентов (сущность КЛИЕНТ). Инженер может не выполнять никаких работ (иначе говоря, выполнять ноль работ) или выполнять много работ, но каждая отдельно взятая работа мо- жет выполняться только одним конкретным инженером. Для одного и того же клиента может выполняться много различных работ, и один и тот же вид работы может выполняться для множества клиентов. Клиент должен оплатить по меньшей мере одну работу, но различные виды работ существуют независимо от клиентов. Связь КЛИЕНТ—РАБОТА имеет атрибут Плата, который показывает сумму, упла- ченную конкретным клиентом за конкретную работу. (Прочие атрибуты сущно- стей и связей не показаны на этой диаграмме.) Иногда одни клиенты приводят других, что показывается с помощью рекур- сивной связи КЕМ_ПРИВЕДЕН. Клиент может привести одного или нескольких Других клиентов. Клиент не обязан быть приведен другим клиентом, но каждого клиента может привести только один клиент. Сущность СЕРТИФИКАЦИЯ_ИНЖЕНЕРА показывает, что данный инженер полу- чил образование и прошел тестирование, требуемое для получения конкретно- Го сертификата. Инженер может иметь сертификаты (сущность СЕРТИФИКАТ). Существование сущности СЕРТИФИКАЦИЯ_ИНЖЕНЕРА зависит от сущности ИНЖЕНЕР Через связь ИНЖЕНЕР—КВАЛИФИКАЦИЯ. СЕРТИФИКАТ - это сущность, описываю- Щая конкретный сертификат.
80 Глава 2 Модель «сущность—связь»: методы и средства моделирования Стандарт IDEF1X Как уже говорилось, модель IDEF1X, представляющая собой модификацию модели -сущность—связь», была объявлена национальным стандартом США в 1993 году Ее основу составляют работы, выполнявшиеся в середине 1980-х годов для нужд военного ведомства. Имея модель «сущность—связь» в качестве фундамента, стан дарт IDEF1X расширяет ее в ряде аспектов, благодаря чему сею помощью стано- вится возможным создавать как концептуальные, так и внут ренние схемы По пово- ду создаваемой базы данных стандарт предполагает, что она является реляционной Стандарт IDEF1X включает сущности, связи и атрибуты, но значения этих понятий в нем сужены, а для их определения применяется более точная термино- логия Кроме того, в IDEF1X введено понятие домена (domain), отсутствующее в расширенной модели «сущность—связь». Наконец, в стандарте IDEF1X претер- пел изменения набор графических символов: в частности, был изъят ромб, а для обозначения категорий (отвечающих иерархиям обобщений и подтипам в расши- ренной модели «сущность—связь») были добавлены новые символы. Различия меж- ду расширенной моделью «сущность—связь» и моделью IDEF1X описаны в табл. 2.1 Таблица 2.1. Соответствие понятий расширенной модели «сущность—связь» и стандарта 1DEF1X Термин расширенной модели «сущность- связь») Термин модели IDEF1X Примечания Сущность Сущность Одно и то же Атрибут Атрибут Одно и то же Связь Связь Одно и то же Связи 1:1 и 1:N Связь N М Идентификационно- зависимая связь Слабая, но не идентификационно- зависимая сущность Неидентифицирующие связи принадлежности Неспецифическая связь Идентифицирующая связь принадлежности Связь принадлежности — это то же, что и связь типа «ИМЕЕТ» Сущность надтипа Порождающая сущность Порождающая сущность имеет связь типа «ЕСТЬ» с категориальным кластером Сущность подтипа Сущность-категория Домен Сущности-категории, принадлежащие к одному категориальному кластеру, являются взаимрисклк)ч£1рщими Сущности В IDEF1X Под сущностью в IDEF1X понимается то же самое, что и в расширенной модели «сущность—связь». Это может быть любая вещь, данные о которой пользователи хотели бы отслеживать. Как и в расширенной модели «сущность—связь», сущно-
Стандарт IDEF1X 81 стн изображаются и виде прямоугольников с прямыми или закругленными угла- ми, хотя прямоугольники с закругленными углами имеют в IDEF1X несколько иное значение (об этом речь пойдет позже, при обсуждении идентифицирующих связей). Сущности могут изображаться без атрибутов (рис. 2.16, а), с указанием толь- ко тех атрибутов, которые составляют первичный ключ (рис 2.16, б), или с указа- нием всех имеющихся атрибутов (рис. 2.17). Различные типы ключей будут подробно рассматриваться в главе 4. Пока что о первичном ключе можно думать как о главном уникальном идентификаторе сущности. В случае, когда сущность изображается со всеми атрибутами, символизирующий ее прямоугольник делит- ся на две части: в верхней части указываются атрибуты, входящие в первичный ключ, а в нижней — все прочие атрибуты. а ПРЕДМЕТ МЕБЕЛИ ОФИС ОТДЕЛ ЗДАНИЕ б Рис. 2.16. Уровни детализации моделей стандарте IDEF1X' а — только сущности, б — сущности и первичные ключи
82 МЕНЕДЖЕР ПЕРСОНАЛ КсдУровня ПочасоваяСтавка Последняя- ДниОтпуска Премия ПРОГРАММИСТ ТЕСТЕР ТЕХНИЧЕСКИЙ ПИСАТЕЛЬ Название Язык Операционнвя- Систвма ОпытРаботы ОпытРаботы Язык Рис. 2.17. Уровни детализации моделей стандарта IDEF1X — сущности и атрибуты Как вы, должно быть, помните (см. рис. 1.3), связи в реляционной модели создаются путем помещения ключа одной таблицы в другую таблицу. По отно- шению ко второй таблице такой ключ называется внешним ключом (foreign key). Вопросы создания внешних ключей и правила, регулирующие их размещение, относятся к проектированию баз данных. Эти ключи являются частью внутрен- ней схемы. Поскольку средства моделирования данных, отвечающие стандарту IDEF1X, мыут использоваться для создания как концептуальных, так и внутренних схем, они позволяют изобразить на схеме размещение внешних ключей. Как правило, на стадии создания концептуальной модели внешние ключи только отвлекают, поэтому мы рекомендуем вам отключить их показ (программные продукты обыч- но предусматривают такую возможность). Исключением из этого правила явля- ется моделирование идентифицирующих связей. Как вы увидите далее, в таких связях внешний ключ одной сущности является частью первичного ключа дру- гой сущности. Для таких сущностей имеет смысл отображать внешние ключи В остальных случаях при создании концептуальной модели на внешние ключи не стоит обращать внимания. Более подробно о внешних ключах вы узнаете из главы 5, где описывается проектирование баз данных.
Стандарт l X Связи в IDEF1X На рис- 2.18 перечислены четыре типа связей, определенные в стандарте IDEF1X Псполыпсмая там терминология хотя и несколько неуклюжа, является при май очень точной — как и полагается для национального стандарта Рассмотрим по- следователъно псе четыре гнпа связей. • Неидентифицирующие (вязи принадлежности • Идентифицирующие связи принадлежности • Неспецифические саязи • Категориальные связи Рис. 2.18. Типы связей в стандарте 1DEF1X Неидентифицирующие связи принадлежности Неидентифицирующие связи принадлежности (non-identifying connection relation- ships) — это связи 1:1 или 1:N между двумя идентификационно-независимыми сущностями (отсюда характеристика «неидентифицирующие»). Связь принадлеж- ности (connection relationship) — это то же самое, что и связь типа «ИМЕЕТ» в рас- ширенной модели «сущность—связь». На рис. 2.19 приведены примеры неидентифицирующих связей принадлеж- ности. Согласно стандарту, неидентифицирующие связи изображаются пунктирной линией. Кроме того, связи принадлежности в IDEF1X всегда рисуются в направ- лении от родителя к потомку. В случае связи 1:N родителем является сущность на той стороне связи, которая обозначена цифрой 1. В случае связи 1:1 любая из сущностей может считаться родителем, но стандарт IDEF1X предписывает вы- брать на эту роль какую-то одну из сущностей. Как видно из рис. 2.19, на конце линии связи рядом с сущностью-потомком на диаграмме «сущность—связь» стан- дарта IDEF1X помещается закрашенный кружок. ОТДЕЛ НазваниеОтдела БюджетныйКод НомерОфиса —ъ------- Р МЕБЕЛЬ СерийныйНомер Тип Размер Материал ДатаПриобре-еиия БЭЙДЖ НомерБэйДжа ДатаВыдачи КемВыдан _______СОТРУДНИК________ НомерСоциальнойСтраховки Имя Телефон КодДолжности КОМПЬЮТЕР Рис. 2.19. Неидентифицирующие связи принадлежности По умолчанию неидентифицирующне связи принадлежности имеют кацикма. ,ь- Ность «один ко многим» с обязательным родителем и необязательным потом- *°м- Такие связи изображаются пунктирной линией с закрашенным кружком
84 ft Моцель -сущность—связь-: Ц средсг.» модолиромим. стороне потомка без каких-либо яругах обозпаченн,,. Так, связь между сущие ™ МФВДРА .. МЕБЕЛЬ на рис. 2.19 имеет вил 1:№ н„ одна из кафедр „е обо., на иметь мебель, но любая мебель, если таковая имеется, должна обязательно чис питься за какой-либо кафедрой. Если кардинальность связи отличается от предполагаемой по умолчанию, ис- пользуются дополнительные обозначения. Если потомок является обязательным рядом с кружком на соответствующем конце линии связи помещается символ Р (от positive - положительный; имеется в виду положительное число). Если ро- дитель является необязательным, то на родительском конце линии связи рисует- ся ромб. На рис. 2.19 связь между сущностями КАФЕДРА и СОТРУДНИК имеет вид 1:N, причем любая кафедра должна иметь по крайней мере одного сотрудника, но отдельно взятый сотрудник не обязан числиться на какои-либо кафедре. Связи 1:1 обозначаются при помощи индексов рядом с кружком на соответ- ствующей стороне связи. Число 1 показывает, что требуется ровно один пото- мок, не больше и не меньше, а буква Z означает, что потомок может быть один, либо его может не быть вовсе. Так, на рис. 2.19 сущность СОТРУДНИК имеет связь с одной и только одной сущностью БЭЙДЖ, а также с одной или нулевым коли- чеством сущностей КОМПЬЮТЕР. Ромб показывает, что компьютер не обязатель- но должен быть связан с каким-либо сотрудником. Поскольку на линии связи БЭЙДЖ-СОТРУДНИК со стороны сущности СОТРУДНИК ромба нет, каждый значок должен принадлежать какому-то сотруднику. Идентифицирующие связи принадлежности Идентифицирующие связи принадлежности (identifying connection relationships) — это то же самое, что и идентификационно-зависимые связи в расширенной моде- ли «сущность-связь». Идентификатор родителя всегда является частью идентифи- катора потомка. На рис. 2.20 сущность ЗДАНИЕ является родителем в идентификаци- онно-зависимой связи с сущностью ОФИС. Обратите внимание, что идентифика- тор сущности ЗДАНИЕ, атрибут НомерЗдания, является частью идентификатора иим'^Т" О начение (ВК) означает, что данный атрибут является внеш- ошн СущН0СТИ <п дан,10М ^е сущности ЗДАНИЕ). Идентифици- связях писуютгя Казываются сплошными линиями, а сущности-потомки в таких связях рисуются с закругленными углами. ЗДАНИЕ НомврЗдания ТелвфонСвкретаря КоличествоЭтажвй МвстоСтоянки ОФИС НомврЗдания (ВК) НомерОфисв НомерСетевогоПорта НомврТелвфонногоПорта МаксВместимость связи принадлежности Рис. 2.20. Идентифицирующие ним вджко "STa Р»лом с закрашен- ум«,ю. Таким образом, „
Стандарт IDEEIX В5 зкество офисов. Если бы рядом с кружком был укатан индекс 1, то в здании мог бы располагаться ровно один офис, в случае индекса Z возможное количество офисов равнялось бы 0 или 1, а индекс Р указывал бы на любое количество офи- сов, большее или равное 1. На родительской стороне идентифицирующей связи не может быть ромба, поскольку сущности-родители в таких связях всегда явля- ются обязательными. Есть важное различие между слабыми сущностями в расширенном модели «сущность—связь» и идентифицирующими связями в модели IDEF1X. Как уже говорилось ранее, слабая сущность — это такая сущность, которая логически зави- сит от другой сущности. Это может быть как идентификационно-зависимая сущ- ность, так и сущность, имеющая свой собственный идентификатор: главное, чтобы она логически зависела от какой-то другой сущности. Сущность ПОДЧИНЕННЫЙ на рис. 2.11 является слабой, и все же у нее есть свой собственный идентифика- тор, отличный от идентификатора сущности СОТРУДНИК. Хотя стандарт IDEF1X допускает слабые сущности, не являющиеся иденти- фицирующими, он не предусматривает для них никакого специального обозна- чения. Минимальное кардинальное число для родителя в таких связях равно 1, но никаких других способов зафиксировать факт логической зависимости от сущности-родителя не имеется. Иными словами, в расширенной модели «сущность—связь» проводилось раз- личие между сущностью, логически зависимой от другой сущности (например, ПОДЧИНЕННЫЙ и СОТРУДНИК), и независимой сущностью, которая просто-напро- сто имеет обязательного родителя. Сущность ПОДЧИНЕННЫЙ логически требует сущности СОТРУДНИК, поскольку подчиненный всегда подчинен кому-то. С дру- гой стороны, в связи СТУДЕНТ—РУКОВОДИТЕЛЬ сущность РУКОВОДИТЕЛЬ может быть обязательной, однако это не делает сущность СТУДЕНТ логически зависимой от нее. В IDEF1X признается такое различие, но отсутствуют символы для его обо- значения. Подытожить это обсуждение можно следующим образом: в расширенной мо- дели «сущность—связь» закругленные углы обозначают слабую сущность, кото- рая может быть как идентификационно-зависимой, так и логически зависимой. В стандарте IDEF1X закругленными углами обозначаются только идентифика- ционно-зависимые сущности, а какого-либо способа изобразить на диаграмме сла- бую сущность, не являющуюся идентификационно-зависимой, не существует. Неспецифические связи Под неспецифической связью (non-specific relationship) в IDEF1X понимается не Чт° иное, как связь «многие ко многим». Неспецифичсские связи обозначаются закрашенными кружками на обоих концах сплошной линии связи (рис. 2.21, а). В 1OEF1X не предусмотрено задание минимальной кардинальности для неспе- Цифической связи. Стандарт IDEF1X обращается со связями «многие ко многим», как с бедными (Родственниками неидентифицирующих связей принадлежности. Причиной явля- <1Ся то» что такие связи не могут быть напрямую выражены в терминах реляци- онной модели. Как вы узнаете из главы 5, связь «многие ко многим» необходимо
86 глава 2. модель-сущность-сдзь. оредетва „одвзиро.аки. сначала преобразовать в две связи 1Н преж» «« ««—> ~»в.гь в реляционной базе данных. Примечание: идентификатором сущности КВАЛИФИКАЦИЯ является сочетание (НомерСоциальнойСтраховки, НазваниеНавыка) б Рис. 2.21. Неспецифические связи а — модели со связью N:M; б — модели с пропущенной сущностью Некоторые воспринимают это как вопиющий дефект модели IDEF1X, по- скольку тем самым идеи концептуальной схемы смешиваются с идеями схемы внутренней. С этой точки зрения, мы должны иметь возможность исчерпыва- ющим образом описать связь M:N, включая минимальные кардинальные числа, в рамках концептуальной модели. Что произойдет с этой связью позже, в про- цессе разработки внутренней схемы, не должно нас интересовать на стадии кон- цептуального проектирования. Другая точка зрения сводится к тому, что связи вида N:M не существуют в ре- альности Их кажущееся существование обусловлено тем, что при создании кон- цептуальной модели был упущен из виду некоторый объект, который, по идее, должен был бы в пен присутствовать. Рассмотрим связь N:M между сущностя- ми СОТРУДНИК и ПРОФЕССИЯ. В большинстве случаев организация хочет знать не только то, какими профессиями владеет сотрудник, но и то, в каком объеме он ими владеет. Выходит, какой-то сущности здесь не хватает. Если мы дополним нашу модель сущностью УРОВЕНЬ_КВАЛИФИКАЦИИ (рис. 2.21, б), связь N:M рас-
Стандарт IDEF1X 87 падегся на две связи 1:N. Первичный ключ сущности УРОВЕНЬ-КВАЛИФИКАЦИИ будет представлять собой комбинацию ключей сущностей СОТРУДНИК и ПРОФЕССИЯ, то есть (ТабельныйНомер, Профессия). Рассмотрим связь между сущностями СТУДЕНТ и ПРЕДМЕТ. Студент может изу- чать множество предметов, и один и тот же предмет может изучать множество студентов. Поэтому возникает впечатление, что эти сущности имеют связь N:M. Однако вспомним, что студенты получают оценки по изучаемым ими предметам Добавим в имеющуюся модель сущность ОЦЕНКА, и тогда то, что казалось связью N:M между сущностями СТУДЕНТ и ПРЕДМЕТ, превратится в две связи 1:N — одна ме- жду сущностями СТУДЕНТ и ОЦЕНКА, другая между сущностями ПРЕДМЕТ и ОЦЕНКА Для тех, кто мыслит в этом направлении, термин «неспецифичность» по отноше- нию к связям N:M попадает как раз в точку. Но тогда как мы поступим со связью N:M между сущностями СТУДЕНТ и РОК- ГРУППА, которая описывает интерес студентов к различным рок-группам? Сту- дент может интересоваться несколькими рок-группами, и одной и той же рок- группой может интересоваться множество студентов. Какой сущности здесь не хватает? Может быть, это альбом, который заинтересовал студента? Или первый посещенный студентом концерт? Эти дополнительные сущности кажутся притя- нутыми за уши и ненатуральными. Или, например, как насчет связи N:M между сущностями СОТРУДНИК и ОФИС? Что здесь можно охарактеризовать как недостающие данные? Дату, когда сотруд- ник занял данный офис? Физическое местоположение сотрудника в офисе? Эти сущности также не оставляют впечатления естественности. Вам следует сформировать собственное мнение по данной проблеме. Однако будьте осторожны в обсуждениях, поскольку для некоторых людей этот вопрос приобретает чуть ли не религиозный характер. Одним из таких людей может быть ваш преподаватель! Категориальные связи Категориальные связи (categorization relationships) представляют собой частный случай связей вида обобщенпе/подтпп в расширенной модели «сущность—связь». Л именно, категориальная связь — это связь между порождающей сущностью (generic entity) и другой сущностью, которая называется сущностью-категорией (category entity). Сущности-категории группируются в категориальные класте- ры (categorization clusters). Например, на рис. 2.22 сущность СОТРУДНИК явля- ется порождающей сущностью, сущности ПРОГРАММИСТ, ТЕСТЕР и ТЕХНИЧЕСКИЙ^ ПИСАТЕЛЬ являются сущностями-категориями, а категориальный кластер, изобра- женный закрашенным кружком над двумя горизонтальными линиями, объединя- ет в себе сущности ПРОГРАММИСТ, ТЕСТЕР и ТЕХНИЧЕСКИЙ_ПИСАТЕЛЬ. Категориальные связи — это связи типа «ЕСТЬ»: например, программист есть с°трудннк. Соответственно, как и полагается для связей этого типа, первич- нЫм ключом сущностей-категорий служит категориальный ключ порождающей сущности. В данном примере первичным ключом сущностей ПРОГРАММИСТ, ТЕСТЕР и ТЕХНИЧЕСКИЙ_ПИСАТЕЛЬ является атрибут ТабельныйНомер. В связи с этим об- стоятельством сущности-категории показываются на схеме без первичных ключей.
88 r„«,a2. Модель.оущкооть-с.язь-: методы, иоредст. мушмедин. СОТРУДНИК НомерСоцивльнойСтраховки Имя Телефон КодДолжности |z ПРОГРАММИСТ Название Язык ОпврационнаяСистема КодДолжности ТЕСТЕР ”1 2 ТЕХНИЧЕСКИЙ ПИСАТЕЛЬ ОпытРаботы ОпытРаботы Язык Рис. 2.22. Категориальные связи В стандарте IDEF1X сущности, входящие в категориадьныи кластер, являют ся взаимоисключающими. На рис. 2.22 сотрудник может быть либо програ i стом, либо тестером, либо техническим писателем. Состоять на двух или более должностях одновременно сотрудник не может. Категориальные кластеры могут иметь дискриминатор (discriminator) — ат- рибут порождающей сущности, указывающий на тип сотрудника. На рис. 2.22 дискриминатором является атрибут КодДолжности. Таким образом, по значению данного атрибута можно определить, какую должность занимает сотрудник — программист, тестер или технический писатель. Способ, при помощи которого это делается, остается за рамками концептуальной модели — мы просто указыва- ем, что это сделать можно. Некоторые категориальные кластеры не имеют дис- криминатора, и конкретная сущность-категория остается в них неопределенной. Есть два типа категориальных кластеров: полные и неполные. В полном кате- гориальном кластере (complete category cluster) показана каждая из возможных для этого кластера категорий. Полные категориальные кластеры обозначаются двумя горизонтальными линиями с зазором между ними. Категориальный кла- стер, изображенный на рис. 2.22, является полным. Поскольку это так, на схеме изображены все без исключения категории сотрудников, входящие в данный кластер. Соответственно, каждый сотрудник может быть классифицирован как программист, тестер или технический писатель. (Вы можете спросить: «Постойте, есть же и другие типы сотрудников. Где, на- пример, бухгалтеры?» Суть в том, что согласно данной модели, других типов со- трудников не существует. Возможно, эта модель используется только в отделе разработки программного обеспечения, где не существует других должностей. может ыть, эта модель просто неверна. Но, как бы то ни было, в соответствии с данной моделью, не существует других типов сотрудников, помимо тех, которые в ней указаны.) Все сущности-категории являются жизненно зависимыми от порождающей сущности, поэтому минимальное кардинальное число связи со стороны порож-
Стандарт IDEF1X 89 дающей сущности равно 1. 1 ак как это справедливо но всех случаях, данное кар- динальное число не показывается па диаграмме. Согласно стандарту IDEF1X, кардинальное число категориальной свяж на стороне сущности-категории всегда равно 0 или 1. Индекс Z на линии, сое ди няюшей порождающую сущность с символом кластера, показывает, что поро- ждающая сущность не обязана (хотя и может) иметь категории Индекс Z на линии, соединяющей символ кластера с сущностью-категорией, показывает, что порождающая сущность может, но не обязана принадлежать к данному типу Многие считают эту запись с индексами Z сбивающей с толку, а то и попросту неправильной. Как уже отмечалось выше, категории в кластере являются вза- имоисключающими. Следовательно, как только устанавливается связь порожда- ющей сущности с одной из сущностей-категорий, кардинальность связей со всеми остальными сущностями данного кластера оказывается равной нулю. Кроме того, индекс Z на линии, соединяющей порождающую сущность с символом кластера, показывает, что эта сущность в принципе может и не иметь категорий. Однако в некоторых случаях для полных кластеров на месте Z следовало бы поставить 1, чтобы показать, что порождающая сущность обязана иметь связь с сущностью- категорией. К сожалению, в модели IDEF1X указание индекса 1 в подобных слу- чаях не предусмотрено. На рис. 2.23 показан еще один категориальный кластер, состоящий из сущно- стей-категорий МЕНЕДЖЕР и ПЕРСОНАЛ. Этот кластер является неполным, на что указывает его символ, состоящий из одной горизонтальной линии вместо двух. Это означает, что по меньшей мере одна категория отсутствует. Например, со- трудник может принадлежать к категории работающих на неполную ставку. Опять-таки все кардинальности на схеме обозначены как Z. СОТРУДНИК НомерСоциальнойСтраховки Имя Телефон КодДолжности ПЕРСОНАЛ nz ( ) КодДолжности менеджер I Z ПРОГРАММИСТ Подуровня Последняя- Дремия Почасовая- Стввка ДниОтпуска Название Язык Операционная Система ; | Z ТЕСТЕР ОпытРаботы I Z ТЕХНИЧЕСКИЙ- ПИСАТЕЛЬ ОпытРаботы Язык Рис. 2.23. Неполные и полные категориальные кластеры
90 Глава 2. Модель «сущность—связь»- методы и средства _моделиров.|ния Мы говорили, что сущности-категории, входящие в категориальный кластер, являются взаимоисключающими. Но это вовсе не означает, что сущность не мо- жет быть связана с двумя или более сущностями-категориями, принадлежащими к разным кластерам. Так, например, на рис. 2.23 сотрудник может быть менедже- ром и одновременно программистом. При этом сотрудник не может в одно и то же время принадлежать и к менеджерам, и к персоналу. Как вы можете видеть, модель IDEF1X дальнейшим образом структурирует связи вида обобщение/подтип, как они определены в расширенной модели «сущ- ность—связь» Давая этим идеям более четкое выражение, стандарт IDE 1 лает их более осмысленными, а следовательно, и более полезными. Имена связей В стандарте IDEF1X всем связям, кроме категориальных, могут присваиваться имена. Обычно имя связи состоит из трех элементов; глагол или глагольное сло- восочетание, описывающее предмет связи с точки зрения родителя, затем косая черта и аналогичный глагол или глагольное словосочетание, описывающее пред- мет связи с точки зрения потомка. (В связи N:M на роль родителя можно назна- чить любую из двух сущностей.) Так, на рис. 2.24 сотрудник использует компью- тер, но компьютер используется сотрудником; сотрудник занимает офис, а офис занят сотрудником. Как правило, глагольное словосочетание, описывающее предмет связи с точки зрения потомка, представляет собой страдательную форму глагольного словосочетания, описывающего предмет связи с точки зрения ро- дителя. В тех случаях, когда это приводит к неуклюжим речевым оборотам, ис- пользуется другой глагол. Например, бизнес-центр состоит из офисов, но офисы находятся в бизнес-центре. ЗДАНИЕ Рис. 2.24. Модель стандарта IDEF1X с именами связей Из-за этого сказуемыми и полезны, когда повторяющегося шаблона имена связей зачастую являются пред- поэтому не слишком информативными. Однако они могут быть характер связи между двумя сущностями неочевиден. На рис 2 25
Стандарт IDEF1X 91 1меется две связи между сущностями КЛИЕНТ и ПРОДАЖА Одна из связей указы* ваеТ на то, что клиент может что-то купить, а другая — на то, что клиент может что-то продать. КЛИЕНТ СДЕЛКА АГЕНТ НомерКлиента Покупает/Куплено Продает/Продано НомерДокумента Продает/Продано Имя Имя Улица Город Штат Индекс Телефон АдресЭпПочты Дата Описание ДоговорнаяЦена Налог Итого Комиссионные Телефон ИмяБрокера Рис. 2.25. Использование имен связей в случае нескольких связей между двумя сущностями Уникальность имен требуется только для связей между одними и теми же двумя сущностями. На рис. 2.25 связь между сущностями АГЕНТ и ПРОДАЖА име- ет то же имя, что и связь между сущностями КЛИЕНТ и ПРОДАЖА. Однако имена двух связей, соединяющих сущности КЛИЕНТ и ПРОДАЖА, должны быть раз- личными. Домены Стандарт IDEF1X дополнил расширенную модель «сущность—связь» понятием домена. Домен (domain) — это именованный набор значений, которые может при- нимать атрибут. Домен может представлять собой фиксированный список значе- ний, а может быть определен и более общим образом — например, как набор строк с максимальной длиной 50 символов. В качестве примера первого подхода можно привести домен НАЗВАНИЯ_КАФЕДР, включающий названия всех офици- альных кафедр в неком университете. Определение этого домена выглядит как простое перечисление названий кафедр: {'Бухгалтерский учет', 'Биология', 'Химия', Вычислительная техника', 'Информационные системы', 'Менеджмент', 'Физика'}. Приме- ром второго подхода может служить домен ИМЕНА_СТУДЕНТОВ, который можно определит!, как строку длиной до 75 символор. Д°мены устраняют неоднозначность Домены столь же важны, сколь и полезны. Например, обратите внимание, что на Рпс. 2.23 как у сущности ПРОГРАММИСТ, так и у сущности ТЕХНИЧЕСКИЙ_ПИСАТЕЛЬ имеется атрибут под названием Язык. Без использования доменов имена этих тРибутов могут толковаться неоднозначно. Описывают ли они одно и то же, _ нет? Возможно, для программиста Язык обозначает язык про!раммировання, а Аля технического писателя — естественный язык. А может быть, в обоих случа- Речь идет о языке программирования. Эту неоднозначность можно устранить, Указав домен, к которому должен принадлежать каждый из атрибутов.
92 Гпаиа 2. Модель сущн.югь-о.Мэь.: методы и оредса «деяиро^ П cnuik ПРОГРАММИРОВАНИЯ можно определить списком {С#, C++, Java, •VlsXe а Д»мИ. ЕСТЕСТВЕННЫМЗЫК - списком (Pyc«rf. 'Фпаннузский' 'Испанский', 'Британский английским', Американский английский} Те Французский, ис ,^п1.спгт Язык сущности ПРОГРАММИСТ принадлежит пень если постановить, что атрибут Язык сущности v тгуымиггимй г домену ЯЗЫК ПРОГРАММИРОВАНИЯ, а атрибут Язык сущности ТЕХНИЧЕСКИЙ_ ПИ«ТИЬ принадлежит к домену ЕСТЕСТВЕННЕЕ J3UK. эти два атрибута иовоз- Йта “..Хинные домены устраняют неоднозначность между атрн- бутами описывающими разные вещи, ио имеющими сходные значения Воз- вращаясь к рис. 2.23, предположим, что для сотрудников, входящих в число персонала, максимальная продолжительность отпуска составляет 30 дней. Пред- положим далее, что мы не ожидаем, что кто-либо из сотрудников проработа- ет более 30 лет. В этом случае каждый из атрибутов ПЕРСОНАЛ.ДлнтельностьОтпус- ка, ТЕСТЕР.ВыслугаЛет и ПРОГРАММИСТ.ВыслугаЛет будет иметь значения в диапазо- не от 0 до 30. (Здесь мы используем запись, в которой атрибуты идентифици- руются путем присоединения имени сущности к имени атрибута через точку.) Не указав домен, мы не сможем определить, описывают ли эти значения одно и то же. Теперь определим домен ДЛИТЕЛЬНОСТЬ_ОТПУСКА как целое число в интер- вале от 0 до 30 и домен ВЫСЛУГА как целое число в интервале от 0 до 30. Мы мо- жем указать, что атрибут ПЕРСОНАЛ.ДлительностьОтпуска принадлежит к домену ДЛИТЕЛЬНОСТЬ_ОТПУСКА, а атрибуты ТЕСТЕР.ВыслугаЛет и ПРОГРАММИСТ.ВыслугаЛет принадлежат к домену ВЫСЛУГА. Домены полезны на практике Домены хороши не только тем, что устраняют неоднозначность. Они полезны и в практическом отношении. Предположим, что в модели университетской ба- зы данных у пас есть атрибут под названием МестныйАдрес, используемый во множестве различных сущностей. Это могут быть, например, сущности СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, КАФЕДРА, ЛАБОРАТОРИЯ и так далее. Предположим также, что все атрибуты МестныйАдрес отнесены к одному и тому же домену МЕСТНЫЙ_АДРЕС, который определен как множество всех возможных значений вида BBB-NNN, где ~мЭТ° СПУСОК кодов зданий, a NNN — список номеров комнат. Тогда все атри- буты МестныйАдрес унаследуют это определение. Теперь допустим, что, построив нашу модель, мы обнаружили, что некоторые комнаты имеют четырехзначные номера. Если бы у нас не был определен соот- етствующии домен, нам бы пришлось найти в модели все атрибуты, использу- местныи адрес, и поменять в них трехзначные номера на четырехзначные. . <С еСТЬ ДОмен’задача становится гораздо проще: стоит изменить определе- ичмрнп>ел1а'ч ВСе аТРМ У™’ пРннадлежащис к этому домену, унаследуют данное иие тпТл v Т° Не ТОЛЬК° сокращает тРУдозатраты, но и предотвращает появле- ие трудных для диагностики и исправления ошибок литьС?г Т. ОДН° ПОЛеЗНОе применение для доменов: они помогают опреде- лить, не описывают ли два атрибута с различными названиями одно и то же.
Стандарт IDEF1X »3 НаприМСР’ СУ,Ц,,ОС гь КАФЕДРА может иметь атрибут под названием БюджегиыиКод, а сущность ПРОЕКТ — атрибут под названием СтатьяРасходое. Используя домены, мы можем быстро определить, нс происходят ли эти атрибуты из одного и того же домена. Без доменов это было бы сделать нелегко. Даже если значения атри- бутов похожи, они могут обозначать совершенно разные вещи Базовые и типовые домены В стандарте IDEE 1X определены два типа доменов. Базовый домен (base domain) — это домен, которому присвоен тип данных и, возможно, перечень значений или определение диапазона. Стандартными типами данных являются Character (сим- вольный тип), Numeric (числовой тип) и Boolean (логический тип). В специфика- ции доменов можно использовать дополнительные типы данных, такие как Date (дата), Time (время), Currency (валюта) и так далее. Список значений — это список, подобный тому, что мы задавали для домена ЯЗЫ^ПРОГРАММИРОВАНИЯ, а приме- ром определения диапазона может служить определение домена ВЫСЛУГА. Типовой домен (type domain) представляет собой подмножество значений ба- зового домена или другого типового домена. На рис. 2.26 изображены типо- вые домены, основанные на базовом домене НАЗВАНИЯ_КАФЕДР. Типовые домены можно организовывать в иерархии, что позволяет достичь большей точности при определении атрибутов. Рис. 2.26. Пример иерархии доменов
94 Глава 2. Модель «сущность-связь»; методы и средства моделирования Стандарт IDEF1X и средства моделирования данных Существует целый ряд программных продуктов, предназначенных для моделиро ванн: данных. Все диаграммы модели IDEF1X в этой книге бы .и нарисованы с помощью программы под названием ERWin от компании Computer Associat В программе Microsoft Visio имеется шаблон для баз данных, позволяющий создавать диаграммы как расширенной модели «сущность-связь», так и модели IDEF1X. Программа ERWin специально предназначена для моделирования данных и вообще удобнее в использовании, чем Visio. Ознакомительную версию ERWin можно загрузить с сайта www.ca.com (зайдя на сайт, щелкните на ссыл- ке Download) На сайте www.microsoft.com можно получить 60-дневную ознако- мительную версию Visio. Еще один продукт для создания моделей «сущность- связь», Designer/2000, выпускается компанией Oracle. Если вы на практических занятиях используете Oracle, то, возможно, ваш преподаватель выдаст вам эту программу. Диаграммы «сущность—связь» в стиле UML UML (Unified Modeling Language — унифицированный язык моделирования) — это набор структур и методик для моделирования и проектирования объектно- ориентированных программ (ООП) и приложений. UML является одновременно и методологией разработки систем ООП, и набором инструментов для разработ- ки таких систем. UML получил известность стараниями группы OMG (Object Management Group) — организации, занимающейся разработкой ООП-моделей, технологии и стандартов с 1980-х годов. Этот язык стал также находить широ- кое применение в среде профессионалов ООП. На UML базируются инструмен- ты для объектно-ориентированного проектирования, разработанные компанией Rational Systems. Будучи методологией разработки приложений, UML является предметом курса системной разработки и поэтому представляет для нас лишь ограничен- ный интерес. Вам могут, однако, встретиться диаграммы «сущность—связь», вы- полненные в стиле UML, поэтому представление об этом стиле следует иметь. Сущности и связи в UML На рис. 2 27 приведено UML-представление структур, изображенных на рис. 2.7. аждая сущность представлена классом сущностей (entity class), который изо- ражен в виде прямоугольника с тремя сегментами. В верхнем сегменте находят- ся имя сущнос I и и другие данные, о которых мы будем говорить далее. Во втором сегменте перечислены имена атрибутов сущности, а в третьем описаны ограниче- ния и методы (программные процедуры), относящиеся к данной сущности.
Диаграммы «сущность—связь» в стиле UML 95 СОТРУДНИК ИдСотрудника Имя Должность Телефон КодКвалификации АВТОМОБИЛЬ—НАЗНАЧЕНИЕ . °-1 1..1 АВТОМОБИЛЬ НомерЛицензии VIN Производитель Медель ГодВыпуска Ограничения и методы перечисляются здесь Ограничения и методы перечисляются здесь а ОБЩЕЖИТИЕ Название МестныйАдрес Вместимость ТелефонКоменданта ОБЩЕЖИТИЕ—ЖИЛЕЦ 0-1 1..* СТУДЕНТ НомерСтудента ИмяСтудента Телефон Группа Комната Ограничения и методы перечисляются здесь Ограничения и методы перечисляются здесь б СТУДЕНТ СТУДЕНТ—КЛУБ 0..* 0..* КЛУБ НомерСтудента ИмяСтудента Телефон Группа Комната НомерКлуба БюджетныйКод Описание Председатель ТелефонПредседателя Ограничения и методы перечисляются здесь Ограничения и методы перечисляются здесь Рис. 2.27. Представления различных типов связей в UML: а — связь 1:1; б — связь 1 :N; в — связь N:M Связи показаны линиями, соединяющими две сущности. Кардинальность представлена в формате х.г/, где х — необходимый минимум, а у — допустимый Максимум. Так, 0..1 означает, что наличие данной сущности необязательно, а мак- с,»гально допустимое количество — одна. Звездочка представляет неограничен- н°е количество. Например, запись 1..* означает, что требуется одна сущность, Допускается неограниченное количество. Найдите на рис. 2.27, a-е примеры связец с максимальной кардинальностью 1:1, 1:N и N:M. представление слабых сущностей ₽еДставление слабых сущностей в UML иллюстрирует рис. 2.28. На линии свя- 1 РяД°м с родителем слабой сущности (то есть рядом с сущностью, от которой НоВИсит слабая сущность) помещается закрашенный ромб. На рис. 2.28, а сущ- С1Ь РЕЦЕПТ является слабой сущностью, а сущность ПАЦИЕНТ — ее родителем.
96 глава_2 Модель сущность связь- Рис. 2.28. Представление слабых сущностей в UML: а — слабая сущность, не являю—аяся идентификационно-зависимой; б — идентификационно-зависимая слабая сущность На рис. 2.28, а показана слабая сущность, не являющаяся идентификационно-за- висимой. Это обозначается выражением <non-identifying> (не идентифи ; ю.» на связи ПАЦИЕНТ-РЕЦЕПТ. На рис. 2.28, б изображена идентификационно-зависи- мая слабая сущность. На это указывает ярлык «identify! ng> (идентифицирующая). Представление подтипов Способ представления подтипов в UML показан на рис. 2.29. На этом рисунке допус- тимыми подтипами сущности КЛИЕНТ являются ФИЗИЧЕСКОЕ_ЛИЦО. ТОВАРИЩЕСТВО и КОРПОРАЦИЯ. В соответствии с рисунком, каждый клиент может иметь один, два или все три указанных подтипа. Для данной ситуации это не имеет смысла: кли- ент должен быть одного и только одного типа. В текущей версии UML отсутствуют средства для обозначения взаимоисключающих подтипов. Можно, однако, само- стоятельно добавить на диаграмму соответствующее обозначение. На рис. 2.30 представлена UML-версия диаграммы «сущность—связь», пока- занной ранее на рис. 2.15. Поскольку связь между сущностями РАБОТА и КЛИЕНТ имеет атрибут Плата, для несения этого атрибута выделена специальная сущ- ность ТА-^Я-К-ЛИЕНТА. Такова стандартная практика при использовании «К™ Обратите также внимание на представление рекурсивной связи ИВЕДЕН.
Диаграммы «сущность—связь» в стиле UML Рис. 2.29. Представление подтипов в UML
98 глава 2. Мп.п.япь «сущность-связь»., методы и средства модолиро^ Конструкции ООП, введенные языком UML Так как UML является объектно-ориентированной ихнологией, классы сущ ностеп UML были дополнены некоторыми конструкциями ООП Здесь мы толь- ко коснемся этих идей, а развитие им дадим в главе 16. Во-первых, классы всех сущнос ей, которые должны храниться в базе данных, номечаютс ключевым словом <persistent> (устойчивый). Это значит, что данные должны продолжать свое существование и после того, как будет разрушен объект, их обрабатыва- вший. Проще говоря, это означает, что класс сущности должен храниться в базе данных. „ Далее, UML допускает назначение атрибутов классам сущностей. Атрибуты класса (class attributes) отличаются от атрибутов сущностей тем, что они при- надлежат всему классу сущностей данного типа. Так, на рис. 2.31 атрибут Число- Пациентов сущности ПАЦИЕНТ является атрибутом всей совокупности сущно- стей этого типа, имеющихся в базе данных. Атрибут ИсточникПоступления описывает источник поступления всех пациентов, записи о которых имеются в базе данных. Рис. 2.31. Представление классов сущностей в UML с помощью конструкций ООП mn пп' ВЫ ПОЗЖе У3наете’ в рамках реляционной модели такие атрибуты клас- Паниентов^ба Хранить’ ®место того чтобы хранить такие атрибуты, как Число- В дпугих слх/ Зяе ДаННЫХ’ ИХ иногда в’«исляют на этапе выполнения программы, сущностей Для к ДЛЯ Х₽анения этих атРибутов выделяется специальный класс С з"а нов™ Z Г сущностей ПАЦИЕНТ’ изображенного на рис. 2.31, можно буть. ЧиХм ПОД Т™ ИбГОЧНИК-ПОСТУПЛЕНИЯ, имеющую атри- ПАЦИЕНТ будут связаны СТ°ЧНИК 0СТУпления. В таком случае все сущности класса Тоетьей^^ 7 Сущностью ИСТОЧНИК_ПОСТУПЛЕНИЯ. тинной Хи^1^10 UML ЯВ™ использование объектно-ориен- Р< нотации для обозначения видимости атрибутов и методов. Атрибу-
Диаграммы «сущность—связь» в стиле UML 99 ты. именам которых предшествует знак «+», являются открытыми, атрибуты со знаком «#» являются защищенными, а со знаком «-» — закрытыми. На рис. 2 31 атрибут Имя сущности ПАЦИЕНТ является защищенным. Эти термины имеют корни в объектно-ориентированном программировании. Открытым (public) называется такой атрибут, который может читаться и изме- няться любым методом любого объекта. Термин защищенный (protected) означает, что атрибут или метод доступен только методам данного класса и его подклас- сов, а термин закрытый (private) указывает на то, что соответствующий атрибут или метод доступен только методам данного класса. Наконец, в UML задаются ограничения и методы, для чего служит третий сегмент прямоугольника, изображающего класс сущностей. На рис. 2.31 на зна- чение атрибута НомерПациента налагается ограничение первичного ключа. Это означает просто, что НомерПациента является уникальным идентификатором. Кроме того, рис. 2.31 указывает, что должны быть созданы следующие методы: ПолучитьИмя() — для открытого доступа к атрибуту Имя (обратите внимание на знак «+» перед методом ПолучитьИмя()), ВвестиИмя() — для установки значения этого атрибута, и ПолучитьРецепт() — для перебора совокупности сущностей клас- са РЕЦЕПТ, связанных с данной сущностью ПАЦИЕНТ. Роль UML в базах данных на сегодняшний день Идеи, которые иллюстрирует рисунок 2.31, представляются довольно туманными в том, что касается применимости объектного мышления к построению и функ- ционированию баз данных. Такая объектно-ориентированная нотация не согла- суется с обычаями и процедурами, принятыми в коммерческих базах данных се- годняшнего дня. Понятие о том, что атрибут сущности может быть скрыт внутри объекта, не имеет смысла, если только база данных не обрабатывается исключи- тельно объектно-ориентированными программами; по даже если так, эти програм- мы должны обрабатывать данные в соответствии с этой политикой. За исключе- нием специализированных объектно-ориентированных СУБД (ООСУБД) и их приложений, так никогда не делается. Напротив, большинство коммерческих СУБД позволяют всем видам про- грамм обращаться к базе данных и обрабатывать любые данные, в отношении ко- торых у этих программ имеются соответствующие полномочия. Более того, с та- К|,ми средствами, как генератор запросов в Microsoft Access 2002 (см. рис. 2.6), Просто не существует способов ограничить доступ к значениям атрибутов отдель- Ного объекта. Итак, все сводится к тому, что вам необходимо уметь интерпретировать диа- гРа'1МЫ «сущность—связь», выполненные в стиле UML. Они точно гак же при- ,Т)Дны ДЛя проектирования баз данных, как и диаграммы расширенной модели УШность—связь». Тем не менее, на текущий момент объектно-ориентнрован- нотация, которая в них вводится, имеет весьма ограниченную практическую Юность Дальнейшую информацию по этой теме вы найдете в главе 16.
методы и средства моделирования 100 Глава 2. Модель «сущность свя—. _ --------- Резюме а хлппряг проясняет роль моделирования данных в про- Тройстоенвая сх™ат1«сская мм. „„Делены три типа схем внешня» ектировании баз данны . . П,п6„я схема является представлением чего-то, «шшешуальная .‘ |х.р»а,„,„. хранящейся в базе дав Внешняя схема является р д внешней схемой описывается только „ых. сто,и, - ’™ — -™Ч“- ZX",a3o данных, а внутренняя схема - представление физический ^“^„шпуальной схемы с использованием конкретного программного ZZ и/илп метода Одна концептуальная схема, как правило, служит осно- Z,, множества внешних схем. Одна и та же концептуальная схема может быть реализована в различных внутренних схемах, в зависимости от того, какие программные средства и методы применяются. Пользователи общаются с разработчиками базы данных в терминах внешних схем. Задача разработчиков состоит в том, чтобы по результатам опроса пользо- вателей построить такую концептуальную схему, которая поддерживала бы все заданные пользователями внешние схемы. Исключительно важно не смешивать концептуальную схему с внутренней схемой. Концептуальная схема должна быть чисто логическим представлением, не искаженным соображениями относитель- но природы и ограничений используемой СУБД. Модель «сущность—связь» была предложена Питером Ченом (Peter Chen) в 1975 году, и различные варианты этой модели могут использоваться для по- строения концептуальных схем. Тиори (Теогеу) и другие расширили исход- ную модель, введя в нее подтипы, и результирующая версия получила название расширенной модели «сущность—связь». На сегодняшний день, когда говорят о модели «сущность—связь», в большинстве случаев имеют в виду именно рас- ширенную модель «сущность—связь». В 1993 году Национальный институт стан- дартов и технологии объявил о стандарте моделирования данных под названием «Единый стандарт моделирования информации», или IDEF1X. Этот стандарт клю 1ает в себя модификацию расширенной модели «сущность—связь», но ис- блтгпУп! Друп1е Пифические символы и предусматривает средства для разра- ш lx поллепжНПИХ СХеМ РЯД прогРаммных продуктов для моделирования дан- X™ в молеЮТ ?ТРТ IDEF1X> НО П₽И ЭТОМ ОНИ вносят и собственные на мХХия поп С00бщССТВт°^ объектного моделирования была разработа- в которую также вошла^ПИСМ ML ^УниФииированный язык моделирования), которую также вошла одна из версий модели «сущность-связь» «Л и™," Cv“ ’ерсий?“ асУшность—связь,- являются суш- ект. за которым пользозатстш юте^бы ™кот“рый идентифицируемый обь- образуют классы сущностей г. ледить. Группы однотипных сущностей характеристики. ИдентнфитттовокГн1 ИМеют атР'Футы. которые описывают их осуществляется HMetZX ™ “^бут, с помощью которого именование, различение отдельных зисацияров класса сущ-
Резюме 101 ности. Уникальный идентификатор указывает на конкретный экземпляр класса сущности, неуникальный — на некоторое множество экземпляров класса. Связи отражают взаимоотношения между сущностями. Классы связей — по взаимоотношения между классами сущностей, а экземпляры связей — взаимоот- ношения между экземплярами сущностей. Класс связей, соединяющий только два класса сущностей, называется бинарной связью. На практике большинство связей являются бинарными. Есть три типа бинарных связей: 1:1, 1:N и N:M. Индексы показывают макси- мальное кардинальное число связи. На традиционных диаграммах «сущность- связь» сущности изображаются прямоугольниками с прямыми или закруглен- ными углами, а связи — ромбами. Для каждой связи определено также мини- мальное кардинальное число — наименьшее число экземпляров сущности, ко- торые должны существовать на каждой из сторон экземпляра связи. Типичные значения минимального кардинального числа — 0 или 1, но могут быть и дру- гие числа. В расширенной модели «сущность—связь» слабой сущностью называется та- кая сущность, которая не может существовать в базе данных без некоторой дру- гой сущности. Слабая сущность может быть идентификационно-зависимой либо логически зависимой от другой сущности. Идентификационно-зависимой явля- ется такая сущность, идентификатор которой включает в себя идентификатор некоторой другой сущности. Слабые сущности изображаются ромбами и пря- моугольниками с закругленными углами. Многозначные атрибуты и группы атрибутов могут быть представлены с помощью идентификационно-зависимых слабых сущностей. Сущность-подтип представляет собой разновидность некоторой другой сущ- ности, называемой надтипом. Связь между надтипом и подтипом является связью типа «ЕСТЬ», поскольку все экземпляры иадтниа и подтипа ссылаются на одно н ю же. Подтипы используются тогда, когда некоторые атрибуты сущности оказываются в определенных ситуациях неприменимыми. Стандарт IDEF1X включает в себя расширенную модель «сущность—связь», ”о придает некоторым терминам иное значение, а также вводит понятие домена. С помощью 1DEF1X можно проектировать как концептуальные, так и впутрен- нне схемы. В данной главе рассматривается только проектирование концепту- альных схем. Сущности в 1DEF1X изображаются прямоугольниками. Если на диаграмме показываются атрибуты, то первичные ключи перечисляются в верхнем сегмен- Те Прямоугольника, а все остальные атрибуты — в нижнем. На диаграммах моде- ли 1DI F1X могут отображаться и внешние ключи, однако это обычно не имеет СмЬ1сла при построении концептуальной схемы. Ь 1DEF1X определено четыре типа связей: неидентифицирующие связи при- надлежности, идентифицирующие связи принадлежности, неспецифическне свя- и категориальные связи. Под неидентифицирующими связями понимают- Л СВязи 1:1 и 1:N типа «ИМЕЕТ» в расширенной модели «сущность—связь». а Диаграмме модели IDEF1X такие связи изображаются пунктирной линией
102 Глвва 2 Модель «сущность—связь», методы и средства модвлирсв; ния с закрашенным кружком на том копне, где находится сущность потомок Необяза тельные родители отмечаются ромбом па соответствующем конце линии связи Есин никаких дополнительных обозначений па стороне потомка не имеется карди- нальное число на этой стороне связи может быть равным О, I или более Индекс Р обозначает кардинальное число' I пли более, Z обозначает 0 или 1, а 1 показывает что имеется ровно один обязательный потомок. Идентифицирующие связи принадлежности — эго то же самое, что и иде фикационно-зависимые связи в расширенной модели «сущность-связь». Такие связи изображаются сплошной линией с закрашенным кружком на стороне по- томка. Кардинальное число со стороны потомка может быть равным О, 1 или бо- лее (индекс отсутствует), 1 и более (индекс Р), 0 или 1 (индекс Z), либо просто 1 (индекс 1). Родитель всегда является обязательным. В IDEF1X отсутствуют сред- ства для обозначения слабых сущностей, не являющихся идентификационно-зави- симыми. Таким образом, в отличие от расширенной модели «сущность-связь», где прямоугольник со скругленными углами представляет любую слабую сущ- ность, в модели IDEF1X таким прямоугольником обозначаются только иденти- фикационно-зависимые сущности. Неспецифические связи в IDEF1X используются для представления связей NM По мнению некоторых, связи N:M не существуют в действительности, а их присутствие указывает на то, что какая-то сущность была пропущена при моде- лировании. Другие считают, что такие связи все же существуют, и следовало бы обеспечить более адекватное их представление в модели IDEF1X. Категориальные связи — это связи типа «ЕСТЬ». В них участвуют поро- ждающая сущность, одна или несколько категориальных сущностей и катего- риальный кластер. Категории, принадлежащие одному кластеру, являются вза- имоисключающими. Полным называется такой кластер, в котором показаны все возможные категории. В неполном кластере отсутствует по меньшей мере одна категория. Дискриминатор — это атрибут порождающей сущности, с помощью которого определяется ее принадлежность к определенной категории. Сущность может иметь более одного категориального кластера и может иметь связь более чем с одной сущностью-категорией, лишь бы все эти категории происходили из разных кластеров. В модели IDEF1X связям могут присваиваться имена. Обычно имя связи со- стоит из трех элементов: глагольное словосочетание, описывающее предмет свя- зи с точки зрения родителя, косая черта и аналогичное глагольное словосочета- ние, описывающее предмет связи с точки зрения потомка. Имена связей важны, котда две сущности имеют между собой более одной связи. Стандарт IDEF1X ввел в модель «сущность—связь» понятие домена. Домен представляет собой именованное множество значений, которое может прини- мать атрибут. Домены устраняют неоднозначность, возникающую при наличии двух атри утов с одинаковыми именами или одинаковым набором значений, о которых неизвестно, описывают ли они одно и то же. Домены полезны на прак- тике, так как позволяют атрибутам наследовать свои характеристики из единого
Воирдды группы I 103 источника Если некоторая характеристика меняется, достаточно и «««-нить оире деление домена, п все атрибуты, принадлежащие «тому домену, автоматичг ски унаследуют произведенное изменение Базовым доменом называется домен, имеющий тин данных и, возможно, список значений или определение диапазона. Типовой домен — зто подмножество базового домена или другого типового домена. Существует ряд коммерческих нршраммиых продуктов для построения диа- грамм модели IDEF1X. Примерами таких продуктов могут служить ERWin, Visio и Dcsigner/2000. Язык UML представляет собой набор структур и методик для моделирования и проектирования объектно-ориентированных программ. Будучи технологией разработки приложений, он в общем и целом является предметом курса систем- ного анализа. Мы рассматриваем UML потому, что он включает в себя одн из модификаций модели «сущность—связь» для моделирования баз данных Сущности, связи и атрибуты UML весьма схожи с теми, которые используют- ся в расширенной модели «сущность—связь». Основное различие состоит в за- писи, а также в том, что в UML сущности и атрибуты дополнены конструкция- ми объектно-ориентированного программирования. UML поддерживает слабые сущности. Вопросы группы I 1. Объясните своими словами значение термина схема. 2. Перечислите схемы, входящие в тройственную схематическую модель ANSI/SPARC, и укажите функцию каждой из них. 3. Приведите пример ситуации, в которой организация может иметь три раз- личные внешние схемы, реализующиеся в одной концептуальной схеме. 4. Опишите, как с помощью внешних схем можно разработать концептуаль- ную схему. 5. Почему так важно не смешивать концептуальную схему с внутренней схемой? 6. В чем суть конфликта между Брюсом и Зельдой? Как вы считаете, смогут ли они прийти к единому мнению относительно способа записи данных? 7- В чем разница между исходной и расширенной моделями «сущность- связь»? 8. В чем состоит важность IDE FIX? В чем состоит важность UML? Дайте определение сущности и приведите пример. Ч- Поясните разницу между классом сущностей и экземпляром сущности *2. Дайте определение атрибута и приведите примеры атрибутов для сущно- сти, описанной вами в ответе на вопрос 10.
104 2. Мшель .оцноеть-свиь-: методы и сродсте молелиромни. 13. Обмен.™, что такое композитный „лентпфикатор. и п|«.«и« ..рииер 14. Какой .га атрибутов, приведенных вами в ответе на „опрос 12, идеитифи цирует сущность? 15. Дайте определение связи и приведите пример. 16 Объясните, в чем разница между классом связей и экземпляром связи. 17’ Дайте определение степени связи. Приведите пример связи СО степенью больше 2, отличный от того, который дан в тексте. 18. Перечислите три типа бинарных связей и приведите примеры. Нарисуйте диаграмму «сущность—связь» для каждого типа. 19 Дайте определения терминов максимальное кардинальное число и мини- мальное кардинальное число, максимальная кардинальность и минималь- ная кардинальность. 20. Назовите и нарисуйте символы, используемые в диаграммах расширенной модели «сущность-связь» для обозначения: (а) сущности; (б) связи; (в) сла- бой сущности и ее связи; (г) рекурсивной связи; (д) сущности-подтипа. 21. Приведите пример диаграммы «сущность—связь» для сущностей ОТДЕЛ и СОТРУДНИК, имеющих связь 1:N. Предположите, что в отделе может и не быть сотрудников, но каждый сотрудник должен работать в каком-либо отделе. 22. Приведите пример рекурсивной связи и изобразите ее на диаграмме «сущ- ность-связь». 23. Дайте определение термина слабая сущность и приведите пример, отлич- ный от того, который дан в тексте. 24. Поясните, в чем состоит неоднозначность в определении термина слабая сущность. Как этот термин интерпретируется в расширенной модели «сущ- ность связь»? Приведите примеры каждого типа слабой сущности, отлич- ные от тех, которые даны в тексте. 25. Дайте определение термина идентификационно-зависимая сущность и при- ведите пример, отличный от того, который дан в тексте. 26. Продемонстрируйте использование идентификационно-зависимой сущ- гптрч ДЛЯ представления многозначного атрибута Профессия сущности ДНИК. Укажите минимальное и максимальное кардинальное число на о еих сторонах связи. Используйте символы расширенной модели «сущ- ность-связь». 27. Продемонстрируйте использование идентификационно-зависимой сущно- сти для представления многозначного композитного атрибута Телефон, со- стоящего из однозначных атрибутов КодРегиона и НомерТелефона. Пусть ри этом атрибут Телефон принадлежит сущности ПРОДАВЕЦ. Укажите ми- нимальное и максимальное кардинальное число на обеих сторонах связи. Используйте символы расширенной модели «сущность-связь»
Вопросы группы I 105 28. Дайте определение сущности-подтипа и прицедите пример, отличный от того, который дан в тексте. 29. Объясните, что значит утверждение «Подтипы используются тогда, когда некоторые атрибуты сущности оказываются в определенных ситуациях неприменимыми». Покажите, как его можно применить к вашему ответу на вопрос 28. 30. Поясните разницу между связью типа «ИМЕЕТ» и связью типа «ЕСТЬ- и приведите пример каждого из типов связи. 31. Дайте определение термина первичный ключ. 32. Что такое вторичный ключ, и почему такие ключи неуместны на концеп- туальной схеме? 33. Что такое неидентифицирующие связи принадлежности? 34. Приведите пример неидентифицирующей связи принадлежности. 35. Объясните значение закрашенного кружка, ромба и индексов Р, Z и 1 на диаграмме «сущность—связь» модели IDEF1X. 36. Чему равна по умолчанию кардинальность неидентифицирующей связи принадлежности? 37. Какому виду связей в расширенной модели «сущность—связь» соответ- ствуют идентифицирующие связи принадлежности? 38. Чем отличается слабая сущность в расширенной модели «сущность—связь» от идентифицирующей связи принадлежности в модели IDEF1X? 39. Как в модели IDEF1X представляются слабые сущности, не являющиеся идентификационно-зависимыми? 40. Как в модели IDEF1X представляются связи N:M? 41. Приведите аргументы в пользу того, что связи N:M не существуют в дей- ствительности. Подкрепите аргументацию примерами, отличными от тех, которые приведены в тексте. 42. Приведите аргументы в пользу того, что связи N:M все-таки существуют. Подкрепите аргументацию примерами, отличными от тех, которые приве- дены в тексте. 43. Какую из двух точек зрения, представленных в ваших ответах на вопро- сы 41 н 42, разделяете вы лично? Почему? 44. Объясните значение терминов порождающая сущность, сущность-катего- рия и категориальный кластер. Приведите примеры. 45. Какова роль дискриминатора в категориальной связи? 46. В чем состоит разница между полным и неполным категориальными кла- стерами? 47. Объясните, почему указание индекса Z рядом с полными категориальны- ми кластерами может сбивать с толку.
106 глава 2. Модель .сущность-связь»; методы и средства модели^ания 48. При каких условиях экземпляр сущности может иметь связь с двумя или более экземплярами категориальных сущностей? 49 Чем категориальные связи в молили 1DEF1X отличаются от подтипов/ налтпнов в расширенной модели «сущность-связь») 50. Опишите традиционный способ именования связей. 51. В каких случаях имена связей могут быть особенно полезными? 52. Что такое домен? 53 Опишите два типа ситуаций, в которых использование доменов устраняет неод! юзначность. 54. Объясните, в чем состоит практическая польза доменов. 55. Дайте определение термина базовый домен. 56. Дайте определение термина типовой домен. Вопросы группы II Для ответа на вопросы 57-64 используйте диаграмму модели IDEF1X «Спортив- ные секции», изображенную на рис. 2.32. Рис. 2.32. Диаграмма «Спортивные секции» 7. Рассмотрим связь между сущностями СТУДЕНТ и ОБОРУДОВАНИЕ. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3 Чему равно минимальное кардинальное число с обеих сторон связи? } снуйте ™ Не°бХ0Д,,МЬ1е-на паш ВЗГЛВД> изменения кардинальное™. Обо- 5) Дайте этой связи подходящее имя. 58. Рассмотрим связь между сущностями ОБОРУДОВАНИЕ и КУРС. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи?
Вопросы группы И 107 3) Чему равно минимальное кардинальное число с обеих сторон связи ? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя. 59. На рис. 2.32 сущность КУРС описывает курс спортивной дисциплины опре- деленного уровня сложности — например, гребля на каноэ для начинающих или подводное плавание для продолжающих. Сущность ЗАНЯТИЯ описывает занятия по данному курсу в конкретной группе — например, занятия по гребле на каноэ для начинающих с началом 7 января 2003 года. Рассмотрим связь между сущностями КУРС и ЗАНЯТИЯ. 1) К какому типу принадлежит эта связь? Правильный ли тип связи вы- бран для данного случая? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности Обоснуйте их. 5) Дайте этой связи подходящее имя. 60. Рассмотрим связь между сущностями ПЛАТА и ЗАНЯТИЯ. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя. 61. Рассмотрим связь между сущностями ПЛАТА и СТУДЕНТ. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя. Рассмотрим связь между сущностями СТУДЕНТ и КЛУБ. ОК какому типу принадлежит эта связь? 2) Опишите новую сущность, введя которую, можно было бы превратить данную связь в две неидентифицирующие связи принадлежности. Ука- жите кардинальность новых связей 3) Как вы считаете, является ли получившаяся структура более удачным решением, чем первоначальная?
108 г^ва 2. Модель «сущность-связь»: методы и средства модвлиромния 63. Добавьте новую жду сущностью сущность под названием ИНСТРУКТОР. Создайте связи ме- ИНСТРУКТОР и сущностями КУРС и ОБОРУДОВАНИЕ 1) Обоснуйте выбор типа связи в каждом случае 2) Укажите кардинальности новых связей. 3) Дайте имена созданным связям. 4) Перерисуйте диаграмму, изображенную па рис. 2.32, добавив в нее но- вые сущности и связи и указав значения кардинальности, выбранные вами в ответах на вопросы 57-62. 64 Измените ваш ответ на вопрос 63, введя новую сущность АДМИНИ1 ТАГОР и сделав сущности ИНСТРУКТОР и АДМИНИСТРАТОР категориями сущности СТУДЕНТ. 1) Какого вида категориальный кластер следует использовать — полный или неполный? Обоснуйте свой выбор. 2) Назовите и опишите атрибут, который мог бы использоваться в каче- стве дискриминатора для этого категориального кластера. 3) Перерисуйте диаграмму, изображенную на рис. 2.32, добавив в нее но- вые сущности и связи. Для ответа на вопросы 65-71 используйте диаграмму модели IDEF1X «Ко- мандировка сотрудника», изображенную на рис. 2.33. -------А______ ЗАКАЗ ГОСТИНИЦЫ Рис. 2.33. Диаграмма «Командировка сотрудника» 65. Рассмотрим связь между сущностями СОТРУДНИК и КОМАНДИРОВКА. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардпнадаюе число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? ) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя.
Вопросы группы II 109 66. Рассмотрим связь между сущностями КОМАНДИРОВКА и ЗАКАЗ_АВИАБИЛ ТА. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя. 67. Рассмотрим связь между сущностями КОМАНДИРОВКА и ЗАКАЗ_ТАКСИ. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя. 68. Рассмотрим связь между сущностями КОМАНДИРОВКА и ЗАКАЗ_ГОСТИНИЦЫ. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя. 69. Рассмотрим связь между сущностями ЗАКАЗ_АВИАБИЛЕТА, ЭЛЕКТРОННЫЙ_ БИЛЕТ и БУМАЖНЫЙ_БИЛЕТ. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? 4) Какого вида категориальный кластер здесь используется — полный или неполный? Не следует ли поменять тип кластера? 5) Приведите пример дискриминатора для этой связи. 70. Добавьте новую сущность под названием ОТЧЕТ_О_РАСХОДАХ. Создайте свя- зи между сущностью ОТЧЕТ_О_РАСХОДАХ и сущностями СОТРУДНИК и КОМАН- ДИРОВКА. 1) Обоснуйте выбор типа связи в каждом случае. 2) Укажите кардинальности новых связей. 3) Дайте имя созданным связям. 4) Перерисуйте диаграмму, изображенную на рис. 2.33, добавив в нее но- вые сущности и связи.
110 Глава 2. модель .сщноеть-с-АЗь.: методы и ередег.з моделирования х. 7л пш>п« новые сущности СЛУЖБЕ НАЯ и ЛИЧ- 71. Измените ваш ответ на вопро , КОМд|_|диРОВКА. Считайте, что СВЯЗЬ идо п Качестве категории сущности twr'iHn/virvoiu-. ™ЧНАЯ " ОРГРАСХОДАХ „с предусматрилаегся 1) Какого вила категориальиый кластер следует иоияь-юв.4ъ полны» или неполный? Обоснуйте свой выбор. 2) Назовите и опишите атрибут, который мог бы использоваться в каче- стве дискриминатора для этого категориального кластера. 3) Перерисуйте диаграмму, изображенную па рис. 2.33, добавив в ш вые сущности и связи. На рис. 2.34 показана концептуальная схема из «Саги о Брюсе и Зельде» в вер- сии IDEF1X. Используйте ее для ответа на вопросы 72-76. Рис. 2.34. Диаграмма из «Саги о Брюсе и Зельде» 72. Рассмотрим связь между сущностями РЫБА и НАБЛЮДЕНИЕ. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардинальное число с обеих сторон связи? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя. 73. Рассмотрим связь между сущностями РЕКА и НАБЛЮДЕНИЕ. 1) К какому типу принадлежит эта связь? 2) Чему равно максимальное кардинальное число с обеих сторон связи? 3) Чему равно минимальное кардиншпшое число с обеих сторон связи? 4) Опишите необходимые, на ваш взгляд, изменения кардинальности. Обоснуйте их. 5) Дайте этой связи подходящее имя. 74. Добавьте новую сущность ПУНКТ_НАБЛЮДЕНИЯ в качестве дочерней сущ- ности в идентифицирующей связи принадлежности с сущностью РЕКА. . далите связь между сущностями РЕКА и НАБЛЮДЕНИЕ, а взамен установи- те связь между сущностями НАБЛЮДЕНИЕ и ПУНКТ_НАБЛЮДЕНИЯ. 1) сп^сЗм^а^ИНаЛЬН0СТЬ СВЯЗИ междУ сущностями РЕКА и ПУНКТ_НА- ЬЛЮДЕНИЯ. Обоснуйте выбранные значения. 2) Укажите кардинальность связи между сущностями ПУНКТ НАБЛЮДЕНИЯ и НАБЛЮДЕНИЕ. Обоснуйте выбранные значения.
Вопросы группы II 111 3) Дайте имена новым связям. 4) Перерисуйте схему на рис. 2.34 в соответствии с изменившейся струк- турой. 75. В схему, получившуюся в результате ответа на предыдущий вопрос, до- бавьте новую сущность НАБЛЮДАТЕЛЬ. Установите связь между сущностя- ми НАБЛЮДЕНИЕ и НАБЛЮДАТЕЛЬ. Создайте для сущности НАБЛЮДАТЕЛЬ категориальный кластер с двумя категориями: ПРОФЕССИОНАЛ и ВОЛОНТЕР 1) Какие типы связей следует использовать? Обоснуйте свой ответ. 2) Укажите кардинальность связи между сущностями НАБЛЮДАТЕЛЬ и НА- БЛЮДЕНИЕ. Обоснуйте выбранные вами значения. Дайте имя этой связи. 3) Какой тип должен иметь категориальный кластер? 4) Перерисуйте схему из ответа на вопрос 74 в соответствии с произведен- ными изменениями. 76. Создайте новую сущность под названием ПРЕДМЕТ. Установите связь меж- ду сущностями ВОЛОНТЕР и ПРЕДМЕТ, 1) Какой тип связи следует использовать в данном случае? Обоснуйте свой ответ. 2) Перерисуйте схему из ответа на вопрос 75, добавив в нее новую сущ- ность и связь. 3) Создайте еще одну сущность под названием ЗАНЯТИЯ, которая будет описывать занятия по некоторому предмету с конкретной группой. Там, где это необходимо, удалите ненужные связи и добавьте новые. Для ка- ждой связи назовите ее тип, укажите кардинальность и выберите имя. 4) Перерисуйте схему из ответа па вопрос 75 в соответствии с измени- вшейся структурой. 77. Отдел внешних сношений университета Highline принимает заявки от ор- ганизаций на тематические доклады. Для обработки заявок отдел хочет создать базу данных. В частности, предполагается вести учет тем, доклад- чиков, сделанных докладов, а также организаций, в которых выступали докладчики от университета Highline. 1) Составьте список возможных сущностей для базы данных «Докладчики». 2) Создайте диаграмму «сущность-связь» стандарта IDE FIX, содержа- щую только сущности (аналогично рис. 2.34). Примите, что связь меж- ду сущностями ДОКЛАДЧИК и ТЕМА имеет вид N:M. 3) Для каждой связи на диаграмме укажите тип, а также минимальное и максимальное кардинальные числа для родителя и потомка. Дайте имена всем связям. 4) Повторите шаги 2) и 3). но добавьте на диаграмму новую сущность, ко- торая позволит устранить связь N:M. 5) Является ли структура, получившаяся в результате ответа на вопрос 4), более удачным решением, чем первоначальная? Обоснуйте свои пред- почтения.
112 Глава 2. Модель «сущность-связь», методы и средства Города® ««« Гж,«оп„»о жиЛья выступавшая ” ^^ХравотастГодном к, крупных городов Сред. “сгоЗп'Х” жпюча» пригороды, с общим кодичктюм иастдения около 2 ГмX. человек. Лгапстпо полег учи местоположения, замости жилья для лип с низким» доходами -а 11 переписных учетах города п его пригород». В пределах этих участков имеется около 250 хм- НИЙ где предоставляется жилье малообеспеченным гражданам . реднем в каждом здании имеется 25 квартир и других единиц жилья 78. Агентство хранит информацию по каждому переписному участку гео- графические границы, типичные доходы населения, имена выборных и главных инвесторов важнейших объектов данного района, основные предприятия, а также прочие демографические и экономические данные. Хранится ограниченное количество информации о криминальной обста- новке. Для каждого здания агентство хранит следующую информацию* наименование, адрес, размер, имя и адрес владельца, имя и адре д ника по закладной, данные о ремонте и реконструкции, а также наличие приспособлений, облегчающих жизнь инвалидов. Кроме того, агентство хранит список всех единиц жилья в здании, включая тип, площадь, число спален, число ванных комнат, наличие кухни и столовой, местоположение внутри здания и различные примечания. Агентство хотело бы иметь дан- ные о среднем числе жильцов на квадратный метр для каждой единицы жилья, но на сегодняшний день не имеет возможностей для сбора и хра- нения такого рода данных. Тем не менее, агентство хранит информацию о том, является ли конкретная единица жилья занятой. Городское агентство бюджетного жилья работает как информационная па- лата и предлагает три основных вида услуг. Во-первых, оно ведет работу с политиками, лоббистами и адвокатскими группами в поддержку закона, который поощрял бы развитие жилья для малообеспеченных через нало- говые льготы, выделение предпочтительных зон развития и другие зако- нодательные стимулы. Для этого агентство предоставляет информацию о жилье для граждан с низким доходом руководству штата, округа и горо- да. Во-вторых, посредством выступлений, семинаров, выставок на съездах и другой PR-деятельности официальные лица агентство прилагает уси- лия к повышению осознания обществом потребности в жилье для ма- лообеспеченных людей. Наконец, агентство предоставляет информацию о таком жилье другим агентствам, работающим с малообеспеченными и бездомными. 1) Составьте список возможных сущностей для базы данных Городского агентства бюджетного жилья. 2) Построите диаграмму «сущность-связь» стандарта IDEF1X. включа- ющую сущности из ответа на вопрос 1).
Вопросы к проекту FiredUp 113 3) Дайте имя каждой связи и убедитесь, что вы правильно определили максимальную и минимальную карди1ылыюсти Может случиться, что в ходе ответа па вопрос 2) вам придется добавить, удалить или изменить тс или иные сущности из перечисленных вами вот вете на вопрос 1). Это нормально и даже типично для процесса моделиро- вания данных. Смело вносите модификации, пока не получите диаграмму, которая, на ваш взгляд, будет правильной. Вопросы к проекту FiredUp Вернемся к проекту FiredUp, который был описан в конце главы 1. Предполо- жим, что фирма FiredUp разработала линию из трех горелок: FiredNow, FiredAlways и FiredAtCamp. Предположим далее, что фирма пролает запасные части для каж- дого типа горелок, а также производит их ремонт. В одних случаях ремонт явля- ется бесплатным, поскольку выполняется в течение гарантийного срока, в других случаях взимается только стоимость деталей, в третьих взимается стоимость деталей и работы. Фирма FiredUp желает вести учет всех этих данных. Когда владельцев фирмы спросили о подробностях, они составили следующий список: КЛИЕНТ: Имя, Улица, Дом, Квартира, Город, Штат, Индекс, Страна, ЭлектронныйАд- рес, Телефон ГОРЕЛКА: СерийныйНомер, Тип, ДатаИзготовления, ИнициалыПроверяющего СЧЕТ-ФАКТУРА: НомерСчета, Дата, Клиент (со списком проданных товаров и ука- занием их стоимости), Сумма РЕМОНТ: НомерРемонта, Клиент, Горелка, Описание (со списком деталей, исполь- зованных при ремонте, и указанием их стоимости, если таковая взимается), Сумма ДЕТАЛЬ: Номер, Описание, Стоимость, ПродажнаяЦена 1. Создайте диаграмму расширенной модели «сущность—связь» для базы данных фирмы FiredUp. Задайте на свое усмотрение минимальную и мак- симальную кардинальность для связей между сущностями. Обоснуйте вы- бранные значения кардинальности. Используйте слабые сущности там, где считаете это нужным. Не используйте подтипы. Укажите идентификаци- онно-зависимые сущности, если таковые имеются. 2- Модифицируйте диаграмму из вашего ответа на вопрос 1, представив сущ- ности СЧЕТ-ФАКТУРА и РЕМОНТ соответствующими подтипами. При каких условиях эта структура окажется лучше, чем предыдущая? 3- Преобразуйте ваш ответ на вопрос 2 в диаграмму стандарта ID X. Вне- сите необходимые изменения, касающиеся подтипов и слабых сущностей. 4- Предположим что фирма FiredUp хочет записывать домашний и мобиль- ный телефон факс и несколько адресов электронной почты своих клиен- тов Модифицируйте свою диаграмму, введя множественные значения атрибутов Телефон и ЭлектронныйАдрес. Можете использовать как диаграм- му расширенной модели «сущность-связь», так и диаграмму стандарта «BEF1X — на ваше усмотрение.
114 Глава 2. Модель «сущность—связь»- методы и средства моделирования 5. Предположим, что фирма FiredUp разрабаплваег различные версии одной и тон же горелки, то есть FiredNow-1, FiredNow-2 и г. д. Модифицируй, те необходимым образом вашу диаграмму из ответа на вопрос 4, чтобы учесть эту ситуацию. Можете использовать как диаграмму расширенной модели «сущность—связь», так и диаграмму стандарта IDEF1X — на ваше усмотрение. Вопросы к проекту Twigs Tree Рассмотрим ситуацию с Самантой Грин, с которой мы познакомились в конце главы 1. Саманта владеет фирмой Twigs Tree, занимающейся стрижкой деревьев. Хотя многие из выполняемых ею работ являются разовыми (например, выкорче- вать дерево или пень), есть и повторяющиеся операции, такие как стрижка де- рева или группы деревьев с периодичностью раз в год или раз в два года. Когда дела идут не слишком хорошо, Саманта звонит бывшим клиентам, напоминая им о своей фирме и о необходимости регулярно подстригать деревья. Отрезанные ветки и стволы Саманта измельчает в стружку с помощью измель- чителя щепы, который она цепляет к своему грузовику. Стружка с него падает прямо в кузов грузовика. Вот уже много лет Саманта свозила стружку в центр переработки, но некоторое время назад ей довелось услышать, что стружку мож- но продавать питомникам и другим организациям для использования в качестве мульчи1. А совсем недавно она узнала, что некоторые из ее собственных клиентов хотели бы сами покупать у нее стружку. Да, как это ни странно, находятся люди, готовые запла тить Саманте за спиливание деревьев и измельчение веток, а потом еще и купить у нее свои собственные опилки как мульчу. «Люблю Америку!», — говорит на это Саманта. Саманта ведет- учет следующих данных: ВЛАДЕЛЕЦ ИмяВладельца, Телефон, Дом, Улица, Город, Штат, Индекс ПОВТОРЯЮЩАЯСЯ_РАБОТА: ПериодВМесяцах, Описание, Плата РАБОТА: ДатаВыполнения, Описание, ПредъявленнаяСумма, УплаченнаяСумма, Дага- Оплаты ДОСТАВКА_СТРУЖКИ: ИмяКлиента, Телефон, Дом, Улица, Город, Штат, Индекс, Дата- Доставки, Количество, ПредъявленнаяСумма, УплаченнаяСумма 1. Для начала предположим, что все выполняемые работы являются повто- ряющимися. Создайте диаграмму «сущность—связь» стандарта IDEF1X для сущностей ВЛАДЕЛЕЦ, ПОВТОРЯЮЩАЯСЯ_РАБОТА и РАБОТА. Смоделируйте связь между сущностями ПОВТОРЯЮЩАЯСЯ_РАБОТА и РАБОТА в виде иден- тификационно-зависимой сущности. Назовите тип каждой связи, укажите максимальную и минимальную кардинальности и дайте имена всем связям. 2. 1 еперь предположим, что все работы являются разовыми. Соответственно, нужно удалить сущность ПОВТОРЯЮЩАЯСЯ_РАБОТА и смоделировать сущ- ность РАБОТА как сильную сущность. Создайте диаграмму «сущность— 1 Мульча — перегной, солома, защищающие почву от испарения, замерзания. — Примеч. перев.
Вопросы к проекту Twigs Tree 115 связь» стандарта IDEF1X, назовите тип каждой связи, укажите макси- мальную и минимальную кардинальности и дайте имена всем связям 3. Объедините своп ответы на вопросы 1 и 2, дав сущности, которая опи- сывает повторяющиеся работы, имя ПОВТОРЯЮЩАЯСЯ_РАБОТА, а сущности, которая описывает разовые работы — РАЗОВАЯ_РАБОТА. Создайте порож- дающую сущность РАБОТА и сделайте сущности ПОВТОРЯЮЩАЯСЯ_РАБОТА н РАЗОВАЯ РАБОТА ее категориями. Создайте диаграмму «сущность связь» стандарта IDEF1X, назовите тип каждой связи, укажите максимальную и минимальную кардинальности и дайте имена всем связям. 4. Добавьте в модель, получившуюся в результате вашего ответа на вопрос 3, сущность ДОСТАВКА-СТРУЖКИ. Для начала предположите, что клиенты, для которых Саманта стрижет и спиливает деревья, никогда не покупают у нее стружку. Создайте для учета продаж стружки новую сущность под на- званием ПОКУПАТЕЛЬ_СТРУЖКИ. Постройте диаграмму «сущность связь» стандарта IDEF1X, назовите тип каждой связи, укажите максимальную и минимальную кардинальности в дайте имена всем связям. 5. Ответьте снова па вопрос 4, но теперь предположите, что клиенты, для ко- горых Саманта стрижет и спиливает деревья, могут также покупать у нее стружку. Для моделирования различных типов клиентов используйте сущ- ности категории, подобно тому, как это сделано в вопросе 3. Создайте диа- |рамму «сущность—связь» стандарта IDEF1X, назовите тип каждой связи, укажите максимальную и минимальную кардинальности и дайте имена всем связям.
Глава 3 Создание моделей данных «сущность—связь»: описание процесса и примеры В этой главе описывается процесс создания моделей данных. Из-за чрезвычай- ной важности этой темы мы подойдем к ней с трех различных позиций. Сначала мы рассмотрим последовательность шагов, которые необходимо предпринять для построения модели данных. Затем, исследовав несколько типичных образцов форм и отчетов, мы научимся создавать модели данных на основе информации, предоставляемой пользователями. В заключение мы рассмотрим практический пример разработки модели данных для университета. Каждый из этих трех под- ходов проливает свет на другие два. Соответственно, лучший способ изучить дан- ную главу — прочитать ее два или три раза. Все три раздела тематически объеди- нены внутри одной структуры. Как отмечалось в главе 2, после того как вы поймете основополагающие идеи, следующим шагом будет попытка применить их на практике, разобрав несколь- ко примеров. Поэтому вам следует ответить на вопросы и выполнить задания, приведенные в конце главы. По возможности используйте один из программных продуктов для моделирования данных, описанных в главе 2. Процесс моделирования данных На рис. 3.1 перечислены шаги, составляющие процесс моделирования данных. Первым шагом является планирование проекта. Основные задачи этого шага — получить «добро» от руководства, обеспечить финансирование, собрать рабочую группу, составить перечень задач и распланировать назначения, договориться об используемых средствах, методах и стандартах, чтобы результаты работы отдель- ных членов группы были согласованы, и определить охват проекта. Определение охвата проекта (project scope) особенно важно при моделировании данных, поскольку в большинстве организаций все взаимосвязано. Например, сущности отдела продаж будут связаны с сущностями отдела кредитов, которые.
Процесс моделирования данных 117 в свою очередь, будут связаны с сущностями отдела отношений с клиентами, а те с сущностями операционного отдела, и т. д. Без четкого указания охвата и рамок проекта процесс моделирования данных может выйти из-под контроля Разуме- ется, наличие таких рамок приведет к тому, что некоторые связи будут нс заданм или просто исключены из рассмотрения. • Планирование проекта • Определение требований —► • Определение сущностей ---- • Определение связей ---- • Определение идентификаторов :• Определение атрибутов • Определение доменов • Проверка модели Рис. 3.1. Шаги процесса моделирования данных Определение системных требований Следующий шаг в процессе моделирования данных — определение системных требований (system requirements), в особенности тех, что непосредственно каса- ются базы данных. Эта обширная и важная тема сама по себе заслуживает не- скольких глав в учебнике системного программирования. Здесь же мы просто рассмотрим традиционные источники требований к моделям данных. Более по- дробно о методах определения системных требований вы узнаете из курса систем- ного программирования. Опрос пользователей и наблюдение за их работой Наиболее распространенные источники требований к моделям данных перечис- лены во врезке. Исключительно ценными источниками являются опрос пользо- вателей н наблюдение за их работой, однако они же оказываются и наиболее ^Рудными в применении. Пользователи, как известно, хотят всего и сразу, но при этом часто забывают важные требования. Пользователь, опрашиваемый в начале вериода, в течение которого проводится опрос, может легко забыть требования, относящиеся к концу указанного периода, и т. д. Решение этих проблем выходит За рамки данной книги, ио является важной темой в курсе системного програм- мчрования. Что касается моделирования данных, цель опроса пользователей состоит в том, чтобы определить перечень потенциальных сущностей и связи между ними. Кро- ме того, важно иметь на руках исходные документы, в частности, формы и отче- ты- которые позволяют выявить возможные сущности и их связи, а также список "«тенциальных атрибутов. Вспомните из «Саги о Брюсе и Зельде», что пользо- “атеди смотрят на данные с различных точек зрения, и порой одна и те же вещь
118 Глава 3. Создание моделей данных «сущность связь» может называться у них разными именами, или наоборот, разные вещи могут быть названы одинаково. Цель опроса пользователей - получить адекватное описание того, как пользователь или группа пользователей представляют свои данные, то есть внешней схемы. ИСТОЧНИКИ ТРЕБОВАНИЙ К БАЗЕ ДАННЫХ --------- ♦ Опрос пользователей. ♦ Наблюдение за действиями пользователей ♦ Существующие формы и отчеты. ♦ Новые формы и отчеты. ♦ Существующие ручные записи. ♦ Существующие компьютерные файлы или базы данных. ♦ Формально определенные интерфейсы (XML). ♦ Предметные специалисты При опросе пользователей следует иметь в виду возможность терминологиче- ских расхождений. ИСТОРИЯ_КЛИЕНТА в бухгалтерии может иметь совсем другое значение, нежели ИСТОРИЯ_КЛЦЕНТА в отделе продаж. Опрашивая пользователей отдела продаж, рискованно считать, что вам известно значение термина история клиента только потому, что вы знаете, как интерпретируется это понятие в бух- галтерии. Результаты опроса пользователей и наблюдений фиксируются в виде заме- ток, набросков, определений элементов данных и т. д. Документация, создава- емая членами рабочей группы, должна быть согласованной и храниться в цен- трализованном информационном репозитории. Формы и отчеты Превосходным (а зачастую и наилучшим) источником требований к модели дан- ных являются формы и отчеты. Имеющиеся документы позволяют определить, как происходит обработка данных в настоящий момент, а новые — указывают на изменения в представлении информации или необходимость отслеживания ка- ких-то дополнительных данных. Образцы заполненных форм и отчетов должны храниться в информационном репозитории. Эти документы будут в дальнейшем использоваться для разработки и проверки модели данных. В следующем разделе мы приведем множество примеров создания моделей данных на основе анализа форм и отчетов. Существующие записи Еще один полезный источник требований — существующие записи. Это могут быть записи, сделанные вручную, например список кодов продуктов в записной книжке или картотеке. 1 акне листки и карточки хранятся в информационном ре- позитории в виде фотокопии. Записи могут иметь и цифровую форму — напри- мер, электронные таблицы или персональные базы данных. Копии таких файлов или выдержки из них следует также внести в информационный репозиторий
Процесс моделирования данных 119 Если имеется база данных большого размера, то с помощью таких программ- ных продуктов, как ERWin или Visio из нее можно реконструировать (reverse engineer) модель данных. Созданные таким способом модели базируются на внутренних схемах и не являются по своей сути концептуальными. Их можно скорее охарактеризовать как описание набора взаимосвязанных таблиц Эти модели, подобно концептуальным моделям, являются полными, но, в отличие от них, не имеют логического характера, а служат лишь представлением физиче- ских структур. Сегодня большие базы данных редко создаются с пуля. Гораздо чаще стоит задача модифицировать уже существующую базу данных. Метод реконструкции играет важную роль в таких проектах. Более подробно эта тема будет рассмат- риваться в главе 8 «Перепроектирование баз данных». Отложить ее обсужде- ние мы вынуждены потому, что для понимания данного материала необходимо знать SQL. Формальные интерфейсы Формальный интерфейс (formal interface) — это стандартизированное внешнее представление. Такие интерфейсы создаются правительственными учреждения- ми, промышленными группами и большими предприятиями для упрощения меж- организационвого обмена данными. Иногда одним из требований к вновь созда- ваемым системам баз данных является получение или выдача данных через такой интерфейс. В этом случае формальный интерфейс также входит в число источни- ков требований к модели данных. Формальные интерфейсы как таковые используются уже много лет, но с по- явлением сети Интернет потребность в межорганизационных стандартах еще более возросла. Публикация и использование таких стандартов в значительной степени упрощаются за счет применения XML. Почти каждая профессия в об- ласти бизнеса или крупная промышленная отрасль уже имеют или разрабатыва- ют собственные XML-стандарты. Языку XML будет посвящена глава 13. Из этой главы вы узнаете о тесной связи, имеющейся между базами данных и XML. Например, как SQL Server, так и Oracle могут записывать и считывать данные в формате XML. Можно ожидать, что в будущем роль формальных интерфейсов будет только увеличиваться и что необходимость поддержки таких интерфейсов станет еще более важным источником требований к модели данных. Предметные специалисты Предметные специалисты (domain experts) — это люди, являющиеся экспертами в определенной области знаний. Например, компания ЗМ имеет предметных специалистов в области абразивных материалов, клеящих веществ, стандартов 11 средств обеспечения безопасности, и т. д. Типичных предметных специалистов обычно можно найти в отделе управления персоналом. Соответственно, они вряд ли будут входить в число пользователей новой базы данных, зато могут предоста- ить важную информацию из своей области знаний, необходимую для построе- ния адекватной модели данных.
Глава 3. Создание моделей данных «сущность связь» Например, компания ЗМ выпускает тысячи и тысячи абразивных продуктов В этих условиях способов реализации связей подтип/надтии или категориаль- ных кластеров может быть множество. Бесценную помощь могут оказать здесь предметные специалисты, просмотрев несметное число потенциальных вариан- тов и отклонив неверные. Однако в работе с предметными специалистами есть и свои минусы Н ни чего опаснее при проектировании базы данных, чем группа «экспертов», сидя- щих за столом и заявляющих: «Если бы я был пользователем...». Только пользо- ватели, и никто другой, могут знать, какие данные и в какой форме нужны пользователям. Таким образом, хотя предметные специалис1ы и мо пролить свет на специфику конкретного проекта, основным источником определения требований к модели данных должны служить сами пользователи. Результатом работы по определению требований будет информационный ре- позиторий, содержащий заметки, схемы, формы, отчеты, файлы и другие мате- риалы, которые могут быть использованы при разработке модели данных. Определение сущностей Определившись с требованиями, рабочая группа может приступать к созданию модели данных. На рис. 3.1 определение сущностей, связей, атрибутов и доменов представлено в виде отдельных последовательных шагов. На самом же деле эти процессы зачастую идут параллельно и развиваются по спирали. Например, при анализе форм и отчетов выявляются как сущности, так и их связи. Кроме того, эти документы могут содержать указания на атрибуты. Таким образом, хотя да- лее мы будем описывать эти процессы раздельно, имейте в виду, что они часто происходят одновременно и носят итеративный характер. Сущность — это некий объект, который пользователи хотят отслеживать, о ко- тором они хотят хранить данные. Часто сущности являются физическими объекта- ми (например, ОФИС или ПРОДУКТ), но они могут представлять собой и абстрактные понятия, такие как ЗАКАЗ, ТРАНЗАКЦИЯ или КОНТРАКТ. Сущности идентифициру- емы, то есть их можно отличить друг от друга. В языковых конструкциях сущно- ши, как правило, следует искать среди членов предложения, выраженных суще- ствительными, а не прилагательными или причастиями. Рассмотрим следующий пример: «Сначала я сортирую заказы по их весу брутто». В аилом предложении объектом действия (сортировки) является ЗАКАЗ (существительное). Для выполнения этого действия используется одна из харак- теристик заказа — его вес в упаковке. Несмотря на то, что слово «вес» является существительным, сама эта характеристика может быть естественно выражена при- частием («весящий»). Таким образом, скорее всего, ВесБрутто является атрибутом, екоторые высказывания пользователей не имеют однозначной интерпрета- ции. Рассмотрим следующее высказывание: «Сначала я сортирую сегодняшние заказы по их весу брутто». Сп °В □ *сегодняшние заказы» могут означать, что сущность ЗАКАЗ имеет атри- бут ДатаЗаказа, и по значению этого атрибута делается выборка из множества
Процесс моделирования данных 121 заказов. Но можно ин^третировать это и так, что мы имеем дело с подтипом, я сущностью-категорией, то есть, например, для порождающей сущности ЗАКАЗ Tpe6yeTc« »n^™ ’нЕ7о'м^шГа ПД?Г0ДНЯ Ш Н И Й-ЗАКАЗ’ ЗАКАЗ.ПОСЛ ЕД НЕЙ. НЕДЕЛИ И ЗАКАЗ.ПОСЛЕДНЕГО.МЕСЯЦА. Оба варианта возможны, и чтобы выяснить, какой ИЗ них подходит лучше, необходимо дальнейшее изучение форм, отчетов я других документов. некоторых случаях в модель данных включаются оба варианта (в нашем примере - и атрибут ДатаЗаказа, и подтипы), а исключение неверного варианта происходит позже в ходе уточнения модели. Рассмотрим языковые конструкции вида «нечто чего-то» («х of у»), например, «телефон клиента», «зона ответственности торгового агента» и «уровень загряз- нения реки». Во всех этих конструкциях упоминаются два логически самостоя- тельных объекта (например, зона ответственности и торговый агент), каждый из которых описывается одиночным существительным или словосочетанием. Почти во всех случаях второй объект (выраженный существительным, изменяемая часть которого стоит в родительном падеже) является сущностью. В приведенных выше примерах сущностями являются соответственно КЛИЕНТ, ТОРГОВЫЙ.АГЕНТ иРЕКА. Первый объект (изменяемая часть которого стоит в именительном падеже) часто является атрибутом, однако это может быть и другая сущность. В приме- рах из предыдущего абзаца телефон и уровень загрязнения будут, скорее всего, атрибутами, а зона ответственности может быть как атрибутом, так и самостоя- тельной сущностью. Далее в этой главе мы покажем, как из форм и отчетов извлекать информацию о сущностях, связях и а трибутах. Пока что следует просто знать, что результатом этой деятельности будет список сущностей, подобный тому, который изображен на рис. 3.2. По мере эволюции проекта этот список будет неоднократно модифи- цироваться. Некоторые из сущностей в этом списке будут признаны синонима- ми, некоторые будут удалены, поскольку не несут интересующей нас информа- ции. Возможно также, что список пополнится новыми сущностями. РАСТЕНИЕ ПОКУПКА КЛИЕНТ ЗАКАЗ ДОСТАВКА ПОКУПАТЕЛЬ ПОДАР ОЧНЫЙ.СЕРТИФИКАТ ВОЗВРАТ СЧЕТ МЕБЕЛЬ a Рис. 3.2. Список сущностей для а — первоначальный вариант; б ПРОДУКТ ПОКУПКА КЛИЕНТ ПОСТАВЩИК ЗАКАЗ ВОЗВРАТ ВОЗВРАТ-ПОСТАВЩИКУ питомника Padden Creek: — окончательный вариант ШоГоП*’СОк на Рис. 3.2 был создан в процессе моделирования данных для неболь- Пей адовоДСтва-пит°мника. Здесь показаны первоначальный набор сушно- набор, который получился по окончании процесса моделирования. ут°Чнения модели рабочая группа рришла к выводу, что необходимость
Глава 3. Создание моделей данных <<сущность Свнзь» в сущностях ДОСТАВКА п ПОДАРОЧНЫЙ_СЕРТИФИКАТ отсутствует. по лому они был* исключены из схемы. Сущности РАСТЕНИЕ и МЕБЕЛЬ были при шаны различными подтипами отсутствующей в первоначальной схеме сущности ТОВАР. Введя эту сущность группа проанализировала требования к модели данных и пришла к вы- воду, что’необходимость в подтипах РАСТЕНИЕ и МЕБЕЛЬ не является нас твой, поэтому данные сущности были удалены В ходе дальнейшей) анализа группа обнаружила, что сущности СЧЕТ и ЗАКАЗ представляют собой синонимы, и в каче- стве предпочтительного термина был выбран ЗАКАЗ. Недостающие щно и ПОСТАВЩИК и ВОЗВРАТ были добавлены в модель. Наконец, рабочая группа реши- ла зарезервировать термин ПОКУПКА для обозначения покупки, сделанной клиен- том у питомника, а термин ЗАКАЗ - для покупки, сделанной питомником у одно- го из поставщиков. Это последнее обстоятельство указывает на необходимость определения зна- чений и способов использования сущностей на стадии выяснения требований. В табл. 3.1 показаны определения, которые использовались в питомнике Padden Creek. Таблица 3.1. Описание сущностей Сущность Описание ТОВАР Товар заказанный у поставщика и приобретенный клиентом. Товары идентифицируются по названию растения или по типу, а не по конкретным экземплярам. Таким образом, товаром может быть «Пион» или «Декоративная кадка», но не конкретные пион или кадка ПОКУПКА Запись о товарах, приобретенных клиентом. Многие покупки регистрируются как сделанные за наличный расчет и не включают информацию о покупателе. К записям о покупках, сделанных при помощи кредитной карты, прилагается квитанция, но цели отслеживать данные кредитной карты клиента не ставится. Данные, идентифицирующие покупателя, записываются при покупках на сумму свыше $150, а также при покупках, совершаемых постоянными клиентами КЛИЕНТ Лицо, приобретающее нечто у питомника Padden Creek ПОСТАВЩИК ЗАКАЗ ВОЗВРАТ ВОЗВРАТ ПОСТАВЩИКУ Идентификационные данные хранятся только для некоторых клиентов Поставщик растений, мебели и других товаров питомнику Padden Creek Заказ товаров у поставщика Запись о товаре, который был возвращен питомнику клиентом Запись о товаре, который был возвращен поставщику питомником Определение связей В модель данных входит описание всех связей между сущностями. Описание связи ж по iaei в соя идентификаторы родительской и дочерней сущностей, тип связи, минимальную и максимальную кардинальности и имя связи. Сущности и их свя- vбычи« С/1ОМО1«Ь№ Диаграмм расширенной модели «сущ- п связь», или UML, а также других стандартизированных методик. Для выявления связей применяются два подхода. Один состоит в том, что рассматриваются все возможные комбинации из двух сущностей для выявления
Процесс моделирования данных 123 •нячи между ними. Если связь признается возможной, пл следующем шаге про 3воД|,тСЯ анализ требований с целью определения кардинальностей и других 1'п’>актер1,СТ1,к связи. При втором подходе информация о связях извлекается Х* иосредственно из документов, описывающих требования к модели данных Иногда используется сочетание обоих подходов. Для исследования всех возможных комбинаций из двух сущностей составляет- ся таблица с именами всех сущностей в строках и столбцах, подобная изображен ной на рис. 3.3. Затем последовательно рассматривается каждая пара сущностей и если связь между этими сущностями возможна, в соответствующую ячейку ставится метка. Например, в первой строке таблицы па рис. 3.3 сущность КЛИЕНТ проверяется на наличие связи с каждой из сущностей базы данных питомника Padden Creek. Здесь потенциальными кандидатами на связь с сущностью КЛИЕН являются сущности ПОКУПКА и ПОСТАВЩИК. ' •- s < ' : : •' , -' - | КЛИЕНТ | ЗАКАЗ 1 1 ПРОДУКТ 1 1 ПОКУПКА I ВОЗВРАТ I ПОСТАВЩИК | ВОЗВРАТ_ПОСТАВЩИКУ | КЛИЕНТ X Y Y ЗАКАЗ X Y ПРОДУКТ Y X Y Y Y ПОКУПКА Y Y X ВОЗВРАТ и Y Y X ПОСТАВЩИК Y X Y ВОЗВРАТ ПОСТАВЩИКУ Y Y X Y -> да, существует потенциальная прямая связь Пусто -> связь маловероятна Рис. 3.3. Таблица потенциальных связей Не существует такого понятия, как односторонняя связь. Если сущность КЛИЕНТ имеет связь с. сущностью ПОКУПКА, то и сущность ПОКУПКА, в свою оче- редь, имеет связь с сущностью КЛИЕНТ. Таким образом, если таблица на рис. 3.3 Полнена правильно, она должна иметь симметричный вид. Бывают, однако, СИтУациц, когда приложение использует некоторую связь только в одном на- бавлении, и никогда - в противоположном. Например, приложение может Житься к сущности ЗАКАЗ и далее найти все связанные с нею сущности "осТАВЩик, но никогда не поступает наоборот - то есть не ищет заказы, связан- Г* с конкретным поставщиком. В этом случае потенциальная диаграмма связей УДет асимметричной. Вообще говоря, так бывает нечасто.
124 Глава 3. Создание моделей данных «сущнос тс Снизь» Выявив возможную связь, рабочая груина ио моделированию данных ан*, лизирует все требования к модели, чтобы определил», существует ЛИ «та связь в действительности. Если да, связь фиксируется в модели данных; если нет а ответствующая ей пометка удаляется из таблицы связей. Если модель данных объемна, использование таблицы связей становится не- целесообразным. Представьте себе модель, содержащую 50 сущностей. Тогда нам придется проанализировать (50 х 50 - 50)/2 - 1225 проверок! Исследовать такое количество сочетаний - долгий, утомительный и трудоемкий процесс, результат которого, скорее всего, не будет стоить затраченных усилий В этой ситуации для выявления связей рабочей группе следует положиться на анализ форм, отчетов и других требований. Определение идентификаторов Каждая настоящая сущность имеет идентификатор — атрибут или группу атри- бутов, которая уникальным образом идентифицирует экземпляр сущности. Если оказывается, что сущность не имеет идентификатора, то либо в ней не хватает каких-то атрибутов, либо она в действительности не является сущностью. Рас- смотрим, например, потенциальную сущность РЕЖИМ_ПОСТАВКИ с атрибутами {Поставщик, Дата, Стоимость}. Ни один из этих атрибутов не является хорошим идентификатором для сущности РЕЖИМ_ПОСТАВКИ. Скажем, атрибут Поставщик мо- жет быть идентификатором сущности ПОСТАВЩИК, но никак не РЕЖИМ_ПОСТАВКИ. Возможно, в данной схеме недостает атрибута СпособПоставки, а может быть, эти атрибуты в действительности относятся к другой сущности — например, ЗАКАЗ. Разумеется, идентификационно-зависимые сущности содержат только часть своего идентификатора. Например, сущность КВАРТИРА имеет идентификатор {Но- мерДома, НомерКвартиры}, но из этих двух атрибутов только НомерКвартиры принад- лежит сущности КВАРТИРА. Атрибут НомерДома принадлежит сущности ЗДАНИЕ — родителю сущности КВАРТИРА в идентификационно-зависимой связи. Таким об- разом, если не удается найти подходящий идентификатор для сущности, которая была классифицирована как не являющаяся идентификационно-зависимой, ино- гда с ши ( проверить, не является она в действительности идентификационно- зависимой от некоторой другой сущности. Может оказаться, что родительская сущность даже отсутствует в модели Сущноети, имеющие одинаковые идентификаторы, следует изучить особен- но пцатсльно. Возможно, они просто синонимичны. Есть также вероятность, чю они являются подтипами, или категориями, одной и той же сущности. 6,0P° лицензирования транспортных средств каждая из сущностей ЛЕГКОВОИ_АВТОМОБИЛЬ, ГРУ30В0Й_АВТ0М0БИЛЬ, ЛОДКА, ТРЕЙЛЕР и САМОЛЕТ может иметь идешификаюр НомерЛицензии. В этом случае возможно, что они все явля- катег°Риями- некоторой обобщенной сущности - скажем, НАЛОГООБЛАГАЕМОЕ_ТРАНСПОРТНОЕ_СРЕДСТВО. Все же в некоюрых редких ситуациях бывает, что две сущности, абсолютно разли шые по своей природе, имеют одинаковые идентификаторы. Например, сущноети ТРУДНИК и БЭЙДЖ могут иметь общий идентификатор НомерСотруд-
Процесс моделирования данных 125 ника. Можно представить сущность БЭЙДЖ как идентификационно-зависимую от сущности СОТРУДНИК, и в этом случае полным идентификатором сущности ЗНАЧОК будет сочетание {НомерСотрудника, ДатаВыдачи}. Иногда выбор между такими альтернативами осуществляется из чисто эстетических соображений. Определение атрибутов и доменов Следующие два шага — определить атрибуты и домены. Обычно атрибуты выяв- ляются при анализе форм, отчетов, существующих файлов и других документов и присваиваются соответствующей сущности. Каждый раз, когда в модель дан- ных добавляется новый атрибут, рабочая группа проверяет, нельзя ли отнести этот атрибут к одному из уже определенных доменов. Если да, этот домен стано- вится доменом данного атрибута. Если нет, определяется новый домен. Изначально каждый новый атрибут будет требовать введения нового домена. По мере продвижения этого процесса, с увеличением количества определенных доменов, вновь создаваемым атрибутам все чаще будут назначаться уже суще- ствующие домены. Закончив с определением атрибутов, полезно просмотреть список доменов на предмет того, не являются ли некоторые из них синонимами или подтипами дру- гих доменов. Внеся соответствующие коррективы, следует еще раз пройтись по списку атрибутов и посмотреть, не требуются ли какие-либо дополнительные изменения в определении доменов. В программах для моделирования данных имеется широкая гамма средств для документирования доменов. Некоторые из них позволяют, определив домен, создавать атрибуты на его основе путем перетаскивания мышью символа домена в прямоугольник сущности. По умолчанию имя атрибута будет совпадать с име- нем домена (при необходимости это имя можно изменить). Наследование свойств доменов В главе 2 обсуждались некоторые практические преимущества использования доменов. Эти преимущес тва обусловлены главным образом тем, что свойства до- мена наследуются всеми атрибутами, принадлежащими к этому домену. Когда свойства доменов изменяются, вместе с ними изменяются и свойства соответ- ствующих атрибутов. Например, если изменится тип данных домена, все атрибу- ты, принадлежащие к этому домену, унаследуют этот тип данных. Кроме типа данных, к наследуемым свойствам доменов относятся определе- ние домена и комментарии. Последнее может показаться тривиальным, однако в действительности комментарии весьма полезны. Например, комментарий, со- общающий, что домен КодДетали базируется на определении, принятом в 2001 го- ду, может иметь важное значение. Если любой атрибут, принадлежащий к до- мен; КодДетали, унаследует данный комментарий, это поможет сэкономить труд 11 предотвратить возможные недоразумения. Наконец, домены имеют такие свойства, как начальное значение и ограниче- ния. Начальное значение — это значение, которое присваивается каждому ново- му экземпляру атрибута, происходящего из данного домена. Ограничения - это
126 Глава 3. Создание моделей даннъоо<суи4ность---связьи правила ограничивающие множество значении, которые может принимать три 6vJ Например, домену КодДетали могут быть присвоен... начальное я. иие Т0000" и ограничение, в соответствии с которым значения атрибутов эго.ю до- мена должны начинаться с символов «Р» или «Z», а за ними должно следов, четырехзначное число. Оба эти свойства будут унаследованы всеми атрибутами, базирующимися на данном домене. Домены как средство реализации политики стандартизации данных Разумеется, можно игнорировать домены и определять каждый атрибут как уни- кальный и независимый от всех остальных. В сущности, как раз это и делается в таких продуктах, как Microsoft Access. Разработчик отдельно задает свойства для каждого столбца таблицы. Идея доменов здесь никак не используется. В организациях подобная практика может привести к несовместимости типов данных и систем. Например, если КодДетали определен в одной системе как целое число в интервале от 10 000 до 99 999, а в другой как строка формата ххппппп, где хх — это буквы «РС», а ппппп — десятичное число, большее или равное 10 000, совместить эти две системы будет сложно. Коды деталей, которые должны со- впадать, будут представляться различными, поэтому потребуется написать специ- альную процедуру, которая бы преобразовывала коды одной системы в коды другой системы. Эта ситуация вдвойне досадна, поскольку в действительности обе системы используют один и тот же код детали, только записывают его в раз- ных форматах. Чтобы предотвратить такого рода несовместимость, некоторые организации разрабатывают так называемые словари данных (data dictionaries), содержащие перечень стандартизированных доменов и описание их свойств. Информацию из этих словарей можно импортировать в программы моделирования данных и ис- пользовать при создании атрибутов. При такой организации работы каждый проект по моделированию данных будет использовать одни и те же стандартизи- рованные компоненты. Естественно, некоторые проекты потребуют определения новых доменов, однако цель состоит в том, чтобы делать это лишь тогда, когда пи один из существующих доменов не подходит. Это относится к функциям администратора данных, которые мы будем обсуждать подробно в главе 9. Атрибуты, указывающие на недостающие сущности и связи И.югда атрибуты могут указывать на необходимость добавления в модель каких- либо сущностей или связей. В частности, признаками недостающей сущности или связи могут быть атрибуты, являющиеся именами или названиями чего-то другого, нежели сущности, которой они принадлежат. Например, наличие у сущности ТОРГОВЫЙ_АГЕНТ атрибута ЗонаОтветственности ЧПНдТтпгштп^ипгтм В°ЗМОЖНО’ следУет ввес™ новую сущность под названием a_uIILIВЬННОСТИ. Если эта мысль верна, атрибут ЗонаОтветственности заменя- ется связью между сущностями ТОРГОВЫЙ_АГЕНТ и 30НА_0ТВЕТСТВЕНН0СТИ. Анало-
Процесс моделирования данн«.. 127 гпчным образом, наличие у сущности ДЕТАЛЬ атрибута Категория наводит на мысль о возможной сущности КАТЕГОРИЯ, имеющей связь с сущностью ДЕТАЛЬ Атрибуты, чьи идентификаторы включают в себя слово «имя» или «название», являются в этом отношении главными подозреваемыми. Так, наличие у сущно- сти ЗАКАЗ атрибута НазваниеТранспортнойКомпании указывает на необходимость введения новой сущности ТРАНСПОРТНАЯ_КОМПАНИЯ, имеющей связь с сущностью ЗАКАЗ. Это явление следует иметь в виду, поэтому, определив атрибуты для всех сущностей, рабочая группа должна исследовать получившуюся модель на пред- мет атрибутов, которые могут служить указанием на недостающие сущности Ра- зумеется, тог факт, что сущность в принципе существует, не означает, что эту сущность непременно нужно добавить в модель. Может оказаться, что хотя вве- дение сущности ТРАНСПОРТНАЯ_КОМПАНИЯ теоретически возможно, реальная по- требность в ней отсутствует. Может быть и так, что определение этой сущности выходит за рамки диапазона охвата проекта. В этом случае наилучши.м способом предохранить модель от «расползания» по организации може т быть как раз со- хранение атрибута ТранспортнаяКомпания. Проверка модели Последним шагом процесса моделирования данных является проверка модели данных. Это, вероятно, самый важный шаг, поскольку если модель данных не- верна, то неверной будет и структура базы данных, построенной на ее основе. Формы, отчеты и другие элементы приложения будут неправильными либо станут конфликтовать со структурой базы данных, из-за чего построение таких отчетов и форм окажется сложным и дорогим процессом. Кроме того, на данном этапе из- менение модели данных сводится просто к изменению диаграммы «сущность- связь», а для модификации уже построенной базы данных могут потребоваться значительные усилия, как вы узнаете из главы 8. Как говорят инженеры-машино- строители, «лучший способ решить проблему — это прежде всего не иметь ее». Что делает модель данных неверной? Один чрезвычайно важный вопрос, которым зачастую пренебрегают из-за кажу- щейся очевидности ответа, — это вопрос о том, что делает модель данных невер- ной. Есть искушение сказать, что модель данных должна отображать реальный мир, и если модель не соответствует реальности, то она неверна. Проблема за- ключается в том, что модели данных вовсе не моделируют реальность. Этот ис- ключительно важный момент труден для понимания, но уяснив его, вы сможете сэкономить себе массу времени, а ваша работа в команде по моделированию дан- ных будет гораздо успешнее. Немецкий философ Иммануил Кант был первым, кто заявил, что наше вос- приятие реальности целиком и полностью детерминировано природой нашего мышления и органов чувств. Здесь можно провес ти аналогию с компьютером: У компьютера имеется фиксированный набор команд, который ограничивает его вычислительные возможности. Мыслительный аппарат человека также имеет
128 Глава 3. Созланиямоделей данных «сущность—связь» -------------- свой «набор команд». Этот набор команд ограничивав. то, что мы мо щм иать, то как мы мыслим. Мир в том виде, как мы его воспринимаем и .наем, Кант называет термином феноменальный мир. Мир вещей самих но себе, вещей, какими они были бы вне нашего восприятия, суть вещей он называет ноуменальным миром Как человеческие существа, мы не можем ничего знать о ноуменальном мире Все это говорится к тому, что нельзя аргументированно предпочесть какую- либо модель на том основании, что она является лучшим представлением «ре- ального мира». Никто из нас не знает ничего о «реальном мире». Наш мысли- тельный аппарат не позволяет нам знать о нем. Возможно, вы скажете: «Постойте, но ведь есть модели, которые лучше дру- гих отображают то, что люди называют термином реальный мир. Например, сущность ПОЖАРНАЯ-МАШИНА с атрибутами КоличествоПарусов и ДатаПоследне- гоПовышенияВЗвании будет крайне неудачной моделью, поскольку пожарные ма- шины не имеют парусов и их никогда не повышают в звании». Чтобы ответить на этот вопрос, прежде всего следует сказать, что человек соз- дает модели ноуменального мира с помощью своего мыслительного аппарата. На протяжении всей человеческой истории лучшими моделями были те, которые наиболее эффективно помогали нашему виду в деле выживания. Это все, что можно сказать по данному поводу. Мы не можем утверждать, что эти модели являлись наиболее адекватным представлением ноуменального мира, поскольку мы не в состоянии ничего знать об этом мире. Единственное, что мы можем постулировать, — это что упомянутые модели работают достаточно хорошо для того, чтобы люди могли мыслить и общаться друг с другом способом, который по сию пору обеспечивал выживание человечества как биологического вида. Если распространить эти рассуждения на мир компьютеров, можно сказать следующее: модель данных моделирует не реальность, а существующую в чело- веческом представлении модель реальности, какой бы она ни была. Модель дан- ных, описывающая пожарную машину, — это модель существующей в человече- ском представлении модели пожарной машины. Если вы еще не потеряли нить дискуссии, вы можете возразить: «Но челове- ческих моделей пожарной машины могут быть сотни! Некто, видевший пожар- ную машину только на фотографии, имеет одну модель, кто-то другой, чей дом был спасен от от ня пожарной машиной, имеет другую модель, а третий, прорабо- тавший пожарным в течение 30 лет, тоже имеет свою модель, отличную от этих двух. Какую из моделей мы должны взять за основу для нашей модели данных?» Вот этот вопрос ведет нас в правильном направлении, и на него у нас есть от- ве i. Мы должны построить такую модель данных, которая наилучшим образом моделирует ментальную модель, существующую в представлении пользователей системы. Точка. Нам необходимо знать, насколько адекватно наша модель отра- жает то, как пользователи представляют свой мир. Я лично потерял десятки, если не сотни часов на встречах, где кто-то пытался обосновать свою модель данных, говоря, что это «лучшая модель реальности». Очевидно, что любой человек, обладающий другим жизненным опытом и ду-
Процесс моделирования данных 129 мающий по-другому, будет иметь другую «модель реальности» и, соответствен' но, будет возражать против э того утверждения. Особенно тяжело, когда такого рода спор происходит между двумя моделистами, пытающимися обосновать не просто две различные внешние схемы (которые, возможно, удастся интегрировать, как в случае с Брюсом и Зельдой), а две различные версии одной и той же концеп- туальной схемы. Как вы знаете, концептуальная схема может быть только одна. Подведем итог: никому не подвластно создание модели, являющейся адекват- ным представлением реальности. Вместо этого люди создают ментальные моде- ли реальности, более или менее удачно функционирующие для целей выжива- ния. В свою очередь, специалисты по моделированию данных создают модели этих ментальных моделей. Единственно уместным вопросом при тестировании модели данных является следующий: «Насколько хорошо данная модель соот- ветствует ментальным моделям людей, которые будут пользоваться этой систе- мой?» Сам разработчик, занимающийся моделированием данных, может считать, что конструируемая им модель представляет собой довольно странный способ восприятия мира, однако это не должно его заботить. Единственное, что должно иметь значение, — это то, насколько его модель соответствует пользовательско- му видению мира. Надеюсь, теперь, когда вы поняли, что является объектом моделирования, вы никогда не будете говорить. «Моя модель является лучшей моделью реально- сти». Ничего подобного быть просто не может1. Методы проверки модели данных Наиболее распространенный способ проверки модели данных — посредством се- рии обсуждений. Сначала рабочая группа по моделированию данных проводит обсуждение модели данных в своем кругу. Иногда команда из нескольких членов рабочей группы, создавшая часть модели, представляет результаты своей работы тру 1 он команде, создавшей другую часть модели. В процессе обсуждения модель проверяется на соответствие системным требованиям. Разумеется, если требова- ния не очень четкие, то обсуждение может быть лишь поверхностным. Это еще о ша причина, по которой столь важно задать как можно более исчерпывающий набор требований. В ходе обсуждений рабочая группа проверяет, все ли требования, выявлен- ные как при опросе пользователей, так и в процессе наблюдения за их работой, Переводя обсуждение на столь глубокнЛ философский у,х>вень. автор неосторожно упускает из виду 04,111 с> щественнын момент. Дело в том. что пользователи также являются для разработчика частью внешне го мира Сасдовательно. если исходить из принципиальной непознаваемости этого мира, кото- рую так настойчиво подчеркивает автор, то утверждение: «Моя модель более адекватно представляет пользовательскую модель реальности» имеет подсобой ничуть не больше оснований, чем утвержде- ние «Моя модель более адекватно представляет реальность». Нам видится, что объяснение может ’ЫТ^Г?₽а‘,Л0 ,,РОЩС вза"мояеГ,ств“е пользователей с информационной системой оказывается бо- * аффективным. если структура этой системы отражает представления пользователей о деловом еш1 ' И,1ЫМИ <ловам,ь если система «говорит на одном языке» с пользователями. Кроме того есть 1 старое как мир правило: «Клиент всегда прав». - Примеч. пере».
130 Глава 3. Создание моделей данны ^сущность—связь» поддерживаются моделью данных. Кроме тою. группа должна убедиться, что сконструированная ею коицеигуальиая схема позволяет строить все внешние схемы, соответствующие требуемым формам и отчетам. Если предусмотрена поддержка внешних интерфейсов, группа исследует модель данных с целью удо- стовериться, что все требования этих интерфейсов выполняются. На стадии об суждений в рабочей группе часто возникают вопросы, касающиеся требований. Эти вопросы необходимо записывать, чтобы получить разъяснения от пользова телей на следующем этапе. После того как будут исправлены недочеты в модели данных, обнаруженные в ходе обсуждения в рабочей группе, проводится второй раунд обсуждений, на этот раз с самими пользователями. Обычно в данном процессе участвуют один или два «ключевых» пользователя из каждой группы, которая будет работать с новой системой. На этом этапе пользователи дают ответы на все вопросы, воз- никшие при обсуждении модели данных в кругу разработчиков. Кроме того, не- которые аспекты модели могут быть решены исходя скорее из художественных предпочтений, чем из насущной необходимости. Например, одна и та же цель может быть достигнута несколькими способами. В этом случае пользователей просят прокомментировать различные альтернативы. Лучший (но не всегда возможный) способ проведения опроса пользователей — объяснить им значения символов, используемых на диаграмме «сущность—связь», и попросить их дать комментарии по поводу модели данных, как она изображена на диаграмме. Хотя пользователям эта символика вряд ли будет знакома, многие из них способны ее понять и эффективно использовать. Иногда, однако, пользователи будут не способны или не склонны обсуждать модель данных в формате диаграммы «сущность—связь». В таких случаях необ- ходимо сконструировать образцы форм и отчетов, которые отражали бы проект- ные решения, реализованные в модели данных. Например, образец бланка зака- за, в котором есть место для указания имени только одного агента, отражает тот факт, что кардинальное число связи между заказом и агентом на стороне послед- него равно 1. Если пользователь спрашивает: «А куда мне вписать второго аген- та?», очевидно, что максимальное кардинальное число в этом случае должно быть больше единицы. Эгу идею можно развить еще дальше, создавая прототипы форм и отчетов. Однако построение таких прототипов может быть дорого, и часто они делаются юлько для наиболее критичных аспектов модели данных. Проверка модели данных — сложная тема, и ей можно было бы посвятить не одну главу. Но все же лучший способ научиться моделированию данных и провер- ке моделей — поработать вместе с опытными разработчиками моделей над реаль- ными проеюами. В этой области ничто не может заменить собственный опыт. Результатом фазы проверки является модель данных, которая, по мнению разработчиков и пользователей, обладает достаточной устойчивостью для удов- летворения всех требований к новой системе. На основе этой модели можно раз- рабатывать реальную базу данных и другие компоненты.
Построение моделей данных на базе анализа форм и отчетов 131 Построение моделей данных на базе анализа форм и отчетов В этом разделе описывается процесс построения моделей данных, основыва- ющийся на анализе форм и отчетов. Мы будем использовать символы стандарта IDEF1X, но в принципе годится любая методика моделирования. Ваша цель должна состоять в том, чтобы понять, как интерпретировать пользовательские документы и трансформировать объекты, представленные в них, в сущности и связи. Одиночные сущности На рис. 3.4, а показан отчет, в основе которого лежит одиночная сущность под на- званием ИНВЕНТАРЬ. Мы знаем, что речь идет об одиночной сущности, поскольку все присутствующие в отчете атрибуты относятся к одной и той же теме. Сущ- ность ИНВЕНТАРЬ изображена на рис. 3.4, б. ИНВЕНТАРНЫЙ ЯРЛЫК: ИнвентарныйНомер: 100 Описание: Стол ДатаПриобретения: 27.02.2002 Стоимость: $350.00 ИНВЕНТАРНЫЙ ЯРЛЫК: ИнвентарныйНомер: 200 Описание: Лампа ДатаПриобретения: 01.03.2002 Стоимость: $39.95 а ИНВЕНТАРЬ ИнвентарныйНомер Описание ДатаПриобретения Стоимость б Рис. 3.4. Одиночная сущность: а — отчет, базирующийся на одиночной сущности; б — сущность, описывающая отчет с рис. 3.4, а Одиночные сущности, не имеющие связей с другими сущностями, встречают- ся крайне редко. Они действительно существуют, но когда вы обнаруживаете та- кую сущность, следует присмотреться к пей повнимательнее. Может оказаться, что эта сущность участвует в связи, которая демонстрируется другой формой или отчетом. Например, в отчете о проекте может быть приведен список инвен- таря, задействованного в этом проекте. В таком случае надо пересмотреть опре- деление сущности ИНВЕНТАРЬ и включить в него эту связь. В последнем разделе этой главы вы увидите примеры того, как эволюционируют сущности и связи в процессе уточнения модели данных.
132 Глава 3. Создание моделей данных «сущность зязь» Идентифицирующие связи принадлежности ГостнничньЯ счет, изображенный на рис. 3.5, а, ян шстся примером отчета, со- повторяющиеся «„«. Зд«ь группа (Дата. Категория, Стоииость) SZeror в документе несколько раз. Такая повторяющаяся группа указывает I” °™что базовая Сущность (пазовом се ГОСТИНИЧНЫМ .СЧЕТ) может быть свяггава С несколькими экземплярами некоторой другой сущности (назовем се СТРОКА- РАСХОДОВ). ОТЕЛЬ ГРЭНДВЬЮ Си Блафс, Калифорния Номер счета: 1234 Дата поселения: 12.10.2003 Имя клиента: Мэри Джонс 10.12.2003 Проживание $ 99.00 10.12.2003 Питание $ 37.55 10.12.2003 Телефон $ 2.50 10.12.2003 Налог $ 15.00 10.13.2003 Проживание $99.00 10.13.2003 Питание $47.90 10.13.2003 Налог $ 15.00 Итого $315.95 ГОСТИНИЧНЫЙ_СЧЕТ НомерСчета ДатаПоселения ИмяКлиента Итого СТРОКА_РАСХОДОВ ДатаНачисления КатегорияРасходов Сумма --------б------- Итого $315.95 а Рис. 3.5. Идентифицирующие связи принадлежности: а — образец счета; б — идентифицирующая связь принадлежности Но какой тип связи имеет место быть между сущностями ГОСТИНИЧНЫЙ_СЧЕТ и СТРОКА_РАСХОДОВ? Это определенно связь принадлежности, но какого рода — идентифицирующая или нендептифицнрующая? Группа вроде {12.10.2002, Но- мер, $99.00} не имеет смысла вне гостиничного счета. Сама по себе эта группа представляет собой просто некие данные, без всякого контекста. Поэтому связь являегся идентифицирующей, как показано на рис. 3.5, б. Обратите также вни- мание, что для того, чтобы уникальным образом идентифицировать отдельную строку расходов в контексте конкретного счета, необходим композитный иден- тификатор вида {ДатаНачисления, КатегорияРасходов}. Из отчета на рис. 3.5, а мы не можем определить минимальную кардиналь- ность связи между сущностями ГОСТИНИЧНЫЙ.СЧЕТ и СТРОКА_РАСХОДОВ. Она мо- жет быть либо «ноль ко многим», либо «один ко многим». Это пример вопроса, ответ на который дается пользователями. Создается ли счет прежде, чем по- явятся какие-либо расходы, или нет? Пускай в данном случае ответ будет поло- жительный. Тогда минимальное кардинальное число будет равняться нулю, что
Построение моделей данных на базе анализа форм и отчетов 133 и демонстрирует рис. 3,5, б. (Если бы минимальное кардинальное число равня- юсь 1. рядом с закрашенным кружком стоял бы индекс Р.) С противоположной стороны связи минимальное кардинальное число равно 1, поскольку каждая идентификационно-зависимая сущность должна иметь (юдителя. Па рпс. 3.6, а показана вторая версия гостиничного счета, в которой имеется два повторяющихся элемента: один из них — это данные строки расходов, а дру- I ой — имя клиента. Поскольку эти группы не зависят друг от друга, для их пред- ставления используются две различные связи. На рис. 3.6, б изображены две идешификациоипые связи принадлежности, соответствующие этим двум повто- ряющимся группам. ОТЕЛЬ ГРЭНДВЬЮ Си Блафс, Калифорния Номер счета: 1234 Имя клиента: Мэри Джонс Фред Джонс Сэлли Джонс Дата поселения: 12.10.2003 10.12.2003 10.12.2003 10.12.2003 10.12.2003 Проживание Питание Телефон Налог $ 99.00 $ 37.55 $ 2.50 $ 15.00 Итого $315.95 10.13.2003 10.13.2003 10.13 2003 $ 99.00 $ 47.90 $ 15.00 Проживание Питание Налог а ГОСТИНИЧНЫЙ СЧЕТ СТРОКА_РАСХОДОВ КЛИЕНТ ДатаНачисления КвтегорияРасходов Сумме ИмяКлиента Рис. з.е. Гостиничный счет с двумя повторяющимися группами: а — образец счета; о — две идентифицирующие связи принадлежности
134 глава 3. Создание моделей панны» .сущность-связь- сплвниге пне 36 с рис. 3.7. Здесь иАе.пифищщиОШ.о-з.висимщ, сушиоеп СЛОЖНАЯ ОТОКА РАСХОДОВ содержит в себе другую илептифиющисиио-ззвисн ™ С,ЩЙ« Ь (ПОДОТРОКА_ААСХОДОВ). На рис. 3.7, б. таким образом, имеется еще Х^тифипируюша» связь принадлежности - связь между сущностями СЛОЖНАЯ СТРОКА РАСХОДОВ и ПОДСТРОКА РАСХОДОВ. ОТЕЛЬ ГРЭНДВЬЮ Qu ВлаФсЛалиЛОЦния Номер счета. 1234 Дата поселения: 12.10.2003 Имя клиента Мэри Джонс ГОСТИНИЧНЫЙ.СЧЕТ НомерСчета ДатаПоселения ИмяКлиента Итого 10.12.2003 Проживание $99.00 10.12.2003 Питание Завтрак $ 15.25 Обед $ 22 30 $ 37.55 10.12.2003 Телефон $ 2.50 10.12.2003 Налог $ 15.00 10.13.2003 Проживание $ 99.00 10.13.2003 Питание Завтрак $ 15.25 Закуска $ 5.50 Обед $ 27.15 СЛОЖНАЯ_СТРОКА_ РАСХОДОВ ДатаНачисления Категория Расходов ВсегоПоКатегории ПОДСТРОКА_РАСХОДОВ Подкатегория Сумма б $ 47.90 10.13.2003 Налог $ 15.00 Рис. 3.7. Гостиничный счет с вложенными группами: а — образец счета; б — вложенные идентифицирующие связи принадлежности Неидентифицирующие связи принадлежности На рис. 3.8 и 3.9 приведены примеры неидентифицирующих связей принадлеж- ности. На рис. 3.8, а в поле Закреплен за сотрудником есть место для имени одного < /дника, а в поле Служебный автомобиль — для названия одного автомобиля. Таким образом, из этих форм следует, что максимальная кардинальность связи между сущностями АВТОМОБИЛЬ и СОТРУДНИК равна 1:1. Сущности и связи, моде- лирующие ситуацию, показаны на рис. 3.8, б. Ин формации о минимальной кардинальности связи, представленные на рис. 3.8, а, формы не несут. Об этом следует спросить пользователей. Одна из возможностей показана на рис. 3.8, б\ здесь каждый автомобиль должен быть
Построение моделей данных на базе анализа форм и отчетов 13В закреплен за одним сотрудником, ио отдельно взятый сотрудник не обязан иметь служебный автомобиль. ДАННЫЕ ТРАНСПОРТНОГО СРЕДСТВА Номер лицензии Серийный номер Производитель Тип | Год выпуска | Цвет Закреплен за сотрудником ДАННЫЕ О СОТРУДНИКЕ Имя сотрудника Номер сотрудника Почтовый ящик Отдел | Телефон Код оплаты Код квалификации Дата приема на работу Прикрепленный автомобиль а ТРАНСПОРТНОЕ СРЕДСТВО НомерЛицензии СерийныйНомер Произеодитель Тип ГодВыпуска Цвет СОТРУДНИК НомерСотрудника ИмяСотрудника ПочтовыйЯщик Отдел Телефон КодОплаты КодКвалификации ДатаНайма 1 б Рис. 3.8. Неидентифицирующие связи принадлежности вида 1:1: а — образец формы; б — неидентифицирующая связь принадлежности На рис. 3.9, а изображена ситуация, которая часто возникает на практике. От- чет' о занятости общежития демонстрирует связь между общежитием и студента- ми, которые в нем проживают. Однако форма с данными о студенте не содержит информации о связи студента с каким-либо общежитием. Указанием на такую связь может служить атрибут МестныйАдрес, но в действительности местный адрес не обязательно должен быть названием общежития. Это пример случая, когда нет даже намека на одну из сторон связи. Как уже отмечалось выше, не бывает такой вещи, как односторонняя связь. Если А связано с Б, то и Б связано с А, и никак иначе. Поэтому когда вы обна- руживаете две сущности, имеющие связь только в одном направлении, ищите свидетельства наличия этой связи с другой стороны. Если вам не удается найти ни одной формы или отчета, которые бы демонстрировали обе стороны связи, необходимо узнать кардинальные числа связи с недостающей стороны от поль- зователей. На рис. 3.9, б показано, что связь между сущностями ОБЩЕЖИТИЕ и СТУДЕНТ имеет вид «О ко многим», то есть студент не обязан жить в общежитии, хотя и может.
136 Глава 3. Создание моделей данных < Г ОТЧЕТ О ЗАНЯТОСТИ ОБЩЕЖИТИЯ , , Общежитие Ингерсолл Има£.туайнта Адамс, Элизабет Бейкер, Рекс Бейкер, Брайди Чарльз, Стюарт Скотт, Салли Тейлор, Линн Ответственный ПР°«ич-|«-щии Сара и Аллен Френч №'.13 710 104 744 319 447 810 3-556? Курс 80 FR JN so so FR а ОБЩЕЖИТИЕ СТУДЕНТ НазваниеОбщежития НомерСтудента ОтветстеенныйПроживающий Телефон ИмяСтудента Специализация Руководитель Курс Школа ПредыдущийКолледж МестныйАдрес МестныйТелефон ОБЩЕЖИТИЕ НазваниеОбщежития _ДолжностьАссистента_ Телефон _Проживание_ ИмяСтудента Специализация Руководитель Курс Школа ПредыдущийКолледж МестныйАдрес МестныйТелефон СТУДЕНТ НомерСтудента б е Рис. 3.9. Неидентифицирующие связи принадлежности вида 1:14: а — образцы форм неидентифицирующая связь принадлежности; в — использование связи для представления ответственного проживающего
Построение моделей данных на базе анализа форм и отчетов 137 Рисунок 3.9, а ставит перед памп интересную дилемму. Обратите внимание, что сведения об ассистенте по общежитию входят в информацию об общежитии Однако ассистент является студентом. Поэтому, вместо того чтобы помещать атрибут АссистентПоОбщежигию в сущность ОБЩЕЖИТИЕ, можно создать вторую связь между сущностями ОБЩЕЖИТИЕ и СТУДЕНТ, которая представляла бы ноле Ассистент по общежитию. Эта альтернатива изображена на рис. 3.9, в. Но и у этой структуры есть свой недостаток. Согласно отчету о занятости об- щежития, ассистентами по общежитию являются Сара и Аллен Френч. Однако это семейная пара, а не отдельный студент. Означает ли это, что, кроме сущности СТУДЕНТ, нам потребуется еще и сущность СЕМЕЙНАЯ_ПАРА? Соответствующие исправления внести можно, единственный вопрос — будет ли результат стоить того. Вполне возможно, что представлять ассистента с такой точностью и не нужно и что поле Ассистент по общежитию имеет скорее характер примечания, чем указания на связь с определенным студентом пли семейной парой. Это дилемма являет собой весьма показательный пример решений, которые приходится принимать в процессе моделирования данных. Четкого ответа на та- кого рода вопросы не существует: решение должно приниматься на базе скорее .эстетических предпочтений, чем инженерных принципов. Лучшее, что можно сделать, — обсудить эти вопросы с пользователями, по они вряд ли будут в состоя- нии попять все нюансы проблемы, и еще мепыпе шансов, что им вообще будет какое-то дело до этого. Возможно, пн один из подходов не будет полностью удовлетвори тельным, так что вам придется выбирать, чем пожертвовать. Неспецифические (N:M) связи Па рис. ЗЛО, а показаны две формы из книжного магазина, указывающие на необ- ходимость связи вида N:M. Кинга связана с множеством авторов, а автор связан с множеством книг. Соответствующая диаграмма модели IDEF1X изображена па рнс. ЗЛО, 6. Как вы помните из главы 2, некоторые люди считают, что несиецпфнческих связей не существует и что всегда есть какая-то недостающая сущность, посред- ством которой связь N:M может быть разбита па две связи 1:N. Случай с книж- ным магазином представляет собой контрпример к этому утверждению. Мы, ра- зумеется, можем вообразить для этой ситуации какие-то недостающие сущности, по нее они будут выглядеть здесь ненатурально. Не существует какой-либо есте- ственной сущности, которая бы могла стоять между сущностями АВТОР и КНИГА. Следовательно, в этом случае связь нужно оставить в модели данных как име- ющую вид N:M. или песнецпфическую. Что делать с такими связями, вы узнаете чл главы 5, где будет обсуждаться проектирование баз данных. Рассмотрим теперь другую связь вида N:M, которая имеет место в архитек- турной фирме Предположим, из опроса пользователей был сделан вывод о иеобхо- димостн сущностей АРХИТЕКТОР и ПРОЕКТ. Пусть для выявления потенциальных рабочая группа использует диаграмму, подобную изображенiioii на рис. 3.3.
138 Глава 3. Создание моделей давньпо^ун^ uu> inxiiTCKTopV может бЫ1ь И" |1КК,)ЛЬК„ т«™ екгов. и на ОДИН „ ПРОЕКТ должна иметь вид N М образом, связь между сущностям и АРХИ i см и АВТОР Имя ГодыЖизни КНИГА ISBN Название >-------- Издательство ДатаКопирайта б Рис. 3.10. Связь N:M: а — образец формы; б — неспецифическая связь Однако на более позднем этапе группа обнаруживает отчет о назначениях архитекторов на проекты (рис. 3.11, а). Этот отчет демонстрирует необходи- мость еще в одной сущности — НАЗНАЧЕНИЕ. Согласно рис. 3.11, б, сущность НАЗНАЧЕНИЕ имеет две идентифицирующих связи принадлежности: одна — с сущ- ностью ПРОЕКТ, а другая — с сущностью АРХИТЕКТОР. Из опроса пользователей разработчики модели выясняют, что каждый архитектор имеет по меньшей ме- ре одно назначение, но при этом могут быть проекты, на которые не назначен ни один архитектор. Соответствующие минимальные кардинальности показаны на рисунке. Сущность НАЗНАЧЕНИЕ не имеет собственного идентификатора. Как и свой- ственно сущностям, являющимся подчиненной стороной в двух связях, она будет иметь идентификатор, являющийся комбинацией из двух идентификато- ров, унаследованных от сущностей АРХИТЕКТОР и ПРОЕКТ. На рис. 3.12 показан третий пример неспецифических связей. Теперь речь идет о самолетах, пилотах и рейсах. Здесь мы имеем сильную сущность под названием РЕЙС, у которой есть две связи принадлежности: одна с сущностью САМОЛЕТ, а другая с сущностью ПИЛОТ. Различие между рис. 3.11, б и 3.12, б со- стоит в том, что сущность РЕЙС имеет собственный идентификатор, НомерРейса, а связи, в которых участвует эта сущность, не являются идентифицирующими.
Построение моделей данных на базе анализа форм и отчетов 139 Отчет о назначении на проект Название проекта Дом Абернати Менеджер проекта Дж. Смит Начало проекта 11.11.2003 Окончание проекта Архитектор Б. Джексон Телефон 232-8878 Номер офиса J-1133 Начало работы по назначению 12.15 2003 Окончание работы по назначению 3.15 2004 Максимальные трудозатраты по бюджету 345 Максимальные затраты на трудовые ресурсы $27,500 Максимальные затраты на материальные ресурсы $17,500 а ПРОЕКТ НазваниеПроекта МенеджерПроекта НачалоПроекта ОкончаниеПроекта АРХИТЕКТОР НАЗНАЧЕНИЕ НачалоНазначения ОкончаниеНазначения МаксТрудозатраты МаксЗатратыТруд МаксЗатратыМат ________.__________J б Рис. 3.11. Связь, описывающая назначение а — отчет о назначении; б — две идентифицирующие связи принадлежности Рассмотрим диаграммы на рис. 3.10, б, 3.11, б и 3.12, б как некоторую общ- ность. Они образуют континуум возможных связей вида N;M. На рис. 3.10, б сущ- ности КНИГА и АВТОР не имеют между собой никакой промежуточной сущности, и связь между ними моделируется как связь вида N:M. Ни во что другое эта связь не преобразуется. На рис. 3.11, б связь между сущностями ПРОЕКТ и АРХИТЕКТОР, на первый взгляд, имеет вид N:M, но потом обнаруживается промежуточная сущность НАЗНАЧЕНИЕ, которая разбивает данную связь на две связи вида 1:N. рис. 3.12, б ситуация сходна с той, которая имеет место на рис. 3.11, б, но сущность РЕЙС является сильной, а не идентификационно-зависимой. В теории, сущности САМОЛЕТ и ПИЛОТ могли бы иметь связь вида N:M, однако этого не про- исходит благодаря наличию сильной сущности РЕЙС.
140 Гиява 3. Создание ^УН ЭДНАЯДИКОН Я АВИАКОМПАНИЯ ------------------ ---ЛДТА 30 07.2003 ИСХОДНЫЙ ПУНКТ Сиэм ПУНКТ НАЗНАЧЕНИЯ Гонконг ТОПЛИВО НА ВЗЛЕТЕ ВЕС НА ВЗЛЕТЕ_________________________________- САМОЛЕТ Хвостовой номер njzjct ТиП 7148 Вместимость_ 140 _______________________________ ПИЛОТ Имя Номер Часов налета Майкл Нильсон 32887 18,348 ЙЙЙ «моте Межодиаролной а САМОЛЕТ ХвостовойНомер Тип ОбщаяНаработкаПланера ОбщаяНаработкаДвигателя НаработкаДвигателяПослеКапре монта ТекущаяВместимость ДапьностьПолетаПоКонфигурации и ПИЛОТ Номер Имя НомерСоциальнойСтраховки Адрес Город Штат Индекс Телефон ЭкстрТелефон ДатаПоследнегоВылета Часы ДатаПоследнегоОсмотра РЕЙС НомерРейса Дата ИсходныйПункт ПунктНазначения Толли воНаВзлете ВесНаВзлете б 1 i < £ 1 с I Рис. 3.12. Потребность в сильной сущности РЕЙС: а — образец документа; б — две неидентифицирующие связи принадлежности
Построение моделей данных на базе анализа форм и отчетов 141 Подтипы и категории Подтипы и категории сущностей1 могут возникать и процессе моделирования данных по разным причинам. Иногда разработчики обнаруживают, что есть не- сколько сущностей, которые описывают одно и то же. Например, в питомнике Padden Creek сущности РАСТЕНИЕ и МЕБЕЛЬ оказались вариациями одной и той же сущности ПРОДУКТ (см. рис. 3.2). А иногда при анализе идентифицирующей связи выясняется, что идентификационно-зависимая сущность не имеет другого идентификатора, кроме идентификатора родительской сущности. В таких случаях рассматриваемая сущность является категорией, или подтипом, а не идентифика- ционно-зависимой сущностью. Иногда сами формы могут наводить на мысль о необходимости подтипов или категорий. Так, например, затененная часть формы на рис. 3.13, а показывает, что имеется два вида постоянных лицензий на вылов рыбы. Когда вам встречаются формы с затененными полями и другими характеристиками, указывающими на различные типы чего-либо, подумайте о том, чтобы ввести подтипы, или категории. На рис. 3.13, бив показаны две разные версии диаграммы стандарта IDE1X, моделирующей ситуацию с лицензированием рыбной ловли. Во второй версии определена сильная сущность СУДНО, являющаяся самостоятельной по отноше- нию к сущности КОММЕРЧЕСКАЯ_ЛИЦЕНЗИЯ. Обратите внимание, что сущности- категории (пли подтипы) могут иметь не только различные атрибуты, но и раз- личные связи с другими сущностями. Выбор между этими двумя схемами будет содержать в себе долю эстетических предпочтений. Обе схемы могут считаться правильными. Скорее всего, решение будет определяться тем, есть ли где-либо еще надобность в сущности СУДНО. Если нет, го можно использовать вариант на рис. 3.13, б. Модель ЗАКАЗ Завершим мы этот раздел анализом формы, которая настолько распространена, что вы должны значь, как ее смоделировать, просто исходя из своего жизненного опыта. Кроме того, это пример формы, в основе которой лежат сразу несколько сущностей. На рис. 3.14, а изображена форма заказа для мебельной фирмы. Черные линии на .ной форме представляют границы между сущностями. Сначала идет сущность, описывающая саму форму (ЗАКАЗ), затем черная линия, затем данные о покупа- теле (КЛИЕНТ), снова черная линия, затем данные о продавце (ТОРГОВЫЙ_АГЕНТ). Таблица представляет многозначную группу, которая моделируется зависимой сущностью СТРОКА_ЗАКАЗА. Исследовав строку заказа, вы обнаружите, что в ней содержатся как данные, относящиеся к самому заказу' (количество и стоимость), так и описания отдельных товаров. Следовательно, имеется потребность в само- стоятельной сущности ТОВАР. Подтипы относятся к расширенной модели «сущность—связь», а сущности-категории — к модели н)1 FIX Как вы знаете из главы 2. они несколько различаются (сущности-категории, пршщдлежа- Щие одному категориальному кластеру, всегда являются взаимоисключающими). Здесь это различие несущественно, и мы используем оба термина как эквивалентные.
142 Глава 3. Создание моделей данных «сущность-свяАл Лицензия на ловлю рыбы Сезон 2003 г Штат ххххх Номер лицензии* 03-1123432 Имя. - — Улица' Город: I Штат: [ | Индекс: Только для коммерческой ловли Только для спортивной ловли Номер судна. Количество лет по данному адресу: Название судна: Номер лицензии прошлого года: Тип судна: Налоговый идентификатор: а ЛИЦЕНЗИЯ_НА_ЛОВЛЮ НомерЛиценэии Имя Улица Город Штат Индекс КОММЕРЧЕСКАЯ_ЛИЦЕНЗИЯ СПОРТИВНАЯ ЛИЦЕНЗИЯ НомерСудна НазваниеСудна ТипСудна НалогоаыйИдентификатор ЛетПоДанномуАдресу НомерЛицензииПредыдГода ЛИЦЕНЗИЯ_НА_ЛОВЛЮ в Рис. 3.13. Пример категориальной связи: а — форма, демонстрирующая потребность в категориях (подтипах); б — категориальный кластер с двумя категориями; в — одна категория имеет дополнительную саязь
Построение моделей данных на базе анализа форм и отчего» 143 ПРОДАВЕЦ КЛИЕНТ КЛИЕНТ ПРОДАВЕЦ б в Рис. 3.14. Форма заказа: а — образец формы; б — сущность СТРОКА_ЗАКАЗА с двумя идентифицирующими связями; а — сущность СТРОКА_ЗАКАЗА с одной идентифицирующей связью На рис. 3.14, б приведены результаты нашего анализа. Обратите внимание, что сущность СТРОКА_ЗАКАЗА зависит как от сущности ЗАКАЗ, так и от сущности ВАР, Эта сущность имеет композитный идентификатор (НомерЗаказа, КодТова- Ра). Это означает, что конкретный товар может фигурировать в заказе не более одного раза. Также обратите внимание на то, что атрибут ЦенаТовара имеется как в сущности ТОВАР, так и в сущности СТРОКА_ЗАКАЗА Атрибут ТОВАР.ЦенаТовара
144 Глава 3. Создание моделей данных «сущность ет»аь» „кта,reuymvH, цепу товар;,. а атрибут ОТОКА.>ЛК«Л.ЦтаТоад. и,у Хара на помет покупки. При тала,..ЯШ зиичеии» з™х а.рибуто».<»» дают, но потом они могут оказаться различными Нарве 314 « изображено альтернативное решение, при котором оди и от же товар может фигурировать в заказе иеоднокраию. Здесь илнпифицируммдад связь между сущностями ТОВАР и СТРОКА JAKA3A была заменена на неид< чти фннпруюпию Для того чтобы сущность СТРОКА ЗАКАЗА имела идентификатор, создается специальный атрибут НомерСтроки. Теперь полный идентификатор сущности СТРОКА_ЗАКАЗА имеет вид {НомерЗаказа, НомерСтроки}. Второй вариант предпочтительнее, если товар может появляться более чем в одной строке одно го и того же заказа. Итак, в этом разделе были приведены примеры распространенных типов сущностей и связей. В следующем разделе мы покажем, как происходит разра- ботка модели данных при моделировании последовательности взаимосвязанных форм и отчетов. Разработка модели данных: пример Предположим, что администрация вымышленного университета Highline ре- шила создать базу данных, в которой содержались бы сведения о колледжах, кафедрах, профессорско-преподавательском составе и студентах. С целью опре- деления требований к модели данных группа, разработчиков собирает серию отчетов. Далее мы проанализируем эти отчеты и создадим на их основе модель данных. Отчет о колледже Отчет, изображенный на рис. 3.15, содержит данные об одном из колледжей уни- верситета, а именно о колледже бизнеса. Университет имеет подобные отчеты обо всех своих колледжах — инженерном колледже, колледже социальных наук и т. д. Задача группы разработчиков — собрать достаточное количество образцов отчетов о колледжах, чтобы получилась репрезентативная выборка. Допустим, чю отчет на рис. 3.15 отвечает требованию репрезентативности. В рассматриваемом отчете приводятся данные как о колледже в целом (на- звание колледжа, имя декана, номер телефона и местный адрес), так и о каждой кафедре, имеющейся в колледже. Отсюда мы делаем вывод, что модель данных должна содержать сущности КОЛЛЕДЖ ц КАФЕДРА, между которыми имеется связь (рис. 3.16). Связь на рис. 3.16 не является идентифицирующей. Вас, возможно, интересует, как определить, в каком случае использовать идеи гифицнрующую связь, а в ка- ком - неидентифицирующую. Вопрос, который нужно себе для этого задать, звучит так: «Имеет ли сущность-потомок (здесь это КАФЕДРА) явный идентиф»-
Разработка модели данных пример !4в катер, который нс содержит в себе идентификатор сущности родителя?» Ес. I да, то потомок является сильной сущности), и следует испольюпатъ иеи.«-н- тмфп пирующую связь. В нашем случае сущность КАФЕДРА имеет явный иден- тификатор НазваниеКафедры, полому она является сильной сущностью и имеет нсидентпфицирующую связь с сущностью КОЛЛЕДЖ Колледж бизнеса Мзри Джефферсон, декан Телефон: 232-1187 Местный адрес Корпус бизнеса, комната 100 Кафедра Заведующий Телефон Всего ст у;литов Бухгалтерский учет Джексон, Сеймур П. 232-1841 318 Финансы Хью Тень, Сьюзен 232-1414 211 Информационные Браммер, Натаниэль Д. 236-0011 247 системы Менеджмент Татл, Кристин А. 236-9988 184 Производство Барнс, Джек Т. 236-1184 212 Рис. 3.15. Образец отчета о колледже КОЛЛЕДЖ КАФЕДРА Рис. 3.16. Модель данных, построенная на базе отчета о колледже Из отчета на рис. 3.15 невозможно определить, может ли кафедра принад- лежать нескольким колледжам. Ответ на этот вопрос должны дать пользова- тели или дальнейшее исследование форм и отчетов. Здесь мы предположим, что согласно информации, полученной от пользователей, кафедра может принад- лежать только одному колледжу, и таким образом, связь между сущностями КОЛЛЕДЖ и КАФЕДРА имеет вид 1:N. Определить минимальную кардинальность отчет на рис 3.15 также не позволяет. Опять-таки предположим, что согласно информации, полученной от пользователей, любой колледж должен, иметь по крайней мере одну кафедру, а каждая кафедра должна существовать хотя бы в одном колледже. Отчет о кафедре и преподавателях Отчет о кащедре, показанный па рис. 3.17, содержит информацию о кафедре и спи- сок преподавателей, работающих на этой кафедре. Обра’цтге внимание, что в отче-
146 Глава 3. Создание моделей данных «сущность—связь» те указан местный адрес кафедры. Поскольку эти данные отсутствуют в сущности КАФЕДРА, изображенной на рис. 3.16, следует изменить определение этой сущно- сти, добавив в него соответствующие данные (рис. 3.18, а). Эта ситуация являет ся типичной для процесса моделирования данных: сущности и связи постоянно модифицируются по мере анализа форм, отчетов и прочих требований. На рис. 3.18, а связь между сущностями КАФЕДРА и ПРЕПОДАВАТЕЛЬ изображена как неспецифическая. Это было сделано потому, что преподаватель может рабо- тать по совместительству. Команда разработчиков должна произвести дальней- ший анализ требований и определить, разрешено ли в университете совмещение. Если нет, эта связь может быть переопределена как неидентифицирующая связь принадлежности (рис. 3.18, б). Кафедра информационных систем Колледж бизнеса Заведующий: Телефон. Местный адрес: Браммер, Натаниэль Д. 236-0011 Корпус социальных наук, комната 213 Джонс, Пол Д. Паркс, Мэри Б. By, Элизабет Офис Корпус социальных наук, комната 219 Корпус социальных наук, комната 308 Корпус социальных наук, комната 233 Телефон 232-7713 232-5791 232-9113 Рис. 3.17. Образец отчета о кафедре Еще одна возможность заключается в том, что группа может найти форму, отчет или какое-то другое требование, относящееся к сочетанию кафедры и пре- подавателя. Допустим, что группа разработчиков модели данных университета Highline нашла отчет, содержащий сведения о звании и условиях найма каждого преподавателя на каждой кафедре. На рис. 3.18, в показана сущность ДОЛЖНОСТЬ, представляющая этот отчет. Обратите внимание, что сущность ДОЛЖНОСТЬ яв- ляется идентификационно-зависимой как от сущности КАФЕДРА, так и от сущно- сти ПРЕПОДАВАТЕЛЬ. Это означает, что идентификатор сущности ДОЛЖНОСТЬ пред- ставляет собой сочетание идентификаторов сущностей КАФЕДРА и ПРЕПОДАВАТЕЛЬ, то есть {НазваниеКафедры, ИмяПреподавателя}. Во всем последующем обсужде- нии мы будем использовать именно эту модель связи между кафедрой и пре- подавателем. Заведующий кафедрой является преподавателем, поэтому можно внести в мо- дель еще одно усовершенствование, убрав атрибут Заведующий из сущности КАФЕДРА и заменив его связью с сущностью ПРЕПОДАВАТЕЛЬ. Это было проделано на рис. 3.18, г: в связи .Заведование. сущность ПРЕПОДАВАТЕЛЬ является родите- лем. Преподаватель может (но не обязан) заведовать кафедрой, притом макси- мум одной; у каждой кафедры должен быть ровно один заведующий.
Разработка модели данных, пример 147 КОЛЛЕДЖ НазваниеКолледжа ИмяДекана Телефон Корпус Комната КАФЕДРА Р НазваниеКафедры ПРЕПОДАВАТЕЛЬ Заведующий ИмяП; «подавателя Телефон . Корпус ЧислоСтудентов НомерОфиса Корпус Телдфом Комната ~ а КОЛЛЕДЖ КАФЕДРА НазваниеКолледжа Р НазваниеКафедры Р ИмяДекана Телефон Корпус Комната Заведующий Телефон ЧислоСтудентов Корпус Комната ИмяПреподавателя б Корпус НомерОфиса Телефон ПРЕПОДАВАТЕЛЬ КОЛЛЕДЖ КАФЕДРА Р ПРЕПОДАВАТЕЛЬ ДОЛЖНОСТЬ Звание Условия КОЛЛЕДЖ НазваниеКолледжа ИмяДекана Телефон Корпус Комната ДОЛЖНОСТЬ Звание Условия г Рис. 3.1В. Альтернативные модели связи между сущностями КАФЕДРА и ПРЕПОДАВАТЕЛЬ а — модель с неспецифической связью; б — модель с неидентифицирующей связью, в — модель с сущностью ДОЛЖНОСТЬ; г — модель с постом заведующего. представленным в виде связи
148 Глава 3. Создание моделей данных «сущность связь» Благодаря наличию связи _3аведование_ необходимоегь в атрибуте jate. „. дня сущности КАФЕДРА отпадает, и мы удаляем этот атрибут Как правило, у за- ведующего кафедрой имеется собственный кабинет и офисе кафедры Если это так, атрибуты Телефон, Корпус п Комната сущности КАФЕДРА будут дуб ировать атрибуты Телефон, Корпус н НомерОфиса сущности ПРЕПОДАВАТЕЛЬ. В связи с этим, вероятно, можно удалить атрибуты Телефон, Корпус и Комната из сущности КАФЕДРА С другой стороны, телефон преподавателя может не совпадать с официальным телефоном кафедры, и у преподавателя может быть свой офис вне кафедрального офиса Из-за этой возможности мы оставим атрибуты Телефон, Корпус и Комната в сущности КАФЕДРА Отчет о студентах кафедры На рис. 3.19 представлен отчет о кафедре и студентах, для которых данная ка- федра является профильной. Этот отчет указывает на необходимость новой сущности под названием СТУДЕНТ Поскольку студенты не являются идентифи- кационно-зависимыми от кафедр, связь между сущностями КАФЕДРА и СТУДЕНТ определена как неидентифицирующая (рис. 3.20). Исходя из содержимого этого отчета, сущности СТУДЕНТ были присвоены атрибуты НомерСтудента, ИмяСту- дента и Телефон. Список студентов Кафедра информационных систем Заведующий: Браммер, Натаниэль Д Телефон: 236-0011 Имя Студента Номер студента Телефон Джексон, Робин Д. 12345 237-8713 Линкольн, Фред Дж. 48127 237-8713 Мэдисон, Дженис А 37512 237-8713 Рис. 3.19. Второй отчет о кафедре В такой интерпретации отчета есть две тонкости. Во-первых, обратите вни- мание, что атрибут, описывающий имя студента, получил у нас название не Имя- СтудентаКафедры (как если бы мы следовали терминологии отчета), а просто Имя- Студента. Это было сделано потому, что ИмяСтудента — более общее название. Название ИмяСтудентаКафедры не имеет смысла вне связи Специализация. Кроме того, заголовок отчета на рис. 3.19 содержит в себе потенциальную неоднознач- ность. Какой телефон в нем указан - кафедры (КАФЕДРА.Телефон) или заведу- ющего ею преподавателя (ПРЕПОДАВАТЕЛЬ.Телефон)? Этот вопрос должен быть решен с пользователям)г. Скорее всего, имеется в виду кафедральный телефон, то есть атрибут КАФЕДРА.Телефон.
Разработка модели данных пример СТУДЕНТ НомерСтудента ИмяСтудента Телефон Рис. 3.20. Модель с сущностью СТУДЕНТ На pm. 3.21 изображено письмо-приглашение, которое университет рассылает поступившим в нею студентам. Для целей моделирования данных это письмо мо- жет рассматриваться как отчет. Элементы, которые должны быть представлены в модели данных, выделены жирным шрифтом. Кроме данных о студенте, в отчете указана профильная кафедра студента и приведена информация о руководителе. Мистеру Фреду Парксу 123, Эльм-Стрит Лос-Анджелес, Калифорния 98002 Уважаемый мистер Паркс, рад сообщить, что Вы приняты на кафедру бухгалтерского учета университета Highline начиная с осеннего семестра 2000 года. Кафедра бухгалтерского учета находится по адресу: корпус бизнеса комната 210. Вашим руководителем назначена профессор Элизабет Джонсон, номер ее телефона 232-8740, офис расположен в корпусе бизнеса, комната 227 Просьба назначить встречу с руководителем сразу по прибытии в университетский городок Поздравляю, и добро пожаловать в университет Highline' Искренне Ваш, Ян П Сматерс, Президент Рис. 3.21. Письмо-приглашение
150 Глава 3. Создание моделей данных «сущность связь» Основываясь на этом письме, мы добавим в нашу модель связь „Руководство^, Но какая сущность должна играть роль родителя в этой связи? Поскольку руково- дитель является преподавателем, первым побуждением будет сделать родителем сущность ПРЕПОДАВАТЕЛЬ. Однако преподаватель выполняет функции руководите- ля в контексте конкретной кафедры. Поэтому правильнее будет сделать родителем сущность ДОЛЖНОСТЬ (рис. 3.22). Для создания отчета, подобного изображенно- му на рис. 3.22, мы от заданной сущности СТУДЕНТ переходим к сущности ДОЛЖНОСТЬ, а затем к ее родителю, сущности ПРЕПОДАВАТЕЛЬ, из которой и полу- чаем интересующие нас сведения о преподавателе. Но это не просто шаблонное решение. Выбор сущности ПРЕПОДАВАТЕЛЬ в качестве родителя имеет под собой веские основания. Согласно этой модели данных, студент имеет максимум одну специализацию и максимум одного руководителя. Эти ограничения не следуют из какого-либо рассмотренного нами отчета. Возможно, студенты могут иметь и по несколько специализаций, но данный конкретный студент имел только одну. Разработчики должны получить ответ на этот вопрос у пользователей. Рис. 3.22. Модель данных со связью ^Руководство В заголовке письма-приглашения используется обращение мистер. Поэтому в сущность СТУДЕНТ добавлен новый атрибут Обращение. Кроме того, как видно из письма, сущность СТУДЕНТ нуждается в атрибутах, описывающих домашний адрес студента.
Разработка модели данных пример 151 И еще одна проблема обнаруживается в связи с этим письмом- студента зо вут Фред Паркс, но для хранения имени студента в сущности СТУДЕНТ выделен только один атрибут. Трудно с абсолютной точностью выделить имя и фами- лию из одной строки, поэтому лучше иметь два атрибута, в одном из которых будет храниться имя (ИмяСтудента), а в другом фамилия (ФамилияСтудента). Что касается имен преподавателей, то они до сих пор хранились нами в формате «Джонсон, Элизабет». В письме же мы видим это имя в формате «Элизабет Джонсон». Чтобы можно было использовать оба формата имени, разделим ат- рибут ИмяПреподавателя сущности ПРЕПОДАВАТЕЛЬ на два атрибута — ИмяПре- подавателя и ФамилияПреподавателя. Аналогичным образом необходимо преоб- разовать атрибут ИмяДекана. Окончательный вид нашей модели, учитывающий эти изменения, показан на рис. 3.23. ПРЕПОДАВАТЕЛЬ КАФЕДРА КОЛЛЕДЖ Рис. 3.23. Окончательный вид модели данных Этот раздел должен был дать вам представление о работе в реальном проекте по моделированию данных. Формы и отчеты анализируются последовательно, и по мере изучения каждого нового документа происходит постепенное уточне- ние модели данных. Типичной является ситуация, когда модель данных пере- сматривается несколько раз на протяжении процесса моделирования.
152 Глава 3. Создание моделей данных «сущно :ть--свяЗы Домены Хотя стандарт IDEF1X н включает в себя концепцию доменов, он не предусмат ривает какого-либо стандартного способа их описания или отображения. Соот- ветственно, в разных программах для моделирования данных используютоя раз- личные способы определения доменов. На рис. 3.24 изображены домены для модели данных университета Highline, определенные в программе для моделирования данных ERWin. Посмотрите на домен String, и вы увидите что в этом домене определен типовой домен Address (Адрес). В домене Address, в свою очередь, определены типовые домены City (Го- род), State (Штат), Street (Улица) и Zip (Индекс). ERWin позволяет задавать широкий диапазон характеристик домена. На рис. 3.24, б изображен словарь домена (domain dictionary). В этом примере пока- заны свойства домена BuildingName (НазваниеЗдания). В верхнем диалоговом окне отображается тип данных этого атрибута - Char(25), что соответствует фиксиро- ванной символьной строке длиной до 25 байт. Атрибуту НазваниеЗдания назна- чен список допустимых значений. В раскрывающемся списке Valid (Допускается) показывается имя BuildingNameList (СписокНазванийЗданий). При нажатии на кноп- ку с многоточием открывается диалоговое окно Validation Rules (Правила проверки диапазона). Для домена BuildingNameList (СписокНазванийЗданий) имеется прави- ло, задающее список допустимых значений. Один из вариантов использования доменов изображен на рис. 3.25. Он анало- гичен рис. 3.23, за исключением того, что к названиям атрибутов присоединены названия доменов. Например, атрибут ИмяДекана происходит из домена Имя. Атрибуты, использующие домен НазваниеЗдания, обведены на рисунке черным фломастером; всего таких атрибутов три. Если бы потребовалось изменить одно из свойств домена НазваниеЗдания (например, добавить еще одно здание в список допустимых значений), то это изменение было бы унаследовано всеми этими тремя атрибутами. С помощью такого рисунка можно также выявить атрибуты, имеющие разные имена, но происходящие из одного и того же домена. Точно так же можно найти атрибуты, имеющие одинаковые имена, но проис- ходящие из различных доменов и поэтому различающиеся по своей сути. ERWin и другие программные продукты для моделирования данных предла- гают множество других возможностей по использованию доменов. Из данного примера вы можете видеть, как это делается и почему это важно. На этом мы завершаем обсуждение моделирования данных с использовани- ем модели «сущность—связь». Как уже говорилось в начале этой главы, для усвоения приведенного здесь материала полезно будет прочесть его два или три раза. Следующая часть книги будет посвящена проектированию баз данных. В гла- ве 4 мы определим важнейшие термины реляционной модели и обсудим процесс нормализации. Затем из главы 5 вы узнаете, как соединить это все воедино, что- бы на основе моделей данных проектировать реляционные базы данных.
Разработка модели данных пример 153 Qfc Domans Й ? <unknown> • еюь Ф Datetime ft H# Number JS’j CoonlOIM8|Or$ ttft HighltnePlWHsNiMite ‘ RoomNumber ' £j StudentNumber Siring £•£] Academic! ill* S Address : CJ City . £j Stele L3 Sheet •• (j Zip .'•• £j CuildmgNene Г'} CoiiegeNene fr'j DepaftnentName ;',' 4 Er-ploy-rertlerms й p | PetsonName • (, I FirstName f '1 LasJName • - Qj Sa’ualat’ionTitle & t/oJti ; Subject Domains a £d'lMcde. jLogcaJ д| _ Soil ........... •... ‘ -v- AJph^et;crs8y i . НйгзгеЫмЯу bc-mem ’ ' '' • .' ; .. -Cl Acade-n сТй'е -T~l Address -Co Civ ? -Cd swe -CD Sued H^z-P "СЗ^ЕЗилЕЗ X'J; -Cd CcHeceMane -Cp DepalmenlName h-Ci Err.clcvmcnlT eims ;T: > f fiyeJ .MO** | Ltf atsyie ’ -. ?CHARf25|......... ffifflBT 4)ATE IDEDMAL inFriMAin : £’' Requited .. j '• VaSd |Butdin54lerreLisl IN 'themes НгВ' ‘McKrtey h'H'' ( 3 л б Рис. 3.24. Представление доменов в ERWin: а — иерархии доменов; б — определение характеристик домена BuildingName (НазваниеЗдания)
! 54 Глава 3. Создание моделей данных «сущность-связь» Рис. 3.25. Модель данных с именами доменов Резюме Первым шагом процесса моделирования данных является планирование про- екта. Оно включает получение одобрения у руководства, формирование рабо- чей группы, разраоотку стандартов и планирование задач и назначений. По- сле этого определяются системные требования. Разработчики проводят опрос пользователей, наблюдают со стороны за их работой, получают образцы форм и отчетов, исследуют существующие и новые файлы, анализируют формаль- ные интерфейсы и советуются с предметными специалистами. Результатом ра- боты по определению требований является единый информационный репози- торий, содержащий различные заметки, документы, описания структуры файлов
Резюме 105 и другие материалы, которые могут быть использованы при создании модели данных. После того как план проекта составлен и требования определены, начинается собственно процесс моделирования. Он состоит из пяти шагов: определение сущностей, определение связей, определение идентификаторов, определение ат- рибутов и определение доменов (см. рис. 3.1). В действительности этот процесс никогда не является строго последовательным: в ходе определения связей может возникнуть потребность в новых сущностях, в ходе определения атрибутов — в новых доменах, и т. д. Обычно элементы модели данных создаются парал- лельно. Сущности — это некие объекты, за которыми пользователи хотят следить. Потенциальные сущности можно выявлять, анализируя реплики пользовате- лей, наблюдая за их работой, исследуя формы, отчеты и другие документы. Сущности в модели данных имеют динамический характер: по мере продви- жения проекта сущности будут неоднократно добавляться, удаляться и моди- фицироваться. Связи можно выявлять путем исследования всех возможных пар сущностей в модели данных (см. рис. 3.3) либо путем анализа требований. Не существует такого понятия, как односторонняя связь: связи всегда существуют в обоих на- правлениях. Бывает, однако, что в конкретном приложении используется только одно направление связи. В этом случае кардинальные числа для неиспользуемо- го направления связи выясняются в беседе с пользователями. Каждая реальная сущность имеет идентификатор. Если возникают затрудне- ние с определением идентификатора сущности, обычно это говорит о том, что с этой сущностью что-то не в порядке. Возможно, она должна быть частью дру- гой сущности, подтипом или категорией, а может быть, ей требуются одна или несколько идентифицирующих связей. Проблемы с идентификаторами указыва- ют на возможность корректировки модели данных. Атрибуты обычно выявляются в ходе анализа форм, отчетов, описаний струк- туры файлов и других документов. Каждый раз, когда в модель данных добав- ляется новый атрибут, список существующих доменов исследуется на пред- мет того, нет ли в нем домена, который подходил бы для нового атрибута. Если нет, создается новый домен. Домены полезны, поскольку атрибуты на- следуют их свойства: при изменении какого-то свойства домена все атрибу- ты, основанные на этом домене, унаследуют это изменение. Домены могут также использоваться для проведения политики стандартизации данных. Не- которые атрибуты могут указывать на недостающие сущности и связи. Осо- бенно это характерно для атрибутов, содержащих в себе слова «имя» или «на- звание». После того как модель данных построена, производится ее проверка. Никакая модель данных не моделирует реальность, ибо это невозможно. Модель данных является моделью человеческого представления о реальности. Модель неверна
156 Глава 3. Создание моделей данных «сущность связь» только в том случае, если она неадекватно отображает способ, которым пользе, вателп видят свой мир. Проверка модели данных осуществляется в ходе серии обсуждении Как правило, сначала идут обсуждения в кругу разработчиков, а затем в кругу пользователей. Часто модель данных может описываться пользователям не- посредственно в терминах модели «сущность-связь», ио иногда для объясне- ния различных аспектов модели данных требуется создавать разного рода маке- ты и прототипы. Во втором разделе главы было показано, как формы и отчеты используются для построения модели данных, а в заключительном разделе процесс, моделиро- вания данных был проиллюстрирован на примере простой базы данных для вы- мытленного университета. Вопросы группы I 1. Перечислите шаги процесса моделирования данных. 2. Опишите задачи, которые предстоит решить на этапе планирования проекта. 3. Перечислите распространенные источники требований. 4. Как опрос пользователей и наблюдение за их работой используются для разработки компонентов модели данных? 5. Почему' так важно прояснять терминологию в ходе опроса пользователей? 6. Как формы и отчеты используются для разработки компонентов модели данных? 7 Как существующие файлы используются для разработки компонентов мо- дели данных? 8. Что означает термин реконструкция в контексте моделирования данных? 9 Объясните, как формальные интерфейсы могут быть источником требо- ваний 10. Почему использование.формальных интерфейсов растет? И Кто такие предметные специалисты? Каковы преимущества и недостатки работы с предметными специалистами при определении требований? 12. У кажите возможную сущность и возможный атрибут в следующей фразе: «Я группирую заявления от студентов по дате...». 13. У кажше возможную сущность и возможный атрибут в следующей фразе: «Я использую название кафедры преподавателя.. ». Может ли эта фраза ссылаться на Две сущности? Если да, то какие? 14. Ооъяснпте, почему синеок сущностей, вероятнее всего, будет меняться по мере , аботы над проектом.
Вопросы группы I 167 15. Почему важно четко определять значение и способ использо* ния сук» постен? 16. Из каких элементов состоит определение связи? 17. Опишите два способа выявления связей. 18. Объясните своими словами, почему не бывает односторонних связей 19. Может ли быть, чтобы в приложении использовалось только одно направ- ление связи? Почему? 20. Пр1 ведите пример сущности, не имеющей явного идентификатора. Что следует сделать с этой сущностью? 21. Приведите пример (отличный от данного в тексте) двух различных сущ- ностей, имеющих один и тот же идентификатор. 22. Как связаны атрибут и домен? 23. Как создаются домены? 24. Объясните преимущества наследования атрибутами свойств доменов. 25. Как домены могут использоваться для проведения в жизнь политики стан- дартизации данных в организации? 26. Приведите два примера атрибутов, указывающих на необходимость введе- ния новой сущности. Пусть в одном примере атрибут содержит слово «имя» пли «название», а в другом не содержит. 27. Почему важно проверять модели данных? 28. Объясните, почему высказывание: «Моя модель данных более адекватно моделирует реальность, чем твоя», является ложным. 29. Если бы некто высказал вам утверждение, описанное в вопросе 28, что бы вы ему ответили? 30 Объясните смысл следующих двух предложений: «Мы не можем сказать, что человеческие модели являются адекватным представлением реального мира, потому что мы ничего не знаем об этом мире. Единственное, что мы можем утверждать, — это что данные модели работают достаточно хорошо, чтобы люди могли мыслить и общаться друг с другом способом, который по сию пору обеспечивал выживание челове- чества как биологического вида». 31. В чем заключается единственный критерий оценки модели данных? 32. Опишите, как проходит этап обсуждения модели данных в кругу разработ- чиков. 33. Опишите, как проходит этап обсуждения модели данных с пользователями. 34. Покажите, как с помощью макета продемонстрировать пользователям смысл понятия максимальной кардинальности связи между двумя сущ- ностями.
158 Глава 3. Создание моделей данных «сущность < вяз»»» Вопросы группы II Ответьте на следующие вопросы, псцользуя символнку стандарта ШПГ1Х; 35. Исследуйте подписной бланк па рис. 3.26. Щ №Н* PaipejewOMiFofefflsiJw '' »W4* W оМ!«И'®®й,аи,ий’1 (За1ф^(Ш211№фа&<Ч^^>1^иОД №_____________________ ---------------------- Гад ifa Ш_____________ Ошривш Прааггрииынеиа 1И^"^ЯС№№0Ы9ва Ой аЬркы/а. Рис. 3.26. Подписной бланк Основываясь на структуре этого бланка, выполните следующее: 1) Создайте модель, состоящую из одной сущности. Укажите ее иденти- фикатор и атрибуты. 2) Создайте модель с двумя сущностями. Укажите идентификаторы, ат- рибуты, имя связи, ее тип и кардинальность. 3) При каких условиях вы предпочтете первую модель второй? 4) При каких условиях вы предпочтете вторую модель первой? 36. Изучите форму акта о нарушении правил дорожного движения, представ- ленную на рис. 3.27. Закругленные углы служат подсказкой о том, где про- ходят границы сущностей. 1) Создайте модель данных с пятью сущностями. Основываясь на элемен- тах данных, имеющихся в акте, определите идентификаторы и атрибу- ты сущностей. 2) Определите связи между сущностями. Дайте каждой связи имя и ука- жите ее тип и кардинальность. Укажите, какие значения кардинальных чисел были определены в результате анализа данных формы, а какие необходимо уточнить в разговоре с пользователями системы. 37. На рис. 3.28 изображен список сообщений электронной почты с полями From (отправитель), Subject (тема), Date (дата) и Size (размер). Основыва- ясь на этом списке, выполните следующее: 1) Создайте модель данных с одной сущностью. Укажите ее цдентифика тор и атрибуты.
Вопросы группы II 15ft 2) Измените свой ответ на вопрос (1), включив в модель сущности ОТ- ПРАВИТЕЛЬ и ТЕМА. Укажите идентификаторы и атрибуты сущностей, а также типы и кардинальности связей. Укажите, какие значения кардинальных чисел были определены в результате анализа данных на рис. 3.28, а какие необходимо уточнить в разговоре с пользовате- лями системы. 3) В колонке From (Отправитель) на рис. 3.28 можно наблюдать два раз- ных стиля написания адресов электронной почты. Один стиль преду- сматривает отображение реального адреса, а другой — отображение имени абонента в адресной книге электронной почты. Создайте две категории сущности ОТПРАВИТЕЛЬ для этих двух стилей. Укажите их идентификаторы и атрибуты. ДОРОЖНЫЙ ПАТРУЛЬ ШТАТА ВАШИНГТОН. УВЕДОМЛЕНИЕ ОБ ИСПРАВЛЕНИИ НАРУШЕНИЯ ФАМИЛИЯ Кренке ИМЯ Дэвид М. АДРЕС 88-я авеню, 5053 ГОРОД Мисер Айленд ШТАТ Ваш. ИНДЕКС 98040 ВОД. ЛИЦЕНЗИЯ 00000 ШТАТ Ваш. У, ДАТАРОЖД. 27.02.1946 РОСТ 180 ВЕС 70 ЦВ. ГЛАЗ Голуб /К ЛИЦ. ТРАНСП. СР-ВА AAA000 ШТАТ Ваш. ЦВЕТ ГОД 90 МАРКА Saab ТИП 900 VIN ЗАРЕГИСТРИРОВАНО ВЛАДЕЛЕЦ АДРЕС ДАТА НАРУШЕНИЯ МЕС. 11 ДЕНЬ 7 ГОД 2003 ВРЕМЯ (Ч): 9.35 РАЙОН 2 КОМАНД- 17 МЕСТО 17 МИЛЬ К востоку ОТ Энумкума ПО SR410 нарушения Написание текста во время управления транспортным средством ПОДПИСЬ ДОЛЖН ЛИЦА: С. Скотт ЛИЧНЫЙ НОМЕР: 850 3 Это предупреждение, дальнейшие действия не требуются 2 Вы .х-ясА «даетесь для ; тпраеки транспортного средства в ремонт. Дальнейшая эксплуатация не разрешается. 3 НЕМЕДЛЕННО ИСПРАВЬТЕ НАРУШЕНИЯ. В «дмчютас подтверждения аздвдотите эту карточку со своей подписью в течение 15/30 дней (если в этой графе стоит пометка) ПОДПИСЬ ВОДИТЕЛЯ Рис. 3.27. Акт о нарушении правил дорожного движения
160 Глава 3. Создание моделей данных «сущность- связь» 4" lmail.com Big Wind 5/13/200? зкв 4 KB Update 5/12/2002 WOA22S9@sa lmeil.com , ,г . WOA2259@sa Imail :qm Re: Saturday Am ! i'.T 5/11/200? 4 У» WDA2259.@sa Imai com Re: Weather windowl 5/10/2002 4 kfe WDA2259@sa Imail com Re- Howdy* 5/10/2002 « зио " '..Г WOA2259®'sailmail.com Still here . •- - - 5/9/2002 зкв -. - '• WDA2259<s?sa)lmail.com Re: Turle Bay 5/8/2002 4 кв Т tiVDA2259g»sailmail.com Turle Bay Л.-. ...лх.. i 5/8/2002 4 кВ ..р.-. W[>A22S9<?,sailmoi|.co n Re; Hi 5/8/2002 ! зкв WD A22S9<j?$eiirndil .com Sunday, Santa Mane 5/2 ~ ЗКВ Ki6vu® aol.com Cabo, Thurs. Noon 5/2/2002 2 КВ ~~ г WDA2259@$a»lmail .com turbo -< Й у s «:-• < V 5/1/2002 3 КВ г WOA2CS9@sailmail .com on our way ''i-fl-.ji Xv;-.*.1. . 4/28/2002 ЗКВ г Tom Cooper RE: Hole 4/26/2002 3 КВ г Tom,Cooper RE. Holai .. .C4! ... .... 4/Z4/2£)02, 2 КВ Рис. 3.28. Список сообщений электронной почты 38. На рис. 3.29 представлена таблица курсов акций со столбцами Symbol (обозначение), Name (название), Last (последнее значение), Change (изме- нение) и % Chg (изменение в процентах). Основываясь на данных этой таблицы, выполните следующее. 1) Создайте модель данных с одной сущностью. Укажите ее идентифика- тор и атрибуты. 2) Измените свой ответ на вопрос 1), включив в модель сущности КОМ- ПАНИЯ и ИНДЕКС. Укажите идентификаторы и атрибуты сущностей, а также типы и кардинальности связей. Укажите, какие значения кардинальных чисел были определены в результате анализа данных на рис. 3.29, а какие необходимо уточнить в разговоре с пользовате- лями спщ-емы. 3) Таблица на рис. 3.29 содержит данные о стоимости акций по состоя- нию на определенную дату и время. Предположим, что таблица была изменена, и теперь в ней отображается стоимость акций на момент закрытия торгов, а кроме того, имеется новый столбец Дата. Внесите соответствующие модификации в модель, построенную вами в ответе на вопрос 2). 4) Измените ваш ответ на вопрос 3), добавив возможность отслеживания портфеля акций. Пускай портфель акций имеет такие характеристики, как имя владельца, его телефон, адрес и список пакетов акций. Список пакетов должен включать наименование компании и количество акций в пакете. Укажите все вновь созданные сущности, их идентификаторы и атрибуты, а также тип и кардинальность всех связей.
Вопросы группы II 161 Symbol Name Last Change «спи JCOMPX Nasdaq Combined Composite Indan 1.400 74’ 4 87 -035» JINDU Dow Jones Industrial Average Index 9,25510* -1880 -0 21» JINX S8P 500 INDEX 971 14 * -594 -0 80» ALTR Altera Corporation 1345* -0450 -3 24» AMZN Amazon com, Inc 15 62 - *0 690 *4 55» CSCO Cisco Systems, Inc 13 39 » 0 280 -2 05» DELL Dell Computer Corporation 24 58* -0170 -0 69» ENGCX Enterprise Growth C 14 60 * -0 210 -1 42» INTC Intel Corporation 1812» -0 380 -2 05» JNJ Johnson 8 Johnson 53 29 * -0.290 0 54» KO Coca-Cola Company 56 70 » -0 5-80 -t 01» MSFT Microsoft Corporation 53 96* *1.040 *1 97» NKE NIKE, Inc 57 34 * *и’адО *1 02» Рис. 3.29. Таблица курсов акций 5) Измените ваш ответ на вопрос 4), добавив возможность отслежива- ния покупки и продажи акций в портфеле. Укажите все сущности, их идентификаторы и атрибуты, а также тип и кардинальность всех связей. 39 На рис. 3.30 показана таблица сравнительных характеристик однофазных воздушных компрессоров со столбцами HP (мощность в л. с.), Model (мо- дель), Tank Gal (емкость бака), Pump RPM (количество оборотов в мину- ту), CFM Disp (вытеснение в кубических футах в минуту) и DEL’D Air (подача в кубических футах в минуту). Обратите внимание, что в таблице фигури- рует две категории продуктов, различающиеся по давлению воздушного потока: модели серии А обеспечивают давление 125 фунтов на квадратный дюйм, а модели серии Е — 150 фунтов на квадратный дюйм. Основываясь на данных этой таблицы, выполните следующее. 1) Создайте категориальный кластер доя представления этих двух серий. По- рождающая сущность будет иметь атрибуты, являющиеся общими для всех однофазных компрессоров, а сущности-категории будут содержать атрибуты, значение которых различается в разных сериях. Предполо- жим, что серий может быть больше, чем две. Укажите сущности, иден- тификаторы, атрибуты, связи, тип категориального кластера и возмож- ный детерминант. 2) На рис. 3.31 показана альтернативная модель данных о компрессоре. Объясните смысл изображенных сущностей, укажите их тип, а также вид и кардинальность связи. Хорошо ли эта модель подходит для пред- ставления данных с рис. 3.30? 3) Сравните ваш ответ на вопрос 1) с моделью на рис. 3.31. В чем заключа- ются принципиальные различия между двумя этими моделями? Какая из моделей, по вашему мнению, является лучшей?
162 Глава 3. Создание моделей данных «сущность -связь* Single Stage ИО v SI »lr« iVjiUbl». wbrtitm*"6" <»r“A" In modtl r.«mW. !«.. К15АЭ0 КИ&ЭО HF Model Tank Gal Ан Performance Approx I Ship Weight Dimenstonf 1 А ф 125 Е® 150 L 1 w H Pump RPM CFM Dlsp DEL'D Air Pump RPM CFM Dlsp DEL'D I Ah | 1/2 F12A-17 17 680 34 2.2 600 2.9 ie | 136 ] 37 | 14 Ы 3/4 F34A-17 17 1080 5.3 3.1 050 4.7 2.3 | 140 | 37 | 14 25 3/4 F34A-30 30 1080 53 3 1 960 47 23 | ieo | I38 1 16 31 | 1 К1А-30 30 560 6.2 4.0 500 5.7 3.1 I 190 ] 38 16 34 | 1 1/2 К15А-30 30 870 08 62 860 0.7 5.8 | 205 | 40 | 20 d 1 1/2 К15А-60 60 870 е.е 6 2 860 0.7 Se I 315 ] 38 16 2 К2А-30 30 1140 13.1 80 1060 12 0 70 I 205 | 40 I20 39 I 2 К2А-60 60 1140 13.1 8.0 1060 120 _LZJ 315 48 120 34 j 2 GC2A-30 30 480 13.1 0 1 460 12 4 ...Z£ . 270 38 16 36 | 2 GC2A-60 60 480 13.1 0.1 460 12.4 7.8 370 40 20 41 I 3 ОСЗА-60 60 770 21.0 140 740 10 9 12.3 288 38 16 36 | 5 GC5A-80 60 770 21.0 14.0 740 10.0 12.3 J 388 40 20 41 i 5 GC5A-60 60 1020 27.8 178 910 24.6 15.0 410 40 120 41 j 5 GC5A-80 80 1020 27.8 17.8 910 24.6 15 0 450 62 20 41 | 5 J5A-80 60 780 28.7 10.0 770 28 6 18 0 | 570 40 23 43 ! 5 J5A-80 80 780 28.7 10.0 770 28.6 18.0 010 63 23 431 Рис. 3.30. Сравнительные характеристики воздушных компрессоров КОМПРЕССОР ТИП Модель 2 ДавлениеВоздушногоПотока HP ЕмкостьБака ПриблВесБрутто Длина Ширина Высота ОбМин Вытеснение Подача Рис. 3.31. Альтернативная модель данных о компрессорах 4) Предположим, что перед вами стоит задача объяснить различия между этими двумя моделями сообразительному пользователю. Как бы вы это сделали? 40. На рис. 3.32 показано расписание показов фильма «Люди в черном-2» в кинотеатрах Сиэтла. Оно имеет вид списка, каждый элемент которого выглядит следующим образом: название кинотеатра, после него в скоб- ках расстояние в милях от центра, в следующей строке адрес кинотеатра, а в третьей и последующих строках - список сеансов, Взяв за образец эти данные, выполните следующее.
Вопросы группы II 103 Men in Black II Even Tommy Lee Jones at his funniest can’t save Will Struth or this goofy alien flick from sequel-itis. Local Theaters and Showtime* 40 mile» from the center of Seattle, WA Ar? ft Tue, Jul 9 Thy Гц Displaying 1 - 32 results, sorted by distance. A.MC Pacific Place 11 (0.5 miles) 600 Pine St, Seattle (206) 652-2404 Showtimes: 11:00 am, 12:00 pm, 12:45 pm. 1:30 pm. 2:30 pm, 315 pm, 4:00 pm, 5:00 pm, 5:45 pm, 6:30 pm, 7:30 pm, 8:30 pm, 9:00 pm, 10:00 pm, 10 45 pm Neptung Theatre (3.9 miles) 1303 NE 45th, Seattle (206) 633-5545 Showtimes: 11:20 am, 1:30 pm, 3:40 pm, 5:50 pm, 8:00 pm, 10:10 pm Req^l S.tiUevuejGaHer»a„l £ (6.2 miles) 500 106th Ave NE, Bellevue (425) 451-7161 Showtimes: 11:00 am, 11:30 am, 1:00 pm, 1:39 pm, 3:00 pm, 3:30 pm, 5:05 pm, 5:35 pm, 7:10 pm, 7:40 pm, 9:20 pm, 9:50 pm I.С E OaIt. Tree Cine<n-a (6.6 miles) 10006 Aurora Ave N., Seattle (206) 527-1748 Showtimes: 11:45 am, 2:15 pm, 4:45 pm, ?;15 pm, 9:45 pm LCE Ffycton^ Cinemas 8 (7.8 miles) 3505 Factoria Blvd SE. Bellevue (425) 641-9206 Showtimes: 12:00 pm, 1:00 pm, 2:15 pm, 3:15 pm, 4:30 pm, 5:45 pm, 7:30 pm, 8:15 pm, 9:45 pm, 10:30 pm .KirHand..Parkplace X'inema (8 miles) 404 Parkplace Ctr, Kirkland (425) 827-9000 Showtimes: 12:15 pm, 2:30 pm, 4:45 pm, 7:20 pm, 9:35 pm Рис. 3.32. Расписание сеансов 1) Создайте модель данных для этого отчета, состоящую из сущностей ФИЛЬМ, КИНОТЕАТР и СЕАНС, Предположим, что в кинотеатрах могут де- монстрироваться и другие фильмы. Хотя изображенный здесь отчет от- носится к определенной дате, ваша модель данных должна позволять указывать расписание сеансов и для других дней. Укажите идентифи- каторы и атрибуты сущностей. Дайте имя каждой связи, укажите типы связей и их кардинальность. Укажите, какие значения кардинальных чисел можно логически вывести из рис. 3.32, а какие необходимо уточ- нить в разговоре с пользователями системы. Примем, что расстояние от центра города является атрибутом сущности КИНОТЕАТР. 2) Данный отчет был сделан для пользователя, который живет недалеко от центра Сиэтла. Пускай требуется составить такой же отчет, но те- перь для жителя пригорода, такого как Беллевью, Рентон, Редмонд или Такома (все это пригороды Сиэтла). В этом случае расстояние от цен- тра города не может быть атрибутом сущности КИНОТЕАТР. Измените ваш ответ на вопрос 1) для этой ситуации. Укажите идентификаторы и атрибуты сущностей. Дайте имя каждой связи, укажите типы связей и их кардинальность.
164 Глава 3. Создание моделей данных «сущность-связь» Теперь пусть стоит задача построить модель национального масшта- ба Модифицируйте ваш ответ на вопрос 2), чтобы его можно было использовать для различных городов, измените соответствующим об- разом ответ на вопрос 1). Укажите идентификаторы и атрибуты сущ- ностей. Дайте имя каждой связи, укажите типы связей и их карди- нальность. RICE KRISPIES NUTRITION INFORMATION SERVING &2Г iOZ(28.4 9.AaOUTlCUPJ SERVINGS PER PACKAGE. 13 MIHfcCW VITMWSA4D CALORIES PROTEIN CARBOHYDRATE FAT CHOLESTEROL SODIUM POTASSIUM 110 150* 2fi 6g 25 c 3ig OS 08’ 0 mg Omg" 290 mg 3$0mg 35 mg 240mg PERCENTAGE OF U.S. RECOMMENDED DAILY ALLOWANCES (U.S. RDA) PROTEIN 2 10 VIT AMIN A 25 30 VITAMIN C 25 25 THIAMIN 35 40 RIBOFLAVIN 35 45 niacin 35 35 CALCIUM 15 IRON 10 10 VITAMIN D 10 25 VITAMIN 8, 35 35 FOLIC ACID 35 35 PHOSPHORUS 15 MAGNESIUM z 6 ZINC 2 COPPER 2 ТЖ.?11/ AH APOTOW. 30 INGREDIENTS.- RICE. SUGAR Sai T CORN SYRUP, MALT FLAVORING WTAMIN C (SOOIUM ASCORBATE AND ASCORBIC ACID) NIACINAMIDE. IRON VITAMIN 8. IP¥- WDOXINE HYDROCNI ORIDB, VITAM N A (^!LaJ^,Tam‘n b* («’BOFlZJin* B< (THtAMfN HYDROCHLORIDE) AND VITAMIN 0 }' TO KEEP THIS CEREAL FRESH BHT HAS BEEN ADDED TO THE PACKAGING Отчет управления по контролю за продуктами и лекарстаами № 6272 Дата: 30.06.2003 Корпорация Kellogg's Название отчета: сводные данные о продуктах по ингредиентам Кукуруза Corn Flakes Krispix Nutngrain (Кукуруза) Кукурузный сироп Rice Krispies Frosted Flakes Sugar Pops Солод Rice Krispies Sugar Smacks Пшеница Sugar Smacks Nutrigrain (Пшеница) a СПИСОК ПОСТАВЩИКОВ Дата: 06.30.2003 Кукуруза Пшеница Ячмень Wilson J Perkins Pollack McKay Adams Kroner Schmidt Wilson Pollack 2.80 2 72 2.83 2.80 1.19 1.19 1.22 0.85 084 6 Рис. 3.33. Отчеты о содержании пищевых ингредиентов 4) Измените ваш ответ на вопрос 3), включив в модель имена ведущих актеров. Предположим, что роли, которые играют актеры, моделиро- вать не требуется. Укажите идентификаторы и атрибуты новых сущно-
Вопросы группы II 1вв стей. Дайте имя каждой вновь созданной связи, укажите типы связей и их кардинальность. 5) Измените ваш ответ на вопрос 4), включив в модель имена ведущих актеров. Теперь предположим, что роли моделировать нужно. Укажите идентификаторы и атрибуты новых сущностей. Дайте имя каждой вновь созданной связи, укажите типы связей и их кардинальность. 41. Изучите три отчета на рис. 3.33. Данные, указанные в них, типичны для подобного рода отчетов. 1) Создайте список потенциальных сущностей, содержащий столько эле- ментов, сколько, по вашему мнению, требуется. 2) Определите, не являются ли какие-либо из сущностей в вашем списке синонимами. Если да, оставьте в списке только один из каждой группы синонимов. 3) Постройте диаграмму стандарта IDEF1X, демонстрирующую связи ме- жду вашими сущностями. Дайте имя каждой связи и укажите карди- нальность. Укажите, какие значения кардинальных чисел можно логи- чески вывести из рис. 3.33, а какие необходимо уточнить в разговоре с пользователями системы. 42. Изучите обложку компакт-диска, изображенную на рис. 3.34. В верхней половине левой части обложки указаны название произведения, его авто- ры (автор идеи, автор книги, по которой написан мюзикл, авторы музыки и либретто), дирижер/хореограф, продюсеры и аранжировщики. В нижней половине левой части перечислены роли и актеры, их играющие. В правой части обложки перечислены композиции — порядковый номер, название, длительность и герои, исполняющие композиции. (Композицию под номе- ром 10 исполняет актриса Marilyn Horne.) 1) Укажите идентификаторы и атрибуты для сущностей КОМПАКТ-ДИСК, АРТИСТ, РОЛЬ и КОМПОЗИЦИЯ. 2) Сконструируйте диаграмму стандарта IDEF1X, демонстрирующую связи между этими сущностями. Дайте имя каждой связи и укажите карди- нальность. Укажите, какие значения кардинальных чисел можно вывес- ти из содержимого обложки компакт-диска, а какие необходимо уточ- нить в разговоре с пользователями системы. 3) Рассмотрите случай с компакт-диском, на котором записан не мю- зикл, а что-то другое. Очевидно, в этом случае отпадает необходимость в сущности РОЛЬ. Тем не менее, у нас есть необходимость во введении еще одной сущности — АВТОР. Создайте диаграмму стандарта IDEF1X, включающую сущности КОМПАКТ-ДИСК, АРТИСТ, КОМПОЗИЦИЯ и АВТОР. Пускай АРТИСТ может быть как одним лицом, так и группой. Предполо- жим, что некоторые артисты записывают произведения как в составе коллектива, так и по отдельности.
166 Глава 3, Создание моделей данных «сущность^связ^ West Side Story Based on a conception of Jerome Robbins Book by ARTHUR LAURENTS Music by LEONARD BERNSTEIN Lynes by STEPHEN SONDHEIM Entire Original Production Directed end Choreographed by JEROME ROBBINS________ Ongtnally produced on Broadway by Robert E. Griffith and Harold S Prince by arrangemenl with Roger L. Slevens Orchestration by Leonard Bernstein with Sid Ramm and Irwin Kostal HIGHLIGHTS FROM THE COMPLETE RECORDING f Maria........... KIRI ТЕ KANAWA Tony...............JOSE CARRERAS Anita..........TATIANA TROYANOS Riff................KURT OLLMAN and MARILYN HORNE singing «Somewhere» Rosalia..........Louise EdeikenDiesel...... .... Marty Nelson Consuela .. Stella Zambalis Baby John . Stephen Bogardus Fanctsca . Angelina ReauxA-rab Peter Thom Action .... David LivingstonSnowboy.. . ..... Todd Lester Bernardo .. Richard Harrell ГЛ Jet Sono 1—1 (Riff. Action, Beby John Arab Chorus [~2~] Somethings Coming ___, (Tony) [3] Merle ____ (Tony) [4| Tonight (Marla. Tony) [~5~| America (Anita Rosalia Chorus) [~б] Cool (Riff, Chorus) I 7 I One Hand. One Heart ____ (Tony Maria) I 8 | Tonight (Ensemble) ।___ (Entire Cast) I 9 1 I Feel Pretty (Maria. Chorus) [to] Somewhere (A Girt) |~tt] Geo OFicer Krupke (Action, snowboy. Diesel, A-rab. r—i Baby John. Chorus) LlxJ A Boy Like That .—। (Anita, Maria) U2J । Have a Love (Mana Anita) fid] Taunting Scene (Orchestra) fis] Finale L—' (Maria. Tony) t?**l И 47) K37J IW4 (340J (T22j И1Ч [2TSJ I3-3C4 П-21) [2-40] Рис. 3.34. Обложка компакт-диска 4) Объедините модели, разработанные вами при ответе на вопросы 2) и 3). Если это необходимо, создайте новые сущности, но стремитесь к тому, чтобы модель оставалась как можно более простой. Укажите идентификаторы и атрибуты новых сущностей. Дайте имя каждой вновь созданной связи, укажите типы связей и их кардинальность. Задачи по моделированию 43. Танцевальный клуб Джефферсона производит обучение танцам и предла- гает индивидуальные и групповые занятия. Плата составляет S45 в час с человека или пары при индивидуальных занятиях, и S6 в час с человека при групповых занятиях. Индивидуальные занятия проводятся на протя- жении всего дня, с полудня до 22 часов, шесть дней в неделю. Групповые занятия проводятся по вечерам. В танцевальном клубе работают два вида инструкторов: постоянные и при- ходящие. Постоянные инструкторы еженедельно получают фиксированную зарплату, а приходящие получают установленную сумму либо за вечер, либо за работу с конкретным классом. Кроме занятий, танцевальный клуб Джефферсона два раза в неделю орга- низует танцевальные вечеринки с музыкальными записями. Входная пла- та составляет $5 с человека. Танцевальный вечер в пятницу пользуется большей популярностью и собирает в среднем около 80 человек; воскрес-
Задачи по моделированию L 167 ный вечер собирает около 30 посетителей. Цель этих танцевальных вече- ров — предоставить ученикам место для пракгики. Еда и напитки не пре- дусматриваются. Танцевальный клуб хотел бы разработать информационную систему, ко- торая позволяла бы вести учет проведенных занятий и учеников. Помимо того, менеджеры клуба хотели бы знать количество и типы занятий, прове- денных каждым инструктором, а также иметь возможность подсчитать среднюю прибыль, приносимую каждым инструктором за одно занятие. Предположим, танцевальный клуб нанял вас для проектирования базы данных. Первым делом вы решаете создать модель данных. Вы знаете, что вам потребуется опросить пользователей и собрать формы, отчеты и дру- гие документы, могущие быть источником требований. Однако перед этим вы хотите сконструировать пробную модель данных. Вы надеетесь, что эта модель сможет помочь вам сформулировать конкретные вопросы, которые вы будете задавать персоналу танцевального клуба. 1) Для построения пробной модели прочтите описание работы клуба в пре- дыдущих абзацах и выделите из него все важные существительные. Из этих существительных составьте список потенциальных сущностей. 2) Исследуйте список, составленный вами при ответе на вопрос 1), и ис- ключите из него синонимы. Кроме того, идентифицируйте сущности, являющиеся подтипами или категориями. Укажите вероятный иденти- фикатор для каждой сущности. Удалите из модели сущности, суще- ствование которых трудно обосновать. 3) Приведенное выше описание содержит недостаточно данных, чтобы указать атрибуты для выявленных вами сущностей. Поэтому создайте дширамму стандарта IDEF1X, на которой будут показаны только сущ- ности и связи. Дайте имя каждой созданной связи, укажите типы свя- зей и их кардинальность. Обоснуйте принятые решения. 4) Теперь щюанализируйтс вашу модель и составьте список вопросов, от- веты на которые вы хотели бы получить у пользователей, чтобы соста- вить адекватную модель данных. 5) Как по-вашему, является ли удачной идея создания пробной модели данных до проведения опросов пользователей? В чем преимущества та- кого подхода? В чем его недостатки? 44. Бюро проката яхт Сан-Хуана — посредническая фирма, занимающаяся прокатом парусных яхт. Яхты не являются собственностью фирмы — она сдает их от имени владельцев, которые хотят получать доход от своих яхт, когда не пользуются ими. За свои услуги фирма Сан-Хуана берет плату. Фирма специализируется на яхтах, которые могут использоваться для многодневных или недельных походов: самая маленькая из яхт имеет дли- ну 28 футов, а самая большая — 51 фут.
Глава 3. Создание моделей данных «сущность-связь» Каждая яхта на момент сдачи в аренду полностью экипирована. Большая часть инвентаря предоставляется владельцами, но некоторый инвентарь добавляется фирмой. Инвентарь, предоставляемый владель м и, включа- ет в себя предметы, закрепленные на яхте, то есть радиос акции, компасы, глубиномеры и прочий инструмент, плиты и холодильники. Есть и другой инвентарь предоставляемый владельцами, но не являющийся частью яхты. Это могут быть паруса, лини, якоря, спасательные шлюпки, спасательные жилеты, а также то, что находится в каютах: блюда, столовое серебро, кухонные принадлежности, постельные принадлежности и т. д. Фирма Сан-Хуана предоставляет также расходуемый инвентарь и припасы — кар- ты, навигационные книги, таблицы приливов и течений, мыло, полотенца для посуды, туалетную бумагу и тому подобные предметы. Важной составляющей обязанностей фирмы Сан-Хуана является учет инвентаря, имеющегося на яхтах. Часть инвентаря является дорогой, а не- которая его часть, в частности та, что не закреплена на яхте, может легко потеряться или быть украдена. В течение срока проката яхты ответствен- ными за инвентарь являются клиенты. Фирма Сан-Хуана ведет подроб- ный учет клиентов и истории проката яхт. Это требуется не только для маркетинговых целей, но и для того, чтобы иметь записи о путешествиях клиентов. Некоторые маршруты и погодные условия более опасны, чем другие, поэтому фирма желает знать об опыте своих клиентов. По большей части фирма занимается только прокатом яхт, то есть капитан или команда не предоставляется. В некоторых случаях однако, клиенты заказывают услуги капитана или каких-либо других членов команды, и то- гда фирма нанимает соответствующий персонал на договорной основе. Яхты часто требуют обслуживания. Контракты, заключенные фирмой Сан-Хуана с владельцами лодок, требуют от фирмы ведения тщательной записи всех операций по обслуживанию и связанных с этим расходов, включая обычные операции, такие как мойка или замена масла, а также внеплановые ремонты. Иногда ремонт может потребоваться во время рей- са. Например, у яхты может отказать двигатель, когда она будет находить- ся далеко от доков Сан-Хуана. В этом случае клиенты вызывают по радио диспетчера фирмы, который определяет наиболее подходящее место для проведения ремонта и направляет персонал оттуда на аварийную яхту. Чтобы принимать все эти решения, диспетчерам требуется информация об имеющихся ремонтных доках, а также сведения о качестве и стоимости предыдущих ремонтов. Предположим, фирма Сан-Хуана наняла вас для проектирования базы данных. Первым делом вы решаете создать модель данных. Вы знаете, что вам потребуется опросить пользователей и собрать формы, отчеты и дру- гие документы, которые могут быть источником требований. Однако пе- ред этим вы хотите сконструировать пробную модель данных. Вы надее-
Вопросы к прочету *ичШр 1«t тесь, что эта модель сможет помочь вам сформулировать конкретные вопросы, которые вы будете задавать персоналу фирмы 1) Для построения пробной модели прочтите описание работы клуб* в f е- дыдущих абзацах и выделите из него все важные существительные Из этих существительных составьте список потенциальных сущностей 2) Исследуйте список, составленный вами при ответе на вопрос 1), и ис- ключите из него синонимы. Кроме того, идентифицируйте сущности, являющиеся подтипами или категориями. Укажите вероятный иденти- фикатор для каждой сущности. Удалите из модели сущности, суще- ствование которых трудно обосновать. 3) Приведенное выше описание содержит недостаточно данных, чтобы указать атрибуты для выявленных вами сущностей. Поэтому создайте диаграмму стандарта IDEF1X, на которой будут показаны только сущ- ности и связи. Дайте имя каждой созданной связи, укажите типы свя- зей и их кардинальность. Обоснуйте принятые решения. 4) Теперь проанализируйте вашу модель и составьте список вопросов, от- веты на которые вы бы хотели получить у пользователей, чтобы соста- вить адекватную модель данных. 5) Как по-вашему, является ли удачной идея создания пробной модели данных до проведения опроса пользователей? В чем преимущества та- кого подхода? В чем его недостатки? Вопросы к проекту FiredUp Вернитесь к вопросам проекта FiredUp, приведенным в конце главы 2, и ответь- те на них, если вы еще этого не сделали. 1. Рассмотрите шаги процесса моделирования данных (см. рис. 3.1) в контек- сте фирмы FiredUp. Без доступа к персоналу фирмы планирование проек- та по моделированию данных невозможно. Вместо этого составьте список вопросов, ответы на которые позволили бы вам составить план проекта. 2. Рассмотрите возможные источники требований (см. врезку «Источники требований к базе данных»). Как, по вашему мнению, все эти типы требо- ваний могли бы быть применимы к фирме FiredUp? Как вы документиро- вали бы выявленные вами требования? 3. Обратитесь к вашему ответу на вопрос 5 к проекту FiredUp, приведенный в конце главы 2. Как вы осуществили бы проверку этой модели данных? Составьте список вопросов, которые вы задали бы персоналу фирмы FiredUp. Как вы использовали бы макеты? Как вы использовали бы про- тотипы?
170 Глава 3. Создание моделей данных «сущность связь» Вопросы к проекту Twigs Tree Вернитесь к вопросам проекта Twigs Tree, приведенным в конце главы 2, и ответь- те на них, если вы еще этого нс сделали. 1. Рассмотрите шаги процесса моделирования данных (см. рис. 3.1) в контек- сте фирмы Twigs Tree. Без доступа к Саманте и другому персоналу фирмы (если он есть) планирование проекта по моделированию данных невозмож- но. Вместо этого составьте список вопросов, ответы па которые позволили бы вам составить план проекта. 2. Рассмотрите возможные источники требований (см. врезку «Источники требований к базе данных»). Как, по вашему мнению, все эти типы требо- ваний могли бы быть применимы к фирме Twigs Tree? Как вы документи- ровали бы выявленные вами требования? 3. Обратитесь к вашему ответу на вопрос 5 проекта Twigs Tree в конце пре- дыдущей главы. Как вы осуществили бы проверку этой модели данных? Составьте список вопросов, которые вы задали бы Саманте. Как вы ис- пользовали бы макеты? Как вы использовали бы прототипы?
Часть II Проектирование баз данных Во второй части книги рассматриваются вопросы проектирования баз данных. В главе 4 описываются реляционная модель и нормализация. Реляционная мо- дель является стандартом, в соответствии с которым проектируется большинство баз данных на сегодняшний день. Этот стандарт лежит в основе большей части современных СУБД. Важность нормализации состоит в том, что она позволяет проверить качество реляционной схемы. В главе 5 на базе идей, изложенных в гла- ве 4, описывается процесс преобразования моделей данных «сущность—связь» в не зависимые от СУБД реляционные схемы.
Глава 4 Реляционная модель и нормализация Реляционная модель является промышленным стандартом хранения и обработки информации в базах данных. В этой главе будут представлены основные понятия и идеи этой модели. Кроме того, будет рассмотрена нормализация - методика преобразования отношений, имеющих нежелательные свойства, в другие отно- шения, свободные от этих свойств. В главах 6—8 будет описываться SQL язык для определения и обработки отношений. Реляционная модель была впервые предложена Э. Ф. Коддом (Е. F. Codd) в эпохальной статье1 1970 года. Изначально реляционная модель воспринима- лась промышленностью как чересчур «теоретическая», медленная и громоздкая для высокоскоростной обработки транзакций. Это предубеждение было по- ст епенпо преодолено, и к 80-м годам XX века благодаря таким продуктам, как DB2 и Oracle, реляционные базы данных уже активно и успешно использова- лись для обработки больших объемов транзакций. Начнем паше изложение с определения нескольких ключевых понятий. Отношения В главе 1 было сказано, что реляционные СУБД хранят данные в форме таблиц. В действительности это не совсем так. Реляционные СУБД хранят данные в форме отношений, которые представляют собой особую разновидность таблиц. Отно- шением (relation) называется двухмерная таблица, обладающая характеристиками, которые перечислены в приведенной ниже врезке. Во-первых, каждая строка та- кой таблицы содержит данные, описывающие некоторую сущность или ее часть. Во-вторых, каждый столбец таблицы представляет один из атрибутов данной сущности. Так, например, в отношении СОТРУДНИК каждая строка содержит дан- 1 о ределенном сотруднике, а каждый столбец содержит определенную ха- рактеристику сотрудника - имя, телефон или адрес электронной почты, 1 OR W7^td377 эд,tional Model of Data for Ur2° Shared Databanks», Communication of the ACM, vU. 1J/U, Ij. Л! 1—лЦ/
Отношение 17> ХАРАКТЕРИСТИКИ ОТНОШЕНИЯ ------------------------------------------—--------I ♦ Строки содержат данные о сущности. ♦ Столбцы содержат данные об атрибутах сущности ♦ Ячейки таблицы содержат одиночные значения ♦ Все записи в одном столбце имеют один и тот же тип ♦ Каждый столбец имеет уникальное имя ♦ Порядок следования столбцов не важен ♦ Порядок следования строк не важен ♦ Не может быть двух идентичных строк. Кроме того, чтобы таблица могла считаться отношением, каждая ее ячейка должна содержать одно и только одно значение; повторяющиеся элементы в ячей- ке недопустимы. Еще необходимо, чтобы все записи в одном и том же столбце принадлежали к одному и тому' же типу. Например, если третий столбец первой строки таблицы содержит табельный номер сотрудника, то и во всех остальных строках третий столбец также должен содержать табельный номер Каждый столбец отношения имеет уникальное имя, и порядок расположения столбцов несуществен. Наконец, в отношении не может быть двух идентичных строк. Пример отношения и две таблицы, не являющиеся отношениями Таблица 4.1 носит название СОТРУДНИК. Рассмотрим эту таблицу в свете характери- стик, перечисленных во врезке «Характеристики отношения». Во-первых, в каж- дой ее строке содержатся данные о конкретном экземпляре сущности СОТРУДНИК, а каждый столбец представляет определенный атрибут сотрудника. Первые два условия, таким образом, выполнены. В каждой ячейке содержится только одно значение, и все ячейки в столбце принадлежат к одному и тому же типу’. Имена столбцов являются уникальными, а порядок следования столбцов и строк можно свободно менять, не опасаясь потери информации. Наконец, в таблице нет одина- ковых строк. Поскольку данная таблица удовлетворяет всем требованиям, пере- численным во врезке, мы можем классифицировать ее как отношение. Таблица 4.1. СОТРУДНИК НомерСотрудника Имя Фамилия Отдел АдресЭлПочты Телефон 100 Джерри Джонсон Бухгалтерия JJ@somewhere.com 236-9987 200 Мэри Абернати Финансы MA@somewhere.com 444-8898 300 Лиз Сматерс Финансы LS@somewhere.com 777-0098 400 Том Карутерс Бухгалтерия TC@somewhere.com 236-9987 500 Том Джексон Производство TJ@somewhere.com 444-9980 600 Элеонора Калдера Юридический EC@somewhere.com 767-0900 700 Ричард Бандалон Юридический RB@somewhere. com 767-0900 Таблицы 4.2, а и 4.2, б не являются отношениями. Таблица СОТРУДНИК не яв- ляется отношением потому, что в столбце Телефон имеются ячейки, содержащие
174 Глава 4. Реляционная модель и нормализация несколько значении (табл. 4.2, «). Для Тома Карутерса указано три номера теле- фона, а для Ричарда Бандалона - два. Мы же с вами знаем, что в ячейке отноше- ния недопустимы множественные записи. Таблица 4.2, а. Таблица, где важен порядок строк НомерСотрудника Имя Фамилия Отдел АдресЭлПочты Телефон 100 Джерри Джонсон Бухгалтерия JJ@somewhere.com 236-9987 200 Мэри Абернати Финансы М A@somewhere. com 444-8898 300 Лиз Сматерс Финансы LS@somewhere com 777-0098 400 Том Карутерс Бухгалтерия TC@somewhere.com 236-9987, 266-9987, 555-7171 500 Том Джексон Производство TJ@somewhere.com 444-9980 600 Элеонора Калдера Юридический EC@somewhere.com 767-0900 700 Ричард Бандалон Юридический RB@somewhere.com 767-0900 Таблица 4.2, б. Таблица, где в одной ячейке имеется несколько записей НомерСотрудника Имя Фамилия Отдел АдресЭлПочты Телефон 100 Джерри Джонсон Бухгалтерия JJ@somewhere.com 236-9987 200 Мэри Абернати Финансы MA@somewhere.com 444-8898 300 Лиз СмаУерс Финансы LS@somewhere.com 777-0098 400 Том Карутерс Бухгалтерия TC@somewhere. com Факс Домашний телефон: 236-9987 266-9987 555-7171 500 Том Джексон Производство TJ@somewhere.com 444-9980 600 Элеонора Калдера Юридический EC@somewhere.com Факс Домашний телефон: 767-0900 236-9987 555-7171 700 Ричард Бандалон Юридический R B@somewhere .com 767-0900_ 1 аблица 4.2, б не является отношением но двум причинам. Во-первых, порядок следования строк является в ней существенным. В строке, следующей за строкой с именем Тома Карутерса, указан номер его факса. Если мы изменим порядок строк, мы можем потерять связь между Томом Карутерсом и номером его факса, торая причина заключается в том, что не все значения в столбце АдресЭл.Почты имеют одинаковый тип. Одни из них являются адресами электронной почты, & Другие характеристиками номеров телефонов. Обратите внимание, между прочим, что хотя в ячейке отношения может быть максимум одно значение, длина его может быть различной. Таблица 4.3 пред- ставляет собой модификацию табл. 4.2, отличающуюся тем, что в нее добавлен столбец переменной длины под названием Комментарий Хотя комментарии мо- гут быть весьма длинными, а длина их колеблется от строки к строке, в одной ячейке по-прежнему содержится только один комментарий. Таким образом, табл. 4.3 является отношением.
Таблица 4.3. Отношение с атриоутом переменной длины НомерСотрудника 100 Имя Фамилия Отдел АдресЭлПочты Джерри Джонсон Бухгалтерия JJ©somewherecom Телефон 230 9987 Комментарии Приступил к работе а бухгалтерии а марта, получив степень магистра делового администрирования. Этой осенью будет сдавать экзамен на дипломироаамюгр бухгалтера Мэри Абернати Лиз Сматерс Том Карутерс Том Джексон Эгих»юра Калдера Ричард Бандалон Финансы MA®>somewhere com 444-8898 Финансы LS®somewhere com 777-0098 Бухгалтерия TC©somewher® com 238-9987 Производство Tj4»svHX>wtM?re com 444-9980 Юридический EC ' vi. recom 767-0900 Юридический RB чч-иЛм-ге com 767-0900 Работает в ко метео постои «юга «оисутмтанта «рнмимсяого отдела на условиях
176 Глава 4. Реляционная модель и нормализация Замечание по терминологии В мире баз данных термины таблица и отношение используются обычно как си- нонимы Соответственно, с этого момента на протяжении всей книги мы будем этого придерживаться. Теперь каждый раз, используя термин таблица мы будем иметь в виду таблицу, обладающую качествами, которые перечислены во врезке «Характеристики отношения». Но имейте в виду, что есть такие таблицы, кото- рые в строгом смысле слова не являются отношениями. Иногда, особенно в контексте традиционной обработки данных, вместо ти- мина отношение используются термины файл (file) или файл данных (data file). При этом строки отношения называются записями (records), а столбцы полями (fields). Но на этом путаница не кончается. Теоретики баз данных также исполь- зуют свою собственную терминологию: отношения они называют отношениями, столбцы - атрибутами (attributes), а строки - кортежами (tuples). Кроме того, зачастую люди смешивают эти наборы терминов. Обычное дело — слышать рас- суждения об отношении, у которого есть строки и поля. Пока вы знаете, о чем идет речь, это смешение не играет роли. Но прежде чем мы двинемся дальше, необходимо упомянуть еще один потенци- альный источник недоразумений. Согласно врезке «Характеристики отношения», таблица, имеющая одинаковые строки, не является отношением. На практике, однако, этим условием часто пренебрегают. Иногда, особенно при манипулиро- вании отношениями с помощью SQL, мы можем получить таблицу, в которой будут одинаковые строки. Чтобы превратить эту таблицу в отношение, нам сле- довало бы удалить дубликаты. Но если размеры таблицы велики, проверка на наличие одинаковых строк может занимать слишком много времени, поэтому по умолчанию в СУБД такая проверка не выполняется. Итак, на практике сущест- вуют таблицы с дублирующимися строками, которые, тем не менее, называются отношениями. С примерами этой ситуации вы столкнетесь в главе 6. Типы ключей Ключ (key) — это один или несколько столбцов, идентифицирующие строку отношения. Ключ может быть уникальным или неуникальным. Например, для отношения в табл. 4.1 столбец НомерСотрудника является уникальным ключом (unique key), поскольку имеет место взаимно однозначное соотношение между значением атрибута НомерСотрудника и строкой отношения СОТРУДНИК. Таким образом, запрос, предписывающий найти все строки отношения СОТРУДНИК, в ко- торых значение атрибута НомерСотрудника равно 200, выдаст единственную стро- ку. Атрибут Отдел является неуникалъиым ключом (non-unique key). Он является ключом, поскольку с его помощью можно идентифицировать строку отношения, но он не уникален, поскольку потенциально одно и то же значение атрибута Отдел может иметь несколько строк отношения. Запрос, предписывающий найти все строки отношения СОТРУДНИК, в которых значение атрибута Отдел равно Бухгал- терия, выдаст несколько строк.
Типы ключе i 177 Из данных табл. 4.1 может создаться впечатление, что атрибуты НомерСотруд- ника, Фамилия и АдресЭлПочты Являются уникальными идентификаторами. Но для того, чтобы решить, так ли это на самом деле, одних приведенных здесь данных недостаточно. О том, является ли тот или иной столбец уникальным, разра- ботчики должны спросить у пользователей или у других специалистов в данной области. Хороший пример — столбец Фамилия. Скорее всего, это просто случай- ность, что все фамилии в наших данных оказались различными. Если спро- сить пользователей, они, вероятно, скажут, что столбец Фамилия в отношении СОТРУДНИК не всегда является уникальным. Композитные ключи Допустим, пользователи говорят, что в общем случае столбец Фамилия не явля- ется уникальным, зато этим свойством обладает комбинация столбцов Фамилия и Отдел. Видимо, у пользователей есть какие-то соображения, позволяющие за- ключить, что в одном и том же отделе ни при каких условиях не будет двух со- трудников с одинаковыми фамилиями. Если это так, то комбинация {Фамилия, От- дел) является уникальным ключом. Ключ, содержащий два или более атрибута, называется композитным ключом (composite key). Например, уникальная комби- нация {Имя Фамилия, Отдел), будет представлять собой композитный ключ с тремя атрибутами. Первичные ключи и ключ и-кандидаты Теперь предположим, что, по словам пользователей, уникальными ключами яв- ляются атрибут НомерСотрудника, атрибут АдресЭлПочты и комбинация атрибутов {Имя, Фамилия, Отдел). Как вы узнаете из следующей главы, при проектировании базы данных один из этих уникальных идентификаторов необходимо выбрать на роль первичного ключа (primary key). Прочие уникальные ключи называются ключами-кандидатами (candidate keys), поскольку они являются кандидатами на роль первичного ключа. Первичный ключ важен не только тем, что с его помощью можно однознач- но ссылаться на строки, но и тем, что он может представлять строки отношения в связях. (Пример использования идентификационных ключей вы могли видеть в главе 1, в описании базы данных фирмы Lakeview.) Кроме того, во многих СУБД используется способ хранения отношений, основывающийся на значении первичного ключа. СУБД также строят индексы и другие специальные структу- ры, облегчающие и ускоряющие нахождение строк на физическом носителе по значению первичного ключа. Иногда для обозначения отношений применяется следующая схема: сначала указывается имя отношения, а за ним в скобках перечисляются имена атрибутов. Первичный ключ отношения подчеркивается. Например следующая запись обо- значает отношение под названием КЛИЕНТ, имеющее столбцы НомерКлиента, Имя, АдресЭлПочты, Телефон и Баланс: КЛИЕНТ (НзвыКлиента, Имя, АдресЭлПочты, Телефон, Баланс)
178 Глава 4. Реляционная модель и нормализация Первичным ключом огиошеппя КЛИЕНТ яиляекя стлбен НоиерКлиен» У т. го отношения могут быть также ключи •кандидаты, ио они нри данном записи не показываются. функциональные зависимое! и Чтобы понять, что такое функциональные зависимости, сделаем небольшой экс- курс в алгебру. Представьте, что вы покупаете печенье в коробках, и вам говорят что одна коробка стоит $4. Зная это г факт, вы можете вычислить стоимость не- скольких коробок печенья по формуле. СтоимостьПеченья = КоличествоКоробок х $4 Если мы захотим выразить связь между стоимостью печенья и количеством коробок в более общем виде, мы скажем, что стоимость печенья зависит от коли- чества коробок. Это высказывание сообщает нам о характере связи между сто- имостью печенья и количеством коробок, хотя и не дает конкретной формулы. Говоря более формальным языком, стоимость печенья функционально зависит от количества коробок. Данное утверждение может быть записано так: КоличествоКоробок -» СтоимостьПеченья Это выражение можно также прочесть следующим образом: «КоличествоКоро- бок определяет СтоимостьПеченья». Переменная, стоящая слева (в данном случае это КоличествоКоробок), называется детерминантом (determinant). В следующем примере мы вычисляем стоимость приобретаемых деталей, умножая количество деталей на цену одной детали: Стоимость = Количество х Цена В этом случае мы можем сказать, что стоимость функционально зависит от количества и цены, иначе говоря, (Количество, Цена) —> Стоимость Здесь комбинация (Количество, Цена) является детерминантом величины Стоимость. Теперь разовьем эти идеи несколько дальше. Допустим, перед вами лежит ме- шок, о котором вы знаете, что он содержит красные, синие и желтые объекты. Известно также, что красные объекты весят 2 кг, синие 1 кг, а желтые 1,5 кг. Если ваш приятель заглянет в мешок, увидит некоторый объект и сообщит вам его цвет, вы сможете определить вес этого объекта. Этот процесс можно формализо- вать точно так же, как это делалось в предыдущих примерах: ЦветОбъекта -> Масса Таким образом, масса функционально зависит от цвета объекта, или цвет объекта определяет массу. Имеющаяся здесь связь не подразумевает равенства, ио функциональная зависимость, тем не менее, остается. Зная цвет объекта, мы можем определить его массу. Если мы при этом знаем, чго красные объекты имеют форму шара, а синие и желтые — куба, можно также утверждать, что ЦветОбъекта -> (Масса, Форма)
Типы ключей 179 Итак, цвет объекта определяет его массу и форму. Один из способов выразить все эти факты — составить таблицу наподобие следующей. ЦветОбъекта Масса Форма Красный 2 Шар Синий 1 Куб Желтый 1,5 Куб Эта таблица удовлетворяет всем условиям, перечисленным в разделе «Отно- шения» (врезка «Характеристики отношения»), поэтому мы можем называть ее отношением. Первичным ключом этой таблицы является столбец ЦветОбъекта. Записать это отношение можно так: ОБЪЕКТ (ЦветОбъекта, Вес, Форма) Вам может показаться, что мы для получения этого отношения проделали ка- кой-то хитрый трюк, но на самом деле единственное применение отношений — это именно хранение экземпляров функциональных зависимостей. Если у нас есть отношение вида РАСТЕНИЕ (Вид, НомерРастения, Стоимость, Цена) мы храним факты о функциональной зависимости НомерРастения -> (Вид, Стоимость, Цена) Функциональные зависимости с композитными группами Компоипные группы, такие как (Количество, Цена), могут появляться на обеих сторонах функциональной зависимости. Но значение группы меняется в зависи- мости от того, на какой стороне она находится. Например, НомерЗаказа -> (НомерКлиента, КодТовара, Количество) означает, что, зная помер заказа, мы можем определить номер клиента, код товара и количество. Это выражение можно записать как совокупность трех выражений: НомерЗаказа -> НомерКлиента НомерЗаказа -> КодТовара НомерЗаказа -> Количество С другой стороны, выражение (НомерКлиента, КодТовара, Количество) -> Стоимость будет означать, что, зная номер клиента, код товара и количество товара, мы мо- жем определить его стоимость. Обратите внимание, что здесь мы не можем разде- лить детерминант на отдельные составляющие. Например, из приведенной выше формулы не следует, что НомерКлиента —> Стоимость Чтобы получить значение атрибута Стоимость, нам необходимы все три состав- ляющие детерминанта.
180 Глава 4. Реляционная мод.дь и нормали 18ци« Разница между первичным ключом и детерминантом Прежде чем мы двинемся дальше, важно, чтобы вы поняли следующую иь хотя первичный ключ всегда является детерминантом детерминант не </л,а» телъно является первичным ключом. Рассмотрим следуют» »- отношение ПРОЖИВАНИЕ (НомерСтжни. НазваниеОбщежития, Плата) Здесь НомерСтудента является идентификатором студента, НазваниеОб^Жг ,। говорит само за себя, а Плата - это плата за проживание в общежитии Прем» дожим. что все студенты, проживающие в одном общежитии, платят одинаковую СУММУ. Поскольку НомерСтудента является первичным ключом, мы знаем, что Номер- Студента -> (НазваниеОбщежития, Плата). Таким образом. НомерСтудента - это од- новременно и первичный ключ, и детерминант. Кроме того, поскольку все студен- ты, проживающие в одном общежитии, платят одинаково, то НазваниеОбщежития —> Плата. Следовательно, НазваниеОбщежития является детерминантом, но не первич- ным ключом. Нормализация К сожалению, не все отношения одинаково желательны. Таблица, отвечающая минимальному определению отношения, может иметь неэффективную или не- подходящую структуру. Для некоторых отношений изменение данных может привести к нежелательным последствиям, называемым аномалиями модифика- ции (modification anomalies). Аномалии могут быть устранены путем разбиения исходного отношения па два или более новых отношения. В большинстве случаев переопределенные, или нормализованные, отношения являются более предпочти- тельными. Аномалии модификации Рассмотрим отношение СЕКЦИЯ на рис. 4.1. Если мы удалим строку с данными о студенте номер 100, мы потеряем информацию не только о том, что этот студент является лыжником, но и о том, что абонемент в секцию лыж стоит $200. Это на- зывается аномалией удаления (deletion anomaly). Суть ее в том, что удаляя ин- формацию об одной сущности (студент с номером 100 является лыжником), мы теряем факты, относящиеся к другой сущности (плата за абонемент в секцию лыж составляет $200). Выполнив одну операцию удаления, мы теряем информа- цию о двух сущностях. Па примере тою же самого отношения можно продемонстрировать аномалию вставки (insertion anomaly). Допустим, нам нужно записать в базу данных ин- формацию о том, что абонемент в секцию подводного плавания стоит $175. Но мы не можем ввести эти сведения в отношение СЕКЦИЯ, пока хотя бы один сту- ден7 не запишется в секцию подводного плавания. Это ограничение выглядит глупо. Почему для того, чтобы указать стоимость абонемента, требуется ждать,
Нормализация 181 пока кто-нибудь не запишется в секцию? Это ограничение называется аномали- ей вставки. Суть его в том, что мы не можем записать в таблицу некоторый факт об одной сущности, не указав дополнительно некоторый факт о другой сущности СЕКЦИЯ (Нь-мооСтудонта. Секция, Плата) Номер Студента Секция Плата 100 Лыжи 200 150 Плавание 50 175 Сквош 50 200 Плавание 50 Рис. 4.1. Отношение СЕКЦИЯ Отношение на рис. 4.1 может быть использовано в некоторых приложениях, но оно имеет явные проблемы. Мы можем устранить как аномалию удаления, так и аномалию вставки, разделив отношение СЕКЦИЯ на два отношения, каж- дое из которых будет содержать информацию на определенную тему. Например, в одно отношение мы поместим атрибуты НомерСтудента и Секция (назовем это отношение СТУДЕНТ—СЕКЦИЯ), а в другое — атрибуты Секция и Плата (назовем это отношение СЕКЦИЯ—ПЛАТА). На рис. 4.2 изображены те же данные, что и на рнс. 4.1, но разнесенные по двум отношениям. СТУДЕНТ—СЕКЦИЯ (ЧЗМййСтУДйИИ, Секция) Номер Студента Секция 100 Лыжи 150 Плавание 175 Сквош 200 Плавание СЕКЦИЯ—ПЛАТА (СЕКЦИЯ. Плата) Секция Номер Студента Лыжи 200 Плавание 50 Сквош 50 Рис. 4.2. Два отношения, полученных из отношения СЕКЦИЯ Теперь, если мы удалим запись о студенте с номером 100 из таблицы СТУДЕНТ СЕКЦИЯ, мы уже не потеряем тот факт, что абонемент в секцию лыж стоит $200. Более того, мы можем добавить в таблицу СЕКЦИЯ ПЛАТА секцию подводного плавания с указанием стоимости абонемента, не дожидаясь, пока кто-либо запи- шется в эту секцию. Таким образом, аномалии удаления и вставки устранены. Разбиение одного отношения на два имеет, тем не менее, один недостаток. Представим себе ситуацию, когда студент хочет записаться в несуществующую секцию. Пусть, например, студент номер 250 хочет записаться в секцию ракетбо- ia. Мы можем вставить соответствующую строку в отношение СТУДЕНТ СЕКЦИЯ (эта строка будет содержать запись (250, Ракетбол)), но следует ли это делать? Стоит ли разрешать студенту записываться в секцию, которая отсутствует в отно- шении СЕКЦИЯ—ПЛАТА? Другими словами, должна ли система каким-либо обра- зом препятствовать добавлению строк в таблицу СТУДЕНТ—СЕКЦИЯ, если название соответствующей секции отсутствует в таблице СЕКЦИЯ—ПЛАТА? Ответ на этот “опрос содержится в требованиях пользователей. Если такое действие должно
182 Глава 4 Реляционная модель и нормализация быть запрещено, данное ограничение (а оно является не чем иным, как бизнес, правилом) необходимо внести в схему базы данных. Позже, па стадии рсализд. цпп выполнение этого ограничения будет возложено па СУБД, если исно.чьзу емая СУБД предоставляет такую возможность. Если нет, то соблюдение ограни ченпя должно обеспечиваться прикладными iipoi раммами Допустим, пользователи говорят, что спортивные секции могут существо- вать п ю того, как кто-лиоо в них запишется, однако студент нс можс! ^апи** саться в секцию, для которой не указан размер абонементной платы (то есть в секцию, данные о которой отсутствуют в таблице СЕКЦИЯ—ПЛАТА). При проек- тировании базы данных это ограничение можно сформулировать любым из сле- дующих способов: «множество значений атрибута Секция в отношении СТУДЕНТ- СЕКЦИЯ является подмножеством множества значений атрибута Секция в отноше- нии СЕКЦИЯ—ПЛАТА», либо «СТУДЕНТ—СЕКЦИЯ [Секция] является подмножест- вом СЕКЦИЯ—ПЛАТА [Секция]», либо «СТУДЕНТ—СЕКЦИЯ [Секция] с СЕКЦИЯ—ПЛАТА [Секция]». Квадратные скобки в этой записи обозначают столбец данных, извлекаемый из отношения. Смысл этих выражений в том, что атрибут Секция в отношении СТУДЕНТ—СЕКЦИЯ может принимать только те значения, которые имеет атрибут Секция в отношении СЕКЦИЯ—ПЛАТА. Это означает также, что прежде чем ввести название какой-то секции в отношение СТУДЕНТ—СЕКЦИЯ, мы должны проверить, что такое название уже существует в отношении СЕКЦИЯ—ПЛАТА. Ограничения, подобные этому, называются ограничениями ссылочной целостности (referential integrity constraints). Суть нормализации Аномалии, присутствующие в отношении на рис. 4.1, можно интуитивно описать следующим образом. Проблемы возникают из-за того, что отношение СЕКЦИЯ со- держит факты, относящиеся к двум различным темам, а именно: 1) кто из студентов какую секцию посещает; 2) какова абонементная плата в каждой из секций. Дооавляя новую строку, мы вынуждены указывать в ней информацию, затра- I ивающую две различные темы; точно так же, удаляя строку, мы поневоле удаля- ем данные, относящиеся сразу к двум темам. Суть процесса нормализации состоит в следующем. Каждое нормализован- ное 01 ношение должно иметь одну-единствеиную тему. Любое отношение, затрагивающее две или более темы, следует разбить на два или более отношения, у каждого из которых будет только одна тема. Когда мы обнаруживаем отноше- ние с аномалиями модификации, мы устраняем эти аномалии, разбивая отно- шение на два или более новых отношения, каждое из которых имеет собствен- ную тему. При этом не стоит забывать, что разбивая отношение, мы, возможно, порож- даем ограничение ссылочной целостности. Поэтому всякий раз, выполнив эту операцию, следует проверять, не возникли ли новые ограничения
Нормализация 183 В оставвгейся части главы вам предстоит познакомиться с правилами норма- лизации. Все эти правила представляют собой частные случаи только что они сапного процесса. Классы отношений Отношения можно классифицировать по типам аномалий модификации, кото- рым они подвержены. В 1970-х годах теоретики реляционных баз данных посте- пенно сокращали количество этих типов. Кто-то находил аномалию, классифи- цировал ее и думал, как предотвратить ее возникновение. Каждый раз, когда это происходило, критерии построения отношений совершенствовались. Эти классы отношений и способы предотвращения аномалий называются нормальными фор- мами (normal forms). В зависимости от своей структуры, отношение может быть в первой, второй или какой-либо другой нормальной форме. Как показывает рис. 4.3, эти нормальные формы как бы вложены друг в дру- га. То есть отношение во второй нормальной форме является также отношением в первой нормальной форме, а отношение в 5НФ (пятая нормальная форма) на- ходится одновременно в 4НФ, НФБК, ЗНФ, 2НФ и 1НФ. Первая нормальная форма (1НФ) Вторая нормальная форма (2НФ) Третья нормальная форма (ЗНФ) Нормальная форма Бойса—Кодда (НФБК) Четвертая нормальная форма (4НФ) Пятая нормальная форма (5НФ) * Доменно-ключевая нормальная форма (ДКНФ) Рис. 4.3. Взаимосвязь нормальных форм Будучи весьма полезными, нормальные формы имели одно серьезное ограни- чение: не существовало теории, гарантирующей, что какая-либо из этих форм устранит все аномалии. Каждая форма могла устранить только определенные их виды. Эта ситуация разрешилась в 1981 году, когда Р. Фагин (R. Fagin) ввел новую нормальную форму, которую он назвал доменно-ключевой нормальной формой (domain/key normal form), или ДКНФ (DKNF). В важной статье Фагин показал, что отношение в ДКНФ свободно от аномалий модификации всех ти- пов . Он также показал, что любое отношение, свободное от аномалий модифи- кации, должно находиться в ДКНФ. До введения ДКНФ теоретикам реляционных баз данных приходилось про- должать поиск все новых и новых аномалий и нормальных форм. Доказательство 4 агина упростило ситуацию. Если мы можем привести отношение к ДКНФ, то можем быть уверены, что в нем не будет аномалий модификации. Вся загвоздка в том, как привести отношение к ДКНФ. 'К111. «А Normal Form for Relational Databases That Is Based On Domains and Keys», ACM Transactions >n Database Systems, September 1981, pp. 387-415.
184 Глава 4. Реляционная модель и нормализация Нормальные формы от первой до пятой О любой таблице лютых, удомеп«>р«»Ш’П оп^лм-пто отношения что она находится в первой нормальной форме (first normal form, INF) Как эд помните, для того, чтобы таблица была m ношением, она должна обладать дадам- терпстпками, перечисленными в разделе «О i ношения». Отношение на рис. 4.1 находится в первой нормальной форме Как мы толы» что убедились, отношения в первой нормальной форме могут иметь аномалии модификации. Чтобы устранить эти аномалии, мы разбиваем исходное отноше- ние на два пли более новых отношения. Когда мы делаем это, новые отношения оказываются в некоторой другой нормальной форме. Какая именно форма это будет, зависит от того, какие аномалии мы устранили, а также от того, каким аномалиям подвержены получившиеся отношения. 9 1 С Вторая нормальная форма (2НФ) Чтобы понять, что такое вторая нормальная форма, рассмотрим отношение СЕКЦИИ на рис. 4.4. Это отношение имеет аномалии модификации, подобные тем, которые мы рассматривали ранее. Если мы удалим строку с данными о студенте номер 175, мы потеряем тот факт, что абонемент в секцию сквоша стоит S50. Кро- ме того, мы не можем ввести информацию о новой секции, пока в эту секцию не запишется хотя бы один студент. Таким образом, данное отношение подвержено как аномалии удаления, так и аномалии вставки. •Й СЕКЦИИ (НомерСтудента, Секция, Плата) Номер Студента Секция Плата 100 Лыжи 200 100 Гольф 65 150 Плавание 50 175 Сквош 50 175 Плавание 50 200 Плавание 1 50 200 Гольф 65 я Pup. 4.4. Отношение СЕКЦИИ Проблема с этим отношением состоит в том, что оно содержит зависимость, затрагивающую только часть ключа. Ключом является комбинация (НомерСтудента. Секция), но отношение содержит зависимость Секция -> Плата. Детерминант этой зависимости (Секция) представляет собой лишь часть ключа (НомерСтудента, Секция). В этом случае мы можем сказать, что атрибут Плата частично зависит от ключа таб- лицы. номалий модификации не оыло бы, если бы Плата зависела от всего ключа, т ы устранить эти аномалии, мы должны разделить отношение на два отношения. Данный пример приводит нас к определению второй нормальной формы (second normal lonn, 2NF): отношение находится во второй нормальной форме, если каждый из его неключевых атрибутов зависит от всего ключа. В соответ-
Нормальные формы от первой др пятой 186 ствии с этим определением, если отношение имеет в качестве ключа единственный атрибут то оно автоматически находится во второй нормальной форме По- скольку’ключ состоит из одного атрибута, то само собой разумеется, что каждый неключевой атрибут зависит от всего ключа, и частичных зависимостей быть не может. Таким образом, вторая нормальная форма представляет интерес только для тех отношений, которые имеют композитные ключи. Отношение СЕКЦИИ может быть разбито на два отношения во второй нормаль- ной форме. Это те самые отношения, которые изображены на рис. 4 2, а именно СТУДЕНТ—СЕКЦИЯ и СЕКЦИЯ—ПЛАТА. Мы знаем, что новые отношения находятся во второй нормальной форме, поскольку у них обоих ключ состоит из одного атрибута. Третья нормальная форма (ЗНФ) Отношения во второй нормальной форме также могут иметь аномалии. Рассмот- рим отношение ПРОЖИВАНИЕ на рис. 4.5, а. Ключом здесь является НомерСтудента, и имеют место функциональные зависимости НомерСтудента -> Общежитие и Обще- житие -> Плата. Эти зависимости возникают потому, что каждый студент живет только в одном общежитии, и каждое общежитие взимает со всех проживающих в нем студентов одинаковую плату. Например, каждый живущий в общежитии Рэндольф-Холл платит $3200 за квартал. ПРОЖИВАНИЕ (Н.-ыиаСтулиНта, Общежитие, Плата) Ключ: НомерСтудента Функциональные зависимости: Общежитие -> Плата НомерСтудента -> Общежитие -> Плата Номер Студента Общежитие Плата 100 Рэндольф 3200 150 Ингерсолл 3100 200 Рэндольф 3200 250 Питкин 3100 300 Рэндольф 3200 а СТУДЕНТ—ПРОЖИВАНИЕ (НоыеоСтУЭДНта Общежитие) Номер Студента Общежитие 100 Рэндольф 150 Ингерсолл 200 Рэндольф 250 Питкин 1 300 Рэндольф ОБЩЕЖИТИЕ—ПЛАТА (Общежитие. Плата) Общежитие Плата Рэндольф 3200 Ингерсолл 3100 Питкин 3100 б р«. 4.5. Устранение транзитивной зависимости: а — отношение с тп^т-,.;. зависимостью, б - два отношения, не имеющие транзи7ив™Х^^
186 Глава 4. Реляционная модель и нормализация Поскольку атрибут НомерСтудента определяет атрибут Общежитие, а атрибут Общежитие определяет атрибут Плата, то косвенным образом НомерСтудента -> Пла- та Такая структура функциональных зависимое!ей называется тпраизитпиииьй зависимостью (transitive dependency), поскольку атрибут НомерСтудента опреде- ляет атрибут Плата через атрибут Общежитие. Ключом отношения ПРОЖИВАНИЕ является одиночный атрибут НомерСтудента, следовательно, отношение находится во второй нормальной форме (и Общежитие и Плата определяются атрибутом НомерСтудента). Несмотря на это, отношение ПРОЖИВАНИЕ имеет аномалии, обусловленные транзитивной зависимостью Что произойдет, если мы удалим вторую строку отношения на рис. 4.5, я? Мы потеряем не только информацию о том, что студент номер 150 живет в Ингер- солл-Холле, но и тот факт, что проживание в этом общежитии стоит $3100. Это аномалия удаления. А как нам зафиксировать тот факт, что плата за проживание в Кэрригг-Холле составляет $3500? Никак, пока в него не решит вселиться хотя бы один студент. Это аномалия вставки. Чтобы удалить аномалии из отношения во второй нормальной форме, необ- ходимо устранить транзитивную зависимость, что приводит нас к определе- нию третьей нормальной формы (third normal form, 3NF): отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и не имеет транзитивных зависимостей. Отношение ПРОЖИВАНИЕ можно разделить на два отношения в третьей нормаль- ной <|юрме. На рис. 4.5, б мы видим два отношения, получившиеся в результате этой операции: СТУДЕНТ—ПРОЖИВАНИЕ (НомерСтудента, Общежитие) и ОБЩЕЖИТИЕ- ПЛАТА (Общежитие, Плата). Отношение СЕКЦИЯ па рис. 4.1 также имеет транзитивную зависимость. В этом отношении атрибут НомерСтудента определяет атрибут Секция, а атрибут Секция определяет атрибут Плата. Поэтому' отношение СЕКЦИЯ не находится в третьей нор- мальной форме. Разбиение данного отношения на отношения СТУДЕНТ—СЕКЦИЯ (НомерСтудента, Секция) и СЕКЦИЯ—ПЛАТА (Секция, Плата) устраняет указанные аномалии. Нормальная форма Бойса—Кодда (НФБК) К сожалению, даже отношения в третьей нормальной форме могут иметь анома- лии. Рассмотрим отношение НАУЧНЫЙ_РУКОВОДИТЕЛЬ (рис. 4.6, а). Пусть требо- вания к этому отношению таковы. 1. Студент может иметь одну или несколько специализаций. н₽а^1ПЬ1^1Н ководителями по одной и той же специализации могут быть несколько преподавателей. по очной,Преподапатель может осуществлять научное руководство только по одной специализации. лий'' акЖе предполагать, что у преподавателей не бывает одинаковых фа
Нормальные формы от первой до пятой 187 Поскольку студенты могут специализироваться в нескольких областях, атрибут НомерСтудента не определяет атрибут Специализация. Более того, так как сту- дент может иметь несколько научных руководителей, НомерСтудента не определя- ет и атрибут ИмяПреподавателя. Таким образом, сам по себе атрибут НомерСтуден- та не может играть роль ключа. ндуоный_руководитЕЛЬ (НомцсСту, ,=нта, Специализация. ИмяПреподавателя) Ключ (кандидат): (Но ерСтудента Специализация) Функциональные зависимости: ИмяПреподавателя -> Специализация Номер Студента Специализация Имя Преподавателя 100 Математика Коши 150 Психология Юнг 200 Математика Риман 250 Математика Коши 300 Психология Перле 300 Математика Риман СТУДЕНТ—РУКОВОДИТЕЛЬ (Н_мср£туд>нт-, ИмяПреподавателя) Номер Студента Имя Преподавателя 100 Коши 150 Юнг 200 Риман 250 Коши 300 Перле 300 Риман РУКОВОДИТЕЛЬ—ДИСЦИПЛИНА (ИмяПреподавателя. Дисциплина) Имя Преподавателя Дисциплина Коши Математика Юнг Психология Риман Математика Перле Психология Рис. 4.6. Нормальная форма Бойса—Кодда: а — отношение, находящееся в ЗНФ, но не в НФБК; б — два отношения, находящиеся в НФБК Комбинация (НомерСтудента, Специализация) определяет атрибут ИмяПрепода- вателя, а комбинация (НомерСтудента, ИмяПреподавателя) определяет атрибут Спе- циализация. Следовательно, любая из этих комбинаций может быть ключом. Два или более атрибута или группы атрибутов, которые могут быть ключом, называ- ются ключами-кандидатами (candidate keys). Тот из ключей-кандидатов, кото- рый выбирается в качестве ключа, называется первичным ключом (primary key). Кроме ключей-кандидатов, есть еще одна функциональная зависимость, ко- торую следует рассмотреть: атрибут ИмяПреподавателя определяет атрибут Спе- циализация (любой из преподавателей является научным руководителем только по одной специализации; следовательно, зная имя преподавателя, мы можем определить эту специализацию). Таким образом, ИмяПреподавателя является де- терминантом. По определению, отношение НАУЧНЫЙ.РУКОВОДИТЕЛЬ находится в первой нор- мальной форме. Оно также находится во второй нормальной форме, поскольку
188 Глава 4 Реляционная модель и нормали; ни* _ , не имеет исключены* атрибутов (каждый из атрибутов яи я край пен мере одного ключа). Наконец, это о 1 ношение находится в третьей нормаль, нон форме, гак как не имеет транзитивных .зависимоегей Гем не менее, несмот- ря на все это, отношение имеет аномалии модификации Пусть студент номер 300 отчисляется из университета Если мы удалим стрму с информацией об этом студенте, мы потеряем тог факт, что научным руководи, телом на кафедре психологии является некий Перле. Эю аномалия удаления. Далее, как мы можем записать в базу тот факт, что преподаватель Кейнс является научным руководителем па кафедре экономики? Никак, пока не появится хотя бы один студент, специализирующийся па экономике. Это аномалия вставки. Ситуации, подобные только что описанной, приводят нас к определению нор- малъной формы Бойса-Кодда (Boyce-Codd normal form, ВК/NF): отношение на- ходится в НФБК, если каждый детерминант является ключом-кандидатом Отно- шение НАУЧНЫЙ.РУКОВОДИТЕЛЬ не находится в НФБК, поскольку детерминант ИмяПреподавателя не является ключом-кандидатом. Как н в других примерах, отношение НАУЧНЫЙ_РУКОВОДИТЕЛЬ можно разбить на два отношения, не имеющие аномалий. Например, отношения СТУДЕНТ—РУКОВО- ДИТЕЛЬ (НомерСтудента, ИмяПреподавателя) и РУКОВОДИТЕЛЬ—СПЕЦИАЛИЗАЦИЯ (Имя- Преподавателя, Специализация) не имеют аномалий. Отношения в НФБК не имеют аномалий, относящихся к функциональным зависимостям, и некогда казалось, что вопрос с аномалиями модификации на этом исчерпан. Однако вскоре обнаружилось, что аномалии могут быть обуслов- лены и иными причинами, нежели функциональные зависимости. Четвертая нормальная форма (4НФ) Рассмотрим отношение СТУДЕНТ на рис. 4.7, которое отображает связи между'сту- дентами, специальностями и секциями. Предположим, что студенты могут иметь несколько специализаций и заниматься в нескольких различных секциях. В таком случае единственным ключом является комбинация (НомерСтудента, Специализа- ция, Секция). Например, студентка номер 100 специализируется по музыке и бух- галтерскому учету и, кроме того, посещает секции плавания и тенниса, а студент номер 150 специализируется только по математике и занимается бегом. СТУДЕНТ (НомерСтудента. Специализация, Секция) Многозначные зависимости: НомерСтудента —> -> Специализация НомерСтудента -> -> Секция Номер Студента Специализация Секция 100 Музыка Плавание 100 Бухгалтерский учет Плавание 100 Музыка Теннис 100 Бухгалтерский учет Теннис 150 Математика Оздоровительный бег Рис. 4.7. Отношение с многозначными зависимостями
Нормальные формы от первой до пятой 189 Какова связь между атрибутами НомерСтудента и Специализация' Это не функ шюнтльная зависимость, поскольку у студента может быть несколько специаль- ностей Одному и тому же значению а трибута НомерСтудента может соответствовать много значений атрибута Специализация. Помимо того, одному и тому же значению атрибута НомерСтудента может соответствовать мною шачеиий атрибута Секция Такая зависимость атрибутов называется мпогашачиой чаншимостъю (multi- line dependency) Многозначные зависимое! и приводят к аномалиям модифи кацнп. Для начала обратите внимание на избыточное! ь данных на рис 4 7 Сту- дентке номер 100 посвящено четыре записи, в каждой из которых указана одна из ее специализаций и одна из посещаемых ею секций. Если бы те же данные хранились в меньшем количестве строк (скажем, было бы две строки — одна для музыки и плавания, а другая для бухгалтерского учета и тенниса), это дезориенти- ровало бы пользователей Получалось бы, что студентка номер 100 плавает только тогда, когда специализируется на музыке, а в теннис играет только тогда, когда специализируется на бухгалтерском учете Но такая интерпретация нелогична. Специальности и секции совершенно независимы друг от друга. Поэтому, чтобы избежать таких неверных заключений, мы храним все сочетания специальностей и секции. Допустим, что студентка номер 100 решила записаться в секцию лыж, и по- этому мы добавляем в таблицу строку [100, Музыка, Лыжи], как показано на рис. 4.8, а. В данный момент из отношения можно сделать вывод, что эта сту- дентка занимается лыжами только как музыкант, но не как бухгалтер. Чтобы данные имели согласованный характер, мы должны добавить столько строк, сколько имеется специальностей, и в каждой из них указать секцию лыж. Таким образом, мы должны добавить строку [100, Бухгалтерский учет, Лыжи], как показа- но на рис. 4 8. б. Это аномалия обновления: требуется слишком много модифика- ций, чтобы внести в данные одно простое изменение. Вообще говоря, многозначная зависимость существует когда отношение имеет минимум три атрибута, причем два из них являются многозначными, а их значе- ния зависят только от третьего атрибута. Другими словами, в отношении R (А, В, С) существует многозначная зависимость, если А многозначным образом определяет В и С, а сами В и С не зависят друг ог друга. Как мы видели из предыдущего при- мера, НомерСтудента многозначно определяет атрибуты Специализация и Секция, но сами Специализация и Секция не зависят друг от друга. Вернемся вновь к рис. 4.7. Обратите внимание на то, как обозначаются много- значные зависимости: НомерСтудента ->-> Специализация и НомерСтудента Сек- ция. Это читается следующим образом: «Атрибут НомерСтудента многозначно опре- деляет атрибут Специализация» и «Атрибут НомерСтудента многозначно определяет атрибут Секция». Данное отношение находится в НФБК (2НФ — поскольку его ключом является совокупность всех атрибутов, ЗНФ - так как отсутствуют транзитивные зависимости, и НФБК поскольку нет неключевых детерминан- тов). Однако, как мы убедились, оно имеет аномалии: если студент берет допол- нительную специализацию, мы должны добавить в отношение столько строк в скольких секциях данный студент занимается, и в каждой из этих строк указать
190 Глава 4. Реляционная модель и нормализация новую специализацию. То же самое справедливо и для случая, когда студент записывается в новую секцию. Если студент отказывается or одной из специали- заций, мы должны удалить все строки, где указана данная специализация Если студент занимается в четырех секциях, то название специализации будет содер- жаться в четырех строках, и все эти строки необходимо будет удалить студент (номугСтудачга, Слеша:еааша, Секция) Номер Студента Специализация Секция 100 Музыка Лыжи 100 Музыка Плавание 100 Бухгалтерский учет Плавание 100 Музыка Теннис 100 Бухгалтерский учет Теннис 150 Математика Оздоровительный бег а Номер Студента Специализация Секция 100 Музыка Лыжи 100 Бухгалтерский учет Лыжи 100 Музыка Плавание 100 Бухгалтерский учет Плавание 100 Музыка Теннис 100 Бухгалтерский учет Теннис 150 Математика Оздоровительный бег б Рис. 4.8. Отношение СТУДЕНТ с аномалиями вставки а — вставка одной строки; б — вставка нескольких строк Чтобы устранить эти аномалии, мы должны избавиться от многозначной за- висимости. Мы сделаем это, создав два отношения, в каждом из которых будет только один многозначный атрибут. Результирующие отношения не будут иметь аномалии. Это отношения СТУДЕНТ—СПЕЦИАЛИЗАЦИЯ (НомерСтудента, Специали- зация) и СТУДЕНТ—СЕКЦИЯ (НомерСтудента, Секция), изображенные на рис. 4.9. СТУДЕНТ—СПЕЦИАЛИЗАЦИЯ (Н. ме, С |у„ентз. Специализация) Номер Студента Специализация 100 Музыка 100 Бухгалтерский учет 150 Математика СТУДЕНТ—СЕКЦИЯ (НомерСтудента, Секция) Номер Студента Секция 100 Лыжи 100 Плавание 100 Теннис 150 Оздоровительный бег Рис. 4.9. Устранение многозначной зависимости Исходя из сделанных нами наблюдений, мы определим четвертую нормаль- ную форму (fourth normal form, 4NF) следующим образом: отношение находится в четвертой нормальной форме, если оно находится в НФБК и не имеет иного-
Доменно-ключевая нормальная форма (ДКНФ) 191 злачных зависимостей. После обсуждения доменно-ключевой нормальной фор- мы (далее в этой главе) мы вернемся к описанию многозначных зависимостей ЛО уже в другом, более интуитивном ключе. Пятая нормальная форма (5НФ) Пятая нормальная форма (fifth normal form, 5NF) связана с зависимостями, име- ющими довольно-таки неопределенный характер. Речь идет об отношениях, кото- рые можно разделить на несколько более мелких отношений, как мы это делали выше, но затем невозможно восстановить. Условия, при которых возникает эта ситуация, не имеют ясной, интуитивной интерпретации. Нам неизвестно, каковы следствия таких зависимостей; мы не знаем даже, есть ли у них какие бы то ни было практические следствия. За более подробной информацией о пятой нормаль- ной форме обращайтесь к работе Дэйта, которая цитировалась ранее в этой главе. Доменно-ключевая нормальная форма (ДКНФ) Все описанные выше нормальные формы были выделены в процессе исследова- ния аномалий у отношений, которые находились в нормальной форме более низ- кого порядка: обнаружение аномалий модификации у отношений во второй нор- мальной форме привело к определению третьей нормальной формы, и т. д. Хотя каждая нормальная форма решала часть проблем, найденных у предыдущей нор- мальной формы, никто не мог сказать, какие проблемы еще не выявлены. Каж- дый такой шаг являлся прогрессом на пути к представлению об оптимальной структуре базы данных, однако никто не мог гарантировать, что не будет обнару- жено еще каких-либо аномалий. В этом разделе мы рассмотрим нормальную форму, которая будет свободна от аномалий любого типа. Когда мы приводим отноше- ния к этой форме, мы знаем, что в этом случае даже скрытые аномалии, связан- ные с пятой нормальной формой, возникнуть не могут. В 1981 году Фагип опубликовал важную статью, в которой ввел понятие доменно-ключевой нормальной формы, пли ДКНФ (domain/key normal form, DKNF)'. Он показал, что отношение в ДКНФ не имеет аномалий модификации, и, оолее того, любое отношение, не имеющее аномалий модификации, должно находиться в ДКНФ. Это открытие положило конец введению нормальных форм, и теперь в нормальных формах более высокого порядка нет необходимости — по крайней мере, для устранения аномалий модификации. Столь же важно и то, что определение доменно-ключевой нормальной формы затрагивает только понятия домена и ключа понятия фундаментальные и близ- кие сердцу специалистов в области баз данных. Они непосредственно поддержи- ваюгся существующими СУБД (или, по крайней мере, могут поддерживаться). R. Fagin «Л Normal Form for Relational Databases That Is Based On Domains and Kevs», ACM Transactions on Database Systems, September 1981, pp. 387-415.
1Q2 глава 4. Реляционная модель и нормализация R каком-то смысле работа Фагина формализовала и обосновала я т ино п,е ХХты верил,, „итуитииио, ..о были не и состоянии 1044,0 «,„ Определение Понятие ДКНФ весьма просто: отношение находится в доменно-ключевой нор- мальной форме, если каждое ограничение, накладываемое на это отношение, я ь ляется логическим следствием определения доменов и ключей. Рассмотрим важ- ные термины, фигурирующие в этом определении: ограничение, ключ и домен. Термин ограничение (constraint) имеет в данном определении намеренно широкое толкование. Фагин определяет ограничение как любое правило регу- лирующее возможные статические значения атрибутов и достаточно точное для того, чтобы можно было установить его истинность или ложность. Примера- ми таких ограничений являются правила редактирования, ограничения связей и внутренние ограничения отношении, функциональные зависимости и много- значные зависимости. Фагин явным образом исключает отсюда ограничения, относящиеся к изменениям значений данных, и ограничения, зависящие от вре- мени. Например, правило «Зарплата продавца за текущий период не может быть меньше, чем за предыдущий период» не подпадает под определение ограниче- ния, которое дал Фагин. За исключением ограничений, зависящих от времени, определение Фагина является широким и охватывает множество случаев. Ключ (key) — это уникальный идентификатор строки, как мы его уже опреде- лили. Третий важный термин в определении ДКНФ — домен (domain). В главе 2 домен был определен как именованное множество допустимых значений атрибу- та. Доказательство Фагана говорит, что ограничения доменов соблюдены, если значения атрибутов удовлетворяют определениям соответствующих доменов. Говоря неформально, отношение находится в ДКНФ, если для выполнения всех ограничении достаточно выполнить ограничения, связанные с доменами и ключами. Более того, поскольку отношения в ДКНФ не могут иметь аномалий модификации, предотвратить возникновение этих аномалий может сама СУБД, контролируя соблюдение ограничений доменов и ключей. К сожалению, пока не известен ни один алгоритм преобразования отношения к доменно ключевой нормальной форме; неизвестно даже, какие отношения мо- оыть приведены к ДКНФ. Нахождение и создание отношений в ДКНФ яв- ляется оолее искусством, чем наукой. служит “Се ЭТ ПРИ пРактическом проектировании баз данных ДКНФ таким обпачп«1еИ СТепени полезным ориентиром. Если определять отношения следствиями ллм₽° Ы "алагаемые «а них ограничения были логическими лий мод1|фикацииНВо м КЛЮЧеН’ ™ ТЙКИе 0ТН0Щения будут свободны от анома- можно соответствую Н01их слУчаях этого удается достичь. Если же это невоз- НИХ программ, 0бра6™м™™™Х™^Ы ”ПР°'НЫ ° Ж”4' форму. У ЩИе Гри п₽имера иллюстрируют доменно-ключевую нормальную
Доменно-ключевая нормальная форма (ДКНФ) 193 Первый пример доменно-ключевой нормальной формы Рассмотрим отношение СТУДЕНТ на рис 4.10, имеющее атрибуты НомерСтудента, Курс, Общежитие и Плата. Здесь Плата - это сумма, которую студент платит за про- живание в общежитии. СТУДЕНТ (НомерСтудента, Курс, Общежитие, Плата) Ключ: НомерСтудента Ограничения: Общежитие -> Плата НомерСтудента не должен начинаться с цифры 1 Рис. 4.10. Первый пример ДКНФ НомерСтудента функционально определяет остальные три атрибута и, следо- вательно, является ключом. Допустим, требования пользователей таковы, что Общежитие -> Плата, а НомерСтудента не должен начинаться с 1. Если нам удаст- ся представить эти требования как логические следствия определения доменов и ключей, то мы сможем быть уверены, согласно теореме Фагина, что аномалий модификации вс возникнет. В данном примере это будет легко сделать. Чтобы реализовать ограничение, указывающее, что номера студентов не долж- ны начинаться с 1, мы просто включим это требование в определение домена ат- рибута НомерСтудента (рис 4.11). Соблюдение ограничения домена гарантирует, что данное требование будет выполнено. Далее нам требуется сделать функциональную зависимость Общежитие -> Плата логическим следствием ключей. Если бы атрибут Общежитие был ключевым, за- висимость Общежитие —> Плата была бы логическим следствием ключа. Поэтому встает вопрос о том, как сделать Общежитие ключом. Атрибут Общежитие не может быть ключом в отношении СТУДЕНТ, так как в одном и том же общежи- тии живет более одного студента, зато он может быть ключом своего собственно- го отношения. Таким образом, мы можем ввести отношение ОБЩЕЖИТИЕ—ПЛАТА с атрибутами Общежитие и Плата. Атрибут Общежитие является ключом этого от- ношения. Введя это новое отношение, мы можем удалить атрибут Плата из отно- шения СТУДЕНТ. Окончательные определения доменов и отношении для этого примера представлены на рис. 4.11. Этот же результат мы получили, преобразовав отношение из 2НФ в ЗНФ для удаления транзитивных зависимостей. В данном случае, однако, процесс был проще, а результат является более надежным. Процесс был проще потому, что нам не требовалось знать, что мы устраняем транзитивную зависимость. Все, что нам было нужно, — это найти действенные способы превращения всех огра- ничении в логические следствия определений доменов и ключей. Результат яв- ляется более надежным по следующей причине. При преобразовании отношения в третью нормальную форму мы знали только то, что количество аномалии в нем
194 Глава 4. Реляционна^2^2Д££!^!122£В^Д^^а^й ----------------- ..„птппой HOPM.UH.IIOH формой Приведя <»н ни. стало меньше по сравнению сся омющепия не б ,дут иметь никами» к ДКНФ, мы точно знаем, что получивши» см и. - аномалий модификации. Определения доменов. Атрибут Имя домена Значения НомерСтудента ИдСтудента 4 десятичные цифры, первая цифра не 1 Курс ГодОбучения { СГ, 'С2', ’СЗ’, ’С4', ‘АС’} Общежитие НазваниеЗдания Char(4) Плата ПлатаЗаОбучение Любая денежная сумма Определения отношений и ключей СТУДЕНТ (НомерСтудента. Курс Общежитие) ОБЩЕЖИТИЕ—ПЛАТА (Общежитие, Плата) Рис. 4.11. Определения доменов и ключей для первого примера ДКНФ Второй пример доменно-ключевой нормальной формы Теперь рассмотрим более сложный пример (рис. 4.12). Отношение ПРЕПОДАВАТЕЛЬ содержит данные о преподавателях, предметах, которые они ведут, и студентах, которыми они руководят. Атрибуты НомерСотрудника и ИмяСотрудника однозначно определяют преподавателя. НомерСтудента однозначно определяет студента, одна- ко ИмяСтудента не обязательно определяет НомерСтудента. Преподаватель может вести несколько предметов и быть руководителем у нескольких студентов, но ка- ждым студентом руководит только один преподаватель. НомерСотрудника начина- ется с единицы, а НомерСтудента не может с нее начинаться. ПРЕПОДАВАТЕЛЬ (НомерСотрудника, ИмяСотрудника, Дисциплина, НомерСтудента, ИмяСтудента) Ограничения: НомерСотрудника —» ИмяСотрудника ИмяСотрудника —> НомерСотрудника НомерСотрудника -> -> Дисциплина | НомерСтудента ИмяСотрудника -> -» Дисциплина | НомерСтудента НомерСтудента —> НомерСотрудника НомерСтудента —> ИмяСотрудника НомерСтудента —> ИмяСтудента НомерСотрудника должен начинаться с 1; НомерСтудента не должен начинаться с 1 Рис. 4.12. Второй пример ДКНФ ио Б°лее точно эти высказывания можно сформулировать в терминах функцио- нальных и многозначных зависимостей, как показано на рис. 4.12. НомерСотруД-
Доменно-ключевая нормальна» форма (ДЦИФ) 161 ника н ИмяСотрудника функционально определяют друг друга (в и. шив эквивалентны). НомерСотрудника и ИмяСотрудника многозначно определяют Дас* циплина и НомерСтудента. НомерСтудента функционально определяет НиьарСаврм* ника и ИмяСотрудника. НомерСтудента определяет ИмяСтудента В более сложных примерах, таких, как этот, ноле то рассмотреть ДКНФ • бо- лее интуитивном свете. Вспомните, что суть нормализации заключается в том, чтобы каждое отношение имело одну гему. Если взглянуть на отношение ПРЕПО- ДАВАТЕЛЬ с этой точки зрения, мы увидим в нем три темы. Первая тема т это соответствие между атрибутами НомерСотрудника и ИмяСотрудника, вторая тема - предметы, которые ведет преподаватель, а третья - идентификационный номер, имя и руководитель данного студента. На рис. 4.13 представлены три отношения, отражающие эти темы. Отношение ППС (профессорско-преподавательский состав) выражает эквивалентность атри- бутов НомерСотрудника и ИмяСотрудника. НомерСотрудника является в нем ключом, а ИмяСотрудника — альтернативным ключом, что означает, что оба атрибута уни- кальны для этого отношения. Поскольку оба они являются ключевыми, функ- циональные зависимости НомерСотрудника —> ИмяСотрудника и ИмяСотрудника -» НомерСотрудника представляют собой логические следствия ключей. Определения доменов: Атрибут Имя домена Значения НомерСотрудника Ид Сотрудников 4 десятичные цифры, первая цифра не 1 ИмяСотрудника ИменаЛюдей Char(50) Дисциплина НазванияДисциплин Char(10); значения {список допустимых названий дисциплин} НомерСтудента ИдСтудентов 4 десятичные цифры, первая цифра не 1 ИмяСтудента ИменаЛюдей Char(50) Определения отношений и ключей: ППС (НомерСотрудника. ИмяСотрудника) Ключ (кандидат): ИмяСотрудника ПОДГОТОВКА (ИмяСотрудника, Дисциплина) СТУДЕНТ (ELwvr Студента. ИмяСтудента, ИмяСотрудника) Рис. 4.13. Определение доменов и ключей для второго примера ДКНФ Отношение ПОДГОТОВКА отражает соответствие между преподавателями и пред метами; в нем указаны предметы, которые может вести каждый из преподавателей Ключом является комбинация (ИмяСотрудника, Предмет). Оба атрибута являются необходимыми для ключа, потому что один преподаватель может вести несколь- ко предметов, а один и тот же предмет может вестись несколькими преподавать ями. Наконец, в отношении СТУДЕНТ для каждого номера студента указано имя
196 Глава 4, Реляционная модель и норм..ли ww - „ .ни Ччметые, что каждое из ото «-Иий имеет этого студента 11111ражаюг все о.раничения. фигурируй .... ‘ л'леш,е подГ0Т06КА ,,ттеми ш«и7'ч«- ,га,° «шчпып зав..спм«пИ Расемагрппая ..стертую кормах «ую ф^, "ы ЛИРУЖ..,™, ™ Для того w>« yen»..™ ................. зависимое™, «об- ход,“о извести м..отоз1Ю.шые атрибут... в ра.ип« отношения Испольная, нами подход заключается а том. чтобы разбит,, отношение с несколькими гема. . на несколько отношений, каждое ш> которых имеет едиистмшую «му Тем самым мы устранили многозначную зависимость. Итак, оба подхода при (ели нас к одинаковому решению. Третий пример доменно-ключевой нормальной формы В следующем примере рассматривается ситуация, которая не охватывается ни одной из нормальных форм, но часто возникает на практике. Это ситуация, когда отношение имеет ограничение на значения данных в строке, которое невозможно описать ни функциональной, ни многозначной зависимостью. Рассмотрим ограничения, имеющиеся в отношении СТУДЕНТ—РУКОВОДИТЕЛЬ на рис. 4.14. Это отношение содержит информацию о студенте и его руководителе. Атрибут НомерСтудента определяет атрибуты ИмяСтудента, НомерСотрудника, Имя- Сотрудника и СотрудникАспирантуры, поэтому он является ключом. Атрибуты Но- мерСотрудника и ИмяСотрудника однозначно определяют члена профессорско-пре- подавательского состава и взаимно эквивалентны, как и в предыдущем примере. И НомерСотрудника, и ИмяСотрудника определяют атрибут СотрудникАспирантуры. Наконец, новым типом ограничения является то, что руководителями аспиран- тов могут быть только сотрудники аспирантуры. СТУДЕНТ-РУКОВОДИТЕЛЬ (НомерСтудента, ИмяСтудента, НомерСотрудника, СотрудникАспирантуры) * Ключ: НомерСтудента Ограничения: НомерСотрудника -> ИмяСотрудника ИмяСотрудника —» НомерСотрудника НомерСотрудника и ИмяСотрудника -» СотрудникАспипантуоы НомерСотКика начинаете бЫТЬ руководителями аспирантов НомерСтудента не должен начинаться с 1 НомерСтудента для аспиранта начинается с 9 СотрудникАспирантуры =П для сотрудников аспирантуры, ____________L0 для остальных сотрудников СотрудникАспирантуры =Г U Рис. 4.14. Третий пример ДКНФ
Доменно-ключевая нормальная форма (ДКНФ) 197 Ограничения доменов заключаются в том, что НомерСтудента не должен начи- наться с 1, для аспирантов НомерСтудента должен начинаться с 9 НомерСотрудника должен начинаться с 1, а атрибут СотрудникАспирантуры должен быть равен 1 для сотрудников аспирантуры и 0 для всех остальных сотрудников. При таком опре- делении доменов т ребование, чтобы аспирантами руководили только сотрудни- ки аспирантуры, может быть представлено как ограничение на значения строки. В частности, если атрибут НомерСтудента начинается с 9, то атрибут СотрудникАспи- рантуры должен быть равен 1. Чтобы привести это отношение к ДКНФ, мы поступим так же, как в предыду- щем примере. Каковы основные темы отношения СТУДЕНТ—РУКОВОДИТЕЛЬ? Одна из тем — это профессорско-преподавательский состав; к ней относятся атрибуты НомерСотрудника, ИмяСотрудника и СотрудникАспирантуры. Вынесем эти атрибуты в отношение ППС. Поскольку атрибуты НомерСотрудника и ИмяСотрудника опреде- ляют атрибут СотрудникАспирантуры, любой из этих атрибутов может быть клю- чом, и это отношение находится в ДКНФ (рис. 4.15). Определения доменов: Атрибут Имя домена Значения НомерСотрудника ИдСотрудников 4 десятичные цифры, первая цифра не 1 ИмяСотрудника ИменаЛюдей Char(5O) СотрудникАспирантуры СтатусСотрудника- Аспирантуры Значения {0, 1} НомерАспиранта Идентификаторы- Аспирантов 4 десятичные цифры, первая цифра 9 НомерСтудента Идентификаторы- Студентов 4 десятичные цифры, первая цифра не 1 и не 9 ИмяСтудента ИменаЛюдей Char(50) ИмяСотрудника- Аспирантуры ИменаЛюдей Значения {ППС.ИмяСотрудника, где СотрудникАспирантуры = 1} Определения отношений и ключей- ППС рудник J, ИмяСотрудника, СотрудникАспирантуры) Ключ-кандидат: ИмяСотрудника РУКОВОДИТЕЛЬ—АСПИРАНТ (djwec Аспирант т. ИмяСтудента, ИмяСотрудникаАспирантуры) РУКОВОДИТЕЛЬ—СТУДЕНТ н.;мс,.Студунт.х ИмяСтудента, ИмяСотрудника) Рис. 4.15. Определение доменов и ключей для третьего примера Теперь рассмотрим данные, относящиеся к студентам и их руководителям. На первый взгляд может показаться, что здесь имеется только одна тема, а именно руководство, однако из требования о том, чтобы аспирантами руководили толь- ко сотрудники аспирантуры, следует иное. На самом деле здесь есть две темы- ру- ководство аспирантами и руководство студентами. Соответственно, на рис 4 15 мы имеем два отношения: РУКОВОДИТЕЛЬ-АСПИРАНТ, содержащее информацию об аспирантах, и РУКОВОДИТЕЛЬ-СТУДЕНТ, содержащее информацию о
J98 Глава4 Реляционная модель и нормализация г- гт„ап₽прния доменов. НомерАспиранта начинается с 9; Посмотрим, каковы_6W™ эТо ИмяСотрудника из строки отношения ППС с атри ИмяСотрудникаАспирантур j. накоНец, НомерСтудента ие должен нами- наться с 1 4 15 поэтому данные отношения находятся деления ключей и доменов на рис. в ДКНФ и не имеют аномалий модификации. В качестве подведения итога обсуждения нормальных форм в табл 4.4 пере- числены все нормальные формы и даны их определяющие характеристики. Таблица 4.4. Нормальные формы Форма Определяющая характеристика 1НФ 2НФ ЗНФ НФБК 4НФ 5НФ ДКНФ Любое отношение Каждый из неключевых атрибутов зависит от всего ключа целиком Нет транзитивных зависимостей Каждый детерминант является ключом-кандидатом Отсутствуют многозначные зависимости Не описывается здесь Все ограничения на отношение являются логическими следствиями определений доменов и ключей Синтез отношений В предыдущем разделе мы подходили к проектированию реляционных схем с ана- литических позиций. Вопрос, задававшийся нами, был таков: пусть у нас имеется некоторое отношение. В хорошей ли форме оно находится? Имеет ли оно анома- лии модификации? В данном разделе мы подойдем к проектированию реляцион- уктур, исходя из синтетической перспективы. Вопрос в этом случае зву- чит так. если у нас имеется набор атрибутов с определенными функциональными зависимостями, какие отношения следует из них формировать? видов ПеРВЬ1Х’ °™етим- что два атрибута (скажем, А и В) могут иметь связь трех 1. 2. 3. 2т атпХ °ПреДеЛЯТЬ ДРУГ д1’Уга: А -> В и В -> А. В этом случае А и В име- ют атрибутивную связь «один к одному». А и В имеют^ятп^1 определять ДРУГОЙ: А -> В, но не В -> А. В этом случае В имеют атрибутивную связь «многие к одному». мучае°А?В т1е1отНКЦИлНаЛЬН0 ИС Связаны: А не -> В и В не -> А. В этом случае А и В имеют атрибутивную связь «многие ко многим». Атрибутивная связь «один к одному» Если А определяет В, а В определяет а ному» (one-to-one relationshin'i r г ' еНИЯ атРноУтов имеют связь «один к од- —fоп₽ммя"в’то А и в у . между тем справедливо и другое утвер-
Синтез отношений 199 ждение: если В определяет А, го между В и А должна быть связь «многие к одно- му» Чтобы оба утверждения были справедливы одновременно, связь между А и В должна в действительности иметь вид «один к одному» (что является частным случаем связи «многие к одному»), как и связь между В и А. Поэтому в данном случае наличествует связь «один к одному». Этот случай иллюстрируется атрибутами НомерСотрудника и ИмяСотрудника в предыдущем разделе, посвященном доменно-ключевой нормальной форме. Каждый из этих атрибутов однозначно определяет сотрудника факультета. Сле- довательно, каждому значению атрибута НомерСотрудника соответствует ровно одно значение атрибута ИмяСотрудника, и наоборот. Относительно примера с атрибутами НомерСотрудника и ИмяСотрудника можно высказать три эквивалентных утверждения. + Если два атрибута функционально определяют друг друга, то между их значениями имеется связь «один к одному». 4- Если два атрибута однозначно определяют одну и ту же вещь (сущность или объект), то между их значениями имеется связь «один к одному». 4 Если два атрибута имеют связь «один к одному», то они функционально определяют друг друга. При создании базы данных с атрибутами, имеющими связь «один к одному», эти два атрибута должны появляться вместе по крайней мере в одном отноше- нии. Другие атрибуты, которые функционально определяются данными атрибу- тами (атрибут, который функционально определяется одним из них, функцио- нально определяется и другим), могут также находиться в этом отношении. Рассмотрим отношение ППС (НомерСотрудника, ИмяСотрудника, СотрудникАспи- рантуры) из третьего примера в предыдущем разделе. НомерСотрудника и ИмяСо- трудника функционально определяют друг друга. Атрибут СотрудникАспирантуры также может появиться в отношении, поскольку он определяется атрибутами НомерСотрудника и ИмяСотрудника. Атрибуты, которые не определяются функцио- нально данными атрибутами, не могут появляться с ними в одном отношении. Рассмотрим отношения ППС и ПОДГОТОВКА из примера № 2, в котором и Номер- Сотрудника, и ИмяСотрудника присутствуют в отношении ППС, по Предмет (из отно- шения ПОДГОТОВКА) там появиться не может. Атрибут Предмет может иметь различные значения для сотрудника факультета, полому Предмет не зависит от атрибутов НомерСотрудника или ИмяСотрудника. Если бы мы добавили атрибут Предмет в отношение ППС, ключом этого отношения обязательно должно было бы быть сочетание (НомерСотрудника, Предмет) либо (ИмяСотрудника, Предмет). В этом случае, однако, отношение ППС не было бы в ДКНФ, потому что зависимости ме- жду атрибутами НомерСотрудника и ИмяСотрудника не были бы логическими след- ствиями ни одного из возможных ключей. Эти утверждения собраны в первом столбце табл. 4.5, а правила определения писей приведены во врезке. Если А и В имеют связь 1:1, они могут находиться п одном отношении R. А определяет В, а В определяет А. Ключом отношения мо- ст быть либо А, либо В. Новый атрибут С может быть добавлен в отношение R, ели один из атрибутов А и В функционально определяет С
200 Глава 4. Реляционная модель и нормализации Таблица 4.5. Три типа связей атрибутов Тип связи между атрибутами Один к одному Многие к одному Определение отношения R(A,B) < д у D С —> D Зависимости я о В-> A D-»C Ключ Либо А. либо В С Правило добавления Либо А, либо В -> С С -> Е атрибутов Многие ко многим T(E,F) E->F F-> Е (E.F) (E.F) -> G • Буквы, использованные в определениях этих отношений, соответствуют тем, которые использу- ются во врезке. ПРАВИЛА ПОСТРОЕНИЯ ОТНОШЕНИЙ “ Связь «один к одному» ♦ Атрибуты, имеющие связь «один к одному», должны фигурировать вместе по крайней мере в одном отношении. Пусть отношение носит имя R, а его атрибуты — А и В ♦ Либо А, либо В должен быть ключом отношения R. ♦ Если некоторый атрибут функционально определяется атрибутом А или В, он может быть добавлен в отношение R. ♦ Атрибут, не определяемый функционально атрибутами А или В, не может быть до- бавлен в отношение R ♦ Атрибуты А и В должны находиться, вместе в отношении R и более ни в каком другом отношении. ♦ Для представления пары (А, В) в отношениях, отличных от R, должен последователь- но использоваться один из атрибутов, А или В. Связь «многие к одному» ♦ Атрибуты, имеющие связь «многие к одному», могут находиться вместе в одном от- ношении. Пускай в отношении S атрибут С определяет атрибут D. ♦ Атрибут С должен быть ключом отношения S. ♦ Если некоторый атрибут определяется атрибутом С, он может быть добавлен в отно- шение S. ♦ Атрибут, не определяемый функционально атрибутом С, не может быть добавлен в отношение S Связь «многие ко многим» Атрибуты, имеющие связь «многие ко многим», могут сосуществовать в одном отно- шении. Пускай в отношении Т имеются два таких атрибута, Е и F. * Ключом отношения Т должна быть комбинация (Е, F). * S ™РТЫЙ 8ТРИбУ^ определяется сочетанием атрибутов (Е, F), он может быть добавлен в отношение Т. ' Атрибут, не определяемый функционально сочетанием атрибутов (Е, F), не может быть добавлен в отношение Т. 1 ' !итЛИЧто6ЛмяеНИе Н0В0Г° 0ТРИбУТа G раСширяет ключ отношения до (Е, F, G), это зна- ношени ю Тпибпс^пГ ИЗТНИЛаСЬ' ЛИб° ЗТРИ6УТ G логически не принадлежит от- нявшейся тит ДУеТ ВЫ РаТЬ другое имя для отношения в соответствии с поме- пиьшсИСЯ ТСМОИ.
Синтез отношений 201 Атрибуты, имеющие связь «один к одному», должны присутствовать вместе по меньшей мере в одном отношении, чтобы они могли быть эквивалентными (например, НомерСотрудника, равный 198, соответствует преподавателю Харту) В общем случае, однако, нежелательно, чтобы эти атрибуты появлялись вместе более чем в одном отношении, поскольку это приведет к ненужному дублирова- нию данных. Часто один из таких атрибутов или оба они появляются в других отношениях. В примере № 2 атрибут ИмяСотрудника появляется и в отношении ПОДГОТОВКА, и в отношении СТУДЕНТ. Можно было бы поместить ИмяСотрудника в отношение ПОДГОТОВКА, а НомерСотрудника — в отношение СТУДЕНТ, но это, во- обще говоря, порочная практика: когда атрибуты спарены подобным образом, из них следует выбрать один, который будет представлять эту пару во всех других отношениях. Во втором примере для этой цели выбран атрибут ИмяСотрудника. Атрибутивная связь «многие к одному» Если атрибут А определяет В, но В не определяет А, то между ними имеется связь «многие к одному» (many-to-one relationship). В отношении РУКОВОДИТЕЛЬ иэ при- мера № 2 НомерСтудента определяет НомерСотрудника. Отдельно взятый преподава- тель может быть руководителем у многих студентов, однако каждым студентом ру- ководит только один преподаватель. Поэтому здесь имеется связь «многие к одному». Чтобы отношение находилось в ДКНФ, все ограничения должны быть след- ствиями ключей, и поэтому каждый детерминант должен быть ключом. Если ат- рибуты А, В и С находятся в одном отношении и А определяет В, то атрибут А должен быть ключом (имея в виду, что он определяет также и С). Если же атри- бут С определяется сочетанием (А, В), тогда сочетание (А, В) должно быть клю- чом. В последнем случае никакой другой функциональной зависимости (напри- мер, А > В) не допускается. Применить эти высказывания к проектированию баз данных можно следующим образом: если в создаваемом отношении А определяет В, то добавлять в это отно- шение можно только те атрибуты, которые определяются атрибутом А. Допус- тим, например, что вы поместили в отношение под названием СТУДЕНТ атрибуты НомерСтудента и Общежитие. В это отношение вы можете добавлять любые другие атрибуты, которые определяются атрибутом НомерСтудента, например, ИмяСтуден- та. Но если атрибут Плата определяется атрибутом Общежитие, его нельзя доба- вить в данное отношение. Атрибут Плата может быть добавлен только в том слу- чае, если НомерСтудента > Плата. Эти правила сведены в среднем столбце табл 4.5. Если С и D имеют связь N:l, они могут находиться вместе в отношении S. С будет определять D, но D не будет определять С. Ключом отношения S будет атрибут С. Другой атрибут, Е, может быть добавлен в отношение S, только если С определяет Е. Атрибутивная связь «многие ко многим» Если А не определяет В, а В не определяет А, то между значениями этих атрибу- тов имеется связь «многие ко многим» (many-to-many relationship). В примере -1 атрибуты ИмяСотрудника и Предмет имеют связь «многие ко многим» Один
202 4. Реляционная модель и нормализации .^пп шм-лмего», а один И тот же предмет ведет преподаватель может веегп М! « МИ(Я им> а|рибута (<| ся многими преподавателями с • ОГ1ИИ|К.11ИЯ ПОДГОТОВКА из приме пыть ключами отношения. l iaupHMt р, к. п-1 № 2 являегся комбинация (ИмяСотрудника. Предмет) построен»'’ orno’iieiuiil. У '1ЮЮЛ“° «! *» то,, можпо^ап™ »Л»'«У™- ...I*1""»...“""° И““О" т Т ”юча Атрибут КолнчествоЧасоа фупкпжишлыю =.»»« "Т от каждого из атрибу то» в сочетании (Ин,Со,рудника. Предмет) и поэтому может быт,, лобаилен . отио- шише. Атрибут Должность в данное отооше.'Ие добапить нельзя. потому то зависит только от атрибута ИмяСотрудника, по не от атрибута Предмет Если тре- Суется хранить атрибут Должность в базе данных, его следует добавить в отноше- ние, содержащее информацию о профессорско-преподавательском составе, а ие О подготовке. Эти правила сведены в правый столбец табл. 4.5. Если атрибуты Е и г имеют связь M:N. то Е не определяет F, a F не определяет Е. Оба эти атрибута можно по- местить в отношение Т, и в этом случае ключом отношения Т будет комбинация (Е, F). Новый атрибут G может быть добавлен в отношение Т, если он определяет- ся обоими атрибутами из сочетания (Е, F). Атрибут G нельзя добавить в отноше- ние Т, если он определяется только одним из атрибутов в комбинации (Е, F). Рассмотрим аналогичный пример. Предположим, мы хотим добавить в отноше- ние ПОДГОТОВКА атрибут НомерАудитории. Определяется ли НомерАудитории клю- чом отношения ПОДГОТОВКА — комбинацией (ИмяСотрудника, Предмет)? Скорее всего, нет, поскольку преподаватель может вести один и тот же предмет в различ- ных аудиториях. Сочетание (ИмяСотрудника, Предмет) и атрибут НомерАудитории имеют связь M:N. Раз это так, можно применить правила, приведенные в табл. 4.5, но здесь рать Е будет играть сочетание (ИмяСотрудника, Предмет), а роль F — атрибут НомерАуди- тории Теперь мы можем построить новое отношение Т с атрибутами ИмяСотруд- ника, Предмет и НомерАудитории. Ключом этого отношения будет комбинация (ИмяСотрудника, Предмет, НомерАудитории). В этой ситуации получается, что мы создали новое отношение с новой темой. Рассмотрим отношение Т, содержащее сведения об именах преподавателей, предметах и номерах аудиторий. Темой это- го отношения больше не является ПОДГОТОВКА; скорее, эту тему можно было бы сформулировать так: КТО-ЧТО-И-ГДЕ-ПРЕПОДАЕТ. Изменение темы может быть как уместным, так и неуместным. Если Номер- удитории является значимым атрибутом, тема действительно должна быть из- менена. В этом случае отношение ПОДГОТОВКА не подходит, и более уместной является тема КТО-ЧТО-И-ГДЕ-ПРЕПОДАЕТ ПОПГПТПККД1 СТ°Р°ны’ в зависимости от требований пользователей, отношение к нТ" 1ЫТ" "Рпгод™“ » ™ ’"« в каком „по есть. В типом случае. помесХь ?п»»г ю Же Д°Л“е" в базе данных, его следует естить в друюе отношение - например, СЕКЦИЯ—НОМЕР ПРЕДМЕТ—СЕКЦИЯ или что-нибудь наподооие этого.
Синтез отношений 203 Многозначные зависимости: часть вторая Изложенные выше соображения, касающиеся атрибутивной связи «многие ко многим» могут сделать концепцию многозначных зависимостей более простой для понимания. Проблема с отношением СТУДЕНТ (НомерСтудента, Специализация. Секция) на рис. 4.7 состоит в том, что в нем имеется две различных связи вида «многие ко многим»: одна между атрибутами НомерСтудента и Специализация, а дру- гая - между атрибутами НомерСтудента и Секция. Ясно, что специализации сту- дента не имеют никакого отношения к секциям, в которых он занимается. Однако если обе связи присутствуют в одном отношении, возникает впечатление, что между этими атрибутами существует какая-то взаимосвязь. Атрибуты Специализация и Секция независимы, и никакой проблемы не воз- никло бы, если бы студент мог специализироваться только в одной области и за- ниматься только в одной секции. Тогда НомерСтудента функционально опреде- лял бы атрибуты Специализация и Секция, и отношение находилось бы в ДКНФ. В этом случае связь каждого из этих атрибутов с атрибутом НомерСтудента имела бы вид «многие к одному». Другой способ представить себе возникающее затруднение состоит в исследо- вании ключа (НомерСтудента, Специализация, Секция). Поскольку в отношении СТУДЕНТ имеются связи вида «многие ко многим», ключ должен содержать в себе каждый из атрибутов. Теперь спросим себя: а какую тему представляет данный ключ? Мы можем сказать, что это комбинация специальности студента и посе- щаемых им секций. Но такая комбинация не одна, их множество. Одна строка этого отношения описывает только часть комбинации, и чтобы получить всю картину, нам нужны все строки, содержащие информацию о конкретном студен- те. Вообще говоря, строка отношения должна содержать все данные, описы- вающие отдельный экземпляр темы данного отношения. Например, строка от- ношения ПОКУПАТЕЛЬ должна содержать все нужные нам данные о конкретном покупателе. Рассмотрим отношение ПОДГОТОВКА из примера № 2 в разделе, посвящен- ном доменно-ключевой нормальной форме. Ключом этого отношения является комбинация (ИмяСотрудника, Предмет). Тема состоит в том, что конкретный пре- подаватель имеет подготовку, достаточную для ведения определенного предмета. Нам нужна только одна строка этого отношения, чтобы получить всю требуемую ин<]юрмацию о комбинации данного профессора и данного предмета (в отноше- ние MOiyr входить такие атрибуты, как КоличествоЧасов, СреднийБаллКурса и т. д.). Глядя на другие строки, мы не получим никакой дополнительной инфор на эту тему. Как вы знаете, решение проблемы многозначных зависимостей заключается в том, чтобы разбить исходное отношение на два новых, каждое из которых будет иметь только одну тему. В отношении СТУДЕНТ—СПЕЦИАЛИЗАЦИЯ пред- ставлены комбинации студентов и специализаций. Все, что мы знаем о каждой из таких комбинаций, содержится в одной строке, и мы не получим какой-либо дополнительной информации о данной комбинации, исследуя другие строки.
204 Глава 4. Реляционная модель и нормализация Ненормализованные структуры В оасемопяиых нами выше методах дормажзаиии аномалии устранились за сч^огаХ исключалось дублирование каких-либо других данных, кроме кла,- чй Обычно к этому в следует стремиться, однако бывают ситуации, в которых предпочтительными являются ненормализованные структуры. В частности, речь ™ о случаях, когда нормализованная схема является неестественной, неудоб- ной или приводит к неприемлемому снижению производительности. Нормализованная схема неестественна Рассмотрим отношение КЛИЕНТ (НомерКлиента, ИмяКлиента, Город, Штат, Индекс), где ключом является НомерКлиента. Это отношение не находится в ДКНФ, по- скольку в нем имеется функциональная зависимость Индекс —> (Город, Штат), ко- торая не следует из ключа — атрибута НомерКлиента. Следовательно, мы имеем ограничение, не являющееся следствием определения ключей. Данное отношение может быть преобразовано в /два отношения следующего вада: КЛИЕНТ (НомерКлиента, ИмяКлиента, Индекс), где ключом является НомерКли- ента, и ИНДЕКСЫ (Индекс, Город, Штат), где ключом является Индекс Эти два отно- шения находятся в доменно-ключевой нормальной форме, но они, скорее всего, не представляют собой более удачного решения по сравнению с исходной таб- лицей. Ненормализованная таблица может оказаться лучше, поскольку ее будет легче обрабатывать, а неудобства, связанные с дублированием данных о городе и штате, не столь существенны. Нормализация неудобна В качестве второго примера рассмотрим отношение КОЛЛЕДЖ (НазваниеКолледжа, Декан, ЗаместительДекана), предположив, что колледж имеет одного декана и от одного до трех заместителей декана. Ключом таблицы в этом случае является сочетание (НазваниеКолледжа, ЗаместительДекана). Эта таблица не находится в до- менно-ключевой нормальной форме, так как ограничение НазваниеКолледжа -> Декан не является логическим следствием ключа таблицы. nPMAu'TJ11011116 1ЕЕ)ЛЛЕ^Ж можно нормализовать, разбив его на два отношения: ч звание олледжа, Декан) и ЗАМДЕКАНА (НазваниеКолледжа, ЗаместительДе; им I днако -ерь, когда приложению базы данных нужно будет получить стпо^<К^ЛЛеДЖепеМ^ пРидется прочитать минимум две, а возможно, и все четы- лей лекянч 1^НЬАХ ^;пВЛаЛЬТернаТИВЫ можно поместить всех трех заместнте- Потучившаяг13 ЛАЦУ ЛЛЕ^Ж; выделив для каждого индивидуальный атрибут. ДекУн За Т пЛИЦа " бЫ СледУЮ1дий вид: КОЛЛЕДЖ! (Назв Декан, ЗаместительДекана!, ЗаместительДеканаг, ЗаместительДеканаЗ! ционадьад Т К°ЛЛЕДЖ1 иах0Д1'тся в ДКНФ, поскольку все его атрибуты функ- ZX чгХ "Г “ЛЮЧа НазваниеКодд™- Однако здесь что^о потеряно. , по именно мы потеряли, предположим, что мы хотим
Ненормализованные структуры 2OS узнать названия колледжей, в которых есть заместитель декана по имени Мэри Абернати. Для этого нам придется искать данное имя в каждом из трех столбцов ЗаместительДекана. Наш запрос будет выглядеть примерно следующим образом: SELECT НазваниеКолледжа FROM КОЛЛЕДЖ! WHERE ЗаместительДекана! = 'Мэри Абернати' OR ЗаместительДекана2 = 'Мэри Абернати OR ЗаместительДеканаЗ = 'Мэри Абернати' Используя нормализованный вариант с таблицей ЗАМДЕКАНА, нам пришлось бы написать только SELECT НазваниеКолледжа FROM ЗАМДЕКАНА WHERE ЗаместительДекана = 'Мэри Абернати' В этом примере даны три возможных решения. В первом из них используется ненормализованная структура и дублируются данные о декане. Второй вариант нормализован, ио для получения всех данных о колледже требуется обрабо- тать от двух до четырех строк. Третий вариант также нормализован, но неудобен в обработке. Какой вариант лучший? Это зависит от требований, нагрузки, размера базы данных и т. д. Если немногие колледжи имеют более одного заместителя декана, возможно, приемлемым будет первый вариант. Если любой колледж может иметь более трех заместителей, последний вариант нереален. Кроме того, он вы- глядит неудачным и с эстетической точки зрения: один и тот же атрибут пред- ставляют три столбца, а используется из них, как правило, только один. Суть рассмотренного примера в том, что иногда следует принимать во внима- ние и другие критерии, помимо нормализации. Нормализация может привести к низкой производительности Представьте себе компанию, занимающуюся рассылкой товаров по почте. База данных этой компании содержит таблицу ТОВАР, находящуюся в ДКНФ и имею- щую следующий вид: ТОВАР (КодТзвара. Наименование, Цвет, Описание, Фото, КоличествоНаСкладе, Зака- занноеКоличество, Цена) Эта таблица служит источником данных для ежемесячно издаваемого катало- га и используется для обработки заказов. Атрибут Описание представляет собой Длинное текстовое поле, в котором описываются возможности и преимущества товара. Его длина может составлять более 1000 байт. Атрибут Фото — это изобра- жение в формате JPEG размером до 256 Кбайт. Если речь идет о создании ката- лога, атрибуты такой величины не представляют проблемы, поскольку таблица обрабатывается только один раз и последовательно.
206 Глава 4, Реляционная модель и нормалиэац „ , ,т, Ш пошее заказы, обращается к згой .. ты- Однако приложение, обР < ’ ‘ 1|1() 11|Ю|.ппОд»гельность здесь выходит ка сячн раз и в ^Учаипом nq * б(„кс заказо|, атрибуты Описание и Фотоне первый план. Дотстнм, I К|ер1И;1ИК используемой СУЬД может используются. В зависим Ч f столбцов значительно замедлит оказаться, что присутствие эгих двух оолыиих с м"1ут гить создать ГГтаблЯ1 • которая будет содержать копию данных, необходимых ДЛЯ К примеру они могут создать таблицу под названием ЗАКАЗ ТОВАРА Наименование, Цвет, КоличествоНаСкладе, ЗаказанноеКоличество, Цена), которая иудет использоваться только приложением, обрабатывающим з ы Обе таблицы- нормализованы, поэтому вы можете сказать троблем; ключается не в нормализации. Но целью нормализации является уменьшение дублирования данных для предотвращения аномалий и возможных проблем с це- лостностью данных. Здесь же данные сознательно дублируются, в результате чего для записи одного факта требуется несколько обновлений. Это похоже на аномалию вставки, пусть даже вставка осуществляется в две различные таблицы. В этом случае проектировщики создают потенциальный источник серьезных проблем с целостностью данных. Им придется разработать процедуры как про- граммного, так и ручного контроля, чтобы обеспечить согласованное обновление данных. Прежде чем воплощать это решение, необходимо убедиться, что повы- шение производительности окупит расходы, связанные с дополнительным кон- тролем, и риск возникновения проблем с целостностью данных. Еще один случай, когда имеет смысл дублировать данные, — это создание от- четов и поддержка принятия решений. Примеры такого дублирования вы увиди- те в главе 15 при обсуждении OLAP и схемы «звезда». Резюме Реляционная модель является на сегодняшний день промышленным стандартом. Впервые она была предложена Э. Ф Коддом в 1970 году. Поначалу ее воспри- нимали как слишком «теоретическую», но уже в 80-х годах благодаря таким прод^ктам’ как DB2 и Oracle, она успешно использовалась в организациях для обработки больших объемов транзакций. Отношение это двухмерная таблица, обладающая качествами, перечисленные МИ во врезке «Характеристики отношений». В мире баз данных вообще и в этой ниге в lacrnocTn термин таблица используется как синоним термина отноше- онной^мпеСТВ^еи Т^И На °')а теРминов’ вторыми обозначаются понятия реляци- ГкоТтеХТп всего?^одьзуются термины таблица, строка и столбец, ио (йХгитнУР ЛЦИОННч°И °бработкн данных иногда можно встретить термины Й," “ ”“е- Т“Р™>™ обозначают те же самые кон- 2“ ™‘т"сшете' Иногда употребляется сме- гня. трого говоря, отношение не может иметь одинаковых
Резюме 207 строк; на деле же иногда этим требованием пренебрегают, поскольку устранение ублируюшихся строк может быть слишком долгим процессом. Ключом называется один или несколько столбцов отношения, идентифициру- ющих строку. Уникальный ключ указывает на одну-единственную строку; неуии- кальиый ключ может указывать на несколько строк. Композитный ключ — это ключ, состоящий из двух или более атрибутов. Каждое отношение имеет один первичный ключ, который должен быть уникальным. Кроме того, отношение мо- жет иметь и другие уникальные ключи, которые называются ключами-кандида- тами. Первичный ключ представляет таблицу в ее связях, и во многих СУБД хранение таблиц основывается на значениях первичного ключа. Для обеспече- ния быстрого доступа по значению первичного ключа обычно строятся индексы. Функциональная зависимость имеет место, когда значение одного атрибута (или множества атрибутов) определяет значение другого атрибута (или множе- ства атрибутов). Атрибут с левой стороны функциональной зависимости на- зывается детерминантом. Можно сказать, что единственным предназначением отношений является хранение экземпляров функциональных зависимостей. Пер- вичный ключ (а также ключи-кандидаты) можно еще определить как атрибут, функционально определяющий все остальные атрибуты отношения. Некоторые отношениях в результате обновления данных страдают от нежела- тельных последствий, называемых аномалиями модификации. Аномалия удале- ния имеет место, когда удаление одной строки из отношения вызывает потерю информации о двух или более сущностях Аномалия вставки возникает, когда реляционная структура вынуждает нас одновременно добавлять информацию о двух сущностях. Аномалии могут быть устранены путем разбиения исходного отношения па два или более новых. Существует много типов аномалий модификации. Отношения можно класси- фицировать по типам аномалий, которые ими ликвидируются. Типы, на которые подразделяются отношения в рамках этой классификации, называются нормаль- ными формами. По определению, каждое отношение находится в первой нормальной форме. Отношение находится во второй нормальной форме, если каждый из его неклю- ченых атрибутов зависит от всего ключа. Отношение находится в третьей нор- мальной форме, если оно находится во второй нормальной форме и не имеет транзитивных зависимостей. Отношение находится в нормальной форме Бойса- Ко (да, если каждый его детерминант является ключом-кандидатом. Отношение находится в четвертой нормальной форме, если оно находится в нормальной <|юрмс Бойса-Кодда и не имеет многозначных зависимостей. Определение пятой нормальной формы не имеет интуитивной интерпретации, и поэтому мы его не приводили Отношение находится в доменно-ключевой нормальной форме, если каждое ограничение, накладываемое на это отношение, является логическим следствием определения доменов и ключей. Под ограничением здесь понимается любое условие, определяющее возможные статические значения атрибутов, истинность которого может быть проверена. Домен — это именованное множество возмож- ных значений атрибута.
208 Глава 4. Реляционная модель и нормализация Отношения можно строить с помощью нормализации, представляющей со- бой процесс анализа отношений, а также синтетическим путем, рассматривая связи между атрибутами. Если два атрибута функционально определяют друг дпуга между ними имеется связь вида «одни к одному*. Если один из двух атри- бутов функционально определяет второй, но не наоборот, между этими атрибу- тами имеется связь «многие к одному». Если ни один из двух атрибутов не опре- деляет другой, между этими атрибутами имеется связь «многие ко многим». Эти факты, перечисленные во врезке «Правила построения отношений», можно ис- пользовать при создании отношений. В некоторых случаях нормализация нежелательна. Всякий раз, когда исходная таблица разбивается на две или более новых, возникает необходимость в дополни- тельной обработке при последующем их объединении. Кроме того, необходимо контролировать соблюдение ограничений ссылочной целостности. Если расходы на дополнительную обработку двух таблиц и обеспечение ссылочной целостно- сти превышают выгоду от устранения аномалий модификации, нормализация не рекомендуется. Вдобавок в некоторых случаях создание повторяющихся столб- цов предпочтительнее обычных способов нормализации, а в других ситуациях для повышения производительности вводится преднамеренная избыт 'Чность. Вопросы группы I 1. Какие ограничения должны быть наложены на таблицу, чтобы она могла считаться отношением? 2. Определите следующие термины: отношение, кортеж, атрибут, файл, за- пись, таблица, строка, столбец. 3. Дайте определение термина функциональная зависимость. Приведите при- мер двух атриоутов, имеющих функциональную зависимость, и двух атри- бутов, не имеющих функциональной зависимости. Если атриоут НомерСтудента функционально определяет атрибут Секция, означает ли о, что значение атрибута НомерСтудента может быть только одно? Обоснуйте свой ответ. 5. 6. 7. 8. 9. 10. Данте определение термина детерминант. той летепчп тРИМеР отношен»я с функциональной зависимостью, в кото- рой детерминант состоит из двух „ли более атрибутов. Дайте определение термина ключ. детерминантом °МожУДеНТа является КЛ1°чом отношения, является ли он в отношении более одного pS*™06 ЗНаЧеНИе ?того появиться торый дан в тексте.* УДаЛенПЯ? Приведите пример, отличный от того, КО- рый дан в тексте”* ВСТаВКП? Приведите пример, отличный от того, кото-
Вопросы группы I 209 И Объясните, как соотносятся между собой первая, вторая, третья нормаль- ная формы, нормальная форма Бойса-Кодда, четвертая, пятая и доменно- ключевая нормальные формы. 12 Дайте определение термина вторая нормальная форма. Приведите пример отношения, которое находится в первой нормальной форме, но не нахо дится во второй нормальной форме. Преобразуйте это отношение в отно- шения, находящиеся во второй нормальной форме. 13. Дайте определение термина третья нормальная форма. Приведите при- мер отношения, которое находится во второй нормальной форме, но не на- ходится в третьей нормальной форме. Преобразуйте это отношение в от- ношения, находящиеся в третьей нормальной форме. 14. Дайте определение термина нормальная форма Бойса—Кодда. Приведите пример отношения, которое находится в ЗНФ, но не находится в НФБК Преобразуйте это отношение в отношения, находящиеся в НФБК. 15. Дайте определение термина многозначная зависимость. Приведите пример. 16. Почему многозначные зависимости не являются проблемой в отношениях, имеющих только два атрибута? 17 Данте определение термина четвертая нормальная форма. Приведите при- мер отношения, которое находится в НФБК, но не находится в 4НФ. Пре- образуйте это отношение в отношения, находящиеся в 4НФ. 18. Дайте определение термина доменно-ключевая нормальная форма. В чем состоит важность этой формы? 19. Преобразуйте следующее отношение к ДКНФ. Сделайте и сформулируйте соответствующие предположения о функциональных зависимостях и до- менах. ОБОРУДОВАНИЕ (Производитель, Модель, ДатаПриобретения, ИмяПокупателя, Те- лефонПокупателя, АдресЗавода, Город, Штат, Индекс) 20. Преобразуйте следующее отношение в ДКНФ. Сделайте и сформули- руйте соответствующие предположения о функциональных зависимостях и доменах. СЧЕТ (Номер, ИмяПокупателя, НомерПокупателя, АдресПокупателя, КодТовара, ЦенаТовара, КоличествоТовара, НомерПродавца, ИмяПродавца, Промежуточный- Итог, Налог, ВсегоКОплате) 21. Снова ответьте на вопрос 20, но теперь добавьте атрибут НалоговыйСтатус- Покупателя (0, если покупатель не освобожден от налога, и 1, если освобож- ден). Добавьте также ограничение, что налог не должен включаться в счет, если НалоговыйСтатусПокупателя равен 1. 22. Приведите пример (отличный от того, который дан в тексте) ситуации, в которой, как вы считаете, нормализацию производить не стоило бы. Изо- бразите отношения и обоснуйте свое решение. 23. Укажите две ситуации, в которых проектировщики базы данных могут преднамеренно прибегнуть к дублированию данных, В чем заключается риск, связанный с подобными решениями?
?10 главаД Рв»иио,Иа»модельидам.лиМии« Вопросы группы II 24. Рассмотрим следующее отношение. Таблица 4.6. Отношение ПРОЕКТ ЗарплатаСотрудника КодПроекта 100А 100А 1ООВ 200А 200В 200С 200С 200D ИмяСотрудника Джонс Смит Смит Джонс Джонс Паркс Смит Паркс $64 000 $51 000 $51 000 $64 000 $64 000 $28 000 $51 000 $28 000 । । I, ,ц|1Я, ПРОЕКТ (НазваниеПроекта, ИмяСотрудника, ЗарплатаСотрудника) Здесь НазваниеПроекта - это название рабочего проекта, ИмяСотрудника - имя сотрудника, участвующего в данном проекте, а ЗарплатаСотрудника — заработная плата данного сотрудника. Если предположить, что представленные здесь данные выявляют все имею- щиеся функциональные зависимости и ограничения, какое из следующих утверждений будет верным? 1) НазваниеПроекта -> ИмяСотрудника 2) НазваниеПроекта —> ЗарплатаСотрудника 3) (НазваниеПроекта, ИмяСотрудника) —> ЗарплатаСотрудника 4) ИмяСотрудника -> ЗарплатаСотрудника 5) ЗарплатаСотрудника -> НазваниеПроекта 6) ЗарплатаСотрудника -> (НазваниеПроекта, ИмяСотрудника) Ответьте на следующие вопросы. 7) Что является ключом отношения ПРОЕКТ? ) Все ли неключевые атрибуты (если таковые есть) зависят от всего клю- ча целиком? 9) В какой нормальной форме находится отношение ПРОЕКТ? 10) Опишите две аномалии модификации, характерные для отношения ПРОЕКТ. 11) Является ли атрибут НазваниеПроекта детерминантом? ) Является ли атрибут ИмяСотрудника детерминантом? 3 Является ли детерминантом сочетание (НазваниеПроекта, ИмяСотрудника)? 4 Является ли детерминантом ЗарплатаСотрудника? } какую?’" ЛИ ЭТ° ОТ9ОШенпе транзитивную зависимость? Если да. то 6) Переделайте это отношение так, чтобы устранить аномалии модификации-
Вопросы группы И 211 25. Рассмотрим следующее отношение: Таблица 4.7. Отношение ТРУДОЗАТРАТЫ ИмяСотрудника КодПроекта КодЗадачи Телефон ВсегоЧасов Дональд 100А В-1 12345 12 Дональд 100А Р-1 12345 12 Дональд 200В В-1 12345 12 Дональд 200В Р-1 12345 12 Памела 100А С-1 67890 26 Памела 200А С-1 67890 26 Памела 200D С-1 67890 26 ТРУДОЗАТРАТЫ (ИмяСотрудника, КодПроекта, КодЗадачи, Телефон, ВсегоЧасов) Здесь КодЗадачи — это стандартный код задачи, Телефон — номер телефона сотрудника, а ВсегоЧасов — количество часов, отработанных сотрудником в рамках данного проекта. Если предположить, что представленные здесь данные выявляют все име- ющиеся функциональные зависимости и ограничения, какое из следующих утверждений будет верным? I) ИмяСотрудника -> НазваниеПроекта 2) ИмяСотрудника —>—> НазваниеПроекта 3) ИмяСотрудника —> НазваниеЗадачи 4) ИмяСотрудника ->-> НазваниеЗадачи 5) ИмяСотрудника -> Телефон 6) ИмяСотрудника —> ВсегоЧасов 7) (ИмяСотрудника, НазваниеПроекта) —> ВсегоЧасов 8) (ИмяСотрудника, Телефон) —> НазваниеЗадачи 9) НазваниеПроекта -> НазваниеЗадачи 10) НазваниеЗадачи —> НазваниеПроекта Ответьте па следующие вопросы. И) Перечислите все детерминанты. 12) Имеет ли данное отношение проблему «неполного ключа»? Если да, то в чем она заключается? 13) Содержит ли данное отношение многозначную зависимость? Если да, то какие атрибуты не связаны между собой? 14) Опишите аномалию удаления, которая имеется в этом отношении 15) Сколько тем содержит данное отношение? 16) Переделайте отношение так. чтобы устранить аномалии модификации С ко 1ько отношении у вас получилось? Сколько тем содержит каждое из новых отношений?
212 Глава 4. Реляционная модел^нормал^иия ним/*» лит*деления отношении» доменов и ключей 26. Рассмотрим приведенные ниже опред Определения доменов: Тип данных Атрибут ИмяСотрудника Имена CHAR(20) DEC(5) CHAR(IO) НомерТелефона Телефоны НазваниеОборудования Оборудование Местоположение Места CHAR(7) Стоимость Деньги CURRENCY Дата Время Даты YYMMDD Времена HHMM, где 00 < НН < 23, 00 < ММ < 59 Отношения, ключи и ограничения: СОТРУДНИК (ИмяСотрудника, НомерТелефона) Ключ: ИмяСотрудника Ограничения: ИмяСотрудника —> НомерТелефона ОБОРУДОВАНИЕ (ИмяСотрудника, НомерТелефона) Ключ: НазваниеОборудования Ограничения: НазваниеОборудования -> Местоположение, НазваниеОбору- дования -> Стоимость СЕАНС (Дата, Время, НазваниеОборудования, ИмяСотрудника) Ключ: (Дата, Время, НазваниеОборудования) Ограничения: (Дата, Время, НазваниеОборудования) -> ИмяСотрудника 1) Модифицируйте определения так, чтобы добавить следующее ограни- чение: сотрудник не может записаться более чем на один сеанс работы с оборудованием. 2) Определим в качестве ночного времени часы между 21.00 и 05.00. До- бавьте атрибут ТипСотрудника, значение которого равно 1, если сотруд- ник работает в ночное время. Измените определения таким образом, чтобы ввести условие, что только сотрудники, работающие ночью, могут записываться на ночные сеансы. Вопросы к проекту FiredUp Фирма FiredUp наняла команду проектировщиков, разработавших для базы дан- ных фирмь! приведенные ниже отношения (вообще-то эту команду следовало бы у ол1 ть. . аза данных должна содержать информацию о проданных горелках, выполненном ремонте и клиентах. Чтобы ознакомиться с потребностями фирмы, обратитесь к проектам в конце глав 1-3. Для каждого из представленных далее
Вопросы к проекту FiredUp 213 отношений укажите ключи-кандидаты, функциональные зависимости и многознач- ные зависимости (если таковые присутствуют). Если ответ не очевиден, приведи- те обоснование этого. В какой нормальной форме находится каждое из отноше- ний, если иметь в виду указанные вами ключи и другие элементы? Преобразуйте каждое из отношений в два или более новых отношения, находящихся в доменно- ключевой нормальной форме. Укажите первичный ключ каждой таблицы, клю- чи-кандидаты и внешние ключи, а также сформулируйте ограничения ссылочной целостности, если они имеются. Отвечая на эти вопросы, исходите из следующих предположений. ♦ Тип и версия горелки определяют емкость бака. ♦ Горелка может ремонтироваться много раз, но не более одного раза в день. • f- На каждый произведенный ремонт выписывается отдельный счет. 4- Горелка может быть зарегистрирована на различных пользователей, но не одновременно. ♦ Горелка состоит из многих деталей, и каждая деталь может использо- ваться во многих горелках. Таким образом, фирма FiredUp ведет записи о различных типах деталей (например, клапан форсунки'), но не об от- дельных деталях (клапан форсунки номер 41734, изготовленный 12 декаб- ря 2001 года). Ниже следует список отношений. 1. ПРОДУКТ! (СерийныйНомер, Тип, НомерВерсии, ЕмкостьБака, ДатаИзготовления, ИнициалыИнспектора) 2. ПРОДУКТ2 (СерийныйНомер, Тип, ЕмкостьБака, ДатаРемонта, НомерСчетаЗаРемонт, СтоимостьРемонта) 3. РЕМОНТ! (НомерСчетаЗаРемонт, ДатаРемонта, СтоимостьРемонта, ИмяВыполня- вшегоРемонт, ТелефонВыполнявшегоРемонт) 4. РЕМ0НТ2 (НомерСчетаЗаРемонт, ДатаРемонта, СтоимостьРемонта, ИмяВыполня- вшегоРемонт, ТелефонВыполнявшегоРемонт, СерийныйНомер, Тип, ЕмкостьБака) 5. РЕМОНТЗ (ДатаРемонта, СтоимостьРемонта, СерийныйНомер, ДатаИзготовления) 6. Г0РЕЛКА1 (СерийныйНомер, НомерСчетаЗаРемонт, НомерДетали) 7. Г0РЕЛКА2 (СерийныйНомер, НомерСчетаЗаРемонт, РегистрационныйНомерВла- дельца) Предположим, что нужно записывать владельца горелки, даже если она никогда не ремонтировалась. Исходя из сделанных предположений, приведенных выше отношений и содер- ^ихся в них атрибутов, а также из ваших знаний о малом бизнесе, постройте ^*я фирмы FiredUp набор отношений в доменно-ключевой нормальной форме, кажите первичные ключи и внешние ключи, а также сформулируйте ограпнче- НИя ссылочной целостности.
214 Глава 4. Реляционная модель и нормализация Вопросы к проекту Twigs Tree Саманта наняла команду проектировщиков, разработавших приведенную ниже реляционную схему для учета клиентов, работ, продаж стружки и прочих дан- ных. Потребности Саманты описаны в вопросах к проекту Twigs Tree, приведен- ных в конце глав 1-3. Для каждого из перечисленных здесь отношений укажите ключи-кандидаты, функциональные зависимости и многозначные зависимости (если таковые имеются). Обоснуйте ваш выбор, если он не очевиден Исходя из этих данных, скажите, в какой нормальной форме находится каждое из отноше- ний. Преобразуйте каждое отношение в одно или несколько новых отношений, находящихся в доменно-ключевой нормальной форме. Укажите первичный ключ каждой таблицы, ключи-кандидаты, внешние ключи. Сформулируйте ограниче- ния ссылочной целостности, если таковые имеются. Отвечая на эти вопросы, ис- ходите из следующих предположений. 4- Клиент может заказать несколько работ, но не более одной в день. 4- Саманта выписывает один счет для всех работ, выполненных для конкрет- ного клиента, но иногда клиенты оплачивают счет поэтапно. 4- По конкретному виду деревьев могут выполняться различные виды работ и этот вид может быть подвержен различным болезням. 4 Клиент владеет только одним участком. 4 Клиенты могут переезжать, но их деревья остаются на прежнем месте. Тете- фонные номера клиентов при переезде могут и не меняться. В любом слу- чае Саманта хочет продолжать вести учет каждого клиента. 4 Для одного и того же клиента может выполняться множество работ, и он может неоднократно приобретать стружку. 1) КЛИЕНТ1 (Имя, Телефон, Дом, Улица, Город, Штат, Индекс, Дата, ЗаказаннаяРабота) 2) КЛИЕНТ? (Имя, Телефон, Дом, Улица, Город, Штат, Индекс, Дата, ЗаказаннаяРа- бота, НомерСчета, СуммаКОплате, ДатаПлатежа, УплаченнаяСумма) 3) ДЕРЕВО (Клиент, Дом, Улица, Город, Штат, Индекс, МестоположениеНаУчастке, Вид, ПриблВозраст, ДатаВыпРабот, ОписаниеРабот) 4) ВИД (НазваниеВида, Болезнь, ТипРабот) 5) ПОВТОРЯЮЩАЯСЯ_РАБОТА (ИмяКлиента, Телефон, ОписаниеРаботы, Периодич- ность, ДатаПоследнейРаботы) 6) ЗАКАЗ_НА_ПОСТАВКУ_СТРУЖКИ (ИмяКлиента, Телефон, ДатаЗаказа, ДатаДоставки)
Глава 5 Проектирование баз данных В этой главе описывается преобразование модели «сущность—связь» в реляци- онную схему базы данных. В качестве входной информации — модель данных и другие системные требования. Суть процесса трансформации такова: сущности преобразуются в таблицы, определяются ключи, представляются связи, и форму- лируются ограничения ссылочной целостности. На выходе мы получаем реляци- онную схему, состоящую из отношений, ключей, ограничений ссылочной целост- ности и процедур, контролирующих их соблюдение. Процесс проектирования базы данных Па рис. 5.1 изображены составляющие процесса проектирования базы данных. Исходной точкой для этого процесса являются модель данных и другие систем- ные требования. Во всех случаях, кроме самых простейших, структурная схема создается с помощью какого-нибудь программного средства для моделирования данных, например, ERWin пли Visio. Готовая схема существует в виде файла. Дополни тельные требования, такие как деловой регламент и ограничения ссы- лочной целостности, документируются вручную и отдельно. Рис. 5.1. Составляющие процесса проектирования базы данных Первым шагом в построении структурной схемы базы данных является пре образование сущностей и атрибутов в таблицы и столбцы.
216 Глава 5. Проектирование баз данных Преобразование сущностей и атрибутов в таблицы и столбцы Чтобы преобразовать модель сущность необходимо представ идентификатор сущности становится ся столбцами этой таблицы. ПоЗДХнИЕ (рис. 5 2, а) нреоб- первичным ключом повои та j. (пис 5 2 б). Идентификатор сущности ЗДАНИЕ - ат- пя ча/ртся в отношение 3 ДАНИ t ^рис. • , ) —, эплииг риб^гг НазваниеЗдания - становится первичным ключом таблицы ЗДА И ЗДАНИЕ НазваниеЗдания Дом Улица Город Штат Индекс Тип ИмяМенеджера ЗДАНИЕ НазваниеЗдания: NOT NULL Дом: NULL Улица: NOT NULL Город: NULL Штат: NULL Индекс: NULL Тип: NULL ИмяМенеджера: NULL б НазванивЗдания Дом Улица Город Штат Индекс Тип ИмяМенеджера в Рис. 5.2. Преобразование сущности в таблицу: а — сущность ЗДАНИЕ; б — таблица ЗДАНИЕ; в — альтернативный способ изображения таблицы Диаграммы на рис. 5.2 были построены с помощью программы ERWin. Обра- тите внимание на символ ключа рядом со столбцом НазваниеЗдания: он говорит о том, что столбец НазваниеЗдания является первичным ключом таблицы ЗДАНИЕ. К сожалению, сущности на диаграмме «сущность-связь» и таблицы на струк- турной схеме базы данных представляются весьма похожими графическими сим- волами. Чтобы отличать их друг от друга, в этой книге прямоугольники сущностей изображаются с тенью, а прямоугольники таблиц — без тени. Иногда разработ- чики изображают таблицы так, как показано на рис. 5.2, в. В этом случае атрибут, являющийся первичным ключом, подчеркивается. Одним из важнейших свойств атрибута является его обязательность или не- обязательность. По мнению некоторых, это свойст во атрибута должно быть опре-
Процесс проектирования базы дкныя 217 ПР пенс в модели данных. При таком подходе решение о том, является ли атрибут обязательным, принимается на стадии моделирования данных Друпосчитают что данное решение следует отложить до этана проектирования В любомслучае это необходимо сделать до того, как будет построена структурная схема. Все пер- вичные ключи являются обязательными. Внешние ключи могут (но не должны) быть обязательными, как вы увидите далее. Обязательность или нгаба ите шкх ч> прочих атрибутов определяется, исходя из системных требований. На рис. 5.2 напротив каждого атрибута указано NULL или NOT NULL NULL чает что атрибут не является обязательным, a NOT NULL — что атрибут является обязательным. В данном примере по системным требованиям проектировщики определили, что только атрибуты НазваниеЗдания и Город являются обязательны- ми На рис. 5.2, в обязательные атрибуты выделены жирным шрифтом Выбор первичного ключа Выбор первичного ключа является важным этапом. Большинство СУБД строят индексы по столбцам первичного ключа. Это позволяет использовать значения первичного ключа для организации физического хранения таблиц, а также упро- щает поиск и сортировку по ним. Кроме того, как вы увидите далее, путем копи- рования первичных ключей таблиц в другие таблицы представляются связи меж- ду сущностями. По этим причинам идеальный первичный ключ должен быть коротким (чтобы он не занимал много места и его можно было бы быстро обра- батывать) и редко меняться (поскольку он может помещаться во множество различных отношений, и все их необходимо будет обновить при изменении зна- чения ключа). Например, идеальным первичным ключом может служить 32-бит- ный целочисленный код детали. Как говорилось в главе 2, некоторые таблицы могут иметь более одного иден- тификатора. В этом случае необходимо выбрать тот из них, который наилучшим образом подходит на роль первичного ключа. Например, на рис. 5.3 показана табли- ца ОТДЕЛ, имеющая идентификатор НазваниеОтдела и два ключа-кандидата — атри- бут БюджетныйКод и сочетание {Здание, Комната}. В терминах модели IDEF1X клю- чи-кандидаты называются алыперчативными ключами (alternate keys). Запись AKn.m означает, что атрибут входит в состав и-го альтернативного ключа и явля- ется в нем m-м по счету. Так, атрибут Здание входит в состав второго альтерна- тивного ключа и является первым по счету атрибутом в этой ключевой rpvnne. ОТДЕЛ НазваниеОтдела БюджетныйКод (АК1.1) Здание (АК2.1) Комната (АК2.2) Рис. 5.3. Таблица с альтернативными ключами ®n!!aHCnW1 проектирования команда должна проанализировать каждую таб- У ее первичный ключ. Если имеются альтернативные идентификаторы, их
218 Глава 5. Проектирование баз данных необходимо сравнить и выбрать наиболее подходящий на ро.п, перьичиоиз кл« ча. Если сущность не имеет идентификатора, следует выбрать один из атрибутов в качестве такового или определить суррогатный ключ, как будет описано далее. Если исходить из перечисленных выше критериев (краткости, числового ти- па и редкого изменения), наплучшим кандидатом на роль первичного ключа на рис. 5.3 представляется атрибут БюджетныйКод. На это, правда, можно возразить что более удачным выбором будет атрибут НазваниеОтдела, так как он является более естественным с точки зрения пользователей. По слову «Бухгалтерия» лю- бой сотрудник сразу же поймет, о чем идет речь, а вот увидев бюджетный код 10445, немногие смогут догадаться, что имеется в виду бухгалтерия. Поэтому, ес- ли названия отделов достаточно коротки, в качестве первичного ключа можно также использовать атрибут НазваниеОтдела. ДЕРЕВО ч Д°м Ч Улица Ч Город Ч Штат Ч Индекс Ч Местоположение Вид Возраст ДЕРЕВО Ч Дом Ч Улица Ч Город Ч Штат Ч Индекс Ч Местоположение Вид Возраст а ________РАБОТА_______ ' Ч дом (FK) Ч Улица (FK) ________. Ч Город (FK) Ч Штат (FK) Ч Индекс (FK) Ч Местоположение (FK) Ч Дата ^Описание б ДЕРЕВО в Рис. 5.4. Потребность в суррогатных ключах: а — таблица со слишком большим первичным ключом; б — дальнейшее разрастание ключа при помещении его в другую таблицу; в — вариант с. использованием суррогатных ключей
Процесс проектирования базы данных 219 Но рассмотрим теперь отношение ДЕРЕВО, показанное на рис. 5.4, а. ую таблицу может использовать фирма, занимающаяся стрижкой или опрыскива- нием теревьев. Первичным ключом этой таблицы является сочетание {Дом, Ули Город Штат, Индекс, Местоположение}, где атрибут Местоположение указывает местоположение дерева на участке. Этот ключ слишком длинный, поэтому его будет трудно индексировать. Кроме того, посмотрим, что получится, если это от- ношение будет выступать в роли родителя в связи. Рассмотрим идентификационно-зависимую таблицу РАБОТА, показанную на рис 5.4, б. По определению идентифицирующей связи, первичный ключ по- томка содержит в себе первичный ключ родителя. В данном случае это означает, что в таблицу РАБОТА будет помещен непомерно длинный ключ таблицы ДЕРЕВО. Теперь мы имеем два проблематичных ключа: один в таблице ДЕРЕВО, другой в таблице РАБОТА. В таких ситуациях проектировщики часто используют сурро- гатные ключи. Суррогатные ключи Суррогатный ключ (surrogate key) — это предоставляемый СУБД уникальный идентификатор, используемый в качестве первичного ключа отношения. Значе- ния суррогат ши о к дюча не имеют смысла для пользователей, поэтому в формах и отчетах они обычно опускаются. СУБД не допускает изменения значения сурро- гатною ключа. В каждой СУБД суррогатные ключи определяются по-своему. На рис. 5.5 изо- бражен процесс определения суррогатного ключа в SQL Server. В поле Identity Seed (Начальное значение) задается начальное значение суррогатного ключа. Это значение присваивается первой проке, вставленной в таблицу' TREE. В поле Identity Increment (Приращение) задается число, которое будет прибавляться к текущему значению суррогатно ключа для получения следующего значения. В примере ня рис. 5.5 первой строке таблицы будет присвоено значение сурро- гатного ключа TreelD, равное 100, второй строке — 110, и так далее. Как происхо- дит определение суррогатных ключей в СУБД Oracle, мы [>асскажем в главе 10. Суррогатные ключи — это короткие числа, которые никогда не меняются. Таким образом, они являются идеальными первичными ключами. К тому же они не создают большой дополнительной нагрузки при использовании в качестве внешних ключей Сравните реляционные схемы на рис. 5.4, б и 5.4, в. Использо- вание суррогатных ключей потенциально экономит сотни байтов дискового про- странства на каждую строку отношения РАБОТА Тем нс менее, у суррогатных ключей имеются два важных недостатка. Во-пер- «Ых. внешние ключи, основанные на суррогатных ключах, не имеют смысла Для пользователей Чтобы понять, почему это может быть проблемой, представь- себе таблицу СОТРУДНИК, содержащую внешний ключ ИдОтдела1, который ответствует суррогатному ключу ИдОтдел в таблице ОТДЕЛ. Значение атрибута м^~"У**ИИС,1а ялючей будут иметь нил ИдХ. тле .Ид. - это сокращение от сло- Х ~ ,у,,1"'‘сти которой принадлежит данный суррогатный ключ, п поди — Примеч перге. г
220 Глава 5. Проектирование баз данных--------.------------------------ ИдОтдела, равное 1150, ничего не скажет пользователям Чтобы узнать отдела, необхо щмо найти в базе данных строку отношения ОТДЕЛ, । юпороЦ рнбут ИдОтдела ранен 1150. Рис. 5.5. Определение суррогатного ключа в SQL Server Сравните это с ситуацией, когда в качестве первичного ключа в отношении ОТДЕЛ и внешнего ключа в отношении СОТРУДНИК используется атрибут Название- Отдела. Если название отдела — это все, что нужно знать пользователю об отделе, где работает сотрудник, то больше обращений к базе данных не потребуется. Со вторым недостатком суррогатных ключей приходиться сталкиваться в слу- чаях, когда информация распределена по нескольким базам данных. Пусты на- пример, у компании имеется три базы данных по продажам, в каждой из которых содержатся сведения об определенной линии продуктов. В каждой из этих баз данных имеется таблица под названием ЗАКАЗ с суррогатным ключом ИдЗаказа. СУ БД присваивает столбцу ИдЗаказа уникальные значения в пределах одной базы данных. Эти значения, однако, не являются уникальными в рамках всех трех баз данных. Таким образом, возможна ситуация, когда две строки в таблице ЗАКАЗ двух различных баз данных будут иметь одно и то же значение атрибута ИдЗаказа Эю не является проблемой до тех пор, пока не возникает необходимость отъединить базы данных. При объединении баз данных, чтобы избежать воз- никновения строк с одинаковыми значениями суррогатного ключа, значения атрибута I/ Заказа необходимо будет изменить. По если меняются значения । (рвичною ключа, то, возможно, потребуется изменить и значения внешних
Представление связей 221 -тцочей В результате получится путаница или, по крайней мере, отребу я ^шая работа по предотвращению этой путаницы. Разумеется, можно обеспечить уникальность значении суррогата! между различными базами данных, задавая для них различные начальные значе- ния Но этот процесс требует тщательного управления и соблюдения соответ- ствующих процедур, и вероятность появления дубликатов все равно Последнее замечание. Некоторые проектировщики баз данных из соображе- ний последовательности стоят на той позиции, что если одна таблица имеет суррогатный ключ, то и все остальные таблицы в базе данных также должны иметь суррогатные ключи. По мнению других, этой политике не хватает гибко- сти: в конце концов, есть данные, могущие служить хорошими ключами (напри- мер, КодПродукта), и если такие данные имеются, то следует использовать их, а не суррогатные ключи. Представление связей После того как для каждой сущности было создано отношение и для каждого от- ношения выбран первичный ключ, следующим шагом является представление связей между сущностями. В реляционной модели все связи представляются путем помещения первичного ключа одной таблицы в другую таблицу. Как уже говори- лось, во второй таблице такой ключ называется внешним ключом (foreign key). Принципы представления связей Конкретный способ представления связи зависит от ее типа. Далее мы обсудим представление каждого из рассмотренных нами типов связей, но прежде необхо- димо понять три принципа, справедливых по отношению ко всем типам связей: поддержание ссылочной целостности, определение альтернативных процедур ее обеспечения и реализация ограничений минимальной кардинальности. Рассмот- рим каждый из этих принципов. Стандартные правила поддержания ссылочной целостности Вс кий раз, когда мы создаем внешний ключ, мы тем самым вводим новое огра- ничение ссылочной целостности. Допустим, мы хотим представить связь между сущностями СОТРУДНИК и ОТДЕЛ. Пусть отдел может иметь множество сотрудни- ков. но любой сотрудник может работать только в одном отделе. Как вы узнаете Птлг'п' такая СБЯЗЬ вида 1:N пРедставляется путем помещения ключа отношения ДЕЛ в отношение СОТРУДНИК. Предположим, что ключом отношения ОТДЕЛ яв- я атрибут НазваниеОтдела; соответственно, мы помещаем его как внешний ключ в отношение СОТРУДНИК. Теперь у нас есть следующее ограничение ссылоч- ной целостности. Значение атрибута СОТРУДНИК.НазваниеОтдела должно существовать среди значений атрибута ОТДЕЛ.НазваниеОтдела.
222 Глава 5.11роектирование без данных При создании связи мы можем процнструкгиронаю СУБД, чтобы Она иГ«зняи- (п.-п С-шс этою ограничения. (В следующей главе вы узнаето кам ЭТО ется с Помощью SQI.) Если сделаю ток, к> каждый раз. прежде чем добавь «еду» стоокх в отношение СОТРУДНИК. СУБД будет проверяю имейся ли «ютвете^ ющее значение атрибута НазваниеОтдела в отношении ОТДЕЛ. Если нет, в добавде- нин строки будет • казано. Аналогичным образом, прежде чем обновить значение столбца СОТРУДНИК-НазваниеОтдела, СУБД будет проверяю, присутствует ли новое значение среди значений атрибута НазваниеОтдела в отношении ОТДЕЛ. Если нет, СУБД не разрешит обновление. Удаление строки в дочерней таблице ие затраги- вает данное ограничение, поэтому его соблюдение в этом случае не проверяется. В связи родитель-потомок, если меняется значение первичного ключа роди- тельской строки, ограничение ссылочной целостности будет нарушено для всех дочерних строк. В связи с этим по умолчанию СУБД не разрешает обновление первичного ключа в строке, имеющей потомков. Так, например, если мы захотим поменять название отдела «Бухгалтерия» на «Бухгалтерский учет», то СУБД не разрешит нам это сделать, если в бухгалтерии числятся какие-то сотрудники. Подобным же образом при удалении родительской строки значение внешнего ключа всех ее дочерних строк будет нарушать ограничение ссылочной целостно- сти. Поэтому строка не может быть удалена, если у нее имеются потомки. Чтобы удалить родительскую строку, необходимо прежде удалить все дочерние строки. Вставка новой родительской строки не затрагивает ограничение ссылочной цело- стности, поэтому его соблюдение не проверяется. Стандартные правила поддер- жания ссылочной целостности сведены в таблицу на рис. 5.6. Действие на родительской твблице Вставка новой строки Всегда разрешена Обновление первичного ключа Запрещено, если имеются дочерние строки Удаление строки Запрещено, если имеются дочерние строки Действие на дочерней таблице Вставка новой строки Запрещена, если значение внешнего ключа в новой строке не соответствует ни одному значению первичного ключа в родительской таблице Обновление внешнего ключа Запрещено, если обновленное значение внешнего ключа не соответствует ни одному значению первичного ключа в родительской таблице Удаление существующей строки ’—- туу- - — г— правила поддержания ссылочной целостности
Представление связей 223 Альтернативные процедуры обеспечения ссылочной целостности Ппя некоторых баз данных описанные ранее стандартные процедуры поддержания точной целостности являются слишком жесткими. Например, приложение мо- жет иметь политику, в соответствии с которой для дочерних строк при необходимо- сти создаются родительские строки. В примере с отношениями ОТДЕЛ и СОТРУДНИК, если в отношение СОТРУДНИК вставляется строка, содержащая название несуще- ствующего отдела, в отношении ОТДЕЛ также создается строка с таким названием. Такая политика, если она существует, заменяет собой заданные по умолчанию правила поддержания ссылочной целостности, и сформулировать ее необходимо на стадии проектирования базы данных. Позже, на стадии реализации, ее принци- пы будут запрограммированы в виде триггеров (об этом вы узнаете из главы 7). Такие нестандартные правила определяются в процедурах обеспечения ссылоч- ной целостности (referential integrity actions). Для каждой связи имеется шесть возможных действий — три над потомком и три над родителем. Это вставка, об- новление в удаление потомка, а также вставка, обновление и удаление родителя. Вводя новую связь, необходимо всегда думать о том, какие действия над ней мо- гут производиться и какие процедуры потребуются для обеспечения ссылочной целостности в каждом из случаев. Две такие процедуры особенно распространены. Они затрагивают обновление п удаление на родительской стороне связи. Что касается обновлении, по умолча- нию значение первичного ключа строки не может быть обновлено, если у этой строки имеются потомки. Но есть и другая возможность — автоматически изме- нять значение внешнего ключа во всех дочерних строках, связанных с данной. Например, когда в отношении ОТДЕЛ название отдела «Бухгалтерия» меняется на «Бухгалтерский учет», можно соответствующим образом изменить значение атрибута НазваниеОтдела во всех дочерних строках отношения СОТРУДНИК. Таким образом связь между строками будет сохранена, и ограничения ссылочной це- лое! пости также будут соблюдены. Такая политика носит название каскадного обновления (cascading updates). Если нам нужно такое поведение, мы должны определить его на стадии проектирования как процедуру обеспечения ссылочной целостности при обновлении. Аналогичным образом, вместо того чтобы запрещать удаление строк, имею- щих потомков, СУБД может автоматически удалять все дочерние строки. Эта процедура также обеспечивает соблюдение ограничений ссылочной целостно- сти. Она носит название каскадного удаления (cascade deletions). Это поведение, если оно желательно, также необходимо предусмотреть на стадии проектирова- ния как процедуру обеспечения ссылочной целостности при удалении. Реализация ограничений минимальной кардинальности Третий важный принцип затрагивает различия между способами реализации огра- ern^v,,Й ы,ой кардинальности для дочерних и родительских строк. Если коХп^’ССТ обязательного Родителя, мы должны объявить обязательным толь- клГч "W«°ro ключа. В этом случае СУБД не допустит, чтобы внешний имел пустое значение, поэтому данная строка всегда будет иметь родителя
224 Глава 5. Проектирование баз данных Если же оояаательиым является потомок, то удобно! ибск и*пгп» для строки гарантированное наличие потомка не существует В ом случае мм стадии проектирования необходимо определить процедуры обеспечения сеидов ной целостности для этого ограничения» а па стадии ре; изации воплотить агги процедуры в виде триггеров. Рассмотрим процедуры, требуемые на дочерней стороне связи. Если минимиыюе кардинальное число на стороне потомка равно 1, это значит, что у родительской строки должен быть как минимум одни потомок. Следовательно, последняя дочери няя строка в связи не может быть удалена. В нашем примере, когда любому отделу в отношении ОТДЕЛ должен соответствовать по крайней мере один сотрудник в отношении СОТРУДНИК, мы не можем допустить удаления строки из отношения СОТРУДНИК, если она содержит запись о единственном сотруднике какого-то отдела. Аналогичным образом, мы не можем разрешить обновление столбца СОТРУДНИК. НазваниеОтдела. если этот сотрудник является единственным в данном отделе. Теперь рассмотрим ситуацию с обязательным потомком с точки зрения роди- теля. Добавляя нову ю родительскую строку, мы обязаны назначить ей потомка. Это можно сделать, создав новую дочернюю строку или назначив в качестве та- ковой уже существующую строку. К сожалению, в СУБД отсутствуют возможности для реализации этих гра- ничений. Поэтому команда разработчиков должна документировать их виде процедур обеспечения ссылочной целостности при обновлении и удалении по- томка и при вставке родителя. Таким образом, всякий раз, когда вам встречается связь с обязательным потомком, имейте в виду, что вам необходимо будет опре- делить соответствующие процедуры обеспечения ссылочной целостности. Познакомившись с этими основными принципами, можно приступить к рас- смотрению способов представления различных видов связей. В табл. 5.1 перечис- лены типы связей и приведены соответствующие термины расширенной модели «сущность—связь» и модели IDEF1X. В следующих разделах мы рассмотрим по очереди все типы связей. Таблица 5.1. Типы связей Тип связи в расширенной модели «сущность- связь» Тип связи в модель IDEF1X Примечания Идентификационно- зависимая Идентифицирующая связь принадлежности 1:1, 1:N типа «ИМЕЕТ» N:M типа «ИМЕЕТ» Неидентифицирующая В IDEF1X в связях 1:1 обязательно связь принадлежности Неспецифическая должен быть родитель и потомок Надтип/подтип Категориальная Категории внутри кластера являются взаимоисключающими. В модели «сущность—связь» такого рода ограничение отсутствует Слабая, но не идентификационно- зависимая Отсутствует Реализуется с помощью процедур обеспечения ссылочной целостное»*
Представлени» связей 220 Представление идентификационно- зависимых связей Для идентификационно-зависимых связей (называемых идентифицирующими связями принадлежности в модели IDEF1X) требуется только поместить ключ родительского отношения в качестве нового столбца в отношение-потомок. По определению, для идентификационно-зависимых связей этот столбец становится частью первичного ключа потомка. Так, например, столбец НазваниеЗдания, яв- ляющийся ключом отношения ЗДАНИЕ (рис. 5.7, «), помещается в отношение КВАРТИРА (рис. 5.7, б). Первичным ключом отношения КВАРТИРА становится соче- тание {НазваниеЗдания, НомерКвартиры}. Разумеется, если первичный ключ роди- теля является композитным, все элементы этого композитного ключа будут по- мещены в дочернее отношение, как это было с отношением ДЕРЕВО (см. рис. 5.4). ЗДАНИЕ НазваниеЗдания КВАРТИРА Дом Улица Город Штат Индекс Тип ИмяМенеджера НомерКвартиры ЧислоСпален Площадь АренднаяПлата ЗДАНИЕ НазваниеЗдания: NOT NULL КВАРТИРА Дом: NULL Улица: NOT NULL Город: NULL Штаг NULL Индекс: NULL Тип: NULL ИмяМенеджера: NULL НомерКвартиры: NOT NULL Ч НазваниеЗдания: NOT NULL (FK) ЧислоСпален: NULL Площадь: NULL АренднаяПлата: NOT NULL а б ЗДАНИЕ ^НазваниеЗдания: NOT NULL Дом: NULL Улица: NOT NULL Город; NULL Штат; NULL D:R U:C Индекс: NULL Тип: NULL ИмяМенеджера: NULL ____________КВАРТИРА___________ НомерКвартиры NOT NULL “ НазваниеЗдания: NOT NULL (FK) ЧислоСпален: NULL Площадь: NULL АренднаяПлата: NOT NULL Рис. 5.7. Представление Идентификационно-зависимых свяшй- > идентификационно-зависимой связи; б - релХн^ «е^- процедуры обеспечения ссылочной целостности
226 Глава 5. Проектирование баз данных Столбец НазваниеЗдания в Для —ключа- Таким образом, Назван^ , и часть первичного ключа отношения КВАРТИРА Но в роли первичного ключа этот столбец выступает только в отношении ЗДАНИЕ Процедуры обеспечения ссылочной целостности Поместив внешний ключ в отношение-потомок, на следующем шаге необходимо определить, какие процедуры понадобятся для реализации ограничении ссылоч- ной целостности при всевозможных действиях над связью. Как отмечалось выше, это могут быть какие-то нестандартные процедуры, заменяющие собой заданные по умолчанию правила поддержания ссылочной целостности, либо процедуры, направленные на то, чтобы гарантировать наличие обязательного потомка. Что касается первого, то по определению идентификационно-зависимой связи, мы имеем следующее ограничение ссылочной целостности. Значение атрибута КВАРТИРА.НазваниеЗдания должно существовать среди значений атрибута ЗДАНИЕ.НазваниеЗдания Теперь подумаем: нужно ли нам вводить какие-то процедуры, подменяющие стандартные правила поддержания ссылочной целостности для данного ограни- чения? Со стороны потомка используемое по умолчанию поведение нас устраи- вает. В самом деле, нам нужно запретить вставку новой строки в отношение КВАРТИРА, если значение атрибута НазваниеЗдания в ней не соответствует ни од- ному из существующих значений атрибута ЗДАНИЕ.НазваниеЗдания, и при тех же обстоятельствах запретить обновление. А вот с родительской стороны лучше было бы, по-видимому, разрешить кас- кадные обновления. Если по той или иной причине название здания должно из- мениться, нет смысла запрещать это изменение: лучше просто распространить его на всех потомков На рис. 5.7, в показано, как такие процедуры обозначаются в ERWin. «U:C» означает «Update:Cascade» («Обновление:Каскадное»). Таким образом, согласно этой схеме, значение атрибута НазваниеЗдания может быть изменено, и эти изме- нения будут распространяться на все квартиры в соответствующем здании. <D:R>> со стороны сущности ЗДАНИЕ означает «DeleteRestrict» («Удаление: Ограничить»), Эта запись означает, что будет запрещено удаление зданий, для которых имеются записи о квартирах. Поскольку такое поведение имеет место по умолчанию, нет необходимости задавать его явным образом. На данной схеме оно указано только для того, чтобы подчеркнуть, что каскадное удаление произ- водиться не будет. Соображения по поводу каскадного удаления в идентификационно-зависимых связях Каскадное обновление не представляет больших трудностей- дочерние строки просто обновляются синхронно с родительскими. Другое дело каскадное удале-
Представление । е« мА 227 ie особенно если у потомков имеются связи с другими таблицами Здесь мм приведем соображения, которыми следует руководствоваться при принятии ре- шения о том, разрешать ли каскадное удаление. Общее правило таково: если идентификационно-зависимая сущность пред ставляет многозначные атрибуты, например, несколько телефонных номеров, как на рис. 5.8, а, в использовании каскадного удаления есть смысл. В конце кон- цов, было бы довольно странно, если бы нельзя было удалить запись о сотрудни- ке только потому, что у него несколько телефонных номеров. Соответствующие процедуры обеспечения ссылочной целостности показаны на рис. 5 8, 6. СОТРУДНИК ТЕЛЕФОН ТЕЛЕФОН СОТРУДНИК б Рис. 5.8. Оправданное каскадное удаление и обновление: а — пример с многозначным атрибутом; б — реляционная схема с каскадным удалением и обновлением Если же идентификационно-зависимая сущность представляет собой не- что иное, чем просто многозначный атрибут, то прежде чем принимать решение об использовании каскадных удалений!, необходимо тщательно проанализировать все требования. Рассмотрим, например, отношение НАЗНАЧЕНИЕ на рис. 5.9, а. Если удаляется информация о сотруднике, является ли это поводом для уда- ления данных о его назначениях? Аналогично, если удаляется проект, следует ли из этого, что нужно удалить все назначения этого проекта? Можно привес- ти множество аргументов в пользу обоих вариантов ответа, и единственный способ разрешить этот спор — проанализировать требования или спросить поль- зователей. Согласно рис. 5.9, б, было принято следующее решение: удаление проекта мо- жет инициировать каскадное удаление строк в таблице НАЗНАЧЕНИЕ, а удаление сотрудника — нет. Обоснование заключается в том, что если удаляется проект, то сделанные в его рамках назначения теряют смысл, а если удаляется сотруд- ник, его назначения должны быть переданы кому-то другому Таким образом, приложение, перед тем как удалить данные о сотруднике, сначала переназначит его работу другому сотруднику, создав для того новые назначения, и удалит •азначения первого сотрудника.
228 Глава 5. проектирование баз данных б Рис. 5.09. Различные решения относительно каскадного удаления и обновления: а — пример с двумя связями; б — со стороны таблицы СОТРУДНИК каскадное удаление не предусматривается Представление идентификационно-зависимых связей с использованием суррогатных ключей Если родитель в идентификационно-зависимой связи имеет в качестве первичного ключа суррогатный ключ, а у потомка роль ключа выполняют данны