- •Введение в базы данных
- •Отношения между прикладными программами и субд
- •Системы обработки баз данных
- •История баз данных
- •Организационный контекст
- •Реляционная модель
- •Коммерческие субд для микрокомпьютеров
- •Клиент-серверные приложения баз данных
- •Базы данных с использованием Интернет-технологий
- •Распределенные базы данных
- •Объектно-ориентированные субд
- •Банк данных
- •Основные понятия и определения
- •Пользователи банков данных
- •База данных
- •Архитектура базы данных. Физическая и логическая независимость
- •Схемы и отображения
- •Независимость от данных
- •Система управления базами данных – субд
- •Процесс прохождения пользовательского запроса
- •Введение в разработку баз данных
- •Метаданные
- •Индексы
- •Метаданные приложений
- •Подсистема средств проектирования
- •Подсистема обработки
- •Ядро субд
- •Создание базы данных
- •Процесс разработки базы данных
- •Моделирование данных
- •Функции субд
- •Модели данных
- •Объектные или инфологические модели данных
- •Модели данных на основе записей или даталогические
- •Реляционная модель данных
- •Преподаватели
- •Сетевая модель данных
- •. Физические модели данных
- •Концептуальное моделирование
- •Реляционная модель
- •Структура реляционных данных
- •Кортежи
- •Внешний ключ
- •Альтернативная терминология
- •Математические отношения
- •Отношения в базе данных
- •Реляционные ключи
- •Реляционная целостность
- •Целостность сущностей
- •Ссылочная целостность
- •Реляционные языки
- •Реляционная алгебра
- •Учебный проект 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
- •Литература по курсу «базы и банки данных»
4 И 5 нормальные формы (4нф и 5нф)
Эти НФ мы рассмотрим в подробностях позже при наличии времени. Ниже приведем лишь краткие сведения по этим формам.
Пример нормализации
В качестве примера рассмотрим процедуру нормализации БД «КОНСУЛЬТАНТ». Как говорилась выше, нормализация проводится методом декомпозиции, поэтому процедура нормализации часто называется декомпозицией. Одним из самых первых, но и одним из самых важных результатов в области реляционных БД стало доказанное Коддом утверждение о том, что большинство потенциальных аномалий в БД будет устранено в случае должной декомпозиции каждого отношения в нормальную форму Бойса-Кодда (НФБК). Хотя существуют нормальные формы более высокого уровня, которые накладывают даже более сильные ограничения на разрабатываемые отношения, на практике большинство проектировщиков стараются получить отношения в НФБК.К этому мы и будем стремиться.
Исходным отношением является универсальное отношение КОНСУЛЬТАНТ (см. рис. 19). Ранее было показано, что это отношение находится в 1НФ (рис. 20).
Опытному проектировщику БД достаточно беглого взгляда на диаграмму, приведенную на рис. 20, чтобы сделать вывод о том, что отношение КОНСУЛЬТАНТ нельзя считать "хорошим". Проектировщик придет к такому выводу, глядя на ФЗ, полученные для отношения КОНСУЛЬТАНТ, и обращая внимание на некоторые их нежелательные свойства. Из рис. 20 можно заключить, что отношение КОНСУЛЬТАНТ имеет только один потенциальный (возможный) ключ, а именно набор атрибутов <Сном,Курс,Семестр>. Этот вывод получен путем нахождения минимального набора значений атрибутов, которые, если они известны, определяют значения всех других атрибутов кортежа. С помощью ФЗ, представленных на рис. 20, легко видеть, что один номер Сном определяет Сфам, Кном и Тном и для определения Оценки должен быть известен весь набор Сном, Курс и Семестр. Таким образом, если известны значения атрибутов данного выше потенциального ключа, то значения всех других атрибутов кортежа, содержащего указанный потенциальный (возможный) ключ, будут однозначно специфицированы.
Детерминанты в отношении КОНСУЛЬТАНТ определить легко: ими являются левые части всех ФЗ в отношении. Детерминантами в КОНСУЛЬТАНТ являются <Сном,Курс,Семестр>, <Сном>, <Кном> и <Тном>. Детерминанты заключены в угловые скобки для того, чтобы в данном случае выделить четыре различных детерминанта Следует заметить, что взаимные зависимости между Кном и Тном дают два детерминанта. Отношение КОНСУЛЬТАНТ не находится в НФБК. Это легко обнаружить, если расположить рядом перечень всех детерминантов и перечень всех возможных ключей и посмотреть, является ли каждый детерминант возможным ключом.
Потенциальные ключи отношения КОНСУЛЬТАНТ - |
Детерминанты отношения КОНСУЛЬТАНТ |
<Сном,Курс,Семестр> |
<Сном,Курс,Семестр> <Сном> <Тном> <Кном> |
Поскольку не каждый детерминант в отношении КОНСУЛЬТАНТ является возможным ключом, следовательно, КОНСУЛЬТАНТ не находится в НФБК и его необходимо подвергнуть декомпозиции.
Декомпозицию отношения, не приведенного к НФБК, на два отношения осуществляют с помощью ФЗ следующим образом:
Пусть отношение R(A,B,C,D,E, ) не приведено к НФБК Определяется ФЗ, например С → D, про которую известно, что она является причиной того, что отношение R не находится в НФБК (С является детерминантом, но не является потенциальным ключом ) Создаются два новых отношения R1(A,B,C,E, ) и R2(C,D), где зависимостная часть ФЗ была выделена из R и опущена при формировании отношения R1 и ФЗ была использована полностью при формировании отношения R2 . Теперь необходимо проверить, находятся ли в НФБК отношения R1 и R2 Про отношение R2(C,D) говорят, что оно является проекцией отношения R. Этот тип декомпозиции называется декомпозицией без потерь при естественном соединении .
В качестве примера использования метода выполним декомпозицию отношения КОНСУЛЬТАНТ. Обращаясь вновь к детерминантам и возможным ключам отношения КОНСУЛЬТАНТ, видим, что имеются три детерминанта, не являющихся возможными ключами:
<Сном>, <Тном>, и <Кном>.
Началом процесса служит следующая схема БД ( универсальное отношение):
КОНСУЛЬТАНТ (Сном, Курс, Семестр, Сфам, Кном, Тном, Оценка).
Кандидатами среди ФЗ для осуществления проекции являются
Сном → Кном; Сном → Тном; Кном → Тном и Тном → Кном.
На этом этапе должно быть принято решение, какую ФЗ следует выбрать для проведения первой проекции. Не исключено, что в итоге выбора той или иной начальной проекции будут получены различные БД. Если это именно так, то каждая из получившихся БД, вообще говоря, должна быть подвергнута анализу с целью выбора наиболее полно отвечающей требованиям и условиям предприятия.
Простым правилом выбора ФЗ для проекции может служить поиск "цепочки ФЗ" вида
А → В → С
с последующим использованием для проекции крайней правой зависимости. Это объясняется следующим. Данная ФЗ является транзитивной. А как вы помните, для приведения к 3НФ необходимо исключить все транзитивные зависимости. Как вы также помните, НФБК является ужесточенной 3НФ. В нашем случае такой "цепочкой" является Сном -> Кном -> Тном и "конец цепочки" Кном -> Тном порождает первую проекцию. Полученные в итоге отношения R1 и R2 приведены на рис. 23 вместе с каждой из связанных с ними ФЗ.
Рис. 23. Отношения R1 и R2, полученные в результате проекции
Кном <-> Тном из отношения КОНСУЛЬТАНТ
Отношение R2 (Кном.Тном) находится в НФБК, поскольку все его детерминанты являются возможными ключами. Отношение R2 не нуждается более в декомпозиции. Однако отношение R1 (Сном, Курс, Семестр, Сфам, Кном, Оценка) не находится в НФБК, так как детерминант <Сном> не является возможным ключом. Следовательно, отношение R1 необходимо подвергнуть дальнейшему разложению. Кстати, отношение R1 имеет частичную зависимость ряда атрибутов от первичного ключа, следовательно, оно не находится даже во 2НФ, а находится в 1НФ. Детерминант <Сном>, из-за которого возникло затруднение, имеет два зависимых от него атрибута
Сном -> Сфам, Сном -> Кном,
что можно рассматривать в качестве единичной ФЗ с составной правой частью
Сном -> Сфам, Кном.
Проекция отношения R1, порождаемая этой ФЗ, приводит к получению отношений R3 и R4, показанных на рис. 24. Эти два отношения находятся в НФБК и вместе с отношением R2 могли бы использоваться при формировании БД для консультанта. На рис. 25 представлен окончательный вид отношений для такой БД (названной КОНС), а также экземпляры каждого отношения с данными, совпадающими с использованными для исходного отношения КОНСУЛЬТАНТ. Заметим, в частности, что в процессе декомпозиции автоматически произошло разбиение исходного отношения КОНСУЛЬТАНТ на три логических компонента: R2, в котором содержится информация о комнатах и телефонах; R3, в котором содержится информация об учебных курсах и полученных студентами оценках; R4, в котором содержится информация о студентах. Такое логическое разбиение является прямым результатом использования в процессе декомпозиции заложенной в ФЗ информации, детализирующей то, как различные атрибуты в исходном отношении соотносятся друг с другом.
Рис. 24. Отношения R3 и R4, полученные в результате проекции
Сном -> Сфам,Кном из отношения R1
Рис.25. а - база данных КОНС, получившаяся после нормализации БД КОНСУЛЬТАНТ; б - экземпляр БД, в котором используются данные, приведенные в универсальном отношении КОНСУЛЬТАНТ
Обзор исходных аномалий
Сейчас самое время задаться вопросом: присутствуют ли в БД Конс те же аномалии, которые характеризовали отношение КОНСУЛЬТАНТ, или декомпозиция автоматически привела к их устранению? Для того чтобы подтвердить устранение аномалий, - а именно эта цель ставилась в первую очередь при осуществлении декомпозиции, - рассмотрим, опираясь на приведенную на рис. 25 БД Конс, проблемы вставки, удаления и обновления.
СДЕЛАЙТЕ ЭТО САМОСТОЯТЕЛЬНО!
Ниже приведен анализ аномалий.
Вставка. Когда отношение КОНСУЛЬТАНТ служило основой БД, новый студент не мог быть в нее включен до действительного завершения им какого-либо курса. В БД Коне информация общего характера о консультируемых студентах хранится в отношении R4. Как только новый студент принимается в университет и ему отводится комната, так этот сту дент может быть включен в БД (в R4). Студенту нет необходимости даже просто приступить к посещению учебного курса для того, чтобы быть включенным в БД. Таким образом, исходная аномалия вставки исключена с помощью декомпозиции.
Обновление. При использовании отношения КОНСУЛЬТАНТ проблема возникла на этапе изменения консультантом номера телефона миссис ДжонсГ на 7777. Результатом этого изменения явилось появление в БД двух различных телефонных номеров для телефона, установленного в комнате 120DH. В БД Конс телефонные номера располагаются в отношении R2, и каждая комната может иметь только один телефонный номер, назначенный расположенному в этой комнате телефонному аппарату. Следует помнить, что номер Кном является первичным ключом отношения R2, а значения первичного ключа по определению должны быть уникальными. Для модификации телефонного номера ДжонсГ следует в кортеже отношения R2, в котором Кном=1200Н, изменить номер Тном на 7777. Обратите внимание на то обстоятельство, что это действие заключается в изменении телефонного номера для комнаты, так что для всех живущих в этой комнате студентов телефонный номер также будет изменен. Таким образом исходная аномалия обновления устраняется с помощью НФБК-проектирования.
Необходимо еще раз подчеркнуть, что устранение аномалии обновления базируется на том предположении, что СУБД, в среде которой будет создаваться БД, не допускает дублирования значений первичных ключей.
Удаление. Когда отношение КОНСУЛЬТАНТ использовалось в качестве БД, удаление кортежа, включавшего значения Сном=4756 и Kypc=MUS389, привело к исчезновению из БД студента с номером 4756. Этого не может произойти в случае БД Конс, поскольку информация об оценках и информация о студентах общего характера разнесена в два различных отношения (R3 и R4). При исключении факта, что студент с номером 4756 посещал курс MUS389 в семестре F83, из отношения R3 будет удален кортеж <4756,MUS389,F83,4.0>. Это действие никак не скажется на общей информации о студенте, хранимой в R4.
