- •Введение в базы данных
- •Отношения между прикладными программами и субд
- •Системы обработки баз данных
- •История баз данных
- •Организационный контекст
- •Реляционная модель
- •Коммерческие субд для микрокомпьютеров
- •Клиент-серверные приложения баз данных
- •Базы данных с использованием Интернет-технологий
- •Распределенные базы данных
- •Объектно-ориентированные субд
- •Банк данных
- •Основные понятия и определения
- •Пользователи банков данных
- •База данных
- •Архитектура базы данных. Физическая и логическая независимость
- •Схемы и отображения
- •Независимость от данных
- •Система управления базами данных – субд
- •Процесс прохождения пользовательского запроса
- •Введение в разработку баз данных
- •Метаданные
- •Индексы
- •Метаданные приложений
- •Подсистема средств проектирования
- •Подсистема обработки
- •Ядро субд
- •Создание базы данных
- •Процесс разработки базы данных
- •Моделирование данных
- •Функции субд
- •Модели данных
- •Объектные или инфологические модели данных
- •Модели данных на основе записей или даталогические
- •Реляционная модель данных
- •Преподаватели
- •Сетевая модель данных
- •. Физические модели данных
- •Концептуальное моделирование
- •Реляционная модель
- •Структура реляционных данных
- •Кортежи
- •Внешний ключ
- •Альтернативная терминология
- •Математические отношения
- •Отношения в базе данных
- •Реляционные ключи
- •Реляционная целостность
- •Целостность сущностей
- •Ссылочная целостность
- •Реляционные языки
- •Реляционная алгебра
- •Учебный проект DreamHome
- •Реляционная алгебра (продолжение)
- •Выборка (или ограничение)
- •Проекция
- •Декартово произведение
- •Объединение
- •Разность
- •Операции соединения
- •Tema-соединение (θ-join)
- •Естественное соединение
- •Внешнее соединение
- •Полусоединение
- •Пересечение
- •Деление
- •Другие языки
- •Примеры применения реляционной алгебры
- •Обзор жизненного цикла информационных систем
- •Жизненный цикл приложения баз данных
- •Проектирование базы данных
- •Проектирование баз данных на основе восходящего подхода (Метод нормализации или декомпозиции)
- •Цель нормализации
- •Проблемы, вызываемые использованием единственного отношения (аномалии обновления)
- •Проблема вставки
- •Проблема обновления
- •Проблемы удаления
- •Функциональные зависимости
- •Процесс нормализации
- •Декомпозиция без потерь и функциональные зависимости
- •Первая нормальная форма (1 нф) (из Коннолли)
- •Вторая нормальная форма (2нф)
- •Третья нормальная форма (знф)
- •Нормальная форма Бойса-Кодда (нфбк)
- •4 И 5 нормальные формы (4нф и 5нф)
- •Пример нормализации
- •. Другая декомпозиция отношения консультант
- •Некоторые комментарии к декомпозиционному алгоритму проектирования
- •Некоторые модификации алгоритма проектирования Избыточные функциональные зависимости
- •Транзитивные зависимости
- •Добавление атрибутов в фз
- •Правила вывода
- •Алгоритм проектирования бд методом декомпозиции (восходящий метод)
- •Проверка отношений на завершающей фазе их проектирования
- •Задачи к текущему материалу
- •Пример аномалий для 2нф
- •Нормальная форма Бойса—Кодда (нфбк) с примером аномалий для 3 формы
- •Язык sql
- •Запрос одиночной таблицы
- •Проектирование в sql
- •Выборка в sql
- •Сортировка
- •Встроенные функции sql
- •Встроенные функции и группировка
- •Запрос нескольких таблиц
- •Вложенные запросы
- •Соединение с помощью sql
- •Сравнение вложенного запроса и соединения
- •Внешнее соединение
- •Операторы exists и not exists
- •Изменение данных
- •Insert into запись
- •Insert into запись
- •Insert into третьекурсник
- •Удаление данных
- •Модификация данных
- •Запрос на sql с exist и not exist (реализация реляционной операции Деления)
- •Операция внешнего соединения таблиц в access (Мои замечания)
- •Псевдонимы столбцов и таблиц
- •Уточнения запроса
- •Теоретико-множественные операции
- •Декартово произведение наборов записей
- •Объединение наборов записей (union)
- •Пересечение наборов записей (intersect)
- •Intersect corresponding (id_компонента, Тип_компонента)
- •Вычитание наборов записей (except)
- •Операции соединения
- •Естественное соединение (natural join)
- •Условное соединение (join... On)
- •Соединение по именам столбцов (join... Using)
- •Внешние соединения
- •Левое соединение {left outer join)
- •Правое соединение {right outer join)
- •Внешнее соединение Преподаватель-Изучение-Предмет. Создание в access. Пример
- •Операторы exists и not exists
- •Низходящее проектирование бд на основе er-модели Модель «сущность—связь» и ее варианты
- •Реализация низходящего проектирования бд на основе er-модели
- •Типы сущностей
- •Способы представления сущностей на диаграмме
- •Атрибуты
- •Типы связей
- •Представление связей на диаграммах
- •Атрибуты связей
- •. Структурные ограничения
- •Показатель кардинальности
- •Степень участия
- •Примеры er-проектирования
- •Модель «сущность—связь» в другом рассмотрении
- •Элементы модели «сущность—связь»
- •Сущности
- •Атрибуты
- •Идентификаторы
- •Три типа бинарных связей
- •Диаграммы «сущность—связь»
- •Изображение атрибутов в диаграммах «сущность—связь»
- •Слабые сущности
- •Представление многозначных атрибутов при помощи слабых сущностей
- •Подтипы сущностей
- •Пример er-диаграммы
- •Документирование делового регламента
- •Модель «сущность—связь» и case-средства
- •Диаграммы «сущность—связь» в стиле uml
- •Сущности и связи в uml
- •Представление слабых сущностей
- •Представление подтипов
- •Конструкции ооп, введенные языком uml
- •Роль uml в базах данных на сегодняшний день
- •Примеры
- •Вопросы группы I
- •Вопросы группы II
- •Литература по курсу «базы и банки данных»
Типы связей
Тип связи - Осмысленная ассоциация между сущностями разных типов.
Тип связи (relationship type) является набором ассоциаций между двумя (или больше) типами сущностей-участников. Каждому типу связи присваивается имя, которое должно описывать его функцию. Например, сущность Owner (Владелец) связана с сущностью Property for Rent (Объект недвижимости) посредством связи Owns (Владеет).
Как и в случае сущностей, здесь следует различать понятия «связь» и «тип связи».
Связь - Ассоциация между сущностями, включающая по одной сущности из каждого участвующего в связи типа сущности.
Каждый уникально идентифицируемый экземпляр типа связи мы будем называть просто связью. Связи указывают на отдельные экземпляры сущностей, объединяемые ими. Другие авторы называют это понятие экземпляром связи (relationship occurrence или relationship instance). В данной главе используются только термины «тип связи» и «связь». Как и при описании понятия «сущность», термин «связь» может использоваться в более общем смысле, там, где этот смысл очевиден.
Представление связей на диаграммах
Существуют разные способы представления представления ER-диаграмм. То есть существуют разные нотации. В качестве примера рассмотрим одну из них. Но мы будем пользоваться и другой нотацией.
В рассматриваемой нотации каждая связь изображается в виде ромбика с указанным на нем именем связи. Ромбик имеет двойной контур, если связь соединяет слабую сущность с сильной сущностью, от которой эта слабая сущность зависит. На рис. 5.5 взаимосвязь между сущностями Branch и Staff представлена с помощью связи IsAllocated, а между сущностями Next_of_Kin и Staff — с помощью связи RelatedTo. Связь RelatedTo показана в виде ромбика с двойным контуром, указывающим на то, что она установлена между слабой (Next of_Kin) и сильной (Staff) сущностями.
Рис.5.5. Представление на ER-диаграмме сущностей Branch(Отделение компании), Staff(Сотрудник) u Next_of Kin(Родственник сотрудника), связей между ними RelatedTo(Связан с) и IsAllocated(Приписан к), а также атрибутов, которые являются их первичными ключами.
Для снижения уровня детализации на отдельной ER-диаграмме часто указываются только те атрибуты, которые представляют первичные ключи изображенных сущностей, а в некоторых случаях атрибуты не отображаются совсем. Например, на рис. 5.5 представлены только те атрибуты, которые являются первичными ключами сильных сущностей, а именно: Staff No и Branch No.
Степень связи – Количество сущностей, которые охвачены данной связью.
Охваченные некоторой связью сущности называются участниками этой связи. Количество участников некоторой связи называется степенью (degree) этой связи. Следовательно, степень связи указывает на количество типов сущностей, охваченных данной связью. Связь со степенью два называется бинарной (binary). Примером бинарной связи является связь Owns с двумя участниками: Owner и Property_for Rent. Ее ER-диаграмма показана на рис. 5.6.
Связь со степенью три называется тернарной (ternary). Примером такой связи является связь SetsUp с тремя участниками: Client, Staff и Interview. Назначение этой связи состоит в представлении ситуации, когда сотрудник отвечает за организацию интервью с клиентом. Диаграмма тернарной связи SetsUp показана на рис. 5.7.
Связь со степенью четыре называется кватернарной (quaternary). Примером кватернарной связи является связь Arranges с четырьмя сущностями-участниками: Buyer (Покупатель), Solicitor (Доверенное лицо), Financial_Institution (Финансовый орган) и Bid (Предложение). Эта связь представляет ситуацию, когда покупатель с помощью доверенного лица и при поддержке финансового органа выражает свое намерение приобрести объект недвижимости. Диаграмма кватернарной связи Arranges показана на рис. 5.8.
Р
ис.5.6.Пример
бинарной связи Owns
(Владеет):
ВЛАДЕЛЕЦ ВЛАДЕЕТ ОБЪЕКТОМ НЕДВИЖИМОСТИ
Р
ис.5.7.Пример
тернарной связи SetsUp
(Отвечает за организацию)
СОТРУДНИК ОТВЕЧАЕТ ЗА ОРГАНИЗАЦИЮ ИНТЕРВЬЮ
С КЛИЕНТОМ
Р
Solicitor
Solicitor
Solicitor – Доверенное лицо,
B
uyer
– Покупатель, Financial_Institution
– Финансовый орган, Bid
- Предложение
Здесь покупатель с помощью доверенного лица и при поддержке финансового органа выражает свое намерение приобрести объект недвижимости.
Рекурсивная связь – Связь, в которой одни и те же сущности участвуют несколько раз и в разных ролях.
Рассмотрим рекурсивную связь Supervises, которая представляет взаимосвязь персонала с управляющим, который также входит в состав персонала. Иначе говоря, сущность Staff дважды участвует в связи Supervises: первый раз — в качестве управляющего, а второй — в качестве сотрудника, которым управляют. Рекурсивные связи иногда называются унарными (unary).
Связям могут присваиваться ролевые имена — для указания назначения каждой сущности — участницы данной связи. Ролевые имена имеют большое значение в рекурсивных связях (при определении функций каждого участника). На рис. 5.9 показан пример использования ролевых имен в рекурсивной связи Supervises. Первое участие сущности Staff получило название Инспектор (Supervisor), а второе — Подчиненный (Supervisee).
Рис. 5.9. Пример рекурсивной связи Supervises с ролевыми именами Инспектор и Подчиненный
Ролевые имена могут также использоваться, когда две сущности связаны несколькими связями. Например, сущности Staff и Branch связаны двумя различными связями — Manages и IsAllocated. Как показано на рис. 5.10, использование ролевых имен существенно проясняет назначение каждой связи. Например, в случае, когда сущность Staff связана с сущностью Branch связью Manages, сотрудник (сущность Staff) с ролевым именем Руководитель (Manager) управляет (связь Manages) отделением компании с ролевым именем Отделение компании (Branch Office). Аналогично, когда сущность Branch связана с сущностью Staff связью IsAllocated, то сотрудник с ролевым именем Работник (Member of Staff) является приписанным к отделению компании с ролевым именем Отделение компании (Branch Office).
Рис.5.10.Пример сущностей, связанных двумя различными связями Manages(Руководит) и IsAllocated(Приписан к), с указанием ролевых имен.
Ролевые имена обычно не требуются, если функции сущностей — участниц данной связи определены недвусмысленно.
