- •Введение
- •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. Методические аспекты реализации нормализации
- •Контрольные вопросы
4.3.1. Функциональные зависимости
В отношении R атрибут типа Y функционально зависит от атрибута типа Х, если каждому значению атрибута X соответствует единственное значение атрибута типа Y.
Синтаксис
X y (X влечет y).
Пример 1.
В отношении
Двигатель(МаркаДвигателя, Мощность, Масса)
значение атрибута Мощность функционально зависит от значения атрибута МаркаДвигателя.
Кроме того, значение атрибута Масса также функционально зависит от значения атрибута МаркаДвигателя.
При определении функциональных зависимостей используется также термин «детерминант»: в отношении R атрибут или комбинация атрибутов называется детерминантом, если от него функционально зависит какой-либо другой атрибут.
Графически функциональные зависимости представляются диаграммами. На Рис. 0 .21 приведена диаграмма функциональных зависимостей для рассмотренного выше примера в двух вариантах исполнения:
а) с вертикальным размещением атрибутов;
б) с горизонтальным размещением атрибутов.
МаркаДвигателя
* МаркаДвигателя
Мощность Масса
*
Мощность
Масса
а) б)
Рис.
0.21
На рисунке звездочкой помечен ключ-кандидат, который и принят в качестве ключа, что отображается его подчеркиванием.
Пример 2.
При отсутствии однофамильцев представим отношение Служащий в виде:
(4.1) Служащий(№Служащего, ФИО, ЗПлата, №Проекта, ДатаОкончания),
а1 а2 а3 а4 а5
где аi (i=1,...,5) - символьные имена атрибутов, вводимые для упрощения построения схем отношений и анализа функциональных зависимостей в них.
Выявим в отношении (4.1) функциональные зависимости и определим ключ. С этой целью изобразим функциональные зависимости отношения "Служащий" в виде схемы на рис.4.2. Здесь линии со стрелками определяют зависимости полей-функций аj , находящихся возле концов линий, отмеченных стрелками, от аргументов аi , находящихся возле начал этих линий. Из схемы, например, видно, что атрибут а1 не является функционально зависимым от атрибута а3 . Действительно, одинаковая зарплата может быть у нескольких служащих. Аналогично а1 не зависит от а4.
Рассмотрим возможные ключи отношения, т.е. ключи-кандидаты. Атрибут а4 не может быть ключом-кандидатом, так как от него зависит лишь атрибут а5. Вместе с тем ключами-кандидатами, обычно помечаемыми в схемах символом "звездочка" (*), могут быть а1 и а2 , так
№Служащего*:
а1
*
ФИО*:
а2
*
ЗПлата:
а3
№Проекта:
а4
ДатаОкончания:
а5
Рис.
0.22
Пример 3.
Рассмотрим отношение Программисты (с зависимостями между группами атрибутов), в котором неповторимы атрибуты ФИО и НазваниеПрограммы (Назв-еПр-мы):
(4.2) Программисты(№Прогр-та, №Программы, ФИО, Назв-еПр-мы, Ресурсы),
а1 a 2 а 3 а 4 а5
где под ресурсами понимаются средства на разработку, которые зависят от программы и от программиста; аi (i=1,...,5) - символьные имена атрибутов.
Схема отношения Программисты с обозначенными функциональными зависимостями приведена на Рис. 0 .23. Здесь линиями с промежуточными черточками обозначены функциональные зависимости от совокупностей атрибутов.
Из рассмотрения функциональных зависимостей видно, что в отношении нет простого ключа. Однако имеется четыре составных (или сцепленных) ключа-кандидата, состоящих из пар атрибутов (а1, а2), (а1, а4), (а2, а3), или (а3, а4), которые помечены звездочками. Так, атрибут а5 функционально зависит от любого из приведенных возможных составных ключей. По соображениям удобства для пользователей ключом принята пара атрибутов (а1, а2), т.е. (№Прогр-та, №Пр-мы), которые в формуле (4.2) и на рисуке подчеркнуты.
а1
*
а2
*
а3
*
а4
*
а5
Рис.
0.23