Text
                    ТЕОРИЯ И ПРАКТИКА
ПОСТРОЕНИЯ
БАЗ ДАННЫХ
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: а — образец формы; б — неспецифическая св