- •Введение в базы данных
- •Отношения между прикладными программами и субд
- •Системы обработки баз данных
- •История баз данных
- •Организационный контекст
- •Реляционная модель
- •Коммерческие субд для микрокомпьютеров
- •Клиент-серверные приложения баз данных
- •Базы данных с использованием Интернет-технологий
- •Распределенные базы данных
- •Объектно-ориентированные субд
- •Банк данных
- •Основные понятия и определения
- •Пользователи банков данных
- •База данных
- •Архитектура базы данных. Физическая и логическая независимость
- •Схемы и отображения
- •Независимость от данных
- •Система управления базами данных – субд
- •Процесс прохождения пользовательского запроса
- •Введение в разработку баз данных
- •Метаданные
- •Индексы
- •Метаданные приложений
- •Подсистема средств проектирования
- •Подсистема обработки
- •Ядро субд
- •Создание базы данных
- •Процесс разработки базы данных
- •Моделирование данных
- •Функции субд
- •Модели данных
- •Объектные или инфологические модели данных
- •Модели данных на основе записей или даталогические
- •Реляционная модель данных
- •Преподаватели
- •Сетевая модель данных
- •. Физические модели данных
- •Концептуальное моделирование
- •Реляционная модель
- •Структура реляционных данных
- •Кортежи
- •Внешний ключ
- •Альтернативная терминология
- •Математические отношения
- •Отношения в базе данных
- •Реляционные ключи
- •Реляционная целостность
- •Целостность сущностей
- •Ссылочная целостность
- •Реляционные языки
- •Реляционная алгебра
- •Учебный проект 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
- •Литература по курсу «базы и банки данных»
Проблемы удаления
В экземпляре отношения КОНСУЛЬТАНТ (рис. 15.3) присутствует только один кортеж, в котором Сном=4756. Этот кортеж соответствует студенту с именем АлексК. Предположим, что консультант узнает, что этот студент не закончил курс MUS389, как это отмечено, и удаляет этот кортеж из отношения. Поскольку это единственный кортеж с информацией об этом студенте, его удаление приведет к исключе нию студента из БД. Если консультант вслед за данной операцией удаления запросит список содержащихся в отношении КОНСУЛЬТАНТ имен всех консультируемых, то имени АлексК в этом списке он не найдет.
Функциональные зависимости
Функциональная зависимость (functional dependency) описывает связь между атрибутами и является одним из основных понятий нормализации. Сама нормализация представляет собой процесс разбиения отношения на два или более отношений с целью недопущения аномалий. Процесс разбиения отношения с целью уменьшения вероятности возникновения аномалий называется декомпозицией.
Функциональная зависимость (ФЗ) определяется следующим образом:
Если даны два атрибута А и В, то говорят, что В функционально зависит от А, если для каждого значения А существует ровно одно связанное с ним значение В (в любой момент времени). А и В могут быть составными, то есть они могут представлять собой не единичные атрибуты, а группы, состоящие из двух и более атрибутов
С практической точки зрения смысл данного определения состоит в том, что если В функционально зависит от А, то каждый из кортежей, имеющих одно и то же значение А, должен иметь также одно и то же значение В. Значения А и В могут изменяться время от времени, но при этом они должны изменяться так, чтобы каждое уникальное значение А имело только одно значение В, связанное с ним. Другими словами: если нам известно значение атрибута А, то при рассмотрении отношения с такой зависимостью, в любой момент времени во всех строках этого отношения, содержащих указанное значение атрибута А, мы найдем одно и то же значение атрибута В. Таким образом, если две строки имеют одно и то же значение атрибута А, то они обязательно имеют одно и то же значение атрибута В. Однако для заданного значения атрибута В может существовать несколько различных значений атрибута А. В этом смысле можно сказать,что функциональная зависимость – это связь МНОГИЕ К ОДНОМУ.
ФЗ описываются с помощью нескольких различных способов нотации. Два наиболее часто используемых способа показаны на рис. 16.
Рис. 16. Два возможных способа записи того, что атрибут В функционально зависит от атрибута А.
Другая терминология: А функционально определяет В или А стрелка В.
Мы будем игнорировать тривиальные (trivial) функциональные зависимости, т.е. зависимости типа А—>В, где атрибут В зависит от некоторого подмножества атрибута А.
. Детерминант функциональной зависимости. Если А -> В есть ФЗ и В не зависит функционально от любого подмножества А, то говорят, что А представляет собой детерминант В. Другими словами: Детерминантом функциональной зависимости называется атрибут или группа атрибутов, расположенная на диаграмме функциональной зависимости слева от символа стрелки.
В конкретной ситуации ФЗ определяется путем детализации свойств всех атрибутов в отношении и выводе заключения о том, как атрибуты соотносятся между собой. ФЗ не могут быть доказаны путем простого просмотра отдельного экземпляра отношения и нахождения двух атрибутов, имеющих те же значения в более чем одном кортеже. Это может служить ключом к тому, в каком направлении следует вести поиск ФЗ, но не доказательством. ФЗ необходимо получить исходя из базовых свойств самих атрибутов.
В качестве примера вновь обратимся к атрибутам в отношении КОНСУЛЬТАНТ (рис. 15.3) и, в частности, к подробному объяснению того, как эти атрибуты связаны между собой. После изучения описаний атрибутов могут быть выведены зависимости, приведенные на рис. 17.
Рис. 17. Различные способы представления ФЗ, существующих между атрибутами отношения КОНСУЛЬТАНТ.
Соображения, приведшие к этим ФЗ, в деталях обсуждаются ниже.
1. Номера студентов являются уникальными. Каждому студенту назначается номер Сном, причем все номера различны. Таким образом, если вы знаете Сном студента, вы знаете, что с ним может быть связана только одна фамилия Сфам: Сном -> Сфам. Обратное не является верным. Сфам -> Сном не является правильной ФЗ, поскольку несколько студентов могут иметь одну фамилию.
2. Каждый студент прикреплен к одной комнате общежития, но в одной комнате может проживать более чем один студент. Таким образом, Сном -> Кном является верным, а Кном -> Сном - нет.
3. Поскольку в каждой комнате только один телефон и каждый телефон, в свою очередь, имеет уникальный номер, получаем Кном -> Тном и Тном -> Кном. Данная ситуация обычно обозначается в виде Сном <-> Тном, и говорят, что Сном и Тном взаимозависимы.
4. Поскольку в каждой комнате только один телефон и этот телефон имеет уникальный номер, следовательно только один телефонный номер может быть связан с данным студентом, или иначе Сном -> Тном.
5. Последняя ФЗ представляет собой пример сложного набора атрибутов, входящих в ФЗ. Зависимость Сном, Курс, Семестр -> Оценка означает, что оценка однозначно определяется только в том случае, если известен Сном студента, изучающего данный Курс в данном Семестре. (Необходимо помнить, что студент может повторить прохождение учебного курса и получить при этом другую оценку).
Самостоятельно следует проверить отношение КОНСУЛЬТАНТ (рис. 15.3) и убедиться в том, что данные в этом отношении согласуются с функциональными зависимостями, представленными на рис. 17. Например, отметим, что
Кном = 120DH и Тном = 2136 всегда располагаются парой (Кном <-> Тном); также Сном=3215 связан только с одной фамилией, именно "ДжонсГ", как и должно быть, поскольку Сном -> Сфам. Другие ФЗ следует верифицировать аналогичным образом. Читателю следует также отметить, что в экземпляре отношения КОНСУЛЬТАНТ, показанном на рис. 15.3, только один номер Сном связан с каждым именем Сфам; однако это не доказывает Сфам -> Сном, что является ложным. Это говорит только о том, что в настоящее время нет двух консультируемых с одной фамилией. В будущем может случиться так, что два студента с одной фамилией будут включены в отношение КОНСУЛЬТАНТ.
