В книге, написанной в форме учебного пособия для студентов, специализирующихся в области информационных технологий, освещается широкий круг теоретических и практических вопросов, связанных с разработкой и использованием баз данных. К особенностям восьмого издания книги относится, в частности, появление материала, посвященного новым технологиям публикации баз данных (XML) и обработки баз данных масштаба предприятия (ODBC, ASP, JDBC, JSP). Книгу отличает продуманность структуры, живой и доступный язык изложения, а также большое количество примеров, моделирующих типичные ситуации из практики делового мира.
Содержание
Предисловие
Особенности настоящего издания
Последовательный обзор глав книги
Благодарности
Часть I. Введение
Глава 1. Введение в базы данных
Четыре примера применения баз данных
Малярная фирма Мэри Ричардс
Бюро проката музыкальных инструментов Treble Clef Music
Бюро лицензирования и регистрации
Туристический информационный центр
Сравнение четырех типов баз данных
Отношения между прикладными программами и СУБД
Системы обработки файлов
Разделенные и изолированные данные
Дублирование данных
Зависимость прикладных программ от форматов файлов
Несовместимость файлов
Трудность представления данных в удобном для пользователя виде
Системы обработки баз данных
Данные интегрированы
Меньшее количество дублирующихся данных
Независимость программ от данных
Представление данных в удобном для пользователя виде
Определение термина "база данных"
Самодокументированность
База данных - это собрание интегрированных записей
База данных является моделью модели
История баз данных
Организационный контекст
Реляционная модель
Коммерческие СУБД для микрокомпьютеров
Клиент-серверные приложения баз данных
Базы данных с использованием интернет-технологий
Распределенные базы данных
Объектно-ориентированные СУБД
Резюме
Вопросы группы I
Проекты
Вопросы к проекту FiredUp
Глава 2. Введение в разработку баз данных
База данных
Данные пользователя
Метаданные
Индексы
Метаданные приложений
СУБД
Подсистема средств проектирования
Подсистема обработки
Ядро СУБД
Создание базы данных
Пример схемы базы данных
Создание таблиц
Определение связей
Компоненты приложения
Формы
Запросы
Отчеты
Меню
Прикладные программы
Процесс разработки базы данных
Общие стратегии
Моделирование данных
Резюме
Вопросы I группы
Вопросы II группы
Вопросы к проекту FiredUp
Часть II. Моделирование данных
Глава 3. Модель "сущность-связь"
Элементы модели "сущность-связь"
Сущности
Атрибуты
Идентификаторы
Связи
Подтипы сущностей
Пример ER-диаграммы
Документирование делового регламента
Модель "сущность-связь" и CASE-средства
Диаграммы "сущность-связь" в стиле UML
Сущности и связи в UML
Конструкции ООП, введенные языком UML
Роль UML в базах данных на сегодняшний день
Примеры
Пример 1: танцевальный клуб Джефферсона
Пример 2: бюро проката парусных яхт Сан-Хуана
Базы данных как модели моделей
Резюме
Вопросы группы I
Вопросы группы II
Проекты
Вопросы к проекту FiredUp
Глава 4. Семантическая объектная модель
Семантические объекты
Определение семантических объектов
Атрибуты
Объектные идентификаторы
Домены атрибутов
Представления семантических объектов
Создание семантических объектных моделей данных
Пример: база данных администрации университета Highline
Спецификация объектов
Типы объектов
Простые объекты
Композитные объекты
Составные объекты
Гибридные объекты
Ассоциативные объекты
Объекты вида родитель/подтип
Объекты вида архетип/версия
Сравнение семантической объектной модели и модели "сущность-связь"
Резюме
Вопросы группы I
Вопросы группы II
Проекты
Вопросы к проекту FiredUp
Часть III. Проектирование баз данных
Глава 5. Реляционная модель и нормализация
Реляционная модель
Функциональные зависимости
Ключи
Функциональные зависимости, ключи и уникальность
Нормализация
Аномалии модификации
Суть нормализации
Классы отношений
Нормальные формы от первой до пятой
Вторая нормальная форма (2НФ)
Третья нормальная форма (3НФ)
Нормальная форма Бойса-Кодда (НФБК)
Четвертая нормальная форма (4НФ)
Пятая нормальная форма (5НФ)
Доменно-ключевая нормальная форма (ДКНФ)
Определение
Первый пример доменно-ключевой нормальной формы
Второй пример доменно-ключевой нормальной формы
Третий пример доменно-ключевой нормальной формы
Синтез отношений
Атрибутивная связь "один к одному"
Атрибутивная связь "многие к одному"
Атрибутивная связь "многие ко многим"
Многозначные зависимости: часть вторая
Оптимизация
Денормализация
Преднамеренная избыточность
Резюме
Вопросы I группы
Вопросы II группы
Вопросы к проекту FiredUp
Глава 6. Проектирование баз данных в рамках модели "сущность-связь"
Преобразование моделей "сущность-связь" в реляционные конструкции
Представление сущностей с помощью реляционной модели
Представление связей типа "ИМЕЕТ"
Представление тернарных связей и связей высших порядков
Представление связей типа "ЕСТЬ" (подтипов)
Пример проекта
Деревья, сети и списки материалов
Деревья
Простые сети
Сложные сети
Списки материалов
Суррогатные ключи
Пустые значения
Резюме
Вопросы I группы
Вопросы II группы
Проекты
Вопросы к проекту FiredUp
Глава 7. Проектирование баз данных в рамках семантической объектной модели
Преобразования семантических объектов в реляционные конструкции
Простые объекты
Композитные объекты
Составные объекты
Представление составных объектов со связью 1:1
Представление связей "один ко многим" и "многие к одному"
Представление связей "многие ко многим"
Гибридные объекты
Ассоциативные объекты
Объекты вида родитель/подтип
Объекты вида архетип/версия
Примеры объектов
Подписной абонемент
Описание продукта
Акт о нарушении правил дорожного движения
Резюме
Вопросы I группы
Вопросы II группы
Проекты
Вопросы к проекту FiredUp
Часть IV. Построение реляционных баз данных
Глава 8. Основы построения реляционных баз данных
Описание реляционных данных
Обзор терминологии
Реализация реляционной базы данных
Манипулирование реляционными данными
Категории языков манипулирования реляционными данными
Интерфейсы языков манипулирования данными
Реляционная алгебра
Реляционные операторы
Выражение запросов в терминах реляционной алгебры
Резюме
Вопросы I группы
Глава 9. Язык SQL
Запрос одиночной таблицы
Проектирование в SQL
Выборка в SQL
Сортировка
Встроенные функции SQL
Встроенные функции и группировка
Запрос нескольких таблиц
Вложенные запросы
Соединение с помощью SQL
Сравнение вложенного запроса и соединения
Внешнее соединение
Операторы EXISTS и NOT EXISTS
Изменение данных
Вставка данных
Удаление данных
Модификация данных
Резюме
Вопросы I группы
Вопросы II группы
Вопросы к проекту FiredUp
Глава 10. Проектирование приложений баз данных
Функции приложения базы данных
Пример приложения: галерея View Ridge
Требования к приложению
Проектирование базы данных
Создание, чтение, обновление и удаление экземпляров представлений
Чтение экземпляров представлений
Создание новых экземпляров представлений
Обновление экземпляров представлений
Удаление экземпляров представлений
Проектирование форм
Структура формы должна отражать структуру представления
Семантика данных должна быть графически очевидна
Структура формы должна побуждать к правильным действиям
Формы в среде графического интерфейса пользователя
Передвижение курсора и единообразная семантика клавиш
Проектирование отчетов
Структура отчета
Подразумеваемые объекты
Реализация ограничений
Ограничения доменов
Ограничения уникальности
Ограничения связей
Ограничения делового регламента
Безопасность и контроль
Безопасность
Контроль
Логика приложения
Резюме
Вопросы I группы
Вопросы II группы
Проекты
Вопросы к проекту FiredUp
Часть V. Обработка многопользовательских баз данных
Глава 11. Многопользовательские базы данных
Администрирование баз данных
Управление структурой базы данных
Управление параллельной обработкой
Необходимость в атомарных транзакциях
Блокировка ресурсов
Оптимистическая и пессимистическая блокировка
Объявление характеристик блокировки
Согласованные транзакции
Уровень изоляции транзакции
Безопасность базы данных
Права и обязанности по обработке
Обеспечение безопасности средствами СУБД
Обеспечение безопасности средствами приложения
Восстановление базы данных
Восстановление путем повторной обработки
Восстановление через откат-накат
Управление СУБД
Поддержание репозитория данных
Резюме
Вопросы I группы
Вопросы II группы
Проекты
Вопросы к проекту FiredUp
Глава 12. Работа с базами данных в Oracle
Установка Oracle
Создание базы данных Oracle
Работа с SQL Plus
Создание таблиц
Создание связей
Создание индексов
Изменение структуры таблицы
Контрольные ограничения
Использование оператора ALTER TABLE с контрольными ограничениями
Представления
Логика приложения
Обработка файлов PL/SQL
Хранимые процедуры
Триггеры
Словарь данных
Управление параллельной обработкой
Уровень изоляции "завершенное чтение"
Уровень изоляции "сериализуемость"
Уровень изоляции "только чтение"
Дополнительные замечания о блокировках
Oracle и безопасность
Резервное копирование и восстановление в Oracle
Средства восстановления Oracle
Типы сбоев
Вопросы, не затронутые в данной главе
Резюме
Вопросы I группы
Проекты
Вопросы к проекту FiredUp
Глава 13. Работа с базами данных в SQL Server 2000
Установка SQL Server 2000
Создание базы данных SQL Server
Создание таблиц
Определение связей
Представления
Индексы
Логика приложения
Хранимые запросы
Хранимые процедуры
Триггеры
Управление параллельной обработкой
Уровень изоляции транзакции
Поведение курсора
Блокировочные подсказки
Безопасность
Резервное копирование и восстановление
Типы резервных копий
Модели восстановления SQL Server
Восстановление базы данных
План обслуживания базы данных
Вопросы, не затронутые в этой главе
Резюме
Вопросы I группы
Проекты
Вопросы к проекту FiredUp
Часть VI. Обработка организационных баз данных
Глава 14. Сети, многоуровневые архитектуры и XML
Разновидности сетевого окружения
Интернет
Интрасети
Беспроводной доступ в сети
Многоуровневая архитектура
Web-сервер под управлением Windows 2000
Web-сервер под управлением Unix и Linux
Многоуровневая обработка
Языки разметки и DHTML
Стандарты языков разметки
Проблемы, связанные с HTML
DHTML
XML - расширяемый язык разметки
XML как язык разметки
XML-документ и DTD
Материализация XML-документов
Терминология и стандарты XML
XML Schema
Протокол WAP
Значение XML для приложений баз данных
Пример применения XML в электронной коммерции
Поддержка XML в Oracle и SQL Server
Резюме
Вопросы I группы
Вопросы II группы
Вопросы к проекту FiredUp
Глава 15. ODBC, OLE DB, ADO и ASP
Окружение web-сервера
Стандарт ODBC
Архитектура ODBC
Уровни соответствия
Задание имени источника данных ODBC
OLE DB
Цели создания OLE DB
Основные конструкции OLE DB
ADO
Вызов ADO из ASP-страниц
Объектная модель ADO
Примеры использования ADO
Пример 1 - чтение таблицы
Пример 2 - чтение таблицы обобщенным способом
Пример 3 - чтение любой таблицы
Пример 4 - обновление таблицы
Пример 5 - вызов хранимой процедуры
Резюме
Вопросы I группы
Вопросы II группы
Вопросы к проекту FiredUp
Глава 16. JDBC, Java Server Pages и MySQL
JDBC
Типы драйверов
Использование JDBC
Примеры использования JDBC
Java Server Pages
JSP-страницы и сервлеты
Apache Tomcat
Настройка Tomcat для обработки JSP
Примеры JSP-страниц
MySQL
Ограничения MySQL
Работа с MySQL
Настройка разрешений на доступ для JDBC
Управление параллельной обработкой
Резервное копирование и восстановление
Заключительное слово о MySQL
Резюме
Вопросы I группы
Вопросы II группы
Проекты
Вопросы к проекту FiredUp
Глава 17. Совместное использование данных предприятия
Архитектуры организационных систем обработки данных
Системы удаленной обработки
Клиент-серверные системы
Системы совместного использования файлов
Системы обработки распределенных баз данных
Загрузка данных
Компания Universal Equipment
Процесс загрузки
Потенциальные проблемы при обработке загруженных баз данных
Оперативная аналитическая обработка данных (OLAP)
Информационные хранилища
Компоненты информационного хранилища
Требования к информационному хранилищу
Проблемы разработки и эксплуатации информационных хранилищ
Информационные лавки
Администрирование данных
Потребность в администрировании данных
Проблемы администрирования данных
Задачи отдела администрирования данных
Резюме
Вопросы I группы
Вопросы II группы
Часть VII. Работа с объектно-ориентированными базами данных
Глава 18. Объектно-ориентированные базы данных
Введение в объектно-ориентированное программирование
Терминология ООП
Пример ООП
Постоянное хранение объектов
Постоянное хранение объектов в традиционной файловой системе
Постоянное хранение объектов с помощью СУБД
Постоянное хранение объектов с использованием ООСУБД
Постоянное хранение объектов в Oracle
Типы объектов и коллекции
Объекты Oracle
Стандарты ООСУБД
SQL3
ODMG-93
Резюме
Вопросы I группы
Вопросы II группы
Приложение А. Структуры данных
Плоские файлы
Обработка плоских файлов в различном порядке
Замечание по поводу адресации записей
Упорядочение с помощью связных списков
Упорядочение с помощью индексов
Бинарные деревья
Резюме по структурам данных
Представление бинарных связей
Обзор видов связей между записями
Представление деревьев
Представление простых сетей
Представление сложных сетей
Представление вторичных ключей
Представление вторичных ключей с помощью связных списков
Представление вторичных ключей с помощью индексов
Резюме
Вопросы I группы
Вопросы II группы
Приложение Б. Создание семантических объектных моделей в программе Tabledesigner
Создание семантической объектной модели
Реконструкция семантической объектной модели по имеющейся базе данных
Публикация базы данных в Web
Следующие шаги
Упражнения
Алфавитный указатель
ОТРЫВОК
Глава 4
Семантическая объектная модель
В этой главе обсуждается семантическая объектная модель (semantic object model), которая, так же как и модель "сущность-связь", описанная в главе 3, используется для моделирования данных. Как показано на рис. 4.1, команда разработчиков опрашивает пользователей, анализирует предоставленные ими отчеты, формы и запросы и на их основе строит пользовательскую модель данных. Эта модель данных в дальнейшем воплощается в структуре базы данных.
Конкретная форма модели данных зависит от конструкций, используемых для ее построения. Если используется модель "сущность-связь", конструируемая модель будет содержать сущности, связи и т. п. В случае использования семантической объектной модели конструируемая модель будет содержать семантические объекты и связанные с ними конструкции, которые описываются в данной главе.
Модель "сущность-связь" и семантическая объектная модель подобны двум различным линзам, сквозь которые смотрят разработчики баз данных при изучении и документировании пользовательских данных. Обе линзы действуют, и обе они в конечном счете воплощаются в определенной структуре базы данных. Однако, поскольку эти линзы не одинаковы и создают разные изображения, структура баз данных, полученных с их помощью, может несколько различаться. Разрабатывая базу данных, вы должны решить, какой подход применять, так же как фотографу приходится решать, какую исполь
зовать линзу. Каждый подход имеет свои сильные и слабые стороны, которые мы обсудим в конце этой главы.
Семантическая объектная модель была впервые представлена в третьем издании этой книги в 1988 г. Она основана на концепциях, разработанных и опубликованных Коддом, Хаммером и Мак-Леодом . Семантическая объектная модель - это модель данных. Ее не следует путать с объектно-ориентированной обработкой баз данных, о которой пойдет речь в главе 18. Вы узнаете, чем цели, свойства и конструкции семантической объектной модели отличаются от объектно-ориентированных баз данных.
Семантические объекты
Задача приложения базы данных состоит в том, чтобы предоставлять формы, отчеты и запросы, с помощью которых пользователи могли бы отслеживать сущности или объекты, представляющие интерес для их деятельности. Целью ранних стадий разработки базы данных является определение того, какие вещи должны быть представлены в базе данных, задание характеристик этих вещей и установление связи между ними.
В главе 3 мы называли эти вещи сущностями. В этой главе мы будем их называть семантическими объектами (semantic objects), а иногда просто объектами. Слово семантический означает "смысловой", и семантический объект - это объект, который в определенной степени моделирует смысл пользовательских данных. Семантические объекты моделируют восприятие пользователя более точно, чем модель "сущность-связь". Мы используем со словом объект прилагательное семантический, чтобы отличать объекты, о которых идет речь в этой главе, от объектов, которыми оперируют объектно-ориенти
рованные языки программирования.
Определение семантических объектов
Сущности и объекты в некоторых отношениях схожи, но у них есть и различия. Мы начнем со сходства. Семантический объект - это представление некоторой вещи, идентифицируемой в рабочей среде пользователя. Если выражаться более формально, семантический объект - это именованная совокупность атрибутов, которая в достаточной степени описывает отдельный феномен.
Подобно сущностям, семантические объекты группируются в классы. У объектного класса есть имя, которое отличает его от других классов и соответствует именам вещей, представляемых этим классом. Так, в базе данных, содержащей информацию о студентах, имеется объектный класс под названием СТУДЕНТ. Обратите внимание, что имена объектных классов, как и имена классов сущностей, пишутся заглавными буквами. Отдельный семантический объект представляет собой экземпляр класса. Например, Уильям Джонс является экземпляром класса СТУДЕНТ, а Бухгалтерия является экз
емпляром класса ОТДЕЛ.
Подобно сущностям, объект имеет набор атрибутов. Каждый атрибут описывает одну из характеристик представляемого феномена. Например, объект СТУДЕНТ может иметь атрибуты Имя, ДомашнийАдрес, МестныйАдрес, ДатаРождения, ДатаОкончанияШколы и Специальность. Этот набор атрибутов также является достаточным описанием (sufficient description), то есть он описывает все характеристики, необходимые пользователям для работы. Как было указано нами в конце главы 3, каждая вещь в мире имеет бесконечное множество характеристик, и мы не в состоянии представить всю их совокупност
ь. Вместо этого мы представляем только те из них, которые требуются для удовлетворения информационных потребностей пользователей в той степени, чтобы они могли успешно выполнять свои функции. Достаточность описания означает также, что объекты являются самодостаточными. Например, все требуемые данные о покупателе содержатся в объекте КЛИЕНТ, так что нам нигде больше не требуется искать, чтобы найти эти данные.
Объекты представляют отдельные феномены (distinct identity), то есть в восприятии пользователей они являются чем-то независимым и самостоятельным, что требует учета. Феномены - это сущности, информация о которых необходима. Чтобы лучше уяснить значение термина отдельный феномен, вспомните, что существует разница между объектами и экземплярами объектов. КЛИЕНТ - это имя объекта, а КЛИЕНТ 12345 - имя экземпляра объекта. Когда мы говорим, что объект представляет отдельный феномен, мы имеем в виду, что пользователи считают каждый экземпляр объекта уникальным и имеющим
самостоятельное значение.
Наконец, стоит отметить, что феномены, представляемые объектами, могут существовать физически, как, например, объекты класса СОТРУДНИК, а могут и не существовать, как объекты класса ЗАКАЗ. Заказ как таковой является моделью контрактного соглашения о предоставлении определенных товаров или услуг в установленном порядке и на известных условиях. Он является не физическим предметом, а представлением соглашения. Таким образом, чтобы нечто могло считаться объектом, ему не обязательно существовать физически - нужно лишь, чтобы это нечто имело самостоятельно
е значение в представлении пользователей.
Атрибуты
Семантические объекты имеют атрибуты, описывающие их характеристики. Есть три типа атрибутов. Простые атрибуты (simple attributes) состоят из одного элемента. Примерами могут быть атрибуты ДатаНайма, НомерНакладной и ИтоговаяСуммаПродаж. Групповые атрибуты (group attributes) являют собой совокупности других атрибутов. В качестве примера можно привести атрибут Адрес, состоящий из атрибутов {Улица, Город, Штат, Индекс}. Еще один пример - атрибут ПолноеИмя, включающий в себя атрибуты {Имя, Отчество, Фамилия}. Семантические объектные атрибуты (semantic object attributes) - это атрибуты,
которые устанавливают связь между двумя семантическими объектами.
Чтобы лучше понять эти определения, взгляните на рис. 4.2, a, который представляет собой пример семантической объектной диаграммы (semantic object diagram), или просто объектной диаграммы (object diagram). Такие диаграммы используются командами разработчиков для описания и визуального представления структуры объектов. Объекты изображаются в вертикально ориентированных прямоугольниках. Имя объекта указывается вверху, а атрибуты записываются по порядку после имени объекта.
Объект КАФЕДРА содержит пример каждого из трех типов атрибутов. Атрибуты НазваниеКафедры, НомерТелефона и НомерФакса являются простыми: каждый из них представляет один элемент данных. МестныйАдрес - групповой атрибут, состоящий из простых атрибутов Корпус и НомерОфиса. Наконец, КОЛЛЕДЖ, ПРЕПОДАВАТЕЛЬ и СТУДЕНТ - это семантические объектные атрибуты, то есть эти объекты связаны с объектом КАФЕДРА и логически содержатся в нем.
Смысл этих объектных атрибутов, или объектных ссылок (object links), как их иногда называют, состоит в том, что когда пользователь думает об определенной кафедре, он имеет в виду не только название кафедры, локальный адрес, номер телефона и номер факса этой кафедры, но также колледж, в котором она находится, профессоров, преподающих на ней, и студентов, занимающихся на ней. Поскольку КОЛЛЕДЖ, ПРЕПОДАВАТЕЛЬ и СТУДЕНТ также являются объектами, полная модель данных содержит диаграммы и для них. Объект КОЛЛЕДЖ несет в себе атрибуты колледжа, объект ПРЕПОДАВАТЕЛЬ - ат
рибуты членов профессорско-преподавательского состава, а объект СТУДЕНТ содержит атрибуты студентов.
Кардинальное число атрибута
Каждый атрибут семантического объекта имеет максимальное и минимальное кардинальные числа. Минимальное кардинальное число показывает количество экземпляров атрибута, которые должны существовать, чтобы объект был допустимым. Обычно это число равно 0 или 1. Если оно равно 0, атрибут не обязан иметь значение, а если 1, то атрибут обязан иметь значение. Хотя это и необычно, минимальное кардинальное число иногда может быть больше единицы. Например, атрибут Игрок в объекте под названием БАСКЕТБОЛЬНАЯ_КОМАНДА может иметь минимальное кардинальное число, равное
5, поскольку таково наименьшее число игроков, требуемое для создания баскетбольной команды.
Максимальное кардинальное число показывает максимальное количество экземпляров атрибута, которое может иметь объект. Обычно оно равно 1 или N. Если оно равно 1, атрибут может иметь не более одного экземпляра; если оно равно N, атрибут может иметь много экземпляров, и предельное количество не задано. Иногда максимальное кардинальное число равно определенному числу, например 5, - это означает, что объект может иметь не более пяти экземпляров атрибута. Например, атрибут ИГРОК в объекте БАСКЕТБОЛЬНАЯ_КОМАНДА может иметь максимальное кардинальное число, равно
е 15, и это будет означать, что в состав команды может быть включено не более 15 игроков.
Кардинальность изображается в виде нижнего индекса атрибута в формате N.M, где N - минимальное кардинальное число, а M - максимальное. На рис. 4.2, б минимальное кардинальное число для атрибута НазваниеКафедры равно 1, и максимальное также 1; таким образом, требуется ровно один экземпляр этого атрибута. Кардинальность атрибута НомерТелефона равна 1.N, то есть кафедра обязана иметь минимум один номер телефона, но в принципе номеров у нее может быть много. Кардинальность 0.1 у атрибута НомерФакса означает, что кафедра может не иметь факса, а может и иметь, но только
один.
Кардинальные числа групп и атрибутов групп, как правило, невелики. Возьмем атрибут МестныйАдрес. Его кардинальность 0.1, то есть кафедра не обязана иметь адрес, но если имеет, то только один. Теперь рассмотрим простые атрибуты, из которых состоит атрибут МестныйАдрес. Как Корпус, так и НомерОфиса имеют кардинальность 1.1. Вы можете удивиться, каким образом получается, что группа может быть необязательной, если атрибуты, составляющие эту группу, являются обязательными. Дело в том, что кардинальные числа действуют только между атрибутом и его контейнером (гру
ппой, содержащей этот атрибут). Минимальное кардинальное число атрибута МестныйАдрес показывает, что этот атрибут не обязан иметь значение, то есть кафедра не обязана иметь адрес. А минимальные кардинальные числа атрибутов Корпус и НомерОфиса показывают, что эти атрибуты должны существовать в атрибуте МестныйАдрес. Таким образом, группа МестныйАдрес не обязана существовать, но если уж она существует, то составляющие ее атрибуты Корпус и НомерОфиса должны иметь значения.
Экземпляры объектов
Объектные диаграммы для кафедры, показанные на рис. 4.2, представляют собой просто формат, общую структуру, которую можно отнести к любой кафедре. На рис. 4.3 представлен экземпляр объекта КАФЕДРА. Здесь указаны значения каждого атрибута конкретной кафедры. Кафедра имеет название "Информационные системы" и расположена в офисе № 213 корпуса социальных наук. Обратите внимание, что атрибут НомерТелефона имеет три значения: в офисе кафедры информационных систем имеется три телефонные линии. Другие кафедры могут иметь меньшее или большее количество телефонов, н
о у каждой кафедры есть по крайней мере один телефон.
Далее, имеется один экземпляр атрибута КОЛЛЕДЖ, со значением Колледж Бизнеса, и множество экземпляров объектных атрибутов ПРЕПОДАВАТЕЛЬ и СТУДЕНТ. Каждый из этих объектных атрибутов является полноценным объектом и имеет все атрибуты, определенные для объекта данного типа. Чтобы не усложнять диаграмму, мы указали на ней только имена экземпляров объектных атрибутов.
Объектная диаграмма - это картина восприятия пользователем объекта в рабочей среде. Таким образом, в воображении пользователя объект КАФЕДРА содержит все эти данные. Кафедра логически содержит данные о колледже, к которому она принадлежит, а также о профессорах и студентах, относящихся к этой кафедре.
Парные атрибуты
В семантической объектной модели нет однонаправленных связей между объектами. Если один объект содержит в себе другой объект, то этот другой будет, в свою очередь, содержать в себе первый. Например, если объект КАФЕДРА содержит в себе объектный атрибут КОЛЛЕДЖ, то и объект КОЛЛЕДЖ будет содержать соответствующий объектный атрибут КАФЕДРА. Эти объектные атрибуты называются иногда парными атрибутами (paired attributes), так как они всегда появляются по два.
Почему объектные атрибуты должны быть парными? Ответ заключается в том способе, каким человеческие существа представляют себе связи между объектами. Если объект А имеет связь с объектом Б, то объект Б будет иметь связь с объектом А. По крайней мере, Б связан с А как "вещь, которая связана с Б". Если этот аргумент кажется неочевидным, попробуйте вообразить однонаправленную связь между объектами. Это сделать невозможно.
Объектные идентификаторы
Объектный идентификатор (object identifier) - это один или несколько объектных атрибутов, с помощью которых пользователи идентифицируют экземпляры объектов. Такие идентификаторы представляют собой потенциальные имена семантического объекта. Для объекта КЛИЕНТ возможными идентификаторами являются НомерКлиента и ИмяКлиента. Каждый из этих идентификаторов является атрибутом, рассматриваемым пользователями в качестве допустимого имени для экземпляров объектного класса КЛИЕНТ. Сравните эти идентификаторы с атрибутами ДатаПервогоЗаказа, КурсАкций или Числ
оСотрудников. Такие атрибуты не являются идентификаторами, потому что пользователи не думают о них как об именах экземпляров объектов класса КЛИЕНТ.
Групповой идентификатор (group identifier) - это идентификатор, содержащий более одного атрибута. Примерами могут служить идентификаторы {Имя, Фамилия}, {Имя, НомерТелефона} и {Штат, НомерЛицензии}.
Объектные идентификаторы могут быть уникальными или неуникальными, в зависимости от того, как пользователи представляют себе свои данные. Например, НомерСчета является уникальным идентификатором объекта ЗАКАЗ, но ИмяСтудента не является уникальным идентификатором объекта СТУДЕНТ. Может быть два студента по имени, к примеру, Мэри Смит. В таком случае пользователи будут идентифицировать с помощью атрибута ИмяСтудента группу из одного или более студентов и затем, если необходимо, использовать значения других атрибутов для указания конкретного члена э
того множества.
В семантических объектных диаграммах объектные идентификаторы обозначаются с помощью букв ID перед атрибутом. Если идентификатор является уникальным, эти буквы подчеркнуты. На рис. 4.2, б, например, атрибут НазваниеКафедры является уникальным идентификатором объекта КАФЕДРА.
Обычно, если атрибут должен использоваться в качестве идентификатора, он обязан иметь значение. Кроме того, как правило, для данного объекта имеется не более одного идентифицирующего атрибута. Поэтому в большинстве случаев кардинальность атрибута-идентификатора равна 1.1, и это значение мы используем по умолчанию.
Есть, однако, относительно небольшое число случаев, когда кардинальность идентификатора отличается от 1.1. Рассмотрим, например, атрибут Псевдоним семантического объекта ЧЕЛОВЕК. Человек не обязан иметь псевдоним, однако может иметь и несколько. Следовательно, кардинальность этого атрибута равна 0.N.
Указание нижних индексов всех атрибутов загромождает семантическую объектную диаграмму. Для упрощения мы предположим, что кардинальность простых идентифицирующих атрибутов равна 1.1, а прочих идентифицирующих атрибутов - 0.1. Если кардинальность простого атрибута имеет другое значение, мы укажем ее на диаграмме. В противном случае нижние индексы простых атрибутов будут опускаться.
Домены атрибутов
Домен (domain) атрибута - это описание множества его значений. Характеристики домена зависят от типа атрибута. Домен простого атрибута состоит из физического и семантического описания. Физическое описание (physical description) показывает тип данных (например, число или строка), длину данных и другие ограничения (например, требование, чтобы первый символ был буквой или чтобы значение не превышало 9999.99). Семантическое описание (semantic description) указывает функцию, или назначение данного атрибута; оно отличает этот атрибут от других атрибутов с тем же физическим описанием.
Например, домен атрибута НазваниеКафедры может быть определен как "набор строк длиной до 7 символов, представляющих наименования кафедр университета Highline". Фраза "набор строк длиной до 7 символов" представляет собой физическое описание домена, а "…представляющих имена кафедр университета Highline" - семантическое описание. Семантическое описание отличает строки из семи символов, представляющие названия кафедр, от строк такой же длины, которые представляют, скажем, названия учебных дисциплин, корпусов или какие-то еще атрибуты.
В некоторых случаях физическое описание домена простого атрибута представляет собой нумерованный список - набор отдельных значений атрибутов. Доменом атрибута ЦветДетали может быть, например, нумерованный список {"Синий", "Желтый", "Красный"}.
Домен группового атрибута также имеет физическое и семантическое описание. Физическое описание - это список всех атрибутов в группе в порядке их следования. Семантическое описание - это описание функции, или назначения, данной группы. Так, физическим описанием домена МестныйАдрес (см. рис. 4.2) является список {Корпус, НомерОфиса}; семантическим описанием является фраза "местоположение офиса в университете Highline".
Домен объектного атрибута - это набор экземпляров объектов данного типа. На рис. 4.2, например, доменом объектного атрибута ПРЕПОДАВАТЕЛЬ является совокупность всех экземпляров объектов класса ПРЕПОДАВАТЕЛЬ, представленных в базе данных. Доменом объекта КОЛЛЕДЖ является совокупность всех объектов класса КОЛЛЕДЖ, представленных в базе данных. В определенном смысле, домен атрибута - это динамически нумерованный список, который содержит все экземпляры объектов данного типа.
Представления семантических объектов
Пользователи имеют доступ к значениям объектных атрибутов через приложения базы данных, которые предоставляют формы для ввода данных, отчеты и запросы. В большинстве случаев такие формы, отчеты и запросы не требуют доступа ко всем атрибутам объекта. Например, на рис. 4.4. показаны представления объекта КАФЕДРА для двух различных приложений. Некоторые атрибуты объекта КАФЕДРА (например, НазваниеКафедры) являются видимыми в обоих представлениях. Другие атрибуты видимы только в одном из представлений. Например, атрибут СТУДЕНТ является видимым только в пр
едставлении СписокСтудентов, а атрибут ПРЕПОДАВАТЕЛЬ виден только в представлении Персонал.
Часть объекта, видимая для конкретного приложения, называется представлением семантического объекта (semantic object view), или просто представлением (view). Представление состоит из имени объекта и списка всех атрибутов, видимых в этом представлении.
Представления используются двояким образом. Когда вы разрабатываете базу данных, вы можете использовать их для разработки модели данных. Взгляните снова на рис. 4.1. Как можно видеть, при разработке модели данных разработчики базы данных и приложений двигаются в обратном направлении. То есть они начинают с форм, отчетов и запросов, которые пользователи объявляют необходимыми, и двигаются назад, к структуре базы данных. Для этого команда выбирает требуемую форму, отчет или запрос и определяет, какое представление должно существовать, чтобы можно было соз
дать такую форму, отчет или запрос. Затем команда переходит к следующей форме, отчету или запросу и делает то же самое. Далее получившиеся два представления объединяются. Описанный процесс повторяется до тех пор, пока структура базы данных не будет полностью сформирована.
Второй аспект использования представлений возникает, когда структура базы данных уже создана. В этом случае представления создаются для поддержки новых форм, отчетов и запросов на основе существующей структуры базы данных. Примеры этого второго подхода приведены в части IV, где обсуждаются SQL Server и Oracle.
Теория и практика построения баз данных. 8-е изд.. / Д. Крёнке - СПб: Питер, 2003. - 800 с.
|