- •Базы данных Базы данных и информационные системы
- •Архитектура информационной системы
- •Модели данных
- •Системы управления базами данных
- •Реляционная модель данных Элементы реляционной модели
- •Ограничения и операции над отношениями
- •Проектирование реляционных бд
- •Избыточное дублирование данных и аномалии
- •Формирование исходного отношения
- •Проектирование бд методом нормальных форм
- •Зависимости между атрибутами
- •Выявление зависимостей между атрибутами
- •Нормальные формы
- •Обеспечение целостности бд
- •Средства защиты бд
- •Языки запросов qbe и sql
- •Язык запросов по образцу
- •Структурированный язык запросов
- •Типы данных в базах данных
Проектирование бд методом нормальных форм
Проектирование БД является одним из этапов жизненного цикла информационной системы. Основной задачей, решаемой в процессе проектирования БД, является задача нормализации ее отношений. Рассматриваемый ниже метод нормальных форм является классически методом проектирования реляционных БД. Этот метод основан на фундаментальном в теории реляционных баз данных понятии зависимости между атрибутами отношений.
Зависимости между атрибутами
Рассмотрим основные виды зависимостей между атрибутами отношений: функциональные, многозначные и транзитивные.
Понятие функциональной зависимости является базовым, так как на его основе формулируются определения всех остальных видов зависимостей.
Определение функциональной зависимости. Атрибут В функционально зависит от атрибута А, если каждому значению А соответствует в точности одно значение В. Математически функциональная зависимость В от А обозначается записью А —>В. Это означает, что во всех записях с одинаковым значением атрибута А атрибут В будет иметь также одно и то же значение. Отметим, что А и В могут быть составными — состоять из двух более атрибутов.
В отношении примера можно выделить функциональные зависимости между атрибутами ФИО —>Отдел, ФИО —>Должность, Должность —>Оклад, ФИО —>Проект. В отношении примера ключ является составным и состоит из атрибутов ФИО, Проект, Управление. Если отношение находится в первой нормальной форме, то все неключевые атрибуты функционально зависят от ключа с различной степенью зависимости.
Частичной зависимостью называется зависимость неключевого атрибута от части составного ключа. В рассматриваемом отношении атрибут Должность находится в функциональной зависимости от атрибута ФИО, являющегося частью ключа. Тем самым атрибут Должность находится в частичной зависимости от ключа отношения.
Альтернативным вариантом является полная функциональная зависимость неключевого атрибута от всего составного ключа. В нашем примере атрибут Вид занятий находится в полной функциональной зависимости от составного ключа.
Атрибут С зависит от атрибута А транзитивно, если для атрибутов А, В, С выполняются условия А —> В и В —> С, но обратная зависимость отсутствует. В отношении примера транзитивной зависимостью связаны атрибуты: ФИО —>Должность —> Оклад
Между атрибутами может иметь место многозначная зависимость.
Определение многозначной зависимости: в отношении R атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами из R.
Многозначные зависимости могут быть «один ко многим» (1:М), «многие к одному» (М:1) или «многие ко многим» (М:М), обозначаемые соответственно: А—В, А—В и А—В.
Например, пусть инженер ведет несколько проектов, а каждый проект может вестись несколькими инженерами, тогда имеет место зависимость ФИО—Проект.
Выявление зависимостей между атрибутами
Выявление зависимостей между атрибутами необходимо для выполнения проектирования БД методом нормальных форм, рассматриваемым далее.
Выявим зависимости между атрибутами отношения СОТРУДНИК, приведенного в примере. При этом учтем следующее условие, которое выполняется в данном отношении.
Условие. Один инженер в одном управлении может сопровождать только один вид работ (нулевые циклы или возведение здания).
В результате анализа отношения получаем зависимости между атрибутами, показанные на рисунке.
а
Оклад
Ф
ФИО
Должность
ФИО —> Оклад
Ф
Проект
Стаж
Ф
Доплата за стаж
ФИО —>Отдел
С
Отдел
Д
Управление
Вид занятий
О клад —> Должность
ФИО, Проект, Управление —>Вид занятий
К выделению этих функциональных зависимостей ФЗ для рассматриваемого примера приводят следующие соображения.
Фамилия, имя и отчество у сотрудников уникальны. Каждому сотруднику однозначно, соответствует его стаж, т. е. имеет место функциональная зависимость ФИО —>Стаж. Обратное утверждение неверно, так как одинаковый стаж может быть у разных работников.
Каждый сотрудник имеет определенную добавку за стаж, т. е. имеет место функциональная зависимость ФИО —> Доплата за стаж, но обратная функциональная зависимость отсутствует, так как одну и ту же надбавку могут иметь несколько сотрудников.
Каждый сотрудник имеет определенную должность (инженер, ведущий инженер, техник, ГИП), но одну и ту же должность могут иметь несколько сотрудников, т. е. имеет место функциональная зависимость ФИО —>Должность, а обратная функциональная зависимость отсутствует. Каждый инженер является работником одного и только одного отдела. Поэтому функциональная зависимость ФИО —>Отдел имеет место. С другой стороны, в каждом отделе много инженеров, поэтому обратной функциональной зависимости нет.
Каждому сотруднику соответствует конкретный оклад, который одинаков для всех работников с одинаковыми должностями, что учитывается зависимостями ФИО —>Оклад и Должность —>Оклад. Нет одинаковых окладов для разных должностей, поэтому имеет место функциональная зависимость Оклад —>Должность.
Один и тот же сотрудник в одном управлении по разным предметам может проводить разные виды работ. Определение вида занятий, которые проводит сотрудник, невозможно без указания проекта и управления, поэтому имеет место функциональная зависимость ФИО, Проект, Управление—>Вид занятий. Действительно, Петров М. И. в 5 управлении ведет работы с нулевым циклом и возведением здания. Но нулевой цикл для жилого четырехэтажного здания, а возведение — торгово-развлекательный центр.
Нами не были выделены зависимости между атрибутами ФИО, Проект, Управление, поскольку они образуют составной ключ и не учитываются в процессе нормализации исходного отношения. После того, как выделены все функциональные зависимости, следует проверить их согласованность с данными исходного отношения СОТРУДНИК.
Например, Должность = инженер и Оклад=10000 всегда соответствуют друг другу во всех записях, т. е. подтверждается функциональная зависимость Должность <—> Оклад. Так же следует верифицировать и остальные функциональные зависимости, не забывая об ограниченности имеющихся в отношении данных.