- •Базы данных
- •Лекция 1 Хранение данных Данные, информация
- •Системы хранения данных на основе файлов
- •База данных
- •Требования к субд
- •Администратор бд (абд)
- •Лекция 2 Модели данных Независимость данных
- •Модель, схема
- •Лекция 3 Ранние модели Иерархическая модель
- •Сетевая модель
- •Лекция 4 Пример базы данных, построенной на сетевой модели Постановка задачи
- •Диаграмма
- •Описание на яод
- •Лекция 5 Реляционная модель Принципы
- •Уточнения
- •Лекция 6 Методы хранения данных и доступа к ним
- •Последовательный метод
- •Прямой метод
- •Индексные методы
- •Индексно-последовательный метод
- •Индексно-произвольный метод
- •Инвертированные списки
- •Хеширование
- •Лекция 7 Реляционная алгебра: определения, изменение отношений
- •Изменение отношений во времени.
- •Лекция 8 Операции реляционной алгебры
- •Булевы операции
- •Выбор; свойства выбора
- •Проекция; свойства проекции
- •Лекция 9 Операции реляционной алгебры (продолжение) Соединение
- •Свойства соединения
- •Лекция 10 Операции реляционной алгебры (продолжение)
- •Деление
- •Постоянные отношения. Переименование атрибутов
- •Эквисоединение, естественное и -соединение
- •Реляционная алгебра. Полнота ограниченного множества операторов
- •Операторы расщепления и фактора
- •Лекция 11 Язык структурных запросов sql
- •Начальные понятия
- •Стандарт ansi
- •Типы данных
- •Интерактивный и встроенный sql
- •Синтаксис
- •Подразделы sql
- •Простейшие действия
- •Функции агрегирования
- •Группировка
- •Возможности форматирования
- •Лекция 12 Язык структурных запросов sql (продолжение) Соединение
- •Вложенные запросы
- •Связанные запросы
- •Предикаты, определенные на подзапросах
- •Объединение
- •Изменение базы данных
- •Лекция 13 Понятие о нормальных формах
- •1 Нормальная форма (1нф)
- •2 Нормальная форма (2нф)
- •3 Нормальная форма (3нф)
- •Нормальная форма Бойса-Кодда (нфбк)
- •4 Нормальная форма (4нф)
- •5 Нормальная форма (5нф) – проекция/соединение
- •Лекция 13 Проектирование данных Процессы проектирования
- •Концептуальное проектирование
- •Логическое проектирование
- •Средства создания модели
- •Лекция 14 Функциональные зависимости
- •Аксиомы вывода
- •Ориентированный ациклический граф вывода
- •Определение реляционной базы данных
- •Представление множества функциональных зависимостей
- •Лекция 15 Покрытия функциональных зависимостей
- •Лемма об эквивалентности фз
- •Неизбыточные покрытия
- •Посторонние атрибуты
- •Канонические покрытия
- •Структура неизбыточных покрытий
- •Оптимальные покрытия
- •3 Нормальная форма
- •Нормализация через декомпозицию и посредством синтеза
- •Нормальная форма Бойса-Кодда
- •Литература
Лекция 13 Понятие о нормальных формах
В лекции дано краткое описание нормальных форм представления реляционных баз данных. Понятия, связанные с нормальными формами 1-3 и формой Бойса-Кодда, будут уточняться в последующих лекциях, форма 4, исключающая многозначную зависимость, и форма 5, проекция-соединение, помимо данной лекции не обсуждаются. Назначение этой лекции – дать по возможности содержательное представление о теме, чтобы была более ясной цель дальнейших формальных рассуждений.
Важнейшие цели, которым служит база данных – это снижение избыточности данных и повышение надежности хранения информации. Любое априорное знание об ограничениях на данные может служить этим целям. Один из способов формализации этих знаний – установление зависимости между данными, которая отражает их семантику. Семантическая информация выражается множеством функциональных зависимостей схемы. Приведем неформальное определение функциональной зависимости.
Определение. Функциональная зависимость имеет место, если значение кортежа на одном множестве атрибутов единственным образом определяет их на другом. Другими словами, множество атрибутов Y функционально зависит от X тогда и только тогда, когда в любой момент времени для каждого из различных значений Y существует только одно из различных значений X.
Встречается и эквивалентный термин: множество X определяет Y. Обозначение – X Y.
Пример
Рассмотрим отношение, заданное следующей схемой:
график (Пилот, Рейс, Дата, Время).
Ясно, что допустимо не любое сочетание значений атрибутов. Их зависимость задается следующими ограничениями:
для каждого рейса определено лишь одно время вылета;
для атрибутов (Пилот, Дата, Время) определен лишь один рейс;
для атрибутов (Рейс, Дата) определен единственный пилот.
Таким образом, задано множество функциональных зависимостей:
Рейс Время
( Пилот, Дата, Время)Рейс
( Рейс, Дата ) Пилот
Конец примера
Некоторые функциональные зависимости могут быть нежелательны в конкретной схеме. Для приведения схемы в корректный вид используется замена одного множества отношений другим, сохраняющим ее эквивалентность. Такое преобразование составляет суть процесса нормализации. В результате исходное небольшое число больших таблиц, обладающее непривлекательными свойствами, заменяется большим числом меньших таблиц, этими свойствами не обладающих.
Согласно определению отношения, все его атрибуты атомарны, то есть не могут быть разделены семантически на более мелкие элементы. Отношение, обладающее этим свойством, называется нормализованным или, что то же самое, находящимся в первой нормальной форме (1НФ). Нормальные формы, в которых находятся отношения, составляют иерархию, в которой формы с большими номерами не обладают некоторыми нежелательными свойствами, характерными для форм с меньшими номерами. В теории нормальных форм для реляционных БД рассматривается шесть уровней нормализации: 1НФ – 5НФ и форма Бойса-Кодда (промежуточная между 3НФ и 4НФ). Каждый из следующих уровней ограничивает типы допустимых функциональных зависимостей отношения. Функциональные зависимости отношения составляют его семантику. Уровень нормализации зависит от семантики отношения.
Отношения, не находящиеся в нормальных формах, не всегда удобны при модификации базы данных, то есть, у них существуют аномалии модификации. Различают аномалии добавления, изменения и удаления.
Надо заметить, что процесс нормализации не всегда сопровождает проектирование данных. Чаще всего в процессе построения информационной модели проектировщик, руководствуясь естественным порядком построения отношений, строит их сразу в третьей нормальной форме. Дейт в [6] приводит убедительные рассуждения по этому поводу. Более того, он утверждает, что отношения, полученные при проектировании, будут сразу в пятой нормальной форме, если проектировщик не злонамерен. В этом с ним солидарна Атре [2], утверждающая, что вполне достаточно владеть навыками проектирования отношений в 3НФ. Тем не менее, нормализация отношений требуется на этапе сопровождения (развития) программной системы, когда выявляются не известные ранее функциональные зависимости, в результате чего отношения теряют нормальную форму.