- •Введение
- •1. Концепция информационных систем
- •1.1. Информация и данные предметных областей
- •1.2. Структура банка данных
- •1.2.1. База данных
- •1.2.2. Система управления базами данных
- •1.2.3. Словарь данных
- •1.2.4. Администратор базы данных и его функции
- •1.3. Контрольные вопросы
- •2. Инфомационное моделирование предметных областей для баз данных
- •2.1. Отображение явлений реального мира данными
- •2.2. Инфологическое моделирование по
- •2.3. Трехуровневое представление информационных объектов
- •2.4. Структурные элементы для моделирования данных
- •2.5. Ключи бд
- •2.6. Интеграция полей бд в отношения
- •2.7. Требования интеграции полей в отношения
- •2.8. Обобщенная структура модели данных в бнд
- •2.9. Er-модель бд
- •2.10. Формирование связей сущностей
- •Способ 1. Определение связи сущностей введением дополнительной сущности
- •Способ 2. Определение связей сущностей добавлением в тип сущности общих атрибутов
- •2.11. Бинарные отношения сущностей
- •2.12. Формы представления структур данных
- •2.13. Организация систем бд
- •2.14. Средства поддержки бд
- •2.15. Виды моделей данных для бд
- •Иерархическая модель данных
- •Сетевая модель данных
- •Реляционная модель данных
- •Контрольные вопросы
- •3. Системы управления базами данных
- •3.1. Функции и состав универсальной субд
- •3.2. Лингвистическое обеспечение субд
- •3.3. Независимость прикладных программ от данных
- •3.4. Операции над данными
- •Селекция данных
- •Обработка данных
- •Запросы к бд
- •3.5. Схема реализации запроса в БнД
- •Распределенная обработка данных
- •Комбинированная обработка данных
- •3.7. Целостность и ограничения целостности данных
- •3.8. Защита данных в бд
- •Контрольные вопросы
- •4.2.2. Вторичный ключ
- •4.3. Функциональные и многозначные зависимости
- •4.3.1. Функциональные зависимости
- •X y (X влечет y).
- •4.3.2. Аксиомы функциональных зависимостей
- •Контрольные вопросы
- •5. Реляционная алгебра
- •5.1. Операции над отношениями
- •5.2. Оператор "объединение" (union)
- •5.3. Оператор "вычитание" (difference)
- •5.4. Оператор "пересечение" (intersection)
- •5.5. Оператор "проектирование" (proj)
- •5.6. Оператор "выбор" (sel)
- •Комбинированный запрос с операторами proj и sel
- •5.7 Оператор "соединение" (join)
- •Запрос с соединением по одному полю
- •Алгоритм реализации
- •Запрос с соединением по нескольким полям
- •Алгоритм реализации
- •Оператор "соединение по условию"
- •5.8. Оператор "умножение" (product)
- •Запрос с оператором умножения
- •Алгоритм реализации
- •5.9. Оператор "деление" (division)
- •5.10. Оптимизация алгоритмов реализации запросов
- •Контрольные вопросы
- •6. Нормализация реляционных бд
- •6.1. Задачи нормализации Бд
- •6.2. Первая нормальная форма
- •6.3. Декомпозиция реляционных таблиц
- •Проблема дублирования, операторы реляционной алгебры для декомпозиции и объединения таблиц
- •Присоединенные записи
- •Теорема Хита
- •Критерий полной декомпозиции с исключением дублирования
- •6.4. Вторая нормальная форма
- •6.5. Третья нормальная форма
- •6.6. Экстранормализационные формы
- •Нормальная форма Бокса-Кодда
- •Четвертая нормальная форма
- •Пятая нормальная форма
- •6.7. Методические аспекты реализации нормализации
- •Контрольные вопросы
Критерий полной декомпозиции с исключением дублирования
Необходимыми и достаточными условиями полной декомпозиции исходной реляционной таблицы с исключением дублирования значений полей являются:
представление БД в 1НФ;
выполнение теоремы Хита;
формировании проекций без какого-либо общего ключа-кандидата.
Пример.
В рассмотренной выше БД
Поставщики (№КИ, Фирма, Телефон)
декомпозиция по принятому на рис. 6.4 варианту была полной и дублирование было полностью устранено, так как:
исходно БД представлена в 1НФ,
принятые структуры полей удовлетворяли теореме Хита,
в проекциях не содержалось какого-либо общего ключа - кандидата.
В случае же применения другого варианта декомпозиции на две проекции:
R21 = proj №КИ,Телефон(Поставщики)
и
R22 = proj №КИ,Фирма(По-ставщики)
не ликвидировано дублирование. Причиной этого явилось то, что каждая из проекций содержит ключ-кандидат NКИ, т.е. декомпозиция не удовлетворяет необходимым и достаточным условиям критерия.
6.4. Вторая нормальная форма
Отношение в 1НФ в ряде случаев может приводить к аномалиям из-за наличия сцепленных ключей. Для их исключения необходимо привести отношение ко второй нормальной форме.
Схема отношения R находится во второй нормальной форме (2НФ), если она находится в 1НФ и каждый ее непервичный атрибут, функционально полностью зависит от соответствующего ключа-кандидата.
Функционально полной зависимостью называется зависимость атрибута одновременно от всех полей ключа.
Если в БД все возможные ключи отношения простые, то отношение находится в 2НФ. Действительно, в этом случае все непервичные атрибуты функционально полностью зависят от каждого возможного ключа, так как все ключи атомарные.
Пример.
Отношение
Поставщики (№КИ, Фирма, Телефон),
имеет простой ключ №КИ и, следовательно, находится в 2НФ. Действительно, его непервичные атрибуты: Фирма, Телефон функционально полностью зависят от первичного ключа №КИ.
Если в отношении имеются сцепленные ключи, то это отношение, являясь отношением в 1НФ, может и не быть отношением в 2НФ.
Рассмотрим отношение
(6.3) Поставки(№Поставщика, №Изделия,
а1 а2
ИмяПоставщика, ИнфОПост-ке, Цена)
а3 а4 а5
где а1,...,а5 - символьные имена атрибутов (см. Рис. 0 .34).
В этом отношении:
поставщики имеют изделия с уникальными номерами;
одному и тому же поставщику в различных регионах могут быть присвоены различные номера;
имеется один составной ключ а1+а2, так как он в целом и отдельные его компоненты определяют все остальные неключевые атрибуты записи. Это иллюстрирует Рис. 0 .34,а, где приведены функциональные зависимости для отношения Поставки.
На Рис. 0 .34,б приведена реализация отношения Поставки. Из Рис. 0 .34,а видно, что атрибуты а3 и а4, не относящиеся к первичным, функционально зависят только от атрибута а2, который является лишь подмножеством составного ключа а1+а2. Это означает, что в отношении нет полной функциональной зависимости всех непервичных атрибутов от сцепленного ключа в целом. Следовательно, отношение не находится в 2НФ.
Нарушение условий 2НФ приводит к ряду затруднений при манипулировании данными в БД:
невозможен ввод информации о поставщике, пока он не реализует поставки какого-либо изделия, т.к. при этом невозможно задать значение всего сцепленного ключа а1+а2;
в случае временного прекращения каким-либо поставщиком поставок изделий, т.е. при отсутствии значения поля а2 запись с этим поставщиком из-за отсутствия ключа удаляется, и, следовательно, теряются все сведения о нем, что нежелательно;
при большом количестве изделий, поставляемых одним поставщиком, в случае изменений, например, информации о поставщике, для внесения этой новой информации необходима проверка каждой записи на содержание этого соответствующего №Поставщика в составе ее сцепленного ключа. В результате возникает необходимость значительной избыточной обработки.
|
|
|
а1 |
а2 |
а3 |
а4 |
а5 | |
|
|
|
1 |
10 |
А5 |
C1 |
12 | |
а1 |
* |
|
1 |
15 |
А1 |
С4 |
22 | |
а2 |
* |
1 |
25 |
А4 |
С2 |
52 | ||
а3 |
|
1 |
19 |
А3 |
С3 |
30 | ||
а4 |
|
2 |
31 |
А2 |
С5 |
55 | ||
а5 |
|
2 |
10 |
А5 |
С1 |
13 | ||
|
|
2 |
25 |
А4 |
C2 |
59 | ||
|
а) |
3 |
25 |
А4 |
С2 |
55 | ||
|
|
|
4 |
10 |
А5 |
С1 |
14 | |
|
|
4 |
31 |
А2 |
С5 |
59 | ||
|
|
|
5 |
19 |
А3 |
С3 |
35 | |
|
5 |
15 |
А1 |
С4 |
24 | |||
|
|
5 |
10 |
А5 |
C1 |
14 | ||
|
|
б) |
Рис. 0.34
С целью устранения перечисленных аномалий необходимо исходное отношение Поставки (см. Рис. 0 .34,а) привести к 2НФ. Для этого требуется реализовать его полную декомпозицию на два отношения, каждое из которых должно быть в 2НФ. Результат нормализации приведен на рис.6.12, где а) и б) - схемы полученных отношений в 2НФ, в) и г) - их соответствующие реализации.
В результате полной декомпозиции от сцепленного ключа а1+а2 полностью зависит лишь атрибут а5, что иллюстрирует схема отношения на Рис. 0 .35,б, а все остальные атрибуты, зависящие лишь от простого ключа а1, выделились в отдельное отношение, представленное схемой на Рис. 0 .35,а.
Практически нормализацию отношений до 2НФ целесообразнее реализовывать при проектировании БД. При этом следует стремиться, чтобы каждый атрибут полностью зависел от всего ключа, иначе его следует выделять в отдельное отношение.
В общем случае отношение, приведенное к 2НФ, может обладать аномалиями для выполнения операций включения, удаления и модификации. В связи с этим необходим дальнейший анализ и реализация следующего этапа нормализации.
а1 |
* |
|
|
а1 |
* |
|
а1 |
а2 |
а5 | ||||
а3 |
|
|
|
а2 |
* |
|
|
|
1 |
10 |
12 | ||
а4 |
|
|
|
а5 |
|
|
|
|
1 |
15 |
22 | ||
|
|
а) |
|
|
|
б) |
|
|
1 |
25 |
52 | ||
|
|
|
|
|
|
|
|
|
1 |
19 |
30 | ||
|
|
2 |
31 |
55 | |||||||||
|
|
2 |
10 |
13 | |||||||||
|
|
|
|
2 |
25 |
59 | |||||||
а2 |
а3 |
а4 |
|
3 |
25 |
55 | |||||||
10 |
А5 |
C1 |
|
4 |
10 |
14 | |||||||
15 |
А1 |
С4 |
|
4 |
31 |
59 | |||||||
25 |
А4 |
С2 |
|
5 |
19 |
35 | |||||||
19 |
А3 |
С3 |
|
5 |
15 |
24 | |||||||
31 |
А2 |
C5 |
|
5 |
10 |
14 |
в) г)
Рис. 0.35