Проектирование баз данных на основе восходящего подхода (Метод нормализации или декомпозиции)

Восходящий подход используется для проектирования простых баз данных. Мы начинаем его изучать для того, чтобы на простых примерах выяснить ряд важных понятий и методов, прежде всего метода нормализации. Как уже говорилось ранее, при восходящем подходе работа начинается с самого нижнего уровня — уровня определения атрибутов (т.е. свойств сущностей), которые на основе анализа существующих между ними связей группируются в отношения, представляющие типы сущностей и связи между ними. При проектировании базы данных в реляционной СУБД основной целью разра­ботки логической модели данных является создание точного представления дан­ных, связей между ними и требуемых ограничений. Для достижения этой цели не­обходимо прежде всего определить подходящий набор отношений. Метод, который используется для решения последней задачи, называется нормализацией (normalization). Нормализация представляет собой вариант восходящего подхода к проектированию базы данных, который начинается с установления связей между атрибутами.

Цель нормализации

Нормализация - метод создания набора отношений с заданными свойствами на основе требований к данным, установленным в некоторой организации.

Процесс нормализации был впервые предложен Э. Ф. Коддом (Codd, 1972, б). Нормализация часто выполняется в виде последовательности тестов для некоторого отношения с целью проверки его соответствия (или несоответствия) требованиям заданной нормальной формы. Сначала были предложены только три вида нормальных форм: первая (1НФ), вторая (2НФ) и третья (ЗНФ). Затем Р. Бойсом и Э. Ф. Коддом (Codd, 1974) было сформулировано более строгое определение третьей нормальной формы, которое получило название нормальной формы Бойса-Кодда (НФБК). Все эти нормальные формы основаны на функциональных зависимостях, существующих между атрибутами отношения (Maier, 1983).

Вслед за НФБК появились определения четвертой (4НФ) и пятой (5НФ) нормаль­ных форм (Fagin, 1977, 1979). Однако на практике эти нормальные формы более вы­соких порядков используются крайне редко.

Универсальное отношение (из Джексона)

Предположим, что требуется разработать небольшую БД для консультанта университета. У консультанта имеется много консультируемых им студентов, живу­щих на территории университетского городка, причем все эти студенты учатся на основном факультете.

Первый шаг процесса проектирования состоит в определении как всех атрибутов, наличие которых в БД ожидает консультант, так и связей между атрибу­тами. Эта информация получается от консультанта в итоге ряда детальных обсуждений, не оставляющих сомнений в том, что он знает какие данные должны быть в БД, каким образом БД будет использоваться и какую информацию консультант ожидает получать от БД. После нескольких бесед с консультантом име­на и условия, связанные с атрибутами, хранение ко­торых предполагается, были определены следующим образом:

Сном: Номер студента. Целое значение, уникаль­ное для каждого студента университета.

Сфам: Фамилия студента. Каждый студент имеет только одну фамилию, но возможно, что одну фами­лию носят несколько студентов.

Кном: Номер комнаты в общежитии городка. Каждый студент живет на территории городка и име­ет комнату. В одной комнате может проживать более одного студента.

Тном: Номер телефона студента. Каждая комната общежития имеет один телефон и им пользуются все студенты, проживающие в этой комнате.

Курс: Номер^курса^ Это идентификационный номер курса, посещаемого студентом. Примером может слу­жить номер МТН122. Консультант будет сохранять данные только о курсах, завершенных студентом.

Семестр: Университетский семестр. Представляет собой семестр, в котором данный курс был завершен студентом. Возможно, что студент изучал один и тот же курс в различных семестрах.

Оценка: Оценка за курс. Оценка, полученная студентом за определенный курс в данном семестре.

На рис. 15.1 представлен образец данных, концеп­туализированных консультантом для их хранения в БД. Хотя на рисунке приводится пример в виде таб­лицы данных, которые могут храниться в БД в неко­торый момент времени, указанная таблица отношени­ем не является.

Рис. 15.1. Данные, необходимые консультанту

Рис. 15.2. Одна "строка" таблицы, приведенной на рис. 15.1

Для иллюстрации того, почему таблица на рис. 15.1 не является отношением, выделим одну "строку" из таблицы (рис. 15.2). На этом рисунке значения четырех полей Сном, Сфам, Кном и Тном - атомарные⁴, в то время как значения в полях Курс, Семестр и Оценка - множественные. Данная "строка" очевидным образом отличается по форме от кортежей, представленных в простых отношениях и рассмотрен­ных выше. Отличие в том, что не все поля строки содержат атрибуты, значения которых атомарные. Для придания данным, приведенным на рис. 15.2, формы отношения необходимо реконструировать их таким об­разом, чтобы каждый элемент кортежа имел атомарное значение. Обычно это удается сделать с помощью простого процесса вставки (результат для данного случая показан на рис. 15.3). В результате этого про­цесса добавляется большой объем избыточных данных - исключение избыточности достигается на следующих этапах проектирования.

Рис. 15.3. Данные из таблицы, приведенной на рис. 15.1, помещенные в корректное отношение

Таблица на рис. 15.3 представляет собой экземпляр корректного отношения. Его называют универсальным отношением проектируемой БД. В одно универсальное отношение включаются все представляющие интерес атрибуты, и оно может содержать все данные, которые предполагается размещать в БД в будущем. Для малых БД (включающих не более 15-20 атрибутов) универсальное отношение может использоваться в качестве отправной точки при проектировании БД. Это отношение содержит все представляющие интерес атрибуты, и имеет структу­ру, в которой каждый кортеж состоит из атомарных элементов.

Говорят, что отношение находится в первой нормальной форме (или 1НФ), если каждый его элемент имеет и всегда будет иметь атомарное значение. Отношение должно быть в 1НФ даже прежде постановки вопроса о его разбиении на два или более отно­шения.