- •Введение в базы данных
- •Отношения между прикладными программами и субд
- •Системы обработки баз данных
- •История баз данных
- •Организационный контекст
- •Реляционная модель
- •Коммерческие субд для микрокомпьютеров
- •Клиент-серверные приложения баз данных
- •Базы данных с использованием Интернет-технологий
- •Распределенные базы данных
- •Объектно-ориентированные субд
- •Банк данных
- •Основные понятия и определения
- •Пользователи банков данных
- •База данных
- •Архитектура базы данных. Физическая и логическая независимость
- •Схемы и отображения
- •Независимость от данных
- •Система управления базами данных – субд
- •Процесс прохождения пользовательского запроса
- •Введение в разработку баз данных
- •Метаданные
- •Индексы
- •Метаданные приложений
- •Подсистема средств проектирования
- •Подсистема обработки
- •Ядро субд
- •Создание базы данных
- •Процесс разработки базы данных
- •Моделирование данных
- •Функции субд
- •Модели данных
- •Объектные или инфологические модели данных
- •Модели данных на основе записей или даталогические
- •Реляционная модель данных
- •Преподаватели
- •Сетевая модель данных
- •. Физические модели данных
- •Концептуальное моделирование
- •Реляционная модель
- •Структура реляционных данных
- •Кортежи
- •Внешний ключ
- •Альтернативная терминология
- •Математические отношения
- •Отношения в базе данных
- •Реляционные ключи
- •Реляционная целостность
- •Целостность сущностей
- •Ссылочная целостность
- •Реляционные языки
- •Реляционная алгебра
- •Учебный проект 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
- •Литература по курсу «базы и банки данных»
Изображение атрибутов в диаграммах «сущность—связь»
В некоторых версиях ER-диаграмм атрибуты обозначаются эллипсами, соединенными с сущностью или связью, которой они принадлежат. На рис. 3.6, а показаны сущности ОБЩЕЖИТИЕ и СТУДЕНТ и связь ОБЩЕЖИТИЕ-ЖИЛЕЦ с принадлежащими им атрибутами. Как видно из рисунка, сущность ОБЩЕЖИТИЕ имеет атрибуты НазваниеОбщежития, Местоположение и КоличествоКомнат, а сущность СТУДЕНТ имеет атрибуты НомерСтудента, ИмяСтудента и Курс. Связь ОБЩЕЖИТИЕ-ЖИЛЕЦ имеет атрибут Плата, который показывает внесенную студентом плату за проживание в конкретном общежитии.
Если сущность имеет много атрибутов, такое их перечисление в ER-диаграмме может сделать ее чересчур громоздкой и трудной для восприятия. В подобных случаях
список атрибутов сущностей дается отдельно, как показано на рис. 3.6, б. Многие CASE-средства показывают такие атрибуты в раскрывающихся окнах.
Слабые сущности
В модели «сущность—связь» определен особый тип сущности, называемый слабой сущностью (weak entity). К слабым сущностям относятся такие сущности, которые могут существовать в базе данных только в том случае, если в ней присутствует сущность некоторого другого типа. Сущность, не являющаяся слабой, называется сильной сущностью (strong entity).
Чтобы разобраться в том, что такое слабые сущности, рассмотрим базу данных отдела кадров с классами сущностей СОТРУДНИК и ПОДЧИНЕННЫЙ. Предположим, что, в соответствии с деловым регламентом, экземпляр сущности СОТРУДНИКлюз/се/л существовать, не будучи связанным ни с одной сущностью класса ПОДЧИНЕННЫЙ, но сущность ПОДЧИНЕННЫЙ не может существовать вне связи с какой-либо сущностью класса СОТРУДНИК. Тогда сущность ПОДЧИНЕННЫЙ является слабой. Это означает, что данные о сущности ПОДЧИНЕННЫЙ могут появиться в базе данных только в том случае, если эта сущность имеет связь с какой-либо сущностью класса СОТРУДНИК.
Как показано на рис. 3.7, б, слабые сущности обозначаются прямоугольниками со скругленными углами. Кроме того, связь, от которой зависит существование сущности, обозначается ромбом со скругленными углами. В качестве альтернативы, в некоторых ER-диаграммах (не показано здесь) прямоугольники для слабых сущностей рисуются двойной линией, а связи, от которых зависит существование этих сущностей, изображаются двойными ромбами.
В модели «сущность—связь» имеется особый тип слабых сущностей, называемый идентификационно-зависимыми сущностями (ID-dependent entities). Это такие сущности, идентификаторы которых содержат идентификатор другой сущности. Рассмотрим сущности ДОМ и КВАРТИРА. Пусть идентификатором сущности ДОМ является атрибут НазваниеДома, а идентификатором сущности КВАРТИРА является композитный идентификатор {НазваниеДома, НомерКвартиры}. Поскольку идентификатор сущности КВАРТИРА содержит в себе идентификатор сущности ДОМ (НазваниеДома), то сущность КВАРТИРА является идентификационно-за-висимой от сущности ДОМ. Сравните рис. 3.7, б с рис. 3.7, а. По-другому можно представить это так, что, как логически, так и физически, квартира не может существовать, если не существует соответствующего здания.
Идентификационно-зависимые сущности встречаются часто. Еще одним примером может служить сущность ВЕРСИЯ в связи с сущностью ПРОДУКТ, где ПРОДУКТ — это некоторый программный продукт, а ВЕРСИЯ — номер его версии. Идентификатором продукта является атрибут НазваниеПродукта, а идентификатором версии является совокупность {НазваниеПродукта, НомерВерсии}. Третий пример — это сущность ИЗДАНИЕ в связи с сущностью УЧЕБНИК. Идентификатором сущности УЧЕБНИК является атрибут Заглавие, а идентификатором издания является совокупность {Заглавие, ПорядковыйНомерИздания}.
К сожалению, в определении термина слабая сущность есть скрытая неоднозначность, и она по-разному интерпретируется различными проектировщиками баз данных (а также различными авторами книг). Эта неоднозначность заключается в следующем: в строгом смысле, слабая сущность определяется как любая сущность, чье присутствие в базе данных зависит от другой сущности; тогда любая сущность, участвующая в связи минимальной кардинальности 1 с другой сущностью, является слабой. Таким образом, рассматривая базу данных образовательного учреждения, можно заключить следующее: если у студента должен быть руководитель, то сущность СТУДЕНТ является слабой, поскольку она не может быть записана в базу данных без связи с какой-либо сущностью класса РУКОВОДИТЕЛЬ. Это толкование, однако, кажется некоторым людям слишком широким. Студент физически не зависит от руководителя (в отличие от случая с квартирой и домом), как не зависит от него и логически (что бы по этому поводу ни думали студент и руководитель!), поэтому сущность СТУДЕНТ должна считаться сильной сущностью.
Чтобы избежать подобных ситуаций, некоторые интерпретируют определение слабой сущности более ограниченно. Чтобы сущность можно было отнести к разряду слабых, она должна логически зависеть от другой сущности. Согласно данному определению, сущности ПОДЧИНЕННЫЙ и КВАРТИРА должны считаться слабыми, а сущность СТУДЕНТ — нет. Подчиненный не был бы подчиненным, если бы не находился в подчинении у кого-то, а квартира не может существовать без здания, в котором она могла бы располагаться. Студент же может логически существовать и без руководителя, даже если деловой регламент этого не допускает.
Чтобы проиллюстрировать эту интерпретацию, рассмотрим несколько примеров. Пусть модель данных включает в себя связь между сущностями ЗАКАЗ и АГЕНТ (рис. 3.8, а). Хотя можно сказать, что для каждого заказа должен быть указан агент, в действительности это не обязательно (заказ может быть, к примеру, продажей за наличные, при которой имя агента не записывается). Следовательно, минимальное кардинальное число, равное 1, проистекает из делового регламента, а не из логической необходимости. Таким образом, сущность ЗАКАЗ, хотя и требует наличия сущности АГЕНТ, не зависит от существования последней, поэтому ЗАКАЗ следует рассматривать как сильную сущность.
Теперь рассмотрим связь между сущностями ПАЦИЕНТ и РЕЦЕПТ, изображенную на рис. 3.8, б. Здесь рецепт не может логически существовать без пациента. Следовательно, помимо того, что минимальное кардинальное число сущности РЕЦЕПТ равно 1, эта сущность также зависит от существования сущности ПАЦИЕНТ. Отсюда следует, что РЕЦЕПТ — это слабая сущность. Наконец, рассмотрим сущность
НАЗНАЧЕНИЕ, изображенную на рис. 3.8, в. Идентификатор этой сущности содержит идентификатор сущности ПРОЕКТ. Здесь, кроме того, что сущность НАЗНАЧЕНИЕ имеет минимальную кардинальность 1 и зависит от существования сущности ПРОЕКТ, она является еще и идентификационно-зависимой от последней, поскольку ее ключ содержит ключ сущности ПРОЕКТ. Таким образом, сущность НАЗНАЧЕНИЕ является слабой.
В этой книге мы определяем слабые сущности как логически зависящие от существования другой сущности. Следовательно, не все сущности, имеющие минимальную кардинальность 1 в связи с другой сущностью, являются слабыми. Только логически зависимые сущности квалифицируются нами как слабые. Это определение также подразумевает, что слабыми являются все идентификационно-зависимые сущности. Кроме того, любая слабая сущность имеет минимальное кардинальное число 1 в связи с сущностью, от которой зависит, но произвольно взятая сущность с минимальным кардинальным числом, равным 1, не обязательно должна быть слабой (Здесь не упоминаются случаи, когда минимальная кардинальность оказывается больше единицы. Логика аналогична, но сущность теперь зависит от набора сущностей).
