- •Введение
- •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. Методические аспекты реализации нормализации
- •Контрольные вопросы
Присоединенные записи
Присоединенными записями называются записи, которые не имеют ключевого поля, и, следовательно, не могут храниться в исходной реляционной таблице, так как будет нарушено правило обязательности ключевого значения в каждой записи, но могут храниться в полной декомпозиции реляционной таблицы.
Рассмотрим два набора полей S1 и S2 из реляционной таблицы R, причем в S1 содержится ключ, и выполняется условие
R = proj S1(R) join proj S2(R).
Запись будет присоединенной, если она занесена в проекцию proj S2(R), но не занесена в проекцию proj S1(R) и, следовательно, не войдет в соединение этих проекций.
Пример.
Рассмотрим для БД "Поставщики КИ" (см. рис.6.5) с проекциями
S1 = (№КИ, Фирма) и S2 = (Фирма, Телефон)
в качестве присоединенной запись для фирмы РОС с телефоном 2462475: (РОС, 2462475).
Фирма РОС еще не приступила к поставке товаров и, следовательно, еще не имеет значения ключевого поля №КИ. Это означает, что ее запись можно хранить в проекции S2, т.е. в полной декомпозиции, но не в исходной реляционной таблице R.
В случае когда добавляемая запись содержит значение ключевого поля, но отсутствуют значения каких-либо других полей, эту запись можно разместить в исходной реляционной таблице, так как не будет нарушаться правило ключа. На местах отсутствующих значений полей следует поставить значение "Пусто".
Теорема Хита
Однако получение рассмотренного результата в общем случае не является столь простой процедурой. При декомпозиции следует учитывать весьма важное обстоятельство, заключающееся в том, что не всякая декомпозиция реляционной таблицы исключает дублирование. Рассмотрим БД
Склад(База, Товар, Поставщик),
приведенную на Рис. 0 .29. Ее декомпозицию можно реализовать двумя способами.
-
База
Товар
Поставщик
28
Р4
INT
28
М3
MT
38
Р6
INT
38
М3
MT
Рис. 0.29
По первому способу получаем проекции:
R11 = proj База,Товар(Склад);
R12 = proj Товар,Поставщик(Склад),
приведенные соответственно на Рис. 0 .30,а. и Рис. 0 .30,б.
-
База
Товар
Товар
Поставщик
28
Р4
Р4
INT
28
М3
М3
MT
38
Р6
Р6
INT
38
М3
б)
а)
Рис. 0.30
При объединении, т.е. композиции полученных проекций, образуется исходная БД "Склад". Это означает, что результатом первого способа (6.2) была полная декомпозиция. Однако, как видно из Рис. 0 .30, при декомпозиции в записях полученных таблиц не удалось исключить дублирование значений полей М3 и INT.
При декомпозиции по второму способу получаем проекции:
R21 = proj База, Поставщик(Склад);
R22 = proj Товар,Поставщик(Склад),
для которых соответствующие таблицы приведены на Рис. 0 .31,а и Рис. 0 .31,б.
База |
Поставщик |
|
Товар |
Поставщик |
28 |
INT |
|
Р4 |
INT |
28 |
MT |
|
М3 |
MT |
38 |
INT |
|
Р6 |
INT |
38 |
MT |
|
|
б)
а)
Рис. 0.31
При объединении этих полученных проекций формируется результирующая таблица, которая, в отличие от исходной БД "Склад", имеет две лишние записи, как показано на Рис. 0 .7. Это означает , что декомпозиция по второму способу не является полной и, следовательно, недопустима для рассмотрения и использования.
-
База
Товар
Поставщик
28
Р4
INT
28
М3
MT
38
Р6
INT
38
М3
MT
28
Р6
INT
38
Р4
INT
Рис. 0.7, в
Следовательно, полная декомпозиция возможна лишь по первому способу (6.2), однако в полученных проекциях не исключено дублирование значений полей МЗ и INT, т.е. поставленная задача осталась нерешенной.
Из изложенного вытекают следующие основные проблемы теории декомпозиции:
формирование правил выбора одной из альтернатив: либо хранить БД в исходном виде, либо выполнить полную декомпозицию БД и хранить ее проекции;
разработка методов анализа с целью определения совокупности проекций, обеспечивающих полную декомпозицию исходной БД.
Теорема Хита для БД, представленной реляционной таблицей, устанавливает взаимосвязь между функциональной зависимостью и полной декомпозицией таблицы.
Рассмотрим БД (рис. 6.8) в виде реляционной таблицы R с тремя непересекающимися наборами полей: S1, S2 и S3, т.е. таких, что каждое поле таблицы принадлежит лишь одному из этих типов, причем S3 функционально зависит от S2.
P1 |
P2 |
P3 |
P4 |
S1 |
S2 |
S3 | |
R1 |
| ||
|
|
R2 |
Рис. 6.8
В этом случае справедлива теорема, называемая теоремой Хита.
Теорема Хита.
Если в реляционной таблице R существуют наборы Si (i = 1,2,3), не пересекающиеся между собой, и набор S3 функционально зависит от набора S2, то справедливо тождество:
R = proj S1, S2 (R) join proj S2, S3 (R),
т.е. имеет место полная декомпозиция реляционной таблицы R.
Проанализируем с позиций теоремы Хита функциональные зависимости для рассмотренных выше БД
Поставщики (№КИ, Фирма, Телефон)
и
Склад(База, Товар, Поставщик).
Для БД Поставщики функциональные зависимости исходной реляционной таблицы и ее проекций приведены соответственно на Рис. 0 .32,а и 6.9,б.
а1а1
а2а2
а3а2
а3
а) б)
Рис. 0.32
Из Рис. 0 .32,а следует, что в БД можно рассматривать три непересекающихся набора Si , соответствующие трем атрибутам аi., причем а3 функционально зависит от а2. Это означает, что декомпозиция, выполненная в соответствии с Рис. 0 .32,б, обеспечивает выполнение условий теоремы Хита и, следовательно, будет полной.
Для БД Склад функциональные зависимости исходной реляционной таблицы и ее двух вариантов проекций приведены соответственно на Рис. 0 .33,а, б и в.
а1 а1 а1
а2 а2 а3
а3 а2 а2
а3 а3
а) б) в)
Рис. 0.33
Из Рис. 0 .33,а следует, что в БД также можно рассматривать три непересекающихся набора Si , соответствующие трем атрибутам аi.. Отметим однако, что в этой БД нет ключа, т.е. она не в 1НФ, и лишь а3 функционально зависит от а2. Тем не менее, декомпозиция, выполненная в соответствии с Рис. 0 .33,б на подмножества (а1, а2 ) и (а2, а3), обеспечивает выполнение условий теоремы Хита, так как а2 входит в оба подмножества, и, следовательно, декомпозиция будет полной. Однако, как видно из Рис. 0 .33,б, дублирование значений полей не удалось исключить. Декомпозиция же, выполненная в соответствии с Рис. 0 .33,в, не обеспечивает выполнение условий теоремы Хита, т.к. от общего атрибута а3 атрибут а2 функционально не зависит, и, следовательно, полученный результат не является полной декомпозицией.
На основании рассмотренного можно заключить, что фактически теорема Хита определяет только необходимое условие исключения дублирования, т.е. лишь возможность полной декомпозиции исходной БД.