- •Установочный модуль
- •Введение
- •Модуль 1
- •Реляционная алгебра
- •Отсутствующие данные
- •Пустые значения
- •Неопределенные значения
- •Интерпретации
- •Правила вычисления выражений
- •Следствия
- •Проверка условий
- •Реляционные объекты данных
- •Формальные определения
- •Домены и атрибуты
- •Схема отношения
- •Именованное значение атрибута
- •Кортеж
- •Отношение
- •Схема базы данных
- •База данных
- •Операции реляционной алгебры
- •Унарные операции
- •Бинарные операции
- •Варианты операции соединения
- •Производные операции
- •Пример построения выражения реляционной алгебры
- •Понятие базовых и виртуальных отношений
- •Понятие полноты реляционной алгебры
- •Формирование запросов на языке SQL
- •Металингвистические символы
- •Реализация операций реляционной алгебры
- •Пример использования подзапросов
- •Группирующие запросы
- •Упорядочение результатов
- •Вопросы для самоконтроля
- •Упражнения
- •Построение выражений реляционной алгебры
- •Модуль 2
- •Базовые и виртуальные отношения
- •Типы данных
- •Базовые типы данных
- •Типы данных, определяемые пользователем
- •Первичные и кандидатные ключи
- •Создание базовых отношений
- •Индексы
- •Модификация базовых отношений
- •Вставка строк
- •Обновление строк
- •Удаление строк
- •Целостность
- •Декларативная поддержка
- •Пример декларативной поддержки целостности
- •Транзакции и блокировки
- •Триггеры
- •Виртуальные отношения
- •Вопросы для самоконтроля
- •Упражнения
- •Декларативная поддержка целостности
- •Модуль 3
- •Нормальные формы
- •Функциональные зависимости (ФЗ)
- •Правила вывода Армстронга
- •Производные правила вывода
- •Независимость правил Армстронга
- •Полнота системы правил Армстронга
- •Нормальные формы
- •Первая нормальная форма (1NF)
- •Вторая нормальная форма (2NF)
- •Третья нормальная форма (3NF)
- •Нормальная форма Бойса-Кодда (Boyce, Codd; NFBC)
- •Пример построения нормализованных схем отношений
- •Вопросы для самоконтроля
- •Модуль 4
- •Проектирование схем баз данных
- •Уровни логической модели
- •Миграция ключей и виды связей
- •Классификация кластеров
- •Иерархическая рекурсия
- •Абстрактная схема
- •Обобщения
- •Пример реализации иерархической рекурсии
- •Сетевая рекурсия
- •Абстрактная схема
- •Сетевая реализация иерархической рекурсии
- •Обобщения
- •Пример реализации сетевой рекурсии
- •Ассоциация
- •Детализация связей многие-ко-многим
- •Обобщения
- •Пример реализации ассоциации
- •Обобщение
- •Абстрактная схема
- •Пример реализации обобщения
- •Композиция
- •Абстрактная схема
- •Пример реализации композиции
- •Агрегация
- •Абстрактная схема
- •Пример реализации агрегации
- •Унификация атрибутов
- •Вопросы для самоконтроля
- •Упражнения
- •Иерархическая рекурсия
- •Сетевая рекурсия
- •Ассоциация
- •Обобщение
- •Композиция
- •Агрегация
- •Дополнительные главы
- •Технологии баз данных
- •Информационные системы
- •Жизненный цикл ИС
- •СУБД и БД
- •Жизненный цикл БД и средства проектирования
- •Модели данных
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Постреляционная модель данных
- •Объектно-ориентированные модели данных
- •XML как модель данных
- •Многомерная модель данных (OLAP)
- •Основные функции СУБД
- •Управление данными во внешней памяти
- •Управление буферами оперативной памяти
- •Управление транзакциями
- •Журнализация и восстановление БД после сбоев
- •Поддержка языков баз данных
- •Типовая организация СУБД
- •Модели взаимодействия с БД
- •Модель с централизованной архитектурой
- •Модель с автономными персональными компьютерами
- •Архитектура «файл-сервер»
- •Архитектура «клиент-сервер»
- •Архитектура «клиент-сервер» трехзвенная
- •Распределенные базы данных
- •Технология тиражирования данных
- •Понятие «фрактал»
- •Геометрические фракталы
- •Алгебраические фракталы
- •Стохастические фракталы
- •Системы итерируемых функций
- •Вопросы для самоконтроля
- •Литература
- •Список иллюстраций
- •Список таблиц
X ! Y 2 F +(S) ) 8r(S)finvhF (S)ir(S) ) invhX ! Y ir(S)g
Теорема полноты системы правил вывода Армстронга утверждает, что внешняя импликация заменяется на эквивалентность (без доказательства).
Из теоремы следует практически важные выводы.
1.Различные множества функциональных зависимостей будут эквивалентны с точки зрения накладываемых ограничений тогда и только тогда, когда их замыкания совпадают.
2.Достаточно ограничиться рассмотрением полностью нетривиальных зависимостей, в которых левые и правые части не пересекаются.
3.Функциональные зависимости с одинаковыми левыми частями допускают произвольное объединение и разбиение правых частей (согласно правилам аддитивности и проективности).
4.2. Нормальные формы
Понятие рассматриваемых в данном разделе нормальных форм связано с понятием функциональных зависимостей. Ограничения, накладываемые заданными множествами функциональных зависимостей на схемы базовых отношений, в общем случае реализуются
1)декларативно с помощью объявления первичных, кандидатных и внешних ключей,
2)процедурно с помощью написания программного кода триггеров.
Смысл нормализации схемы базы данных состоит в определении схем базовых отношений, позволяющих максимально уменьшить необходимость в написании программного кода, увеличить производительность и облегчить поддержку целостности данных.
Вернемся к ранее рассмотренному отношению, содержащему данные о результатах экзаменационной сессии (см. табл. 4.1), и опишем схему базы данных с учетом ограничений функциональных зависимостей:
Вариант 1 схемы БД
Сессия(№ ЗК, Ф, И, О, МнемоП, Оценка) primary key(№ ЗК, МнемоП)
{№ ЗК} ! {Ф, И, О}
Здесь для поддержания целостности данных, то есть для выполнения ограничения функциональной зависимости {№ ЗК} ! {Ф, И, О}, при изменении фамилии необходимо просматривать все кортежи отношения и вводить необходимые изменения (что чревато ошибками; ситуация усугубляется, если Ф, И, О имеются и в других отношениях). Однако поддержку этой функциональной зависимости можно реализовать автоматически с помощью объявлений ключей, если провести декомпозицию этого отношения так, чтобы ненавязанная функциональная зависимость {№ ЗК} ! {Ф, И, О} была навязана объявлением ключа № ЗК в отношении, полученным из исходного проекцией на объединение атрибутов левой и правой частей функциональной зависимости (рис. 4.1).
Вариант 2 схемы БД
Студенты(№ ЗК, Ф, И, О) primary key(№ ЗК)
Сессия(№ ЗК, МнемоП, Оценка)
primary key(№ ЗК, МнемоП)
foreign key(№ ЗК) references Студенты(№ ЗК)
Рис. 4.1.: Результат декомпозиции отношения (см. табл. 4.1)
Цель нормализации в аспекте функциональных зависимостей – навязать базе данных требуемые функциональные зависимости с помощью объявлений первичных, кандидатных и внешних ключей базовых отношений.
Принцип проектирования схем баз данных – не смешивать атрибуты различных понятий в одном базовом отношении.
4.2.1. Первая нормальная форма (1NF)
На ранних стадиях проектирования схем баз данных для краткости используются
1)наряду с простыми, то есть атомарными, и составные атрибуты, составленные из нескольких разнородных атрибутов;
2) наряду с однозначными и многозначные атрибуты, представляющие множества значений.
Возможны различные комбинации простых или составных и однозначных или многозначных атрибутов (табл. 4.2).
Таблица 4.2.: Примеры атрибутов различных видов
АТРИБУТ |
простой |
составной |
однозначный |
Телефон |
Адрес |
многозначный |
Телефоны |
Адреса |
Определение. Отношение находится в первой нормальной форме тогда и только тогда, когда его схема содержит только простые однозначные атрибуты, причем с одной и той же семантикой.
Конец определения.
Рассмотрим пример ненормализованного отношения:
Вариант 1 схемы БД
Должности(КодД, Наименование) primary key(КодД)
candidate key(Наименование)
Сотрудники(№ таб, ФИО, КодД, Телефоны, ДатаПУ) primary key(№ таб)
foreign key(КодД) references Должности(КодД)
Здесь имеются следующие ошибки нормализации:
1)атрибут ФИО является составным, то есть составленным из разнородных атрибутов;
2)атрибут Телефоны является многозначным, то есть его значением является множество значений;
3)атрибут ДатаПУ (Дата приема или увольнения) не имеет однозначной семантики.
Впоследнем случае невозможно понять, какая именно дата внесена для конкретного сотрудника
–приема или увольнения. Если ввести дополнительный атрибут, определяющий смысл даты, то смысл даты можно будет определить, но останется возможность хранения только одной из этих дат для каждого сотрудника.
Для приведения отношения к первой нормальной форме следует:
1)провести разбиение атрибутов на простые с тем, чтобы исключить составные атрибуты и атрибуты с неоднозначной семантикой;
2)провести декомпозицию отношения с тем, чтобы исключить многозначные атрибуты.
После приведения отношения Сотрудники к первой нормальной форме получим:
Вариант 2 схемы БД
Должности(КодД, Наименование) primary key(КодД)
candidate key(Наименование)
Сотрудники(№ таб, Ф, И, О, КодД, Дата приема, Дата увольнения: null)
primary key(№ таб)
foreign key(КодД) references Должности(КодД)
Телефоны(№ таб, Телефон) primary key(№ таб, Телефон)
foreign key(№ таб) references Сотрудники(№ таб)
Примечание. В отношении Телефоны атрибут № таб является одновременно атрибутом первичного ключа и внешним ключом, ссылающимся на первичный ключ отношения Сотрудники
На отношение, находящееся в первой нормальной форме, в общем случае наложены ограничения уникальности первичного и кандидатных ключей, ограничения внешних ключей, а также ограничения функциональных зависимостей.
Как провести классификацию ограничений функциональных зависимостей?
Атрибут, содержащийся в каком-либо первичном или кандидатном ключе отношения, называется ключевым. Все атрибуты отношения, следовательно, разбиваются («разбиваются» – значит без пересечения) на ключевые и неключевые. Поэтому все ограничения функциональных зависимостей можно разбить на два класса – с ключевыми и неключевыми атрибутами в правой части.
В левой части функциональной зависимости могут быть представлены атрибуты, не образующие в совокупности первичный или кандидатный ключ («не ключ»), так как зависимости с левой частью, образующей ключ, навязываются ограничениями уникальности при объявлении ключей.