- •1. Основы построения баз данных 11
- •2. Модели представления данных 22
- •3. ДатАлогические модели данных 38
- •4. Семантическое моделирование 101
- •5. Базы данных в сетях 155
- •6.Современное состояние и 177
- •1. Основы построения баз данных
- •1.1. Архитектура системы баз данных
- •1.2. Жизненный цикл базы данных
- •Контрольные вопросы и задания
- •2. Модели представления данных
- •2.1. Классификация моделей данных
- •2.2. Разновидности инфологических моделей данных
- •Контрольные вопросы и задания
- •3. ДатАлогические модели данных
- •3.1. Иерархические модели
- •Между предками и потомками автоматически поддерживается целостность ссылок. Основное правило: никакой потомок не может существовать без своего родителя, у некоторых родителей не может быть потомков.
- •3.2. Сетевые модели
- •3.3. Реляционные модели
- •3.3.1. Основные понятия реляционной модели
- •3.3.2. Реляционная алгебра
- •3.3.3. Язык запросов по образцу qbe
- •3.3.4. Структурированный язык запросов sql
- •Основные инструкции языка sql
- •Values ("3110", "чп Иванов п.Т.", null)
- •3.4. Проектирование реляционных баз данных
- •Контрольные вопросы и задания
- •4. Семантическое моделирование
- •4.1. Объектно-ориентированное проектирование
- •4.1.1. Представление объектов
- •4.1.2. Описания классов
- •4.1.3. Атрибуты в odl
- •4.1.4. Связи в odl
- •4.1.5. Обратные связи
- •4.1.6. Множественность связей
- •4.1.7. Типы в odl
- •4.1.8. Проектирование с использованием odl
- •Правильность
- •Устранение избыточности
- •4.1.9. Подклассы
- •4.1.10. Множественное наследование в odl
- •4.1.11. Моделирование ограничений
- •Ссылочная целостность
- •Прочие ограничения
- •4.1.12. Переход от объектно-ориентированной модели к реляционной
- •4.2. Диаграммы "сущность-связь"
- •4.2.1. Компоненты диаграмм "сущность-связь"
- •4.2.2. Множественность e/r-связей
- •Многосторонние связи
- •4.2.3. Роли в связях
- •4.2.4. Атрибуты связей
- •4.2.5. Конвертирование многосторонних связей в бинарные
- •4.2.6. Проектирование e/r моделей
- •Простота
- •Типы элементов проекта
- •Определения подклассов
- •Наследование в e/r-модели
- •Моделирование ограничений
- •Ссылочная целостность
- •Слабые множества сущностей
- •Переход от e/r-диаграмм к реляционным проектам
- •Контрольные вопросы и задания
- •5. Базы данных в сетях
- •5.1. Архитектура "клиент-сервер"
- •5.2. Распределенные базы данных
- •5.3. Базы данных в Интернет
- •Контрольные вопросы и задания
- •Контрольные вопросы и задания
- •Информационные ресурсы Internet
- •Словарь терминов
- •Список сокращений
- •Темы рефератов
4.2.3. Роли в связях
Некоторое множество сущностей может многократно фигурировать в одной и той же связи, от символа связи к множеству проводится столько линий, сколько раз это множество участвует в данной связи. Каждая из таких линий определяет роль, которую множество играет в связи.
Пример 4.15. На рис. 50 изображена связь Быть_учеником множества Мастера с самим собой. Каждая связь – это связь между двумя мастерами, один из которых является учеником другого. Для различения этих двух мастеров, в рамках данной связи одна линия отмечена ролью Наставник, а другая ролью Ученик, которые обозначают мастера-наставника и его ученика соответственно. Предполагается, что у наставника может быть много учеников, но у каждого ученика есть только один наставник. Таким образом, стрелка E/R-диаграммы на рис. 50 показывает связь типа "многие-к-одному" множества Ученик с множеством Наставник.
Пример 4.16. В качестве примера, включающего в себя многостороннюю связь и множество сущностей со многими ролями, на рис. 51 дается более сложная версия связи Договоры, введенной в примере 4.5. Здесь показана связь Договоры между двумя цехами, мастером и изделием. Для иллюстрации предполагается, что цех, имеющий договор на пошив изделия с определенным мастером, может заключить со вторым цехом договор, позволяющий привлекать возможности другого цеха, например для получения каких-либо материалов или выполнения тонких работ. Такая связь описывается четверками вида:
(цех_1, цех_2, мастер, изделие),
причем цех_2 заключает с цехом_1 договор на привлечение мастера цеха1 для изделия цеха2.
На рис. 51 есть стрелки, указывающие на Цеха в двух ролях: как "владельца" мастера и как производителя изделия, но нет стрелок, указывающих на Мастера или Изделия. Это значит, что при наличии мастера, изделия и цеха, производящего изделие, только один цех может "владеть" мастером. (Предполагается, что мастер имеет договор только с одним цехом.) Аналогично, данное изделие производится единственным цехом, поэтому при наличии мастера, изделия и цеха, "владеющего" мастером, можно определить единственный производящий изделие цех. Заметим, что обоих случаях для определения уникальной сущности реально нужна только одна из остальных сущностей (например, для определения уникального производящего цеха необходимо знать только изделие), но этот факт не изменяет множественное определение многосторонней связи.
Стрелки не указывают на Мастера или Изделия. При наличии мастера, "владеющего" им цеха и цеха, выпускающего изделия, может быть заключено множество договоров, позволяющих мастеру работать над различными изделиями. Значит, совсем не обязательно, что остальные три компонента в четверке данной связи определяют единственное изделие. Аналогично, производящий цех может заключать контракт с другими цехами об участии нескольких их мастеров при работе над одним своим изделием. Таким образом, мастер не определяется тремя остальными компонентами данной связи.
4.2.4. Атрибуты связей
Бывает удобно приписывать атрибуты к связи, а не к одному из множеств сущностей, находящихся в данной связи. Рассмотрим связь, представляющую договор мастера с цехом на изготовление изделия (рис. 49). Допустим, надо записать гонорар, указанный в этом договоре. Однако гонорар нельзя связать с мастером, так как он может получать разные гонорары за работу над разными изделиями. Не очень хорошо связывать договор с цехом (различным мастерам он может выплачивать разные гонорары) или с изделием (разные мастера получают за подобные изделия разные гонорары). Удобно связать гонорар с тройкой:
(мастер, изделие, цех)
во множестве отношений для связи Договоры. На рис. 52 показана схема рис. 49 вместе с атрибутами. Связь имеет атрибут гонорар, а множества сущностей имеют те же атрибуты, которые были показаны на рис. 47.
Размещать атрибуты на самих связях нет необходимости. Вместо этого можно ввести новое множество сущностей с атрибутами, приписанными данной связи, и включить такое множество в связь.
Пример 4.17. Изменим E/R-диаграмму (рис. 52), на которой связь Договоры имеет атрибут гонорар.
Создадим множество Гонорары с атрибутом гонорар (рис. 53).