- •Введение в базы данных
- •Отношения между прикладными программами и субд
- •Системы обработки баз данных
- •История баз данных
- •Организационный контекст
- •Реляционная модель
- •Коммерческие субд для микрокомпьютеров
- •Клиент-серверные приложения баз данных
- •Базы данных с использованием Интернет-технологий
- •Распределенные базы данных
- •Объектно-ориентированные субд
- •Банк данных
- •Основные понятия и определения
- •Пользователи банков данных
- •База данных
- •Архитектура базы данных. Физическая и логическая независимость
- •Схемы и отображения
- •Независимость от данных
- •Система управления базами данных – субд
- •Процесс прохождения пользовательского запроса
- •Введение в разработку баз данных
- •Метаданные
- •Индексы
- •Метаданные приложений
- •Подсистема средств проектирования
- •Подсистема обработки
- •Ядро субд
- •Создание базы данных
- •Процесс разработки базы данных
- •Моделирование данных
- •Функции субд
- •Модели данных
- •Объектные или инфологические модели данных
- •Модели данных на основе записей или даталогические
- •Реляционная модель данных
- •Преподаватели
- •Сетевая модель данных
- •. Физические модели данных
- •Концептуальное моделирование
- •Реляционная модель
- •Структура реляционных данных
- •Кортежи
- •Внешний ключ
- •Альтернативная терминология
- •Математические отношения
- •Отношения в базе данных
- •Реляционные ключи
- •Реляционная целостность
- •Целостность сущностей
- •Ссылочная целостность
- •Реляционные языки
- •Реляционная алгебра
- •Учебный проект 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
- •Литература по курсу «базы и банки данных»
Представление многозначных атрибутов при помощи слабых сущностей
Многозначные атрибуты представляются в модели «сущность—связь» путем создания новой слабой сущности и построения связи вида «один ко многим». В качестве примера на рис. 3.9, а изображено представление многозначного атрибута ДоверенноеЛицо сущности КЛИЕНТ. Создается новая сущность под с именем ДОВЕРЕННОЕ_ЛИЦО с единственным атрибутом ДоверенноеЛицо. Связь между сущностями ДОВЕРЕННОЕ_ЛИЦО и КЛИЕНТ имеет вид «один ко многим». Созданная таким образом сущность должна быть слабой, поскольку она логически зависит от сущности, имеющей многозначный атрибут.
На рис. 3.9, б изображено представление многозначного составного атрибута Адрес. Новая слабая сущность АДРЕС содержит всю совокупность атрибутов, а именно атрибуты Улица, Город, Штат и ПочтовыйИндекс.
Подтипы сущностей
Некоторые сущности имеют необязательные наборы атрибутов; эти сущности часто представляются с помощью подтипов (subtypes) (Подтипы были добавлены в модель «сущность—связь» после публикации оригинальной статьи Чена, и они являются частью того, что называется расширенной моделью «сущность—связь»).
Рассмотрим, например, сущность КЛИЕНТ с атрибутами НомерКлиента, ИмяКлиента и СуммаКОплате. Предположим, что клиент может быть физическим лицом, товариществом или корпорацией и что необходимо указывать некоторую дополнительную информацию, зависящую от типа клиента. Пусть эта информация имеет следующее содержание:
ФИЗИЧЕСКОЕ_ЛИЦО: Адрес, НомерСоциальнойСтраховки
ТОВАРИЩЕСТВО:ИмяУправляющегоПартнера,Адрес,ИдентификационныйНалоговый-Номер
КОРПОРАЦИЯ: КонтактноеЛицо, Телефон, ИдентификациониыйНалоговыйНомер
Одна из возможностей — отнести все эти атрибуты к сущности КЛИЕНТ, как показано на рис. 3.10, а. В этом случае, однако, некоторые атрибуты будут неприменимы. Например, такой атрибут, как имя управляющего партнера, не имеет смысла для индивидуального или корпоративного клиента, и таким образом, он не может иметь какого-либо значения.
В модели, более близкой к реальной ситуации, вместо этого будет определено три подтипа сущностей, как показано на рис. 3.10, б. Здесь сущности ФИЗИЧЕСКОЕ_ ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ изображены как подтипы сущности КЛИЕНТ. Последняя, в свою очередь, является подтипом (supertype) для сущностей ФИЗИЧЕСКОЕ_ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ.
Символ е рядом с линиями связи указывает, что сущности ФИЗИЧЕСКОЕ_ЛИЦО, ТОВАРИЩЕСТВО и КОРПОРАЦИЯ являются подтипами сущности КЛИЕНТ. Каждый подтип должен принадлежать надтипу КЛИЕНТ. Кривая линия с цифрой 1 рядом показывает, что сущность КЛИЕНТ должна принадлежать к одному и только одному подтипу. Это означает, что подтипы являются взаимоисключающими и что требуется только один из них.
Сущности со связью типа «ЕСТЬ» должны иметь один и тот же идентификатор, поскольку они представляют различные аспекты одного и того же. В данном
случае таким идентификатором является НомерКлиента. Сравните эту ситуацию со связью типа «ИМЕЕТ», показанной на рис. 3.3, где сущности представляют различные вещи.
Иерархии генерализации имеют специальную характеристику, называемую наследованием (inheritance), которая означает, что подтипы классов сущностей наследуют атрибуты от надтипа. Сущность ТОВАРИЩЕСТВО, к примеру, наследует атрибуты ИмяКлиента и СуммаКОплате от сущности КЛИЕНТ.
Причины, по которым подтипы используются в моделировании данных, отличаются от причин, по которым они используются в объектно-ориентированном программировании. Фактически, в модели данных они применяются с единственной целью: избежать ситуаций, при которых некоторые атрибуты должны иметь нулевые значения. Например, на рис. 3.10, а, если атрибуту НомерСоциальнойСтра-ховки присвоено значение, то остальные четыре атрибута должны быть равны нулю. Эта ситуация наиболее ярко проявляется в медицинских приложениях: представьте себе, например, что пациенту мужского пола задается вопрос о количестве беременностей. Нулевые значения более детально обсуждаются в главе 6.
