Нормализация данных

Нормализация данных является самым ответственным этапом, поскольку неправильная нормализация приводит к непредсказуемым результатам работы информационной системы.

Нормализация данных состоит в анализе исходной информации с целью выявления количества типов объектов, сведения о которых необходимо хранить в базе данных, и установлении перечня свойств объектов каждого типа. По результатам нормализации определяется необходимое число таблиц базы данных, а именно, для каждого типа объектов должна быть своя таблица, полями которой являются свойства объектов данного типа. Нормализация должна выполняться в соответствии с требованиями правил нормализации (нормальных форм). Чтобы понять технологию их использовангия рассмотрим следующий пример.

Пусть необходимо создать информационную систему для некоторой фирмы, торгующей кондитерскими изделиями, клиентами которой являются организации. Фирма ведёт учёт своей деятельности, фиксируя следующую информацию о заказе:

Номер заказа;

Дата заказа;

Наименование клиента;

Адрес клиента;

Название продукта;

Цена продукта;

Количество продукта;

Стоимость заказа.

В целях упрощения анализа и уменьшения объёма излагаемого материала будем считать, что клиенты заказывают каждый раз только один продукт и что цена на продукты не меняется во времени.

Первое, что нужно сделать – это определиться с целью создания базы данных и кто ее будет использовать для того, чтобы определить поле, с которым будет связан однозначно первичный ключ. Очевидно, что эта база данных нужна для получения оперативной информации о доходах, получаемых при выполнении заказов, что зависит от работы с клиентами. Поэтому первичный ключ будет связан с полем Наименование клиента. После этого надо выполнить второе требование первой нормальной формы. Так как поля Наименование клиента и его адрес однозначно связаны с первичным ключом и один и тот же клиент может делать два и более заказа, то поля Код клиента, Наименование клиента, Адрес клиента выделяет в отдельную таблицу, которую назовем Клиенты. Оставшиеся поля образуют вторую таблицу, которую назовем Заказы. Так перечисленные три поля исключены из исходной таблицы, то во второй таблицы надо предусмотреть поле, с помощью которого можно получить информацию о сделанных заказах клиента. Очевидно, что это поле должно содержать в себе значения первичного ключа и эти значения будут повторяться. Имя этого поля может быть любым, для простоты назовем его Код клиента. Очевидно, что эти две таблицы связаны отношением один-ко-многим.

Вторая таблица не находится в первой нормальной форме, так как у нее нет первичного ключа. Так как эта таблица находится со стороны многие, то для нее нужно создать составной первичный ключ. Его образуют поля Код клиента, Код продукта и либо Номер заказа, либо Дата заказа. Выберем – Код клиента, Код продукта, Номер заказа.

Обе таблицы находятся в первой нормальной форме. Приведем их ко второй нормальной форме. В соответствии с ее условиями кандидатом для такого анализа будет вторая таблицы, так как только она имеет составной первичный ключ и только для нее имеет смысл искать частичные функциональные зависимости между элементами составного первичного ключа и не ключевыми полями. Здесь также легко заметить, что поля Наименование продукта и Цена продукта будут определяться только полем Код продукта, но не полями Код клиента и Номер заказа. Поэтому эти данные могут повторяться и их надо исключить в отдельную таблицу, которую назовем Продукты. Между таблицами Заказы и Продукты по полю Код продукта будут отношения один-ко-многим.

Итак, в нашем случае мы имеем объекты трёх типов: клиент, продукт, заказ.

После определения количества типа объектов и выявления их свойств осталось попробовать уменьшить объём хранимой информации, так как чем меньше объём базы данных, тем быстрее будет работать информационная система. В нашем случае единственная возможность сделать это – исключить из свойств заказа его стоимость. Действительно, стоимость заказа определяется произведением цены продукта на количество и, следовательно, всегда может быть вычислена, если в этом возникнет необходимость.

Итак, в результате нормализации мы выяснили, что база данных содержит три типа объектов: клиент, продукт, заказ. Эти объекты обладают следующими свойствами.

Таблица 1