Алгоритм нормализации
Рассмотрим алгоритм приведения структуры базы данных от универсального отношения к НФБК, с добавлением практических аспектов.
При разработке структуры базы данных следует учитывать вопросы ее реального применения. С точки зрения теории, связь между таблицами реализуется за счет первичных и внешних ключей, точнее, по совпадению их значений. При этом, в дочерней таблице значение внешнего ключа может повторяться многократно, а сама процедура соединения двух таблиц связана с реляционной операцией ограничения, т.е. фактически, с поиском по значению внешнего ключа соответствующей записи в родительской таблице. С точки зрения хранения и обработки данных на компьютере, строковые данные являются самыми труднообрабатываемыми. Как следствие, желательно избежать повторения строковых значений и заменить поиск по ним на поиск по целочисленным, легко обрабатываемым данным.
Шаги нормализации:
Определение первичного ключа универсального отношения.
Определение функциональных зависимостей неключевых полей от части составного ключа.
Формирование новых таблиц по зависимостям из предыдущего пункта по правилу №1 перевода из 1НФ в 2НФ.
Определение функциональных зависимостей между неключевыми полями в таблицах, полученных на предыдущем этапе.
Формирование новых таблиц по зависимостям из предыдущего пункта по правилу №2 перевода из 2НФ в 3НФ.
Введение нумерации ключевых полей. В таблицах, где первичный ключ состоит из одного поля строкового типа, добавляется фиктивное поле целочисленного типа, в котором осуществляется «нумерация» строк таблицы. Исходное строковое поле исключается из состава ключа, а вновь введенное целочисленное поле вводится в состав ключа.
Выделение справочников. Рассматриваются строковые поля, не обрабатывавшиеся в предыдущем пункте. Поле, в рамках рассматриваемой задачи, должно принимать значения из ограниченного множества, и значения поля могут повторяться в различных строках таблицы, в которой находится рассматриваемое поле. Для таких полей формируется новая таблица, состоящая из двух столбцов. Само строковое поле и целочисленное поле, вводящее нумерацию строк таблицы. Это поле является первичным ключом. В таблицу вносятся только уникальные значения рассматриваемого строкового поля. В исходной таблице строковое поле заменяется на целочисленное. Целочисленное поле выступает в роли внешнего ключа для связи с новой таблицей.
Нормализация в примерах.
Рассмотрим пример нормализации структуры базы данных по учету билетов на рейсы пассажирских авиалиний, вылетающие из некоторого аэропорта.
Универсальное отношение для рассматриваемой задачи приведено на рис. 1.
Краткая инфологическая модель.
Представленная база данных хранит информацию о рейсах, вылетающих из рассматриваемого аэропорта, пассажирах вылетавших конкретным рейсом в конкретный день. По рейсам хранится: пункт назначения, время вылета, марка самолета, число посадочных мест и цена билета. О пассажире хранится: фамилии, паспортные данные и значение накопительной скидки.
Шаг №1.
Первичный ключ универсального отношения «Авиабилеты» составной и состоит из столбцов: «№ Рейса», «Дата вылета», «Паспортные_данные». Первичный ключ определяется из семантики прикладной области, которая сформулирована в инфологической модели. При описании универсального отношения были выделены три понятия прикладной области: рейс, пассажир и связь между ними – билет. Столбцы, определяющие уникальность рейса и пассажира, входят в первичный ключ. Если бы пассажир мог воспользоваться конкретным рейсом только однажды, то первичный ключ должен был бы быть «№ Рейса», «Паспортные_данные». Однако пассажир может неоднократно летать одним и тем же рейсом, поэтому «Дата вылета», дополнительно характеризующая билет должна быть включена в первичный ключ. Далее первичный ключ таблицы будем помечать подчеркиванием сплошной линией наименований столбцов, входящих в его состав.
Полученная нами таблица с первичным ключом находится в 1НФ, т.к. все значения в таблице атомарные, и мы потребуем для нее ограничение целостности по первичному ключу.
Рис. 1. Универсальное отношение
Шаг №2.
Значения столбцов «Пункт_прибытия», «Время_вылета», «Марка_самолета», «Кол-во_мест» и «Цена_билета» всегда одинаковы для всех записей таблицы с одинаковым значением столбца «№ Рейса». Т.е. эти столбцы функционально зависят от столбца «№ Рейса», являющегося частью первичного ключа. Записываются эти функциональные зависимости в следующем виде:
«№ рейса» → «Пункт_прибытия», «Время_вылета», «Марка_самолета», «Кол-во_мест», «Цена_билета».
Аналогично значение столбцов «ФИО» и «Скидка%» функционально зависят от значения столбца «Паспортные_данные»:
«Паспортные_данные» → «ФИО», «Скидка%».
Таким образом, таблица «Авиабилеты» не удовлетворяет условиям 2НФ. Рассмотрим указанные выше аномалии, возникающие при выполнении операций над данными этой таблицы.
Таблица содержит одновременно данные по рейсам и пассажирам. Вытекающая избыточность видна на примере пункта прибытия: пункт прибытия 111 рейса указан четыре раза.
Аномалию добавления можно показать на примере появления нового рейса. В данную таблицу невозможно добавить информацию о рейсе, пока на него не продано ни одного билета, т.к. не будет соблюдаться ограничение целостности по первичному ключу.
Изменение времени вылета рейса 111, выполненное не для всех строк, может привести к противоречивости данных в разных билетах – аномалии изменения.
Аномалия удаления станет причиной потери информации о пассажирах, которые летали только одним рейсом при удалении этого рейса из базы. Помимо восстанавливаемой информации о паспорте и фамилии, будет утеряна невосстанавливаемая информация о скидке.
Шаг №3.
Для выявленных на предыдущем шаге зависимостей применяем правило №1 перевода таблиц из 1НФ в 2НФ. В результате применения правила для зависимости от «№ Рейса», получим структуру базы данных, представленную на рис. 2. Здесь новая таблица «Рейсы» будет удовлетворять 2НФ, а исходная таблица по-прежнему не будет удовлетворять 2 НФ. В результате применения правила для зависимости от столбца «Паспортные_данные», получим структуру базы данных, представленную на рис. 3. Здесь все три таблицы удовлетворяют 2НФ.
Прямую связь между таблицами будем показывать линией, соединяющей эти таблицы, а тип связи будем указывать маркировкой ее концов: «1» – со стороны один и «М» - со стороны многие.
Шаг №4.
Таблица «Авиабилеты» не имеет в своем составе неключевых полей, поэтому она точно удовлетворяет 3НФ.
Будем считать, что столбцы «ФИО» и «Скидка%» таблицы «Пассажиры» взаимонезависимые. Возможную зависимость «ФИО» → «Скидка%» рассмотрим позже.
Значение столбца «Кол-во_мест» всегда одинаковы для всех записей таблицы «Рейсы» с одинаковым значением столбца «Марка_самолета». «Кол-во_мест» функционально зависит от столбца «Марка_самолета»: «Марка_самолета» → «Кол-во_мест».
Таблица «Рейсы» не удовлетворяет условиям 3НФ. Избыточность связана с неоднократным повторением характеристики марки самолета.
Аномалия добавления связана с невозможностью добавления новой марки самолета в базу данных до тех пор, пока не появится хотя бы один рейс, летающий самолетом такой марки.
Изменение количества пассажиров, выполненное не для всех строк таблицы «Рейсы» может привести к противоречивости характеристик одной и той же марки самолета – аномалии изменения.
Аномалия удаления может стать причиной потери информации о марке самолета и ее характеристиках. Если какой-либо маркой самолета летает единственный рейс или группа рейсов, то при его или их удалении потеряется вся информация о марке самолета.
Шаг №5.
Для выявленной на предыдущем шаге зависимости применим правило №2 перевода из 2НФ в 3НФ. В результате, получим новую структуру базы данных, состоящую из четырех таблиц, находящихся в 3НФ (рис. 4).
Шаг №6.
Условиям данного шага – таблица с простым первичным ключом строкового типа – удовлетворяют таблицы «Пассажиры» и «Марки». В таблице «Рейсы» поле «№Рейса» считаем целочисленным. В результате получим модифицированную структуру базы данных (рис. 5). При этом функциональные зависимости, рассмотренные ранее, остались в силе:
«№ рейса» → «Пункт_прибытия», «Время_вылета», «Марка_самолета», «Кол-во_мест», «Цена билет»;
«Паспортные_данные» → «ФИО», «Скидка%»;
«Марка_самолета» → «Кол-во_мест».
Определяющие столбцы в зависимостях на данном шаге перестали быть первичными ключами, т.е. все три таблицы перестали удовлетворять условиям 3НФ. Однако эти столбцы являются возможными ключами своих таблиц и в этом случае они удовлетворяют 3НФ в общем виде. Если же мы пользуемся определениями с учетом только первичного ключа, то «нормальность» этих таблиц будет обоснована НФБК, где уже однозначно прописываются зависимости от всех возможных ключей. Аналогично в случае введения функциональной зависимости «ФИО» → «Скидка%» столбец «ФИО» должен являться возможным ключом таблицы «Пассажиры».
Шаг №7.
В данном пункте необходимо проверить два строковых столбца, «ФИО» в таблице «Пассажиры» и «Пункт_прибытия» в таблицы рейсы. Отдельно хотелось бы отметить, что тип данных, отвечающий за хранение даты и времени, является не строковым, а числовым.
Для столбца «ФИО» не будем строить справочник, столбец «ФИО» мы проанализируем ниже.
Столбец «Пункт_прибытия» полностью удовлетворяет условиям справочника. Допустимые значения столбца принадлежат ограниченному множеству городов-аэропортов, и несколько рейсов может летать в один и тот же город, что соответствует повторению значений. Структура базы данных после формирования справочника представлена на рис. 6.
Полученное решение удовлетворяет НФБК.
Если же при приведении к 2НФ сразу учесть наличие возможных ключей, то изменятся промежуточные решения, однако конечное решение совпадет с полученным ранее.
Допустим, что столбец «ФИО» имеет уникальные значения для каждого пассажира. Тогда универсальное отношение имеет два возможных ключа:
«№ Рейса», «Дата вылета», «Паспортные_данные» – первичный ключ;
«№ Рейса», «Дата вылета», «ФИО» – возможный ключ.
При этом к зависимости «Паспортные_данные» → «ФИО» добавляется зависимость «ФИО» → «Паспортные_данные». Но столбец «ФИО» не попадает в перечень анализируемых на шаге №2, так как он является ключевым рис. 7.
Приведение таблицы «Рейсы» к 3НФ будет без изменений.
А вот таблица «Авиабилеты» теперь имеет избыточность, хотя и удовлетворяет 3НФ. Повторение значений поля «ФИО» – избыточность. Таблица не удовлетворяет НФБК, т.к. в зависимостях «Паспортные_данные» → «ФИО» и ФИО» → «Паспортные_данные» определяющие столбцы не являются ключами таблицы. Дальнейшая нормализация таблицы «Авиабилеты» заключается в выносе поля «ФИО». В результате должна появиться таблица, состоящая из полей «Паспортные_данные» и «ФИО», где «Паспортные_данные» –первичный ключ. Новую таблицу можно объединить с уже существующей таблицей «Пассажиры». В результате получится схема, представленная на рис. 4. Далее структура базы данных модифицируется по указанному выше алгоритму.
Рис. 2. Структура базы данных на третьем шаге. После избавления от первой зависимости
Рис. 3. Структура базы данных на третьем шаге. После избавления от второй зависимости
Рис. 4. Структура базы данных на пятом шаге
Рис. 5. Структура базы данных на шестом шаге
Рис. 6. Структура базы данных на шестом шаге
Рис. 7. Структура базы данных на третьем шаге. Вариант с возможными ключами
Полученную структуру базы данных обычно описывают даталогической схемой. Схема включает в себя описание всех таблиц с указанием по каждой таблице названия, перечня столбцов с указанием их имен, типов данных, принадлежность к первичному и/или внешнему ключу. Указываются связи между таблицами с указанием полей, по которым осуществляется связь – первичный и внешний ключи, образующие связи. Существует множество программных продуктов, позволяющих автоматизировать разработку таких схем. На рис. 8 приведена даталогическая схема рассматриваемой базы данных, разработанная в пакете MS Visio. Принадлежность столбца таблицы первичному и/или внешнему ключу помечается, соответственно: PK – первичный ключ и FK – внешний ключ. Стрелка связи показывает направление от дочерней таблицы к родительской таблице.
Рис. 8. Даталогическая схема базы данных
Показанные выше обозначения, принятые в пакете MS Visio, не являются общепринятыми и в других пакетах применяются другие графические индикаторы свойств связей и полей.